Al final, el tema del hasghtag de #NoEstimates hay ido calando y calando, para gusto de unos y desacuerdo de otros, pero hemos de reconocer que falta de popularidad no se le puede criticar y que se está convirtiendo en un punto central para los amantes del debate sobre las estimaciones, como es mi caso. A mí, el tema de las estimaciones, desde siempre, me ha apasionado, así que, para los que hemos estado metidos en este tema desde hace años, seguir de primera mano este nuevo debate fresco sobre el tema es todo un lujo.
El último en sumarse a dicho debate a sido uno de nuestros autores de referencia en estás páginas… McConnell. Hace unas semanas el amigo Pablo @psluaces me dio el aviso de que McConnell (recuerda, autor de Software Estimation: Demystifying the Black Art, Por qué dicen que Code Complete es el libro de ingeniería del software más vendido o Rapid Development) se sumaba al debate del #NoEstimates y, en este caso, desde un punto crítico.
Y, por si fuera poco, como contra réplica a los argumentos de McConnell estaban los de Ron Jeffries, uno de los precursores del #NoEstimates (además de ser uno de los creadores de eXtreme Programming y uno de los firmantes del manifiesto ágil), con el que tuve la suerte de hablar un rato en persona sobre este tema en el Agile 2015 Washington D.C. #Agile2015.
Así que, como no podía ser de otra manera, en estos días tranquilos de agosto he ido tirando del hilo sobre este último debate. Ambos autores han ido escribiendo post en forma de replica y contra réplica, dejando argumentos muy interesantes sobre un tema al que parece que le queda mucho para que exista una postura única (como pasa con cualquier tema interesante, por cierto).
Por cierto, antes de empezar con lo que viene más abajo, si no conocías el tema, te recomiendo leer ¿Tiene sentido estimar? Quizá no deberíamos estimar proyectos #NoEstimates explicado o Un proyecto ágil se guía por valor no por estimación (más sobre #noEstimates)
El primero que empezó fue McConnell, con el vídeo que puedes ver más abajo, en el que en unos 12 minutos explicaba su visión del #NoEstimates.
Yo te recomiendo ver el vídeo, pero si no lo vas a hacer, te destaco que uno de los puntos que más se ha debatido es una conversación entre un, digamos, albañil y una pareja que quiere rehacer su cocina por 30.000$, y en la conversación tratan el tema de “estimar o no estimar”.
Si McConnell subió su vídeo a YouTube un 30 de julio… el 31 ya tenía un post de réplica de Ron Jeffries.
El post de réplica de Ron
El post de réplica de Ron es bastante largo, pero te sintetizo que critica el ejemplo del albañil de cocinas, ya que, como comenta, en el escenario de construir una cocina propuesto por McConnell la pareja tiene un presupuesto y el albañil parece ignorarlo, lo cual, en palabras de Ron, es malo.
Ron comenta que #NoEstimates persigue que hagamos decisiones del tipo: ¿qué queremos? No cuánto va a costar sino qué, dentro de este presupuesto, ¿qué es lo que queremos? Las mejores respuestas para construir la cocina no vendrán de la estimación, sino de colaborar, desde la construcción, desde un entendimiento común de lo que podemos conseguir para el presupuesto disponible.
Otra de las críticas es un clásico: los problemas que ha traído al mundo del software compararse con la construcción de cosas físicas, en este caso la construcción de cocinas. Quizá recuerdes aquel post del 2011 de Dos razones por las que fabricar software no es lo mismo que fabricar coches o construir casas.
También expone el cambiar el ejemplo, enfocándolo de la manera: “Tengo un presupuesto de 30000$ cómo podemos invertirlo de la mejor manera”. Y propone dividir el proyecto en áreas, no hacer la cocina por completo sino dividirlo por áreas de construcción.
El post de Ron es más largo, pero no es cuestión de alargar este ya largo post, creo haberte destacado lo más importante en los anteriores.
La réplica de McConnell
Pero el tema no termina aquí, como respuesta al post de Ron aquí tienes el de McConnell.
En su respuesta, también bastante larga, que me voy a atrever a resumir, McConnell dice que le gusta la idea de dividir el proyecto en pedazos y la idea de presupuestar cada pieza individualmente. Pero.. ¿qué hace que sea posible desglosar el proyecto? ¡haber estimado!
Respecto a las comparaciones del mundo físico (cocinas) con el software, McConnell dice que es una cortina de humo. Sí, hay componentes físicos de una remodelación de la cocina y hay muy pocos o ningún componente físicos en la mayoría de los proyectos de software. Así que esa es la diferencia. Pero incluso con más componentes físicos en una remodelación de cocina, el costo de la mano de obra es un factor importante en los costes, así como es en el software, el coste laboral es la principal fuente de incertidumbre y riesgo en ambos casos. La presencia de incertidumbre y riesgo es el factor que hace interesante la estimación en ambos casos.
Igualmente, el post de McConnell es más largo, pero no es cuestión de alargar este ya largo post, curiosamente, ninguno responde al otro con comentarios en su post sino que escribe otro de respuesta en su propia página.
Una más
La cosa no termina aquí y el 1 de agosto Ron lanza una respuesta a la respuesta de Mcconnell. La respuesta habla un poco más de lo mismo, con argumentos de más nivel de detalle y que por no alargar el post, y porque creo que lo más importante está dicho, te la dejo en el anterior enlace por si este debate te ha llegado al alma y no puede dejar de leer sobre ello.
Como ves, múltiples posturas al más alto nivel de un tema que lleva acompañando al mundo del desarrollo software desde que tiene nombre y que aún hoy está más vigente y de moda que nunca. Disfrútalo (que para sufrirlo ya tendrás tiempo)
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
Hola a todos,
Yo opino que si tengo que cambiar mi cocina y me viene un albañil y me dice que cuánto dinero tengo para empezar a ver hasta dónde llega la reforma, pienso que me engañará. Así que posiblemente nunca le diga el dinero que tengo sino que le diría lo que quiero y que me fuera diciendo precio.
Claro que si el albañil es de confianza, pues la negociación es diferente.
Y entonces entra en juego lo que para mi es clave en todo este asunto. Y es la confianza.
Sin confianza en un tercero, cómo te vas a fiar de sus buenas intenciones y de que no te va a engañar? Si es hasta muy probable que el account manager con el que tratas no esté en la compañía para el día que vayas a reclamar…
Es una utopía el pensar que el albañil será muy bondadoso y por el bien de todos va a poner todas sus buenas intenciones para darte lo más que pueda con el dinero que tienes. Por norma general, el albañil va a intentar terminar lo antes posible y llevarse lo más que pueda. Y más sin confianza.
Y oigo mucho acerca de que la tecnología no es lo mismo que la construcción. Y en cierta forma estoy de acuerdo en algunos aspectos de tal distinción. Pero esto del #NoEstimates ya creo que es tirar demasiado de la cuerda y vivir en un mundo de fantasía e ilusión.
Pero en esa comparación construcción-tecnología, al albañil al menos le estoy viendo la cara. En este mundo, al que ves en la negociación es posiblemente a una persona trajeada y no tienes idea de cuáles van a ser los albañiles, arquitectos, diseñadores, testers, analistas, controladores(no JP)…
Estoy de acuerdo en el cambio para la mejora continua. Pero el cambio con sensatez y acorde a los riesgos
Saludos.
De hecho, hay un post más de Ron Jeffries, altamente recomendable: http://ronjeffries.com/articles/015-aug/est-mcc-again/
Hola Javier,
muy buen artículo. Creo que vale la pena explorar bien este tema, para contextualizar bien dónde es recomendable usar el #NoEstimates, huyendo de los debates «Flame» que abundan en nuestro sector. Que dos «vacas sagradas» como McConnell y Jeffries discutan sobre el tema remarca que no es una trivialidad.
El ejemplo de la cocina me parece adecuado, pues tiene un presupuesto no trivial (30.000$) y enmarca el factor más importante, la implicación del cliente. En un extremo tenemos «implicación 0» y un técnico que tiene que hacer un presupuesto (probablemente saldrá mal, ponga buena o mala fé). En el otro tenemos la «implicación 100», donde el cliente está dispuesto a analizar con el proveedor, punto a punto lo que se va a hacer, y colabora en las decisiones. Optar por estimar o no sin consensuar este enfoque de colaboración no tiene sentido, el cliente tiene que entender su responsabilidad. Tanto un presupuesto «cerrado» como uno «abierto/ágil/bla-bla» sin implicación del cliente tienen mucho riesgo. Un presupuesto, pre-análisis, sprint 0, oferta comercial, etc. bien hechos bajan mucho este riesgo, porque permiten «descubrir» el trabajo que hay que hacer y sientan las bases para una colaboración posterior en su ajuste. Scott Ambler insiste en esto en su framework DAD. Yo he visto bastantes «ofertas ágiles» con un anàlisis inicial muy pobre que son en esencia una bolsa de horas, sin riesgo alguno para el proveedor.
Los #NoEstimates son perfectos para colaboraciones estables y con confianza, con pequeños paquetes de trabajo donde la estimación no aporta un beneficio (ni identificando el coste ni posibles riesgos técnicos que den información relevante para el cliente). Esto son mantenimientos evolutivos, equipos de «componente» que dan soporte a otros equipos, etc. Lo explica muy bien David Anderson en su libro Kanban.
Yo creo que nunca se llegará a una postura unitaria por dos razones: 1) hay y habrá diferentes filosofías sobre el tema, y 2) hay contextos muy diferentes donde tiene sentido hacer las estimaciones por los beneficios que aportan. Eso sí, discutir sobre el tema siempre nos da más criterio.
¡Buen verano!
Àlex Ballarin – itnove.com