Métricas en la gestión de proyectos: estimaciones, costes, plazos y user stories

27-07-2009 Luis Artola

Ya estemos utilizando Kanban, SCRUM o Feature Driven Development, si estamos intentando aplicar cualquier metodología ágil necesitaremos elaborar un Product Backlog del proyecto donde cada ítem represente una user story (o una feature, o …). Además, deberemos priorizar esos items para ver cuales son más importantes y añaden más valor, e implementarlos primero.

Una de las claves a la hora de poner manejar cómodamente las user stories, elegir en qué iteración desarrollarlas y poder estimar cuanto tiempo tardaremos o si estamos cumpliendo el plan previsto, es hacer que sean del mismo tamaño (o, al menos, de un tamaño similar). Esto no siempre será posible, pero hay que intentar dividir una user story en varias, o juntarlas, para conseguir la mayor homogeneidad posible.

Para poder estimar el tiempo que nos llevará una user story, tenemos varias técnicas:

• por analogía: “si un item me costó 3 horas, y éste es del mismo tamaño, éste también me costará 3 horas.” Cuidado con ésta manera de estimar porque si te equivocas en tu primera estimación, propagarás el error al resto de estimaciones…
• descomposición: si no soy capaz de estimar cuanto me costará un story point, quizá pueda subdividirlo en una serie de story points más fáciles de estimar. Nunca llevar esto demasiado lejos, podemos perder mucho tiempo descomponiendo más y más y más…
• WideBand Delphi: para cuestiones realmente difíciles de estimar. Se trata de un proces en el que se implica a varios programadores y se busca el consens a base de rondas iterativas. Para ver exactamente cómo se haría: aquí.
• … y juegos típicos de SCRUM como el Planning Poker.

Una vez que tengamos nuestra estimación para los items más prioritarios, podremos ver cuantas horas y cuantos programadores serán necesarios para llevar a uen puerto la iteración en el tiempo estimado. Ésta es nuestra primera métrica: Iteration velocity, esto es, el número de horas (o de story points) resultos multiplicado por el número de programadores que participarán.

Si la Iteration Velocity de cierta iteración que va a durar tres semanas se ha planificado en 45 user stories, y pasada una semana sólo se han resuleto 3 user stories, se puede ver claramente que el equipo se está retrasando. Esto se suele representar mediante un gráfico BurnDown.

Diariamente el programador introducirá las horas reales que le están suponiendo los story points. Las horas reales, son una métrica muy evidente. Si estamos por debajo de lo estimado, habrá que añadir story points a la iteración, y si estamos por encima, habrá que ver por qué, y en caso de no haber remedio, disminuir el número de story points de la iteración para poder llevarla a buen puerto.

Si la iteración va mal, y no nos va a dar tiempo a completarla como lo planificamos habrá que ver por qué. A eso nos ayudarán un par de métricas:

• unplanned items: esto es, el número de items que hemos descubierto que había que hacer para poder realizar las funcionalidades desarrolladas. Esto puede darse por varios motivos. El primero es no haber detectado una dependencia (para poder hacer el item x, debería hacer primero el Y), y el segundo es un mala fase de análisis y diseño, que nos haga ahora descubrir cosas sobre nuetro software que ya deberíamos saber.
• defects: si el mismo equipo que se dedica al desarrollo se dedica a la solución de defectos encontrados en las iteraciones anteriores, y el número de defectos encontrados es alto, puede ser que nuestro equipo se esté dedicando a solucionar defectos en vez de desarrollar nuevas funcionalidades, y que esto lo esté retrasando.

Y, por último, dejo aquí un interesante artículo sobre preguntas que podemos hacernos a la hora de controlar el desarrollo de un proyecto, y cómo obtener las respuestas en un entorno SCRUM.