Este es un asunto un poco controvertido en la comunidad, tenemos defensores de los 2 abordajes, los libros de Ken Schawber y Mike Cohn, vemos la recomendación de estimar las tareas en horas, pero ya hace algún tiempo la idea de abrir mas las estimaciones de tareas está creciendo y ganando fans y yo soy uno de ellos en particular. Lo que suele ocurrir es que la planificación del sprint puede ser largo y cansador cuando el equipo tiene que estimar cada una de las tareas que considera son necesarias para desarrollar los temas del backlog, que normalmente se ve son interminables discusiones de si una tarea va a llevar 4 o 6 horas, cuando esta información no es realmente importante a la hora de entregar un elemento rápido.
En mi opinión, es totalmente posible alcanzar todos los objetivos de un sprint, tanto en lo que respecta al incremento de software producido, como en lo que respecta al proceso, y simplificar la planificación, sin dañar en nada a su resultado. En el artículo La cura para la estimación de tareas: ¡no hacerlo más!, Alan Atlas habla muy bien de esto.
Según Alan las dos razones principales por lo que la mayoría de los equipos utilizan las estimaciones de tareas son:
- Crear un compromiso que sea viable para el equipo en términos de incremento de software
- Para crear un gráfico burndown para realizar el seguimiento del progreso del equipo.
Bueno, estos 2 objetivos pueden lograrse sin la necesidad de estimación de las tareas.
El compromiso del equipo sólo puede basarse en la cantidad de puntos de historia que el equipo cree que puede ser entregada en el momento del sprint y a medida que aunque la velocidad del equipo se va estabilizando las estimaciones son aún menos necesarias.
Sin embargo, el gráfico burndown puede pasar de ser basado únicamente en la cantidad de tareas, lo que exigirá del equipo una disminución del tamaño de las tareas, identificandolas más claramente, de modo que el gráfico sólo se actualizará cuando haya terminado una tarea completamente. Además de este cuadro también es interesante utilizar un burndown basado en puntos de historia. Si bien el burndown basado en cantidad da una idea del progreso técnico, el basado en puntos de historia de una idea de progreso mas volcado al negocio.
Creo que las estimaciones de tareas pueden llevar a un microgerenciamiento innecesario y costoso para el equipo y, de hecho, se puede abandonarlos sin perjuicio al proyecto y tornandose la planificación y el seguimiento más simples.
Vos que pensas? Te parece bien las estimaciones de tareas? Te parece que sirven? Te aburren y cansan y ves que no sirven para mucho en lo que respecta al compromiso? Le sirve al equipo de trabajo? Te gustaría llevar dos gráficos burndown?
Basado en Estimar ou Não Estimar
