Herramientas Agile: No Estimates; Ventajas y desventajas

Hace unos años nuestro compañero Miquel nos hablaba en un artículo sobre la estimación de los elementos a implementar utilizando “Puntos de historia” y abría la puerta a un nuevo movimiento referente a la estimación: #NoEstimates.

Las Estimaciones Agile como herramienta

Estimar usando Puntos de Usuario es una herramienta y como tal tiene un propósito (en este caso varios) y puede ser usada de muy distintas maneras. En las empresas donde el desarrollo de software sigue una orientación a proyectos clásica, normalmente se requiere una planificación extensiva y cuidada. Se ha visto en esta herramienta la solución para conseguir dicha planificación, mapeando los costes de implementar software con los puntos de historia de usuario junto con la velocidad de entrega.
 
Aunque la adopción de esta herramienta pueda haber ayudado a la comunicación y colaboración entre equipos (o departamentos), existen organizaciones donde la gestión de proyectos de manera “Agile” tan sólo ha cambiado en que ahora en vez de estimar en horas las tareas, se estima en puntos de usuario. Es decir, no ha cambiado nada.
 

Introduciendo No Estimates

Hablando con gente de la PMO, cuando oye por primera vez el concepto #NoEstimates, ves como un sudor frío recorre su alma y lo siguiente son las preguntas: “¿no estimáis? ¿y entonces como planificáis? ¿Cómo sabéis si llegáis a tiempo?” Supongo que estas preguntas son las mismas que hemos tenido todos cuando hemos oído este concepto por primera vez.
 
Antes de nada, aclarar que el hecho de no estimar no significa que el desarrollo del trabajo sea anárquico, sin ningún control sobre el avance y totalmente ciegos a la predictibilidad. Todo lo contrario, la idea de la herramienta de #NoEstimates es de poder ofrecer una predictibilidad lo más aproximada posible.
 
Se basa en que el desarrollo software es, por su propia naturaleza, no repetitivo e impredecible. El producto exacto que se construye es desconocido hasta que está ya desarrollado. Es por esto por lo que no tiene sentido establecer valores estrictos de “dificultad” a los requerimientos de un producto que nos es desconocido, sino que lo que tiene más sentido es considerar que el valor que por nuestro conocimiento previo les asignaríamos es variable, variable dentro de unos márgenes de incertidumbre.

Como lo podemos usar en los equipos para estimar

Se podría parecer a hecho de ordenar un garaje. Tenemos que ordenar un garaje de 20m2, en realidad no podemos saber exactamente el tiempo que tardaremos en ordenarlo. Pues hasta que no abrimos la puerta y empezamos a mirar el contenido de las cajas no sabemos lo que nos encontraremos. A diferencia de las estimaciones relativas, no se trata aquí de si un garaje de 20m2 es 2 o 3 veces más complicado de ordenar que uno de 10m2 sino de si podríamos ordenarlo en menos de una mañana. Lo cual resultaría más sencillo de decidir.
Las funcionalidades no se estiman por comparación entre ellas, sino que se evalúan con una “duración máxima”. Esta duración sería de la mitad de una iteración.
 
En vez de una estimación para cada uno de los elementos del backlog, lo que hacen es para cada elemento preguntarse “¿esto podríamos hacerlo en media iteración?” Si la respuesta es “si”, pasan a evaluar el siguiente elemento. En caso negativo, se buscaría como puede dividirse ese elemento para que los elementos resultantes cupieran en media iteración.
 

No Estimates: Ventajas y desventajas

Esta herramienta, a parte de las ventajas de las estimaciones en puntos de usuario como la comunicación y colaboración entre los miembros del equipo, presenta alguna otra ventaja:

• Ahorro de tiempo en el proceso de estimar:
  • Este es la gran ventaja de este método. Nos focalizamos en la parte más valiosa de las estimaciones que es el diálogo entre los miembros del equipo y no tanto en el detalle de si es un 3 o un 8 o un 13.
  • No entramos en tanto detalle para cada uno de los elementos del backlog.
  • Si queremos estimar el alcance completo de un proyecto, el esfuerzo de estimar un backlog entero es drásticamente mucho menor.
• Ofrece un gobierno del proyecto más real. Dado un tamaño máximo, haber completado el 90% de los elementos estadísticamente es más cercano al 90% del proyecto, que si usamos las estimaciones relativas donde un elemento del backlog podría ser igual de grande que el resto de los elementos de este.

 
Personalmente, le veo una gran desventaja sobre el uso de “No Estimates”. El hecho de romper elementos que exceden del tamaño máximo puede dar lugar a elementos en el backlog que no aporten valor al cliente, o que aporten valor a medias. Podríamos decir que este es el pequeño precio a pagar por un gran ahorro de tiempo y una visión más real del avance del proyecto.