Estimar, predecir el futuro, es como un arte. Hay muchas técnicas para respaldar a las estimaciones con complejos cálculos matemáticos y estádisticas, orientadas a que la gerencia quede feliz - siempre está bueno si podemos mostrar datos de algo y resumirlo en un único número (¡42, obvio!). Pero esto sólo sirve para darle una aparente legitimidad a lo que en realidad es un montón de dudas.
Los equipos ágiles tienen varias técnicas para estimar historias. Como me dice mi doctor, "tantas soluciones significa que ninguna es muy buena"...
El ABC de la estimación
- Estiman todos los contribuyentes.
- Descomponer las historias en tareas para verificar el alcance.
- Llegar al consenso con Planificación de Poker.
- Disminuir la granularidad a medida que se incrementa al tamaño de la historia.
- Estimar en tamaños relativos.
Predecir el futuro con estimaciones es prepararnos para un fracaso inminente. Cuando estimamos, siempre estamos equivocados. Siempre. Es sólo una cuestión de qué tan equivocados estamos. Y está bien - podemos mejorar con el tiempo, y el negocio siempre le encuentra valor a las estimaciones. La repetición y la familiaridad con las tareas pueden mejorar drásticamente el margen de error.
El mejor consejo: ¡comenzar simple! Estas cinco guías nos pueden ayudar a abrinos camino en las estimaciones:
- Estiman todos los contribuyentes. No sólo estima un representante de los desarrolladores y el líder del equipo, y obviamente que NO estima el cliente o quien pida el requerimiento (¡que bizarro!). Estiman quienes van a trabajar directamente con la historia. De otra forma no tiene sentido.
- Descomponer las historias en tareas para verificar el alcance. Este ejercicio ayuda a verificar si se comprendió bien la historia, y a menudo genera discusiones sobre cosas que podrían impactar en la estimación. A veces una rápida descomposición en tareas le permite al equipo darse cuenta que la historia era mucho más grande de lo pensado.
- Llegar al consenso con Planificación de Poker. Esta técnica de estimación basada en Wideband Delphi es una forma divertida, colaborativa y rápida para llegar a un consenso en el equipo. Se muestran las cartas, si todos están de acuerdo o muy cerca, se selecciona el tamaño y se avanza. Si no hay acuerdo, se debate por unos minutos y se vuelve a probar. Si todavía hay desacuerdo, se avanza hacia la siguiente historia y se vuelve más tarde a intentar.
- Disminuir la granularidad a medida que se incrementa al tamaño de la historia. No podemos estimar las cosas de forma precisa. A medida que la historia se hace grande, más de un par de días, incluso una diferencia de un día es muy poco. "¿Es una historia de 6 ó 7 días?" Ufff, como si importara. Hagámosla y nos enteramos. La serie de Fibonacci es un clásico entre los equipos ágiles. Una historia que el equipo piensa es de 6 seguramente no se va a completar en 5 días, así que elegimos 8.
- Estimar en tamaños relativos. Hay mucho debate sobre este tema, pero lo cierto es que el tamño no se degrada en el tiempo, y no varía dependiendo de las habilidades del desarrollador. Los días calendario si. El libro Agile Estimating y Planificación de Mike Cohn tiene mucha más información adicional y diferencias entre estos dos enfoques.
