Estimar es como pesar melones
Y a veces no es timar
En los últimos años ha surgido una tendencia en el desarrollo de software que intenta huir de estimar, es un tema que comenzó con el #NoEstimates de Woody Zuill (uno de los primeros impulsores del Mob Programming) y del que se ha hablado mucho:
- Estimar es timar: Example Mapping by Dani Latorre
- La futilidad de estimar problemas complejos by Simón Muñoz
- Estimar no es timar, pero se le parece mucho by Jerónimo Palacios
- Estimar no es timar by Javier Martín de Agar
Y el hecho de que se haya hablado mucho sobre ello es importante, ya que ha influido en gran manera en la forma en que desarrollamos. En algunos entornos estimar se ha convertido incluso en un tabú que hace que no solo no se estime, sino que se vea como un estigma.
Sin embargo, como algunos de los artículos que he mencionado arriba sugieren, estimar no es del todo timar, pero es indudablemente peligroso. Por tanto, en este artículo os daré mi opinión sobre cuándo es necesario estimar y bajo qué condiciones hacerlo.
Cuándo es necesaria la estimación
Los desarrolladores estimamos continuamente, aunque muchas veces no verbalicemos ni el proceso ni el resultado. Estimamos cada vez que pensamos en cómo vamos a resolver un problema, en cómo vamos a iterar una parte del producto o a crear algo nuevo. El mero proceso de pensar en los pasos a seguir para llegar a nuestro objetivo nos da una idea aproximada de cuánto nos puede costar.
Y este tipo de estimación es esencial y necesaria para el correcto funcionamiento de un equipo que desarrolla software. Una de las claves de éxito de un equipo ágil es la buena priorización de las tareas a realizar. Sin esa estimación que nos indica hacia dónde van los tiros, esta priorización no solo se vuelve complicada, sino que se convierte en un juego de azar.
En este sentido el papel del desarrollador es clave en las planificaciones. En todos los equipos en los que he trabajado ha surgido más de una vez la frase “uff esto es un melón 🍈”, que indica de forma rigurosa la dificultad de la tarea propuesta. Esa frase no es nada más y nada menos que una estimación vaga del esfuerzo necesario para abordar esa tarea. Y ese tipo de estimaciones son necesarias para que luego el PM o responsable de la priorización tome las decisiones de la manera más informada posible.
Cómo de precisa ha de ser la estimación
Cuando situamos al PM frente a un campo de melones la estimación deja de tener significado y vuelve a convertirse en el juego de la ruleta. El coste de los desarrollos deja de tener relevancia y lo que define la priorización pasa a ser exclusivamente el conjunto de estímulos externos que han llevado a consideración cada una de las tareas, haciendo la priorización, por tanto, menos precisa en la visión a medio y largo plazo.
Por eso, los desarrolladores debemos ser capaces de hacer una estimación del peso de los melones tan solo mirándolos (aunque a veces tenemos la oportunidad de acercarnos a tantearlos en forma de spike).
Sin embargo, estimar el peso de los melones no tiene que ser una ciencia exacta ni mucho menos. Para el cometido al que nos enfrentamos basta simplemente con saber qué melones pesan más que otros y qué melones son desproporcionadamente grandes (estos requerirán de consideración extra a la hora de priorizar si son esenciales para el producto).
Qué peligros tiene estimar
Como podréis imaginar, el pesaje de melones usando solo el sentido de la vista es una tarea complicada y queda lejos de ser precisa. Estas restricciones son importantes de tener en cuenta, ya que las expectativas sobre ese pesaje deben quedar claras.
Los problemas vienen cuando nos tomamos demasiado en serio el peso de un melón o asumimos que su medida es más precisa de lo que es. Cuando hablamos de melones hemos de asumir que el peso que le hemos dado es aproximado y que, al igual que los melones de verdad, puede variar con el tiempo.
Por lo tanto, hemos de evitar la zona peligrosa en la que nos comprometemos con una estimación de su peso, ya que apostar todo a un melón nunca es una buena estrategia.
Por otro lado, el tiempo que dedicamos a pesar los melones también puede ser problemático. Si dedicamos más esfuerzos a medir cada una de las tareas del que invertimos resolviéndolas estaremos perdiendo el tiempo.
Y en cuanto al tiempo dedicado, hemos de evitar estimar proyectos completos, ya que como nunca vamos a acertar, todo el esfuerzo que dediquemos a estimar cada una de las partes móviles de un proyecto será esfuerzo perdido.
Cuándo y cómo estimar
Como hemos visto, estimar (osea medir los melones a los que nos enfrentamos) a veces es necesario, ya que cualquier priorización que afecte al medio plazo requiere saber grosso modo cuánto tiempo va a invertir el equipo en cada parte del desarrollo.
Por otro lado, estas estimaciones han de considerarse imprecisas y hay que tener en cuenta que pueden cambiar durante el proceso de creación. Si a mitad de desarrollo nos damos cuenta de que un melón era más grande de lo que pensábamos, podemos actuar en consecuencia y repriorizar si fuese necesario.
Y finalmente, recalco otra vez el tener en cuenta el tiempo que invertimos fuera en el campo midiendo melones. No debe consumirnos el preciado tiempo que tenemos para desarrollar y hemos de entender que cuanto más alcance tenga la funcionalidad o proyecto que estemos estimando, más se alejará de la realidad.
TL;DR
El proceso de estimación en el desarrollo de software es crucial para la buena marcha de un equipo ágil, ya que proporciona una guía sobre la dirección y el esfuerzo requerido en cada tarea.
Sin embargo, estimar no es una ciencia exacta y puede llevarnos a terrenos peligrosos si nos aferramos demasiado a las cifras o dedicamos excesivo tiempo a esta labor. Es importante entender que las estimaciones son aproximadas y pueden cambiar durante el proceso de desarrollo.
Por ello, debemos emplear el tiempo de manera eficiente y ser conscientes de que, cuanto más amplio sea el alcance del proyecto, más imprecisas serán nuestras estimaciones.
En resumen, estimar es necesario en determinadas circunstancias, pero debemos hacerlo con cautela y flexibilidad, reconociendo siempre su naturaleza no exacta y su potencial para cambiar a lo largo del tiempo.