Más debate (ya al más alto nivel) sobre #NoEstimates McConnell y Ron Jeffries
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)