Las estimaciones son un desafió cotidiano para muchos equipos de desarrollo de software pero curiosamente hay mucho material y de larga data sobre este tema. Sin embargo cada vez que me cruzo con equipos y personas que tienen dificultades para hacer estimaciones precisas, les pregunto si estudiaron el tema y la respuesta que suelo obtener es: no. Es como que mucha gente se resigna a que sus estimaciones sean muy imprecisas o esperan que mágicamente sus estimaciones mejoren.

Más allá del comportamiento de «la gente» hay que destacar un punto ¿que es lo que nos enseñan en la universidad sobre estimación? En mi caso tuve 1 clase sobre estimación y fue 100% teórica. Lo único que saqué de esa clases fue una lista de nombres de métodos de estimación, pero sin siquiera entender seriamente las diferencias entre ellos. Más aún, nunca en toda la carrera tuve un ejercicio específico de estimación.

Obviamente con esa formación escasa, yo también tuve dificultades con las estimaciones, pero en un momento decidí estudiar el tema seriamente y eso me ayudó mucho. Estudié diversos métodos de estimación y los puse en práctica. Conté puntos de función, utilicé software de estimación (como Construx Estimate), CoCoMo, Planning Pocker, Dephi (y sus variantes), estudié probabilidad, estadística y otras N yerbas relacionadas. Y hasta escribí un capítulo de un libro sobre estimaciones. Hoy en día estoy muy conforme con mis estimación ya que tengo un desvió menor al 10%.

Analicemos la cuestión un momento. El problema parece ser que uno estima que algo llevará tiempo TE y se pone a hacerlo y termina llevando TR, siendo TR >> TE. Ojo si fuera TR << TE, la estimación también sería «mala». Lo que uno pretende es que TE ~ TR ¿hasta que punto es aceptable la diferencia entre TE y TR? Dependen del contexto y del objetivo de la estimación. Pero eso será tema de un futuro artículo, ahora voy a referirme a cuestiones más generales.

A mi parecer en la gran mayoría de los casos la situación es que el tiempo real es bastante mayor al tiempo inicialmente estimado (TR >> TE), pero en mucho casos el problema no está en la estimación sino en la ejecución. Muchas veces no nos dedicamos de lleno a la tarea sino que mientras hacemos la tarea seguimos viendo twitter, o contestando mail, o leyendo whatsapp. También es común que aparezca alguna otra tarea imprevista de mayor prioridad y entonces dejamos colgada la tarea X. Este «task switching» es extremadamente perjudicial y termina impactando en el tiempo real que nos lleva la tarea sobre todo si no llevamos un registro de las interrupciones.

Más allá de la precisión de la estimación, gran parte del problema radica en la ejecución.

¿Cómo podemos hacer entonces para mejorar la ejecución? Para mi aquí hay dos puntos claves:

• Llevar registro de las tareas, los tiempos y las interrupciones para tener números concretos que nos muestren como es la realidad
• Planificar el trabajo en pequeños incrementos, procurando que en principio ninguna tarea exceda un par de horas de trabajo.

Planificar el trabajo en pequeños incrementos ayuda a disminuir las interrupciones y mejorar la ejecución

Volviendo al tema concreto de la estimación, algo concreto que suelo hacer es combinar diversas técnicas de estimación, pero eso será parte de otro artículo.

Continuará…