Sobre #NoEstimates

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.

well-ask-for-estimates

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.

10 comentarios en “Sobre #NoEstimates

  1. Buenas Juanma,

    Antes de nada, felicidades por el artículo.

    Simplemente comentar que casi siempre que tratamos estos temas hablamos del cómo y el qué hacer a la hora de afrontar problemas relacionados con estimaciones.

    Pero hay otros aspectos que juegan un factor muy importante en las planificaciones: cuándo hacerlas, cuánto tiempo guardar para esta actividad y quién debe estar presentes en estas.

    Pecando de reducción al absurdo, bajo mi punto de vista creo que el 90% de los problemas y discusiones relacionados con este tema tienen origen en una planificación hecha demasiado rápida, tanto que no te da tiempo a pensar que tarea es necesaria y que pasos son necesarios para llevarla a cabo, y otras veces se hace influenciada por roles «demasiado externos» al desarrollo.

    Un saludo

  2. Muy de acuerdo con este post. Siempre me ha parecido que, al menos en la mayoría de entornos, no estimar no es una opción. La gente de marketing, ventas, operaciones, etc, necesitan saber cuando se va a lanzar un producto nuevo o esa característica «revolucionaria» que lo va a cambiar todo. Muchas veces sus actividades suceden alrededor de la fecha de lanzamiento, antes y despues.

    En ese sentido, me quedo con este artículo:

    «Mature engineers do not shy away from making estimates, and are always trying to get better at it.’

  3. Creo que estimar no es malo, pero abusar de las estimaciones si lo es, muchas veces se estima algo y después se estima sobre esa estimación y asi muchas veces en un circulo de juntas sin fin donde nadie toca una sola linea de código y simplemente allí se queda todo en ideas, en humo, nadie conecta, ni concreta una sola idea, eso es muy malo y costoso.

    Un gif para amenizar el articulo :D

    http://giphy.com/gifs/3o7TKMIiATSlYZaHte?tc=1

    Creo que todo en exceso es malo, se debe tener un balance, definir estimaciones de mas de un mes es mentir.

    El otro dia vi por alli un bio en github que decia «think more, talk less» y se me ocurrio uno para mi que decia «do more, think less».

    Excelente articulo.

  4. Muy buen artículo e interesante tema.

    Aún tengo que leer más sobre el concepto de No Estimates, pero creo que el mismo ya parte de un mal nombre. Quizás sea intencionado precisamente para motivar la polémica y hacernos pensar sobre el tema.

    Trabajando para clientes y no en producto propio, cuesta imaginar el no estimar cuando la competencia lo hace. Y aun sin competencia, la necesidad de reducir la incertidumbre de conocer los costes de tiempo y dinero de lo que se va a hacer. Incluso si reducimos a tareas pequeñas que prioricemos y entreguemos ASAP.

    Un saludo.

  5. Micael Gallego dijo:

    Muy buen artículo. Gracias por compartir tus reflexiones.

    Me va a venir muy bien para mi clase de priorizacion de historia de usuario del posgrado de agile del IEBS.

  6. eh.. este… yo… :-) Buen tema para debate, y excelente artículo como siempre.

    ¿Por qué dices que la estimación no se puede separar del tiempo?¿Podríamos medir solo el esfuerzo?

    ¿Por qué quieres planificar en tiempo algo que nunca has hecho? (pintar) Eso sería como pedirte que digas un número del 1 al 1.000.000 :-)

    Si te sientan junto a 2 pintores novatos + 2 expertos y les preguntan a todos «¿cuánto esfuerzo os llevaría de forma individual, pintar la pared?» las respuestas podrían ser como estas:

    – Expertos: muy poco
    – Novatos: algo
    – Tú: Mucho mucho mucho.

    Si ahora dedicas un tiempo a que cada uno cuente el por qué de su estimación, seguramente aprenderás cosas que te hagan estimar diferente.

    – No empieces pintando la pared desde abajo :-)
    – El diluyente no es a ojo, tiene su proporción.

    Ahora ya ha pasado un año desde que pintaste tu primera pared y es algo que haces a diario. ¿Necesitarías estimar esfuerzo? Sin pensarlo dirías: «poco». Esto no significa que no puedas equivocarte, porque si llega la hora de pintar y no hay pintura, tendrás que estimar nuevamente tu esfuerzo para incluir «ir a comprarla». La estimación es un elemento que cambia incluso durante el desarrollo de la tarea.

    Fíjate en todas las preguntas que haces en el post. ¿Si hicieras esa actividad todos los días? ¿Si le preguntas a gente que lo ha hecho todos los días? Seguramente tu primera vez serás conservador, tienes datos pero no experiencia.

    – Pillaré tráfico seguro
    – Y ahora quién encuentra dónde aparcar
    – La cola para pasar por caja en el mercado hará que me cueste más

    Luego irás aprendiendo las horas de menos tráfico, el sitio estratégico donde siempre hay un hueco para aparcar, y aprenderás a usar los self-checkout del super. :-)

    ¿Necesitarás una estimación para saber la respuesta después de tener info+experiencia?

    De la X y el «compromiso adquirido», da para otro tema. Pasa como las estadísticas, estas herramientas deberían ser para el equipo y no ser usadas como control.

    PD: No me sabía lo de «camisas de once varas» Gracias por ese «titbit»

  7. Omar,

    Casi siempre que alguien habla de «esfuerzo», en el fondo está metiendo una indirección a tiempo. ¿A qué te refieres con esfuerzo?

    El resto de las cosas que mencionas, en realidad no evitan estimar tiempos, lo que hacen es que, gracias al conocimiento acumulado, puedas tener estimaciones mejores.

    PD: Nunca había oído «titbit». Gracias por esa palabra nueva :)

  8. ¿Podemos decir entonces que el esfuerzo que implica una tarea, será mayor o menor si la haces un martes por la mañana que si la haces un viernes a las 12? :-)

    A la persona en el equipo que le toca hacer una tarea, cuyo esfuerzo se estimó como «bajo», ha tenido un finde fatal. ¿Decimos que aumentó la complejidad de la tarea y que llevaría más esfuerzo porque ha demorado más tiempo en realizarse?

    El esfuerzo para hacer algo es el mismo si todas las dependencias están resueltas. El tiempo que demores puede depender de más factores.

    Sobre el resto de cosas: no estimar no significa que no conlleve un esfuerzo o un tiempo realizar algo, significa que ni siquiera tienes que sentarte a pensar cuánto esfuerzo te llevaría hacerlo.

  9. Como siempre, estamos bastante de acuerdo: Ni tanto ni tan poco. Algunos de los problemas básicos de las estimaciones es que para empezar no se crean como toca y después tampoco se tratan como deben.
    Como mencionas para hacer una estimación estamos hablando de basarnos en cosas parecidas que ya hemos hecho, cuando en multitud de casos la propia velocidad de la informática nos tiene todo el tiempo aprendiendo cosas nuevas, probando técnicas nuevas, los equipos cambian…
    Luego además es que te piden que hagas la estimación antes de saber realmente lo que tienes que hacer, eso entra dentro del plano de ver el futuro, aun más incertidumbre…
    Añádele que después de hacer tú un esfuerzo de realmente estimar como toca, la respuesta que recibes es «uhh, eso es mucho. Además el dia X empieza el evento/curso, u ocurre tal así que tiene que ser para la semana antes» Así que uno piensa, ¿para que hacerlo?
    Y eso sin entrar en las estimaciones ágiles del tipo «no, no, para estimar tiene que participar todo el equipo, poker planning y eso» Donde la estimación de la gente de operaciones o el junior sin experiencia se promedia para sacar tareas de desarrollo y las de los programadores y el de QA para sacar lo que se tarda en montar un entorno de despliegue… de risa.

    El problema es que luego hay que hacer presupuestos anuales, calcular gastos, ver cuanto personal necesitas para hacer los proyectos, saber si tienes que contratar mas o menos gente, y eso es algo que no se puede hacer «por sprint» así que las dos realidades y necesidades chocan frontalmente.

    Si los dos frentes entienden que la cosa está así de chunga y trabajan para minimizar los problemas, más o menos se puede ir lidiando. Si las dos partes se pegan de tortas, típico comportamiento «ellos vs nosotros» pues acaba como acaba la mayoría de veces

Comentarios cerrados.