Estado del proyecto : métricas ágiles

Acabo de leer el artículo que Xavi Albaladejo ha publicado en Proyectos Ágiles titulado “Métricas ágiles y cuadro de mandos balanceado para Scrum“.

En mi modesta opinión, me parece una buena recopilación de métricas (algunas difíciles de automatizar, como la del resultado de las retrospectivas, pero no por ello de menor valor. Me atrevo a preguntaros, ¿qué 5, 6 ó 7 métricas usarías para que el cliente tuviera una visión resumida del estado del proyecto? Vamos, ¿cómo construiríais el “cuadro de mandos” para vuestros clientes?

Vale, como está feo tirar la piedra y esconder la mano, ahí van las mías:

  • Velocidad del equipo (para cada sprint)
  • ROI. Cada historia de usuario debe tener un valor de negocio asignada por el Dueño del Producto y, por tanto, podemos saber cuánto valor de negocio se ha convertido en cada sprint.
  • Las tres métricas de calidad que Xavi resalta: Satisfacción del cliente o usuario, Incidencias o defectos detectados por los usuarios, Defectos detectados por el equipo de desarrollo.
  • Tiempo de puesta en producción después de cada sprint. (Esta métrica no la incluye Xavi, pero a mi entender serviría para, de alguna manera medir parte de las “Lecciones aprendidas”)

Me gustaría también ser capaz de ofrecer al cliente alguna medida del riesgo que se está asumiendo y cómo va afectando éste durante la vida del proyecto, pero sinceramente no sabría bien cómo hacerlo. Quizás una buena referencia para esto (en inglés) sería este artículo que enseña a estimar el riesgo con una hoja de cálculo.

No estaría mal mostrar el “panel de control” como una “radar chart” para poder comparar de un vistazo varias métricas de un sprint a otro, p.ej.

¿Sería diferente el cuadro de mandos del cliente y el del ScrumMaster o jefe de proyecto? Hombre, el corazón me dice que deberían ser iguales por eso de que “somos un equipo”, “la transparencia con el cliente”, y todo eso…, pero la razón me dice que a cada uno le interesa una perspectiva diferente del proyecto:

  • al cliente es algo más económico, de valor de negocio, de rentabilidad de la inversión en marcha,
  • mientras que al ScrumMaster le interesa más bien los impedimentos que se pueden estar acercando para poderse adelantar a su aparición.

Por eso creo que deben ser diferentes. ¿Cuáles serían vuestras métricas para el ScrumMaster?

Las mías, creo que serían:

  • Velocidad del equipo. Sí, también, de hecho, con más razón incluso que para el cliente. De esta métrica se pueden sacar muchas conclusiones que contrastar en las retrospectivas con el equipo. Es muy importante averiguar a qué pueden ser debidas las variaciones en la velocidad: estimamos mejor, hemos eliminado un impedimento que puede volver a surgir, ha surgido un impedimento que nos retrasa…
  • Las líneas de código. Sí, sé que es un poco llamativo y
    “anticuado”, pero me parapeto detrás de un excelente artículo de James
    Shore (autor de “The Art of Agile Development”) sobre cómo medir la deuda técnica.
  • Felicidad del equipo. Bfff, esto es dificil de explicar, pero la actitud que tiene el equipo después de cada retrospectiva es importantísimo en el desarrollo del siguiente sprint. Recomiendo leer sobre el “Niko-niko calendar“, y si alguien lo pone en práctica, estaría encantado de conocer sus impresiones.
  • Desviación en las estimaciones. Me parece importante ofrecer este feedback al equipo (porque el “cuadro de mandos” creo que debe ser para todo el equipo), y por ello creo que el ScrumMaster debe ser capaz de recopilar esta información y manejarla con cuidado porque puede afectar mucho a la credibilidad del equipo (incluso para ellos mismos).
  • Calidad del código: cobertura, complejidad ciclomática y las reglas de calidad acordadas que podamos automatizar con herramientas como Checkstyle, PMD, JDepend… Para esto último aconsejo encarecidamente que probéis Sonar.

Algunas métricas (como el “nikocal”) no son exactamente cuantificables, pero no es importante porque de lo que se trata es de ver las tendencias. En todos los casos, lo que importa no es la “instantánea” sino la tendencia puesto que sólo de las tendencias podemos sacar conclusiones o al menos elaborar hipótesis que nos ayuden en nuestro camino.


Doy por supuesto que tenemos en las paredes o en una herramienta (como radiadores de información) nuestros paneles constantemente actualizados con las historias de usuario del sprint en curso, las iniciadas y las terminadas, así como el gráfico de “burndown” y cualquier otro que vuestro(s) equipo(s) haya(n) considerado a bien tener siempre a la vista.

Y también doy por supuesto que nuestro equipo y nuestra organización están ya lo suficientemente maduros como para no tener que medir cosas como:

  • Número de veces que se rompe el build (en Integración Continua)
  • Calidad de los commits en el SCM. Por ejemplo, si pasan días sin que nadie haga commit es que algo muy malo está pasando. O si los commits no llevan un comentario que permita identificarlo y trazarlo con la tarea correspondiente.

  • Anonymous

    Hola José Manuel,

    Sobre lo del “Tiempo de puesta en producción”, quizás lo más conveniente sea expresarlo como: “Tiempo de entrega de un requisito tras su petición (responsividad a necesidades del cliente, Time to Market, tiempo de servicio), en función del tipo del tipo de requisito (urgente, etc.) y cumplimiento de los Acuerdos de Nivel de Servicio (ANS / SLA).”

    Sobre la medición de los riesgos, una forma de cuantificarlos es la severidad, ententida como la probabilidad de que se den multipicada por el impacto que producirían.

    Salud,

    Xavi AlbaLaDejo 😉

  • Jose Manuel Beas

    Hola Xavi, muchas gracias por tu aportación.

    Sí, estoy de acuerdo con la “reescritura” de tiempo de puesta en producción. Tu enfoque lo hace más “de negocio”. De todos modos, supongo que lo mejor es que cada uno elija las “marcas” donde le viene mejor medir en función de sus circunstancias. Pero tienes mucha razón en que tener en cuenta factores, muchas veces olvidados, como la responsividad (el tiempo que tarda el cliente desde que pide un cambio o nueva funcionalidad hasta cuando ésta está “en servicio”) es una métrica importantísima (junto con la satisfacción del cliente) puesto que esa combinación es la que debería hacer que una empresa de software (que debe ganar dinero) tenga más o menos éxito.

    En cuanto a la severidad como medida de riesgos, vale: en cualquier caso se trata de una estimación de cada historia de usuario y, como estimación, es algo bastante subjetivo. Aunque la transformemos en una multiplicación, tanto la probabilidad de ocurrencia del riesgo como el impacto que suponemos puede tener, son valores subjetivos. Además, no sería muy ágil ponernos a calcular al céntimo el valor económico del impacto de un riesgo… 🙂 Lo importante es que el equipo (incluyendo al P.O.) siempre apliquen los mismos criterios comparativamente. (Aunque personalmente creo que, a medida que avanza el proyeco, tendemos a minusvalorar los riesgos, bien porque nos acostumbramos a ellos o porque vamos tomando confianza).