Métricas ágiles

Uno de los puntos fundamentales cuando nuestra organización quiere adoptar una gestión del cambio, sea cual sea la metodología a implantar, son las métricas.

Al igual que suceden con las KPI en el ámbito Internet, disponer de métricas tiene infinitos beneficios, nos permitirá identificar oportunidades de mejora, identificar una reducción del rendimiento, controlar la calidad, controlar la satisfacción...

He leído al respecto esta interesante herramienta, con una categorización desde mi punto de vista acerta, aunque nada fácil, como veremos a continuación.

La verdad es que la categorización es muy adecuada, pero voy a centrarme en las que considero más interesantes.

• Velocidad. La velocidad expresa la capacidad de esfuerzo productivo que tenemos a cada sprint, son las tareas que se han finalizado satisfactoriamente en el sprint, y finalizadas quiere decir finalizadas, testeadas y, a ser posible, validadas por el cliente/product owner.
  
  
• Focus factor. Una métrica a trabajar con cariño, pero que es fundamental en nuestra adopción de una metodología ágil. Es el resultado de dividir las horas que se esperaba durasen las tareas de dicho sprint, entre las horas reales que ha dedicado el equipo. Es medir la diferencia entre esfuerzo y duración, generalmente provocado por multi-asignación, por interrupciones, etc. en ningún caso por falta de interés o profesionalidad (de ahí que alerte que debe tratarse con cariño) En cualquier caso, es una métrica, un porcentaje, que nos alerta de oportunidades de mejora ... quizá el cliente está saltando el product owner, quizá el SAU utiliza en exceso el equipo técnico, quizá la oficina no ayuda a la concentración ... etc
  
  
• Earned Value. Teniendo en cuenta la relevancia que le da el manifiesto ágil al valor que aportamos al cliente, es interesante medir qué valor generamos al cliente para cada iteración, es habitual que este valor sea resultado de sumar los valores de prioridad que ha dado el usuario a los user stories que se han liberado durante el Sprint.
  
  
• Número de incidencias detectadas por el cliente. Es un valor complejo de gestionar, y sobretodo es difícil que lo podamos tener en consideración en las retrospectivas, por que la detección de una incidencia no tiene un espacio de tiempo definido. En cualquier caso, és una métrica de referencia que nos puede ayudar a fomentar en el equipo la preocupación relativa a la calidad de lo producido. Y alertarnos de problemas en la gestión de la calidad interna. Si disponemos de una herramienta de gestión (por ejemplo JIRA) que permita al usuario registrar incidencias, el cálculo será más sencillo.
  
  
• Número de incidencias detectadas por el equipo. De igual modo a la métrica anterior, puede llegar a ser un dato relevante, puede indicar relajación en el control de calidad, o necesidad de mejora de los mecanismos automáticos.
  
  
• Tiempo de despliegue por release. Tiempo requerido para tener en producción una release, es una métrica que nos puede indicar si necesitamos un entorno de integración contínua, o si este está funcionando o dejando de funcionar adecuadamente
  
  
• Calidad del código. Aplicación de herramientas como PMD, CheckStyle o el famoso Sonar qué también se estuvo evaluando durante mi colaboración con Alliaria/IN2
  
  
• Lead Time (Ciclo de vida de una petición) Tiempo que pasa desde que recibimos una nueva petición, por ejemplo un cambio, hasta que este está en producción. Esta métrica nos da la agilidad real del equipo. Pero es importante poder discriminar por urgencia o importancia del cambio.
  
  

U otras igualmente importantes que nos ayuden a garantizar el ritmo de trabajo (dedicación del equipo, felicidad del equipo, ... )

----- Update 26/05/2011

Un concepto interesante a introducir, aunque su aplicación como he podido comprobar durante mi investigación, ha sido el "Value Stream Mapping" propuesto por Lean Development. Es un concepto que invita a la reflexión del valor que se aporta durante la cadena productiva de cara a la primera regla de lean ... elimina residuos

Veamos que métricas o conceptos propone:

1. Touch Time & Cycle Time. Touch: Tiempo que dedica el equipo a trabajar en una tarea, pensar, diseñar, desarrollar, testing, etc. sin incluir emails, coffee time, y otras interrupciones. En resumen esfuerzo. Cycle: Hace referencia a la suma del tiempo desde que recibimos una tarea hasta que la liberamos completamente. Es decir duración (Es una métrica muy similar al focus factor)
2. Value Added & Non Value Added. A la finalización del sprint, que tareas que hemos ejecutado representan un valor para el cliente, y cuales no. Nos servirá para medir cuanto estamos focalizado a cliente (Pero no creo que nos deba obsesionar en las fases iniciales, sobretodo en proyectos grandes que nos exigen cierto trabajo interno de arquitectura)
3. Be Brutal & Be Conservative. Es la definición de cómo te vas a posicionar a la hora de decidir si una tarea es o no de valor añadido. Así como para decidir el Cycle y Touch time aceptable para una tarea (si es que podemos llegar a definirlo)

----- End

En resumen, toda métrica que nos aporte control a la hora de medir como de beneficiosa está siendo la adopción de una mejora en nuestro proceso de trabajo, es de interés. O planteándolo de otro modo, sí ... no sabemos como de buena va a ser una medida o decisión ... si no vamos a poder medir su beneficio, tenemos un problema!!

Pero, tampoco es importante obsersionarse con tener todas las métricas, las retrospectivas nos daran ese aliento de mejora, y cada organización necesita unas métricas específicas. 


Podéis encontrar una relación bastante completa en Proyectos ágiles



Referencias

• Appropriate Agile Mesurement | Article
• Principles for Agile Metrics | Blog
• Se hace camino al Andar | Blog
• ABetterTeam | Metrics Tool
• Proyectos Ágiles | Blog
• Presentación SlideShare | Deepak Mittal 
• Metrics in Agile Development | Blog

Saludos,