Etiqueta: estimacion

El problema no está en la estimación

Recurrentemente escucho equipos decir que tienen problemas con la estimación, pero cuando tengo la oportunidad de trabajar con ellos durante un par de iteraciones queda en evidencia que la estimación es solo una pequeña parte del problema. El problema grueso suele estar en la ejecución.

Describo el caso típico: un equipo estima que en una iteración completará una cantidad N de ítems. Al finalizar la iteración resulta que completa Z ítems siendo Z bastante menos que N. Instantáneamente se cree que el equipo estima mal.

Entonces me sumo a la dinámica de trabajo del equipo durante una iteración participando de sus Planning, Review, Retros y Dailies. Una vez más el equipo compromete N ítems pero completa Z ítems (N>>Z), pero adicionalmente a eso detecto las siguientes situaciones que ocurrieron durante la iteración:

  • Se trabajaron a pedido del cliente otros ítems que no eran parte del plan inicial de la iteración
  • También se invirtió esfuerzo en arreglar el servidor de tests que dejó de funcionar debido a un update no planificado
  • Parte del equipo tuvo que participar de una reunión con otro equipo que planea reutilzar algunos de los componentes desarrollados por este equipo
  • Un miembro del equipo enfermó y estuvo en cama 2 días sin poder trabajar.

Todas estas cuestiones fueron realizadas sin modicar el plan/compromiso de la iteración y tampoco fueron registradas en ningún lado. De haberse registrado, la lectura de la iteración sería:

  • Se comprometieron N items
  • De los N items comprometidos se completaron Z (siendo Z menor a N)
  • Adicionalmente se completaron otros A items que no estaban planificados
  • Muchas veces A + Z es mayor o igual a N

El haber trabajado en items nos planificados y no haber gestionado correctamente su inclusión nos indica que hay un claro problema de ejecución.

Luego de haber visto recurremente esta situación he decidido armar un taller de planificación adaptativa y seguimiento de proyectos para intentar ayudar a los equipos con problemas de estimación, planificación y ejecución.

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

Libros sobre estimación y planificación Ágil

Durante mucho tiempo mi libro de referencia sobre esta temática fue el clásico Agile Estimating and Planning de Mike Cohn. Pero hace un par de años lei otro libro que me pareció mucho mejor: Planning Extreme Programming, de Kent Beck y Martin Fowler. Este libro fue publicado en 2001, 5 años antes del libro de Cohn y si bien tiene mucho puntos en común con este, tiene también un conjunto de cuestiones muy prácticas que no están presentes en el libro de Cohn. Entre las cuestiones que me gustan de este libro es que sugiere como proceder cuando las cosas no funcionan «felizmente». Por otro lado creo que es un libro para leer de punta a punta, ya que -al igual que todos los libros de la serie XP- tiene capítulos cortos que hacen muy amena su lectura.

Resulta que ayer estaba preparando una clase para FIUBA y tomé algunas cosas de este excelente libro de Beck y Fowler y me pareció que sería interesante compartir esta opinión pues tengo la sospecha que no es muy popular.

Combinando métodos de estimación

Quiero compartir un método de estimación que suelo utilizar con buenos resultados (buen resultado = estimación muy cercana al resultado real, ojo que esto no es consecuencia exclusiva de una buena estimación, sino también de una buena ejecución).

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.

More about Agile Open Tandil (estimation session)

Two folks asked me to write a bit more about the afternoon sessions, especially about the estimation one and here I go, I will resume what we talk in that session.

The format of the session was open, there were more that 20 people and each talk about the way he uses to estimate.

In may opinion the natural process is to first estimate the size, then the effort, and finally considering a certain team you can deduce duration and cost, but not everybody uses this process (or unless not explicitly), some stated to estimate duration at once.

In few words, the following methods were mentioned:

  • Parametric methods (or magic formula-based methods that is the way I like to call them), basically this methods propose to analize your requirements and count points to determinate the size. Then you use that points in a formula that adds some variables to adjust the estimation based on particular information of the project (programming language, experience in similar projects, etc). In this category are Cocomo methods.
  • Expert opinion and manager manipulation methods (this original name is mine): maybe this is one of the most commonly used methods. Several people in the session told to used it and I know that some colleagues in my company use it all the time. It is very simple, a manager (boss, project leader, project manager or whatever you call it) ask an expert (some time not so expert) to estimate certain items. Then the manager adds some buffer and that’s it. Not very formal, not very precise but fast and easy.
  • Several-experts-based methods: I know this is a very ambiguous name, but that is the idea, I want to use this name to refer several different methods that include Delphi methods and planning poker (I think that planning poker is a Delphi variant). In these methods you have a team of experts (when I say experts I am just referring to people that is capable of give a realistic estimation because of his experience). Something very interesting of these methods is that under certain conditions these methods get a probabilistic support: if there are 4 or more experts and each expert opinion is independent, then we can apply the central limit theorem and get an confidence interval.

In my case I always try to use methods in the third group, in particular to estimate the complete product backlog at the start of a project I prefer to use Wideband delphi and then when estimating tasks at the begining of an iteration I prefer planning poker. During the session I mention a spreadsheet I use for Wideband-Delphi and after the session some people asked me to share the spreadsheet, so I published it here.

When I started writing this post I get the idea of preparing an estimation workshop, I think it could be an interesting activity, well I will analyze it.

That ‘s all, see you.

eSTImation MAnager (stima)

Last Monday, my classmate Maria Florencia Perez  finished her studies when she presented her proffesional work: Stima. It is a software that allow users to perform estimations of duration and effort for software development project. It is based on use case points method and it provides some useful features like metrics, estimation history and comparison.

The application is available under Apache License and can be downloaded from Google code rigth at this location.