Entre las múltiples cosas que hay que reconocer a los agilistas está su facilidad para crear eslóganes pegadizos. El manifiesto ágil es un perfecto ejemplo de ello. En los últimos años, uno de estos eslóganes ha escapado de los más selectos círculos internos hasta llegar al común de los mortales: el #NoEstimates.

Asumo que me puedo meter en camisas de once varas (curioso el origen de la expresión, por cierto) porque otra de las características de la comunidad ágil es su sensibilidad hacia ciertos temas, y más viniendo de los que no tenemos carnet de agilista, pero estoy seguro de que con la discusión algo podre(mos) aprender sobre esto del movimiento No Estimates, sus implicaciones y su viabilidad.

Los múltiples problemas de estimar

Todo el que se haya dedicado alguna vez a desarrollar software conoce los problemas asociados a tener que hacer una estimación del tiempo que se tardará en implementar algo.

Hay mucha literatura al respecto y no creo que sea necesario entrar en detalle, pero es fácil ver que existen diferentes tipos de problemas.

Por una parte, tenemos problemas relacionados con la incertidumbre propia del desarrollo de software que nos impide hacer estimaciones todo lo precisas que nos gustaría.

Esta incertidumbre tiene un componente intrínseco a la propia implementación. Por definición de desarrollo estamos construyendo algo diferente; si no fuera así, estaríamos entregando un producto y no habría nada que desarrollar. Al tratarse de algo diferente, no podemos saber exactamente cuánto vamos a tardar en hacerlo. Esta parte se puede mitigar (en mayor o menor medida) cuando tenemos experiencia previa en desarrollos similares realizados en condiciones similares.

A eso se le une la dificultad para estar seguro de lo que hay que hacer.

Ya no es que no sepamos cuanto tardaríamos en hacer algo, es que muchas veces tampoco estamos seguros exactamente de qué es lo que hay que hacer. Y nadie lo sabe. Ni siquiera quien nos lo ha encargado. Aquí, las ideas ágiles de iteraciones pequeñas, conversaciones continuas, etc., ayudan bastante a tratar con el problema y disminuir la incertidumbre.

Este tipo de limitaciones asociadas al propio proceso de desarrollo en general se llevan más o menos bien y no resultan demasiado dolorosas de tratar. Asumes que te puedes equivocar, ajustas, reorganizas… y al final lo consigues.

Los problemas más desagradables de la estimaciones surgen de la interpretación que hacen otras personas de las mismas.

La RAE ofrece varias definiciones de la palabra estimar, y normalmente cuando a ti te preguntan cuánto tardarás en hacer algo, eres consciente de la incertidumbre de la que hablábamos antes y aplicas la cuarta definición:

4. tr. Creer o considerar algo a partir de los datos que se tienen.

Por desgracia, demasiadas veces tu interlocutor va a entender la primera:

1. tr. Calcular o determinar el valor de algo.

Igual parece una tontería pero el matiz de a partir de los datos que se tienen es muy importante. Tú eres consciente de que te falta información y que con lo que sabes ahora podrías tardar X, pero según vayas obteniendo más información podrás afinarlo más. Para tu interlocutor, vas a tardar X. Punto. La estimación se ha convertido en un compromiso, que si no se cumple no es porque haya cambiado la información disponible, sino porque no has hecho bien tu trabajo.

Dejemos de estimar

En realidad, este tipo de problemas (entre otros) son precisamente los que trata de resolver el movimiento ágil.

La aproximación de No Estimates para ello es limitar al máximo (hasta el punto de eliminar, si es posible) la parte de estimación de todo el proceso. Como explica Ron Jeffries en su post de 2013 sobre No Estimates:

The basic idea, as I understand it, is that it is possible to do small chunks of work incrementally, leading as rapidly as possible to a desired shippable product, and that when you do that there is no need to do much of anything in the way of estimating stories or the project.

Tiene sentido. Si tu objetivo es alcanzar lo más rápido posible un producto entregable, parece razonable trabajar en tareas pequeñas que te lleven lo antes posible a conseguir ese producto. Si haces eso, no hace falta estimar las tareas porque, a fin de cuentas, son las que tienes que hacer para obtener el producto que quieres. Es más importante tener claro qué tareas hay que realizar y en qué orden, y ponerse a hacerlas. Cuando estén, estarán.

Estoy seguro de que hay contextos en los que trabajar de esta forma puede dar lugar a unos resultados magníficos, pero hay muchos escenarios (me atrevería a decir que la mayoría) en los que creo que las estimaciones, bien utilizadas y entendidas como tales, son críticas para poder desarrollar un producto con éxito.

La necesidad de estimar

No nos engañemos, estimar es díficil. Y más cuando manejas tantos grados de incertidumbre como los que mencionábamos antes. Pero aun así, te pasas toda la vida estimando, aunque sea inconscientemente, y sobre cosas de las que tienes aun menos conocimiento.

