Frecuencia de seguimiento
En el seguimiento de sprints ágiles, según un cronograma establecido, los miembros del equipo ingresan información sobre las tareas en las que están trabajando. Los equipos pueden optar por hacerlo diariamente, semanalmente, dos veces por semana o con la frecuencia que mejor se ajuste a sus necesidades de información. Ingresar la información diariamente garantiza que 1) se registre mientras está fresca en la memoria de los participantes y 2) se actualicen los gráficos y diagramas del proyecto. Muchos equipos realizan el seguimiento una o dos veces por semana hasta la última semana de la iteración, y luego se aseguran de proporcionar información con mayor frecuencia para garantizar la visibilidad diaria durante toda la iteración. Gran parte de esta información también debe comunicarse durante la reunión diaria de seguimiento. Se espera que la revisión de un gráfico de seguimiento reemplace la valiosa comunicación de dicha reunión.
Finalización de características frente a finalización de tareas
Cuando se completan todas las tareas de una funcionalidad, esta se considera finalizada. Algunos equipos también pueden incluir el requisito de que todas las pruebas de aceptación sean superadas.
Preguntas Frecuentes
¿Por qué realizar un seguimiento de una iteración?
Para iteraciones extremadamente cortas, como una semana, la necesidad de medir el estado intermedio disminuye, pero incluso en una iteración de una semana, es valioso comprender si el trabajo está a la mitad de su finalización a mitad de la iteración, así como cuánto trabajo adicional se ha añadido desde el plan inicial. A medida que las iteraciones se alargan, aumenta la necesidad de conocer el estado con precisión.
¿Qué información se registra durante una iteración?
Durante una iteración, se requiere un seguimiento mínimo de la información. Para cada tarea, se debe registrar periódicamente el esfuerzo invertido y la estimación del trabajo restante. También se debe hacer un seguimiento del estado de las pruebas de aceptación. Scrum ignora el esfuerzo invertido para centrar el seguimiento del sprint exclusivamente en las estimaciones del trabajo restante.
¿Quién introduce la información de seguimiento?
Por lo general, cada persona ingresa su propia información de seguimiento. Algunos equipos optan por designar a una sola persona en cada iteración para recopilar y actualizar todos los datos de seguimiento del equipo.
¿Con qué frecuencia los miembros del equipo registran su tiempo?
Cada organización establecerá su propio calendario de seguimiento. Los equipos suelen tener intervalos que van desde diarios hasta semanales, con iteraciones más largas.
¿Deberían modificarse las estimaciones durante una iteración?
Las estimaciones son solo eso: estimaciones. Algunas tareas se completarán antes, otras después, y generalmente se identificarán nuevas tareas. El objetivo es la consistencia y la fiabilidad continuas, no la precisión de las estimaciones. Si un equipo entrega consistentemente el equivalente a 20 días ideales de funcionalidades en cada iteración, lo que suele resultar en una estimación de tareas de entre 200 y 220 horas, entonces esta información es suficiente para planificar y gestionar un proyecto con precisión. Esto puede traducirse en 260 horas de trabajo real por iteración si se realiza un seguimiento. Por lo tanto, no es necesario revisar las estimaciones, dado que se utilizan estimaciones históricamente validadas para la planificación, en lugar de datos reales o capacidad proyectada.
¿Qué ocurre si el esfuerzo restante supera la estimación original de una tarea?
Si esto es cierto, entonces esto es lo que se introduce. En algunas tareas, esto es simplemente una realidad, y el objetivo es representar la realidad mediante el seguimiento de la información, no mediante un ideal o un cálculo.
¿Por qué no se calcula simplemente el esfuerzo restante?
Las cifras calculadas no representan el estado real de una tarea o proyecto; representan un cálculo matemático que históricamente ha demostrado ser poco fiable e impreciso. Para comunicar con precisión el estado de una tarea, los miembros del equipo siempre deben considerar lo que queda pendiente en función de toda la información disponible.
¿Cómo sabes cuándo una tarea está terminada?
Una tarea se considera terminada cuando ya no queda trabajo por hacer por parte de nadie en dicha tarea.
¿Cómo se sabe cuándo una función está terminada?
Una funcionalidad se considera terminada cuando no queda absolutamente ningún trabajo por hacer en ella y ha sido aceptada por el cliente.
¿Qué ocurre al final de una iteración si una funcionalidad solo está parcialmente terminada?
Si una funcionalidad está parcialmente completada, corresponde al cliente determinar si debe dividirse, trasladarse a la siguiente iteración, reordenarse, etc. El desarrollo ágil se considera generalmente binario: o se entrega valor o no. Si se realiza el trabajo, pero no se entrega valor comercial, se considera un proyecto sin valor. Si la funcionalidad puede dividirse, entregando parte del valor durante la iteración actual y parte posteriormente, la decisión final recae en el cliente y el equipo.
