Sunday, 12 May 2013

Si se puede medir, se puede mejorar

Hace unos días hablaba sobre métricas con unos entusiastas de las metodologías ágiles como yo. Comentábamos sobre la necesidad que tenemos todos de facilitar datos a la dirección de nuestra empresa sobre la marcha del proyecto o a nuestros clientes, que están realizando una inversión en nuestro producto y han puesto unas expectativas en él.

Todo esto me hizo recordar el clásico axioma de calidad atribuido a Peter F. Drucker y que dice algo así: "Lo que no se puede definir, no se puede medir, lo que no se puede medir no se puede mejorar, y lo que no se puede mejorar finalmente se deteriora" Hay muchas variaciones de esta frase y muchas versiones diferentes también sobre su autoría. Yo prefiero usarla desde un punto de vista más positivo diciendo "Si se puede medir, se puede mejorar"

Una métrica básica para el seguimiento del proyecto con SCRUM es la suma del trabajo que queda por hacer. Diariamente podemos sumar las estimaciones de las tareas que quedan por hacer en el sprint. Esto nos dará la cantidad total de trabajo restante para terminar la actual iteración (Release Burndown) Con un poco de suerte al día siguiente habremos conseguido terminar algunas tareas más y esta suma será algo más pequeña. Si lo representamos en una gráfica, ésta irá decreciendo hasta alcanzar el eje 0 (cuanta más pendiente tenga la gráfica más velocidad lleva el equipo) Lo mismo podremos hacer con toda la pila del producto si sumamos las estimaciones de todas las funcionalidades que quedan aún por hacer.

Otro gráfica útil y sencilla que podemos utilizar es la CFD (Cumulative Flow Diagram) con la que, tomando los datos del tablero Kanban donde reflejamos la marcha proyecto, vamos anotando cada semana cuantas tareas tenemos y en qué estado están. Si por ejemplo tenemos un tablero sencillo en el que sólo tenemos las tareas en tres estados, ToDo (Por hacer), In Progress y Done, la gráfica mostraría algo como esto:


Al principio del proyecto todas las funcionalidades estarán por hacer (en color azul) y al final del mismo todas habrán alcanzado habrán sido marcadas como realizadas ('Done', en color verde)

La representación no está escogida al azar. He observado en varios proyectos que la gráfica suele tomar esta forma característica. Una velocidad baja al principio (poca pendiente) cuando el equipo se está conjuntando, alta velocidad cuando se ha superado la fricción inicial (alta pendiente) y despacio nuevamente hacia el final del proyecto cuando se descubre que todas las tareas no se habían cerrado correctamente y quedan cosas por corregir (no se cumplió correctamente con la definición de 'Done')

Hay muchas otras métricas que pueden ser usadas, recomiendo posts interesantes en "5 métricas de desempeño para proyectos de desarrollo ágil y Scrum" y en "Métricas ágiles y cuadro de mandos integral para Scrum" En cualquier caso, uses las métricas que uses, asegúrate de que merece la pena el esfuerzo en registrar los datos y calcularlas. Más métricas no significan mejor gestión.

No comments:

Post a Comment