Métricas, procesos y de como se juntan

"Les recomiendo hacer este estudio si y solo si van a tomar conducta a partir del resultado", nos dijo hace un tiempo el médico genetista. a mi pareja y a mí, cuando estábamos iniciando los trámites para un estudio genético invasivo que entrañaba cierto riesgo.

Este buen doctor podría dedicarse a la consultoría en informática, o, al menos, podría aportar su criterio en lo que refiere a la definición, recolección e interpretación de métricas de procesos. Su criterio es simple y útil: uno no debería medir algo si luego no piensa hacer nada con esa medición. Las métricas que se recolectan pueden no ser útiles hoy, pero debería existir al menos expectativas de usarlas en un futuro, y estas expectativas deberían ir acompañadas de alguna idea de como se espera que sean útiles. Más allá del abuso de su jerga médica (en castellano, lo que él dijo se diría más o menos como "si no van a hacer nada con el resultado, les recomiendo no hacer este estudio ya que entraña algún riesgo") su idea es aplicable a casi cualquier ámbito, con excepción, quizá, de la ciencia básica.

La respuesta a la pregunta sobre que métricas se deben recolectar en un proceso de desarrollo de software es sencilla: las que sean útiles para tomar decisiones. Lo que es un poco más complicado es la instrumentación de esta respuesta. Vamos a tratar de aplicar una variación libre del método GQM, que, como todo, tampoco es rocket science. Un mapa de ideas siempre es bueno para ordenar las idem:

Lo que se desea, basicamente, es ganar dinero. La rentabilidad en un proyecto de software se puede ver amenazada por una mala estimación inicial ( los proyectos a precio cerrado tienen sus problemas, como bien nota Scott Ambler, pero son la forma más común hoy, al menos en el entorno donde yo me desenvuelvo. Será tema para otro post), por retrabajos (generados por mala calidad de lo producido o por cambios en los requerimientos) y retrasos en el calendario que, además de posibles multas, entorpecen la disponibilidad de las personas del equipo de trabajo y los recursos asociados.

Después de mucho pensar (o de poco pensar pero durante mucho tiempo), derivé un conjunto de métricas con las que me siento cómodo:

• Cantidad de defectos, desagrupados por etapa del proyecto (cuando antes se producen, peor es) y tipo de entregable (defecto en software, en especificación funcional, en especificación técnica, o en el proceso mismo). Asimismo, me interesa el tiempo promedio de solución de un defecto.

• Sobreesfuerzo generado por defectos, es decir, el esfuerzo necesario para corregir los defectos, desagregado por actividad.

• Cantidad de cambios a los requerimientos, también desagrupados por etapa del proyecto y cantidad de cambios aceptados y rechazados.

• Velocidad de avance del equipo, medida por la cantidad de historias del usuario o de requerimientos implementados por unidad de tiempo y como avance ganado, definido como tiempo insumido / (tiempo insumido + tiempo estimado para completar ).

• Milestones cumplidos en tiempo, demorados y demora promedio.

• Cantidad de cambios al plan del proyecto, y el motivo de los mismos (cambios a los requerimientos, cambios a la dotación del equipo de trabajo, errores en la estimación).

• Desvío de la estimación original, por componente y actividad, para lo cual el sistema de registración de horas está alineado con la forma de estimar: se imputan horas con el mismo concepto y granularidad con que se estima el proyecto.

Es probable que al mapa le falten algunos objetivos (será más fácil ganar dinero si entrego un software que le entregue valor al usuario, no simplemente algo que cumpla con las especificaciones, por ejemplo), y seguir el rastro de esos objetivos probablemente nos agregue nuevas métricas.

Por otra parte, tengo un conjunto de métricas, las que por ahora no son útiles, pero espero poder utilizarlas en el futuro:

• Cobertura de código por el testing: en entornos manejados (java, .net), asociado al proceso de integración continua, se mide el porcentaje de código cubierto por las pruebas unitarias y de regresión. Mi esperanza es, en algún momento, relacionar esto con la cantidad de bugs detectados por los procesos de prueba y certificación del usuario, para derivar un valor que minimice la suma entre el esfuerzo necesario para corregir bugs y el esfuerzo de construcción de pruebas unitarias y de regresión.
• Cantidad de no conformidades detectadas por las herramientas de inspección automática, como PMD, Checkstyles, FxCop, Macker, con la misma esperanza que ya mencioné para la cobertura. Relación entre puntos de caso de uso y horas por actividad: guardo la esperanza de construir una base de datos lo suficientemente grande que pueda servirme de base para hacer una estimación por puntos de caso de uso.
• Métricas de complejidad y tamaño de la solución, como cantidad de clases, paquetes, componentes desarrollados sobre los especificados. Aquí la idea para el futuro es poder determinar cuantitativamente cuan confiables son mis espeficiaciones técnicas y cuanto del producto real terminan por cubrir.
• Espero poder madurar las métricas de defectos, para relacionarlas con la cantidad de pruebas realizadas y determinar si el no encontrar más defectos significa que el producto está estable o no se están buscando correctamente y armar tendencias de ocurrencias de errores.

De todas maneras, y como resumen, vale la pena recordar el concepto que vertió el buen doctor que nos atendió: el esfuerzo de recolectar una métrica sirve si ésta puede servir de base para una toma de decisión. Y por cierto, el objetivo de estas métricas (o de cualquier otras) no es cumplir con CMMI, signifique esto lo que signifique, sino dar información útil, que sirva para tomar decisiones, sobre la performance del proceso y el estado del proyecto.