Por motivos que no vienen al caso últimamente he tenido que «disfrutar» del mundo de las manualidades y hacer cosas que jamás hubiera pensado, como pintar una pared o montar un mueble. No tenía ni idea de eso (ni tengo ahora, para qué engañarnos), pero aun así estimaba tiempos. Lo necesitaba. ¿Cuánto tardo en pintar una pared? ¿Me vale una tarde al salir del trabajo? ¿Reservo el sábado? ¿Todo el fin de semana? ¿Me cojo una semana de vacaciones? ¿Un año sabático? (Nota: para los curiosos, en la reunión de retro ya quedó claro que la solución era externalizar esa parte del proyecto).

Esto lo hacemos continuamente: ¿me dará tiempo a recoger al niño, pasarme por el centro comercial a hacer al compra y ayudarle con los deberes? ¿cuánto tráfico habrá? ¿habrá mucha cola en el centro comercial? ¿tendrá muchos deberes?

Necesitamos tener una idea de lo que vamos a tardar en cada tarea, aunque sea conocer el orden de magnitud que nos puede llevar, para poder organizarnos. La diferencia, claro, es que nosotros somos conscientes de que es una estimación y puede no ser precisa, y normalmente nos dejamos un colchón, ya sea de tiempo extra o de tareas que pueden entrar y salir de nuestra agenda, para tratar de ajustarnos a los imprevistos y a nuestros propios errores de estimación.

Hay situaciones en que esa misma idea se puede llevar al desarrollo de software.

Si no estás vendiendo horas y estás desarrollando tu propio producto (algo que, soy consciente, no es lo más habitual), establecer un marco de tiempo para las funcionalidades que quieres implementar y planificar qué quieres haber conseguido en ese plazo de tiempo, teniendo en cuenta que estás estimando, no comprometiéndote, y que es necesaria cierta flexibilidad en las tareas que se completarán, es perfectamente viable. Implica comunicación fluida, confianza e implicación por parte de todos los afectados (empresa, comercial, desarrollo, etc.), pero puede funciona bien.

Dándole una vuelta de tuerca a esto podríamos pensar: ¿para qué establecer un marco de tiempo? Vivimos en un mundo de continuous deployment con evergreen apps, lo que hay que hacer es aportar valor en cuanto lo tengamos. Y si lo que quiero es aportar valor, lo que tengo que desarrollar es aquello que más valor me aporta. Eso es lo mejor que puedo hacer en cada momento dado, por lo que no hace falta estimar nada: haz en cada momento lo que más valor te aporte y ya está. Volvemos al No Estimates.

Sin entrar en que los marcos de tiempo pueden tener su razón de ser en el mundo real por motivos completamente ajenos al desarrollo de software, el problema para aplicar eso es que no se puede separar valor de tiempo.

Vamos a dejar de lado otro factor complicado como es medir el valor (que ya de por si implica otro tipo de estimación) y vamos a suponer que tenemos una forma completamente exacta de medir el valor que nos aportarán dos funcionalidades, por ejemplo porque tenemos dos potenciales clientes que están dispuestos a pagar por ellas.

Digamos que la funcionalidad A nos puede aportar 100.000 €, y la funcionalidad B 1.000.000 €. En base a eso, está claro, déjate de estimaciones y haz la B que nos reporta 10 veces más dinero.

Ahora imagina que te digo que en implementar la funcionalidad A se tarda 1 hora, y implementar la B se tardan 10 años. Probablemente tu visión cambie y empieces a ver la funcionalidad A más apetecible.

A la hora de decidir qué funcionalidades debemos implementar no pesa tanto el valor como la densidad de valor con respecto al tiempo. Si a eso le unes las restricciones de que ciertas tareas no se pueden partir, decidir qué implementamos en una aplicación es, en el fondo, una variante algo más compleja del problema de la mochila.

Por desgracia normalmente ni sabemos seguro lo que vamos a tardar ni sabemos seguro lo que vamos a ganar, por lo que tomar decisiones no es tan sencillo como en el ejemplo que he puesto.

Conclusiones

La planificación en el desarrollo de software me parece una de las partes más complicadas de tratar porque requiere lidiar con mucha incertidumbre y gestionar bien las expectativas de todos los implicados.

Basarlo todo en estimaciones de tiempo convertidas en compromisos en firme es un error: el foco ha de estar en aportar valor y centrarnos en aquellas tareas que más valor aporten. Esa es la base del movimiento No Estimates, y es un buen objetivo a perseguir, pero en general la propia definición de valor implica hacer una estimación a priori del tiempo y esfuerzo que supondrá llevar a cabo esa tarea.

Por último, no está de más recordar que a la hora de planificar no sólo debemos basarnos en el ratio valor/tiempo, sino que hay factores como el riesgo que asumimos al hacer determinados cambios que también pueden ser muy importantes.

Ser consciente de todas estas variables y del grado de certeza que tenemos sobre cada uno de ellas es clave para tomar decisiones. Siempre vas a tener cierto margen de error (a veces muy grande) y hay que vivir con ello, pero al menos estarás en mejor posición para afrontar los distintos problemas que puedan surgir por el camino.