Soy el propietario del producto en un proyecto, que es esencialmente la integración de una nueva tecnología en un producto existente. Un desarrollador externo ha escrito un prototipo y ahora tenemos la tarea de integrar estos cambios en nuestro código base.
Por lo que entiendo de nuestro, esto se trata principalmente de hacer una gran revisión del código y asegurarse de que el código esté en buenas condiciones para la producción. Calculan que este trabajo tomará alrededor de tres meses y tiene muchas dependencias en otros proyectos El trabajo no se ha desglosado a un nivel o forma que pueda expresarse como historias de usuarios.
¿Cuál es la mejor manera de dividir esto en historias de usuarios con un valor que pueda expresar a la empresa y asegurarme de que, en última instancia, el producto brinde valor al cliente final?
Como propietario del producto, me centraré en el qué y el por qué, y dejaré que el equipo de desarrollo se preocupe por el cómo, es decir, la revisión del código, etc. Escribiré 4 epopeyas para cada uno de los siguientes y luego los dividiré en historias y escribiré pruebas de aceptación y resultados esperados:
¿Por qué está integrando la nueva tecnología?: Presumiblemente, tiene un gran beneficio comercial para justificar todo el costo. Esta epopeya y el conjunto de historias deben garantizar que extraigas el máximo ROI (retorno de la inversión).
Esto parece ser una reescritura importante, como volver a cablear un automóvil: desea asegurarse de que todas las características existentes continúen funcionando como están. Debe escribir un conjunto de historias para asegurarse de que todas estas se prueben y validen por regresión.
Usted mencionó 'muchas dependencias en otros proyectos': quiere asegurarse de no romper los otros proyectos.
Requisitos no funcionales: con una reescritura tan importante, también debe salvaguardar los requisitos no funcionales. Esto incluye seguridad, rendimiento, confiabilidad, disponibilidad, portabilidad, escalabilidad, usabilidad, mantenibilidad, etc.
Ashok da una gran respuesta. Para agregar a su #2, estas revisiones de código revelarán la calidad del código. Si bien las regresiones manuales son una buena idea, son costosas y consumen mucho tiempo a largo plazo. Considere pensar en requerir pruebas automatizadas (integración, unidad) como criterio de finalización. Como PO, puede solicitar, en consulta con un Arquitecto o líder técnico, ver un nivel mínimo de cobertura de código automatizado o documentación que demuestre que los flujos comerciales críticos respaldados por el nuevo código tienen casos de prueba y/o pruebas automatizadas en su lugar. También puede solicitar que se documenten los defectos durante las revisiones del código.
Las pruebas automatizadas que ejecutan y prueban con frecuencia las integraciones y la lógica básica son una excelente manera de mostrar/mejorar la calidad del producto y garantizar la longevidad de la solución.