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 numero 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 numero 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 numero 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, mas 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 pronostico 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 mas claro donde tocara tierra la tormenta o si se volverá un huracán o tifón. Entre mas 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.

¿Que 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 mas 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 sera enorme porque se desconoce la cantidad de trabajo a realizar, la capacidad del equipo para entregar trabajo, el porcentaje de desperdicio o re trabajo que sera necesario. En el siguiente sprint  empiezas a conocer la cantidad de las variables que mencione anteriormente, por lo tanto estimando el numero de items entregados contra el numero  de items faltantes puedes obtener un numero mas fiel a la realidad. Con cada iteración la medida se hará mas precisa.

Usa el cono de incertidumbre a tu favor.

Cualquier persona que este 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 esta gastando el esfuerzo del equipo. Con números en la mano, y conociendo las tendencias puedes ir con los interesados del proyecto y convencerlos 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 esta es una posición muy romántica, lo se. La fecha de despliegue suele ser no negociable.

¿Que 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  esta 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 numero 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, esta bien que tus estimaciones fallen, lo que no esta bien es que te quedes en la ilusión de las estimaciones y jamas 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