ISO 9001 y Scrum: Indicadores reloaded

Agrego una charla que tuvimos con Martín Salias y Matías Woloski en el Architect Forum en Microsoft Argentina, y algunas ideas adicionales que tuve a partir de eso.

A Martín le parece riesgoso usar un indicador de velocidad, puede haber tentación de usarlo para micromanagement. De acuerdo, pero creo que ese riesgo existe con cualquier medición. Por ejemplo, en PSP se pide que cada persona mida como usa su tiempo en las distintas actividades, con la intención de mejorarse. Esos datos se podrían usar, agrupados, para identificar posibles mejoras a nivel grupal u organizacional, pero nunca debería usarse para que el manager trate de evaluar a cada persona. Algo parecido pasa con los defectos, quien los detecta y quien los corrige, etc. Definitivamente un tema a tener en cuenta en cualquier uso de métricas.

Matías tenía preferencia por otras métricas, antes que objeciones a la velocidad. Ellos usan métricas basadas en la calidad, como cobertura de prueba y cumplimiento de standard de codificación. Esto está ligado al tipo de código que ellos hacen, en muchos casos son ejemplos para terceros, que deben mostrar buenas prácticas.

Disparado por estos comentarios, me repasé la justificación interna que hicimos (no reflejada en lo que fue al procedimiento): La idea que teníamos es que debemos medir throughput, en el sentido de la Teoría de las Restricciones (Theory of Constrains). Que es el throughput? Cuanto valor producimos por unidad de tiempo. Es la principal métrica a considerar desde el punto de vista de TOC. Cómo medimos el valor producido?
Mmm… ok, no sabemos cuanto es el valor ($) que producimos con una funcionalidad en particular, pero sabemos que valor estuvo dispuesto a pagar el Product Owner por eso. Ese valor es la estimación que tenía ese ítem o user story en el momento de la planificación. No importa si después se tardó más o menos. El PO decidió “comprar” ese ítem de backlog con la información que tenía en ese momento.

Entonces, ¿cuál es el throughput? Es el valor producido (número de días estimados al momento de la estimación para los ítems cumplidos)/por unidad de tiempo. Nosotros tomamos unidad de tiempo sprint.

Voilà! El throughput es la velocidad!

YMMV!