Rss Feed Tweeter button Facebook button Linkedin button

subscribe: Posts | Comments | Email

Métricas Ágiles (I)

1 comment
Métricas Ágiles (I)

Lo que mides es lo que tienes.

He estado trabajando y leyendo  sobre las distintas métricas  que se pueden plantear en un proyecto ágil y como poder realizar los seguimientos de este tipo de proyectos.  Hay bajo mi punto de vista dos clasificaciones de las métricas de un proyecto Ágil según sea el rol que las vaya a consumir.

Así, para el equipo y el Scrum Master, podemos plantear métricas de seguimiento y calidad de código con componente técnico y que nos garanticen el seguimiento en base a la máxima de que el mejor indicador en el Software que funciona. Y por otro lado , para el Product Owner, existen otro tipo de métricas que se emplean para el seguimiento de indicadores orientados al negocio y al reporting a la alta dirección.

Este será el primero de una serie de artículos sobre esta temática. En el primer caso, escribiré acerca de los fundamentos a tener en cuenta en las métricas Ágiles, para seguir con una segunda entrega dedicada a las métricas para el Equipo y el Scrum Master, dejando para un último artículo las métricas o cuadros de mando para los Product Owner.

Comenzando por las Anti-métricas.

Prácticas habituales de métricas que todos hemos escuchado o “sufrido” en muchas ocasiones están obsoletas y no reflejan ni demuestran con sus valores ningún indicador de importancia.

Me refiero a casos como :

KLOC  ( Miles de líneas de código) o KLOC/Desarrollador.  Con esta métrica, premiamos a los desarrolladores más productivos. ¿Seguro? . Sirve para conocer la dimensión del Software, pero nunca debe ser empleada para medir productividad. Podemos premiar o recompensar a aquel que desarrolla una función o clase con más lineas de código no optimizado y poco eficiente, frente al que con muchas menos líneas de código consigue el mismo resultado. Y si se usa como medida de dimensión del software, tampoco nos dice nada. El “corta-pega”  existe y no por ello un sistema con millones de KLOC es mejor que otro con menos lineas.

Tareas completadas. Con esta métrica, premiamos  a los que inventan un sinfín de pequeñas de tareas, sin evaluar la importancia de las mismas y el valor que aportan al proyecto.

Tiempo trabajado en la tarea. Si queremos que alguien se siente en silencio y trabaje en una tarea de manera individual, y cuanto más tiempo mejor,  estaremos posiblemente premiando  al poco eficiente. Necesitamos compromiso con la eficiencia , no solo con la presencia.

Estas tres métricas, tienen generalmente muy poco o nulo valor en proyectos ágiles.

En su lugar, tenemos que buscar métrica ágiles que :

Reafirmen y refuercen los principios Lean y Agile. “El software que funciona es la principal medida de progreso”.

Medir los resultados, no solo las salidas. ¿Prefieres tener el 95% de avance  en todo, pero no tener nada que enseñar al cliente , o el 70% con un software entregado y funcionando?.  Un Gráfico de Gantt , refleja un % de avance de las tareas pero : ¿cual es la razón objetiva por la que ponemos un 80% o un 90% de cumplimiento o grado de avance de una tarea?. ¿ El tiempo transcurrido desde la fecha de inicio es una métrica efectiva?.

Seguir las tendencias no los números. Cuando aprendes a volar en un avión, lo primero que haces es mirar los cuadros de mando constantemente. Nunca terminas de corregir el rumbo y estás continuamente mirando los indicadores para evitar desviaciones. Sin embargo, si tapas el panel y te enfocas a mirar hacia afuera, al horizonte, de repente el avión se nivela y todo es más fácil. Hace ya muchos años, tuve la gran suerte de poder pilotar una pequeña avioneta y puedo decir que esto me pasó. No, no soy piloto, esto solo fue una vez, pero guardo de ello una experiencia muy agradable. Lo mismo podríamos decir de conducir un coche. Si miramos continuamente el cuadro de mandos nos desviamos de la carretera. Tenemos que evitar estar continuamente mirando los indicadores en nuestros proyectos de software, y centrarnos en el foco de producir software de calidad. Fijar el rumbo y dirigirnos a la meta.

Centrarnos en  un pequeño conjunto de indicadores y diagnósticos. Tenemos que concentrarnos en la producción de artefactos de software que realmente importan (el código!) y consumir el menor tiempo posible en recabarlos para ayudarnos a mantener el rumbo.

Indicadores y métricas fáciles de recoger. Tenemos que pasar la mayor parte de nuestro tiempo centrados en la  producción de software, no en informar sobre su producción.Las métricas que recolectemos deben ser fáciles de obtener y no deben consumir mucho tiempo. Automatiza todo lo que puedas.

Agile tiene que ver con la honestidad y la transparencia. Si recopilamos datos para satisfacer agendas ocultas, no estamos siendo fieles a estos valores.

Las métricas ágiles deben proporcionan datos que se puedan emplear  para una conversación de valor entre los miembros del equipo. Las métricas son sólo datos. Lo importante es conversar sobre tendencias y patrones que nos ayuden a anticiparnos ante futuros problemas.

Aplicando estos fundamentos , estaremos en la linea de obtención de métricas Lean / Agile que nos ayuden a conseguir información de tendencias de datos valiosas que nos permitan enfocarnos a mejorar continuamente nuestra producción de Software.

Métricas SI, pero cuidado con lo que mides.  Lo que midas será lo que obtendrás. !!!!

Permanece atento a la segunda entrega de la serie de Métricas Ágiles : Métricas para el equipo y el Scrum Master.

  1. Interesante artículo, el concepto de métricas y antimétricas nos permite enfocarnos en lo que realmente es importante, que es producir software que funcione para nuestros usuarios.

    Algunas métricas que podríamos proponer para medir esto es:
    – Valor entregado al cliente: Valorar las historias en función de la prioridad para el usuario final y cuando las entreguemos registrarlas en la métrica.

    – Tabla Burndown y Velocidad: Nos permite medir la frecuencia con la cual hemos “hecho” (done) los elementos de la pila de producto (donde hecho significa que ya hemos probado, no sólo desarrollado):

    – Deuda Técnica: A mayor deuda técnica, pues menos eficiencia.

    – Cantidad de actividades en estado “En Proceso”: Si utilizamos los principios de “Lean” entre mayor cantidad de actividades (elementos de la pila de producto) tenemos en proceso, quiere decir que estamos tardando más y somos menos eficientes.

    Un Saludo.

Trackbacks/Pingbacks

  1. Métricas Ágiles – Comunidad Ágiles Paraná | Comentando Libertades - [...] http://www.gestiondeproyectosit.es/blogit/2012/12/metricas-agiles-i/ , http://www.gestiondeproyectosit.es/blogit/2012/12/metricas-agiles-ii/ , [...]
  2. Métricas Agiles (IV) | GestiondeProyectosIT - [...] los articulos anteriores de la serie Métricas ágiles, hemos visto los fundamentos, las métricas habituales y las métricas específicas…

Leave a Reply

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *


*