Digamos que tengo un Epic que se estima que toma 3 sprints para hacer.
Y Epic se divide en tareas/historias de usuario de la A a la Z.
El problema es que, para hacer B, necesitamos A, para hacer C necesitamos B, etc. Y en el sprint uno, solo completamos A a E,
y no creo que se pueda clasificar como "Terminado/Terminado" dentro de un sprint, ya que esa funcionalidad no se puede probar porque rompe la funcionalidad existente, ¿cuál es la mejor práctica para tal escenario?
P.ej.
1) Epic = Renovación de la funcionalidad Super Calculator.
2) La calculadora tiene la funcionalidad Calcular A, Calcular B para Calcular Z y un resultado final.
3) Debe hacer Calcular A para hacer Calcular B, ya que Calcular B requiere el resultado de Calcular A, etc. hasta Z.
4) La calculadora existente tiene de la A a la Z, pero todas sus reglas han cambiado.
5) El resultado final de la calculadora es incorrecto si solo se cambia Calculate A to B, ya que C existente se romperá.
6) Se pueden probar unidad por unidad, pero los probadores no pueden registrarlos ni probarlos en la interfaz de usuario y no se pueden definir como hechos, ya que la versión no debe incluir cambios parciales, ya que los clientes están usando la calculadora.
Dichos escenarios están afectando nuestro gráfico de trabajo pendiente por sprint y los jefes se quejan, de ahí esta pregunta.
Salud
El objetivo de un sprint suele ser completar una o más funciones visibles para el usuario. Sin embargo, ciertamente hay proyectos en los que esto no siempre es posible. Puede valer la pena volver a evaluar si esto es posible en su situación.
Por ejemplo, las matemáticas sin duda respaldan el concepto de subexpresiones, por lo que cada sprint podría tener el objetivo de completar una o más subexpresiones. Podrías demostrar la ejecución exitosa de cada una de las nuevas subexpresiones durante tus Sprint Reviews.
Si su software se diseñó de manera no modular y las características no se pueden reemplazar de forma incremental, aún puede desarrollar nuevos módulos junto con los antiguos y mostrar esos incrementos en cada sprint. Luego tendrá una gran historia de usuario de "intercambio" al final de su proyecto, donde tendrá algún tipo de transición a los nuevos módulos, pero ciertamente es una opción en algunos casos.
Siempre puede ajustar la duración de su Sprint para asegurarse de tener el tiempo adecuado para ofrecer características funcionales. Si bien la mayoría de los proyectos de Scrum varían entre 2 y 4 semanas por sprint, también he visto proyectos con sprints de 90 días, pero la metodología aún requiere que cada sprint cumpla con un Sprint Goal y entregue al menos un elemento de Product Backlog para se un éxito.
Si su proyecto realmente tiene valor cero a menos que todos los elementos funcionen completamente, entonces Scrum o cualquier otra forma de desarrollo puramente iterativo no es el enfoque correcto. Por ejemplo, si está reescribiendo una pieza de software que está demasiado acoplada para reemplazar una pieza a la vez, entonces los beneficios del desarrollo iterativo no son obvios.
Es posible que desee considerar Kanban, Lean o incluso el desarrollo en cascada tradicional si no puede ofrecer ningún valor a los usuarios hasta el final del proyecto. Un automóvil no se puede conducir con una sola rueda; a riesgo de una analogía defectuosa, tal vez su proyecto de software tampoco pueda usarse sin el 100% de todas las piezas nuevas en su lugar.
Personalmente, creo que todos los proyectos se pueden refactorizar en proyectos de valor incremental, pero eso puede requerir una reingeniería completa del plan del proyecto y del proceso de gestión del proyecto. Si eso simplemente no es posible por razones políticas o prácticas, entonces debe buscar una metodología basada en algo más que características incrementales.
Si puede, cree un adaptador de compatibilidad con versiones anteriores desde el módulo E que acaba de terminar hasta el módulo F heredado. De esta manera puedes modificar el flujo de cada sprint, reemplazando módulos antiguos y colocando un adaptador al final, para que el resto de módulos sigan recibiendo los datos de la forma en que los esperan.
Todd A. Jacobs