Guía al movimiento #NoEstimates

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 entregarle, 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.

Relacionado
Cuatro herramientas básicas de un Product Owner

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

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 espititú de #NoEstimates es su Whitepaper, cuyos puntos fundamentales se describen a continuación.

Los cuatro pasos de #NoEstimates:

  1. 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
  2. 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.
  3. Desarrollar cada trozo siguiendo la Definition of Done. El trabajo solo está hecho cuando está en mano de clientes reales.
  4. 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.

Relacionado
Los 10 libros ágiles fundamentales

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 estaimaciones 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.

Avatar for Jerónimo Palacios Vela

Posted by Jerónimo Palacios Vela

Mi misión es ayudar a mejorar la profesión del desarrollo de software. Soy Professional Scrum Trainer de Scrum.org, Accredited Kanban Trainer de Lean Kanban y facilitador de LEGO® Serious Play. Vivo entre Berlín y Granada. Me encantan la vela y el Rugby

Suscribete a nuestra lista de correo

Suscribete a nuestra lista de correo

Recibe actualizaciones en la comodidad de tu bandeja de entrada. Un email a la semana. Sin Spam. Sin Trucos.

Suscripción con éxito

Shares
Share This