Estimaciones, el eterno desafío
La estimación, ese desafío omnipresente en la vida de cualquier equipo de desarrollo de software. Los desarrolladores suelen sentirse abrumados por el temor de asumir compromisos al proporcionar fechas estimadas.
¿Cuál es el problema inherente a las estimaciones? En sí mismas, las estimaciones no son problemáticas. El inconveniente surge cuando no se manejan adecuadamente las expectativas de quienes reciben la información. En un entorno determinista, donde la incertidumbre es baja, las estimaciones son valiosas, ya que ofrecen un alto grado de fiabilidad y facilitan la planificación.
Estimar en un mundo tan complejo como el del software, como exploramos en este artículo, presenta desafíos particulares. La complejidad introduce numerosas variables desconocidas, lo que convierte nuestras estimaciones en poco fiables. Además, cuanto más intentamos prever a largo plazo, menos confiables son nuestras estimaciones, tal como ilustra el cono de incertidumbre.
¿Significa esto que nunca podemos estimar? En realidad, en el mundo de Scrum, sí estimamos, ¡y lo hacemos frecuentemente! Sin embargo, en lugar de intentar estimar todo al principio, lo hacemos cada vez que comienza un Sprint, con un horizonte temporal de unas pocas semanas. Si deseamos prever el futuro de nuestro producto a más largo plazo, esperamos hasta tener evidencias sólidas. Esto implica que, a medida que acumulamos experiencia, podemos empezar a planificar a más largo plazo, reduciendo así la incertidumbre.
¿Son las estimaciones propensas a errores? A menudo escuchamos en equipos de software la frase «nos equivocamos con la estimación». Sin embargo, esta afirmación parece incorrecta. Nadie se equivoca al hacer una estimación, ya que, por definición, es una predicción del futuro y, como tal, puede ser incorrecta. Las estimaciones se basan en la información disponible en ese momento, y es normal que, al enfrentarnos a la realidad, descubramos que nuestras estimaciones no eran precisas. Pero no deberíamos frustrarnos por ello.
Otro problema común con las estimaciones es cuando se ven influenciadas por las demandas comerciales. Frases como «esto debe estar listo antes de Navidad, ahora estima cuánto tomará» pueden ser perjudiciales para el desarrollo de software. En tales casos, trabajar para entregar la mayor cantidad de software valioso antes de la fecha puede ser más sensato que realizar estimaciones poco realistas.
Lecciones aprendidas son parte integral del proceso de construcción de productos. Sin embargo, si somos realistas y proporcionamos estimaciones elevadas, existe el riesgo de que los clientes opten por otro proveedor. A veces, tomamos la decisión de reducir la estimación y luego intentamos «arreglarlo con la gestión», lo cual suele ser un dolor de cabeza y desvía el foco de lo importante: generar valor.
¿Cuál es la alternativa a las estimaciones? Con el tiempo, he llegado a la conclusión de que no hay una técnica única y correcta para estimar. Tradicionalmente, se ha adoptado un enfoque de «Gestión Basada en Estimaciones», lo cual puede ser riesgoso en un entorno donde las estimaciones son inherentemente poco fiables. En cambio, abogo por un enfoque de «Gestión Basada en Evidencia», que se apoya en la experiencia y el método científico. Este enfoque implica comenzar temprano, aprender continuamente y mejorar basándonos en la evidencia acumulada.
Scrum, concebido con este pensamiento empírico, funciona bien cuando las estimaciones no dominan el día a día. No sugiero que los equipos prescindan de las estimaciones, pero tampoco deben obsesionarse con ellas. Muchos equipos de desarrollo responden «estimar» cuando se les pregunta acerca de una Sprint Planning en Scrum, cuando la respuesta debería ser «planificar». En Scrum, la velocidad se utiliza como un indicador para prever el futuro del equipo, basándonos en datos reales acumulados hasta la fecha, no en estimaciones.
Para obtener más información sobre la «Gestión Basada en Evidencia», puedes consultar este documento publicado por Scrum.org. En futuros posts, intentaré profundizar en este tema, ya que el software exitoso se basa en la experiencia, no en ilusiones creadas con estimaciones en el aire.
¿Y tú, cómo gestionas tus equipos de desarrollo de software?
0 comentarios