Cómo mejoré mis estimaciones

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á…

Combinando métodos de estimación

Quiero compartir un método de estimación que suelo utilizar buenos resultados (buen resultado = estimación muy cercana al resultado real).

Este método es un mezcla de PERT y Wideband Delphi, por ello voy a describir en forma resumida las partes que uso de cada uno de los estos métodos y luego voy a explicar cómo las combino.

Program Evaluation and Review Technique (PERT)

Este método fue desarrollado por la Armada de EEUU durante la década de 1950. El mismo asume que la duración de una tarea obedece a una distribución probabilística Beta y en base a ello propone que cada tarea sea estimada a partir de tres escenarios: optimista, normal y pesimista. En base a esto el tiempo esperado para completar una tarea puede calcularse como:

Tiempo esperado = (optimista + (4*normal) + pesimista) / 6

Si bien el método PERT dice muchas más cosas, esta premisa es la que puntualmente nos interesa.

Wideband Delphi

Este método fue desarrollado por Boehm y Farquhar en la década de 1970. Es un método de estimación grupal basado en la opinión de expertos. Propone que la estimación sea realizada por un grupo de al menos 3 expertos. Se toma como entrada la lista de ítems a estimar, se establecen algunas premisas (como ser unidad de estimación y generalidades relacionadas al contexto como podría ser la arquitectura de base sobre la que se trabajará) y  se procede de la siguiente manera:

  1. Se discute el alcance de cada ítem para despejar dudas y ambigüedades de manera de asegurar que todos los estimadores esten estimando lo mismo.
  2. Cada estimador estima en forma privada.
  3. Se comparten las estimaciones y se analiza la convergencia/divergencia de los resultados. En caso de divergencia, los estimadores explican como fue que llegaron a los valores dados. Para realizar este análisis es común volcar los número en una hoja de cálculo y ver la media y la desviación de los mismos.
  4. Se repiten los pasos 2 y 3 hasta lograr convergencia.

Mi propuesta

Conceptualmente la propuesta es simple, básicamente consiste en aplicar la dinámica de Wideband Delphi pero asumiendo la premisa de PERT y pidiendo por ello que cada estimador brinde 3 valores para cada item. Adicionalmente agrego algunas pequeñas variantes a la dinámica de Wideband Delphi como por ejemplo la participación explícita de un moderador. Esto resulta en el siguiente procedimiento:

  1. Los ítems a estimar se cargan en la planilla del moderador y se le reparte un planilla impresa a cada estimador.
  2. Se discuten alguna generalidades de la estimación (alcance de los ítems, arquitectura de base, unidad de estimación, etc) y el moderador toma nota de todas ellas.
  3. Se discute el alcance de cada ítem para despejar dudas y ambigüedades de manera de asegurar que todos los estimadores esten estimando lo mismo. El moderador también toma nota de esto
  4. Cada estimador estima en forma privada y al finalizar entrega su planilla al estimador.
  5. El moderador carga la información provista por cada estimador y al finalizar comparte con los estimadores la media y el desvío obtenido para cada ítem.
  6. Mientras que haya ítems con un desvío mayor al buscado (este es un parámetro que debe definirse de antemano), los estimadores explican cómo fue que llegaron a los valores dados y se repiten los pasos 4 y 5.

Algunas consideraciones adicionales de mi gusto:

  • Generalmente propongo estimar la construcción y luego en base a ello derivar la estimación de otras actividades asumiendo un % particular para cada una de ellas  (10 % control de la configuración, 10% prueba exploratoria, 15% gestión, etc)
  • Siempre estimo esfuerzo, no tiempo ya que el tiempo depende de cómo se planifique el proyecto y la cantidad de gente que participe del mismo.
  • Suelo buscar que el desvió en cada ítem no supere el 20%
  • Me gusta utilizar este método principalmente al comienzo de los proyectos (etapa de preventa) para obtener un estimación de orden de magnitud y poder jugar con los intervalos de confianza y generar distintos escenarios para la propuesta formal al cliente.

Aquí les comparto la hoja de cálculo que suelo utilizar para aplicar este método.

Ejercicio de estimación

Un cuestión que siempre me hizo ruido de mi formación en FIUBA es el hecho de que en la materia que estudie métodos de estimación nunca me hicieron aplicarlos, o sea nunca me hicieron estimar, ¡cuac! Terminé la materia y sabía “los algoritmos de estimación” de memoria, pero en el contexto de la materia no los había aplicado nunca. Por suerte para esa altura de mi vida, ya tenía unos cuantos años de trabajo en la industria, con lo cual ya conocía algunos de los métodos vistos e incluso ya los utilizaba en mi trabajo diario.

Siendo consciente de esa falencia en mi formación, cuando comencé a dictar Ingeniería de Software en UNQ, me ocupe de incluir en la materia una clase práctica de estimación. El ejercicio que suelo utilizar para esa práctica se llama La fábrica de aviones y lo aprendí en un taller de Agiles 2009 en Florianópolis, Brasil.

El foco del ejercicio está en estimar la velocidad de un equipo y requiere simplemente varias hojas de papel tamaño a4 (~10 hojas por alumno). Describo a continuación la dinámica:

  1. Se divide a los alumnos en grupo5 (~5 por grupo)
  2. Cada grupo representa un fábrica de aviones y se les pide que indiquen que cantidad de aviones puede construir en un lapso de 10 minutos
  3. La forma de los aviones queda a criterio de cada grupo, pero deben asegurarse que el diseño elegido pueda volar X cantidad de metros (suelo pedir 5 metros)
  4. Se pide que cada avión cumpla con ciertos criterios estéticos: numéro de serie en las alas, nombre del equipo constructor a ambos lados, 2 puertas (una cada lado) y 6 ventanas (3 de cada lado). Todo esto se dibuja con lapicera en cada avión.
  5. Explicada la consigna se les pide a los alumnos que indiquen que cantidad de aviones pueden generar en 10 minutos. Difícilmente pueden hacer una estimación “razonable” sin haber generado al menos un avión. Si los alumnos toman conciencia de eso y aplican lo visto en la materia, deberian pedir una iteración para hacer un spike: generar un par de prototipos de avión y ver cuales son las implicancias de construirlos.
  6. Se les da entonces 1 iteración para generar algunos prototipos. Al final de la misma deben entregar el prototipo que copiarán las siguiente iteraciones y deben decir también que cantidad de aviones se comprometen a entregar al final de la siguiente iteración (básicamente tienen que estimar su velocidad).
  7. A partir de aquí se realizan iteraciones verificando al final de cada una que los aviones entregados cumplan con las condiciones previamente indicadas (3 y 4). Sólo se contabilizan aquellos aviones que cumplan con todas las condiciones, incluyendo el volar al menos X distancia.
  8. Luego de 3 iteraciones se ve que la velocidad del equipo se estabiliza.

Algunas variantes que pueden utilizarse sobre esta dinámica básica son:

  • Trabajar sobre las condiciones de aceptación y poner el foco en el Definition of Done
  • Modificar los equipo o la duración de las iteraciones para evidencias como eso afecta a la velocidad

Si alguno de los lectores llega a utilizar está dinámica me gustaría que me comentara los resultados.