×
×

#NoEstimates: una barbaridad ágil

Javier Garzás hacía recientemente referencia en su blog al movimiento #NoEstimates, que propugna eliminar las estimaciones de las actividades de desarrollo de software (nuevos proyectos, tareas aisladas como mantenimientos, etc.). El resumen del argumento es que, ya que no es posible generalmente tener requisitos bien definidos y que no vayan a cambiar durante el proyecto, es mejor no hacer estimaciones.

Mi opinión es que es una barbaridad que puede tener una buena acogida en el movimiento ágil, pero que merece la pena rebatir bien. No vaya a ser que alguien se lo crea. Aquí van algunos argumentos:

  1. Las estimaciones son difíciles, pero no son algo que no podamos controlar. El cono de la incertidumbre nos avisa de los márgenes de riesgo en función del esfuerzo puesto en la elaboración de requisitos. Además nos anima a usar herramientas de definición de alto nivel del proyecto, como el Sprint 0 o el uso de maquetas.
  2. Muchos proyectos se estiman con un nivel de confianza aceptable. El Chaos Report 2013 dice que el 39% de proyectos son exitosos y que sólo el 13% son cancelados.
  3. Sin una estimación de alto nivel, por prudente que la tomemos, es muy difícil reunir un equipo y poder dar visibilidad a los clientes. La herramienta Release Burndown requiere de estimaciones previas.
  4. La velocidad (Velocity) permite al equipo anticipar que podrá entregar en el próximo Sprint, mejorando la confianza del Product Owner y realimentando el avance real respecto al estimado.
  5. Finalmente, y probablemente lo más importante: en muchos contextos simplemente no es aceptable comenzar sin estimaciones y la mayoría de los clientes no lo van a admitir. Yo no lo haría con ningún proveedor de ningún sector.

Por supuesto, sí que hay contextos donde no estimar es una buena opción. Uno de ellos es el mantenimiento evolutivo donde llegan un flujo de peticiones, normalmente de tamaño pequeño (p.e. menos de 1 semana) y con bajo riesgo. Lo más importante en la priorización de peticiones suele ser el valor aportado, y hacer una estimación para decidir la prioridad simplemente aumenta el tiempo de entrega (lead time) sin aportar más valor añadido. Se puede ver una buena explicación en el libro Kanban, de David J. Anderson.

Para cerrar el artículo, quería recomendar uno de los mejores libros de ingeniería del SW que he leído, Agile Estimating and Planning, de Mike Cohn. Después de leer el libro parece difícil no poner serias objeciones a este movimiento.

Imagen: Cone of Uncertainty. www.agilenutshell.com/cone_of_uncertainty