¿Alguien puede responder mi pregunta aquí? He estimado de 5 a 6 tareas como análisis (4 horas), diseño (3 horas), revisión lógica (1 hora), revisión por pares (1 hora), prueba unitaria (1 hora), codificación (2 horas) y liberación ( 1 hora). Pero durante el análisis mismo llegué a saber que el resto de la actividad no será aplicable. En este escenario, ¿debo hacer que las horas sean cero para todas las tareas que se han vuelto obsoletas o debo eliminar las tareas?
A medida que se requiere trabajo nuevo, el Equipo de Desarrollo lo agrega al Sprint Backlog. A medida que se realiza o completa el trabajo, se actualiza el trabajo restante estimado. Cuando los elementos del plan se consideran innecesarios, se eliminan. Solo el Equipo de Desarrollo puede cambiar su Sprint Backlog durante un Sprint. El Sprint Backlog es una imagen altamente visible y en tiempo real del trabajo que el Equipo de Desarrollo planea realizar durante el Sprint, y pertenece únicamente al Equipo de Desarrollo.
Por lo tanto, si ha determinado que algunas de las tareas no son necesarias, elimínelas.
@David Arno sugirió enfoques para llenar el vacío en el Sprint. Sin embargo, si esto sucede con frecuencia o si es una parte importante de su Sprint, debería considerar hacer una historia de investigación en un cuadro de tiempo (también conocida como pico) en un Sprint anterior. El mismo análisis, que posiblemente incluya una prueba de concepto mínima, le permitirá planificar con más confianza.
Eliminar las tareas.
Si te encuentras escribiendo las mismas tareas como j-unit, pruebas de desarrollo, etc. para todas tus historias/atrasos, no son tareas, son criterios realizados y se pueden incorporar a una tarea de nivel superior como "implementar XYZ como parte de la solución."
Intente y minimice la sobrecarga asociada con la creación y administración de detalles de nivel de tarea dentro de la iteración si no agrega ningún valor.
El primer punto a destacar es que le sugiero que esté desglosando sus tareas en detalles demasiado finos y esté creando una mini cascada dentro de su sprint. La prueba unitaria y la codificación generalmente se realizan al mismo tiempo, por lo que tener dos tareas separadas probablemente cause problemas. Si adopta principios de TDD, el acto de escribir las pruebas y desarrollar el código es el diseño, etc.
Habiendo dicho eso, sus tareas son las que son. Si una tarea ha hecho que otras sean irrelevantes, entonces, dependiendo de las circunstancias, normalmente harías una de las siguientes:
Si hay muchas otras tareas asignadas al sprint, simplemente elimine las que no sean necesarias. Luego discuta con el maestro de scrum y el propietario del producto si es posible agregar otras tareas (del trabajo pendiente) al sprint.
Si las tareas que se van a eliminar constituyen la mayor parte del sprint restante, informe al propietario del producto que el sprint debe abandonarse y que las reuniones de final/inicio del sprint deben adelantarse y planificarse un nuevo sprint.
Todd A. Jacobs
david arno