Si la semana pasada hablábamos de uno de los movimientos que mas se ha extendido durante los últimos años en entornos de desarrollo de Software, DevOps, hoy toca hablar de uno de los que causan sensaciones encontradas, #NoEstimates.
¿Qué es #NoEstimates?
#NoEstimates es un movimiento. No es una herramienta específica sino una manera de pensar en torno a las estimaciones y previsiones en desarrollo de Software. Su principal promotor es Woody Zulia junto con Vasco Duarte.
La idea es animar a construir pequeñas piezas de software de manera iterativa e incremental que te lleven tan pronto como sea posible a tener un producto entregable, sin dedicar miles de horas a predecir el futuro.
Hay que aclarar que el nombre del movimiento es un poco engañoso. Esto es quizás uno de los aspectos que menos me gustan del mismo. En realidad, #NoEstimates bien podría llamarse #BetterForecasting o #DoScrumRight y estaría bastante más ajustado a la realidad.
Woody Zuill lo describe así:
Hay que dejar de estimar inmediatamente. Poner software en las manos del cliente lo más pronto posible y seguir a partir de ahí. ¿Como funciona esto? Cuando un Manager pregunta por una estimación por adelantado, los desarrolladores pueden preguntar: ¿Cual es la feature más importante?, para luego entregar un prototipo de esta feature en dos semanas. Entregar suficiente software lo suficientemente rápido, con espacio suficiente para tener feedback y poder refinar. Sólo entonces la demanda de previsiones desarparece. Vamos a dejar de intentar predecir el futuro. Hay que hacer algo y luego empezar a construir sobre ello.
Existe una cierta agresividad a la hora de fomentar y promover el uso de #NoEstimates que personalmente no es de mi gusto. Por otro lado, #NoEstimates no es más que «Sigue el Agile Manifesto y entrega Software«. Sin embargo hay más cosas, como el whitepaper y algunos artículos que obligada lectura para entenderlo mejor.
Artículos fundamentales sobre #NoEstimates
El sitio web tiene una visión general de casi todo el material que se ha publicado en torno a este tema. Material muy interesante
- El Whitepaper de #NoEstimates y el libro (todavía no está publicado) de Vasco Duarte
- No Estimates Programming series – Intro Post de Woody Zuill
- Estimates? WE don’t need no stinking estimates
- The #NoEstimates Movement, por Ron Jeffries
- My First, Last & Only Blog Post about #NoEstimates
Si quieres leer más, puedes hacerlo en este artículo de Barry Overeem que resume los artículos citados anteriormente.
El Whitepaper de #NoEstimates
El documento que refleja cual es el espíritu de #NoEstimates es su Whitepaper, cuyos puntos fundamentales se describen a continuación.
Los cuatro pasos de #NoEstimates:
- Seleccionar la pieza más importante de trabajo que necesitas terminar (mayor valor primero). Hay que tener una visión clara y decidir el trabajo más importante. Hay que prioritizar pero también estar listo para cambiar esas prioridades
- Trocear ese trozo de trabajo en partes que no tengan riesgo. Cada trozo debería de ser suficientemente pequeño que si no se entrega de primeras, no va a poner en riesgo los objetivos del proyecto.
- Desarrollar cada trozo siguiendo la Definition of Done. El trabajo solo está hecho cuando está en mano de clientes reales.
- Iterar y refactorizar. Aprender de la implementación anterior y mejorar hasta que refleje la definición de un producto de alta calidad.
Algunos puntos clave
El tema #NoEstimates es controvertido, principalmente porque los seguidores del mismo se han apropiado de una parte del espíritu del Agile Manifestó de una manera casi violenta.
Es fácil encontrar en Twitter discusiones sobre el tema de las estimaciones que acaban en desprecio o incluso ofensa personal. Ese es el motivo por el cual ha quedado tan reducido a unos pocos.
Sin embargo, el tema es interesante una vez que nos olvidamos del nombre o las formas. Las organizaciones están acostumbradas a querer manejar la incertidumbre con previsiones o estimaciones de que va a ocurrir. Sin embargo, si miramos un poco más arriba, veremos que este problema viene desde la propia fundación de las organizaciones. Aquellas que tienen participaciones, demandan saber que va a pasar. Aquellas que son públicas, tienen que responder ante su accionariado.
Por tanto, quizás la solución al problema sea ver cuales son las necesidades de esas organizaciones y buscar una manera de hacerlo mejor. Hay elementos de este movimiento, del cual solamente hay una pincelada en este artículo, que pueden ayudar. Con cabeza y sin agresividad.
[…] así que me puse a investigar a ver en qué consistía y si me aplicaba. Revisé este post de Jero (típico old but gold), de ahí fui al whitepaper original, a la web propia de […]