Agile Estimation: ¿Que es el cono de la incertidumbre?.
La estimación de costos y tiempos en un proyecto siempre es odiosa, nadie la quiere hacer. Es posible que se postergue en el tiempo el número mágico (cuanto tiempo te vas a tardar). Es molesto dar una estimación por una razón, una estimación es eso, una estimación, lo que representa una medida subjetiva y cambiante. Esto no es sinónimo de una medida, desgraciadamente se entiende lo contrario. En el momento que emites el número mágico, todos los engranajes de la empresa dan por hecho que eso tardaras; tu, basándote en los pocos insumos que puedas tener al inicio del proyecto, estimas un número en días, horas o semanas, acolchonas la fecha para tener un tiempecillo extra por si surge algo. No hay estimación perfecta, y antes de rodear o evitar una mala estimación deberías darla por hecho en la administración de tus proyectos.
El problema de estimar no es exclusivo del desarrollo de software.
Vivimos en un mundo caótico donde no se puede predecir todo, no es un tema de capacidad mental o computacional, más bien es un problema de poca información acerca de un problema. Incluso teniendo gran cantidad de información siempre va a existir un rango importante de error. Un ejemplo de esto es el pronóstico del tiempo o el monitoreo de las tormentas tropicales. Cuando una tormenta tropical se acerca a alguna costa, los científicos emiten un comunicado donde indican la posible ruta de esta. En ningún momento dan una predicción, solo indican que de acuerdo a sus datos la tormenta podría pasar por determinados puntos.
Conforme pasa el tiempo se hace más claro donde tocara tierra la tormenta o si se volverá un huracán o tifón. Entre más datos tengas sobre un comportamiento determinado, el porcentaje de certeza aumenta y el rango de error disminuye. Este fenómeno se llama: cono de incertidumbre.
¿Qué es el cono de la incertidumbre?.
El cono de la incertidumbre es una tendencia estadística que surge en un sistema medido, donde una estimación se va haciendo más precisa con el paso del tiempo y midiendo continuamente. Las primeras iteraciones de cualquier proyecto va a tener un rango de error que puede ir hasta 4 veces la estimación original. Si estimas que te tardaras 4 meses en un proyecto, teóricamente la duración del proyecto puede llegar hasta 16 meses. ¿Esto significa que debes estimar 4 veces cualquier proyecto?, obvio no. Significa que en el primer sprint o cadencia el rango de error será enorme porque se desconoce la cantidad de trabajo a realizar, la capacidad del equipo para entregar trabajo, el porcentaje de desperdicios o re trabajo que será necesario. En el siguiente sprint empiezas a conocer la cantidad de las variables que mencione anteriormente, por lo tanto, estimando el número de items entregados contra el número de items faltantes puedes obtener un número más fiel a la realidad. Con cada iteración la medida se hará más precisa.
Usa el cono de incertidumbre a tu favor.
Cualquier persona que esté involucrada en el desarrollo de software entiende o sabe del fenómeno del cono de incertidumbre, comúnmente se asocia los cambios en las estimaciones como ineptitud o pereza por parte del equipo. En parte es culpa del equipo de desarrollo, la mayoría de los equipos de desarrollo no se toman el tiempo de recolectar información que demuestre en que se está gastando el esfuerzo del equipo. Con números en la mano, y conociendo las tendencias puedes ir con los interesados del proyecto y convencerlos de que no se deben de tomar las primeras estimaciones muy en serio, a partir del tercer o cuarto sprint ya podríamos hablar de una estimación apegada a la realidad. Bueno, eso está es una posición muy romántica, lo sé. La fecha de despliegue suele ser no negociable.
¿Qué hago con los proyectos con fecha pactada?.
Un proyecto con una fecha fija es un problema si las características a entregar no son negociables. Un proyecto con fecha fija, características fijas y no negociables, y con poco tiempo de desarrollo es crónica de una muerte anunciada. El rango de acción en un proyecto con fecha pactada está en la negociación de las características. Una estimación apegada a la realidad puede ayudarte a medir cuantas características podrán entregarse llegada la fecha de despliegue. Con un número en mano puede llegar con tus product owners y negociar que va y que no va en la fecha de despliegue.
Conclusiones.
Es un pecado no medir ni estimar en un proyecto, está bien que tus estimaciones fallen, lo que no está bien es que te quedes en la ilusión de las estimaciones y jamás te muevas hacia las mediciones. El cono de la incertidumbre es tu aliado a la hora de comunicar los riesgos e implicaciones en el desarrollo de un proyecto.
Autor imagen: Joaquín Martínez
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20