El valor ganado

Scott Ambler, entre otros, critica el uso de Earned Value como métrica para los proyectos de desarrollo, y como siempre, con muy buenas razones:

• Se tiende a asumir que toda tarea realizada es valor ganado, así, por ejemplo, llegamos a que ganar el 90% del valor nos cuesta el 90% del esfuerzo y el último 10% de valor otro 90% ( me encantan esos proyectos donde siempre estamos finalizando.)
• Es difícil usar el EV para el software, ya que el nivel de interdependencia de los componentes es alto.

Repasando el earned value, la forma de calcularlo es asignarle un valor a cada tarea, definir una política de suma (es decir, si puedo sumar un 50% de la tarea o solo sumo tareas completas), y luego, con el avance, recolectar lo terminado y hacer una suma de los valores de cada tarea terminada.

Yo siempre pensé que me gustaba el Earned Value, de hecho, iba a escribir un post para defenderlo. Lo que ocurre es que estuve años diciéndole Earned Value a otra cosa. Suele pasar, sucede lo mismo cuando digo que soy liberal y me saludan como compañeros de ideología cada personaje... (no, no voy a hablar de política, pero soy liberal, humanista, y ... bueno, si les interesan sigan los links al think tank de Paul Kurtz ).

Volviendo, mi earned value se basa en lo siguiente:

• Primero, no toda tarea aporta valor. Hay tareas necesarias para laburar pero que, luego de terminarlas, no tengo algo de software que mostrar. Sería delirante decir que tengo dos mil pesos de earned value porque terminé de conectar mi entorno de desarrollo. Después de tener mi entorno de desarrollo up & running, mi earned value es cero. Todavía no gané ningún valor.
• Yo entrego productos, no tareas cumplidas. Por lo tanto, el earned value se incrementa cuando termino una parte del producto, no cuando termino una tarea (y por cierto, terminado es terminado, no es terminado pero me falta probarlo)
• Lo que me dice cuan cerca estoy del objetivo es la distancia que me separa del mismo, no cuanto recorrí para llegar a él. Mi objetivo no es estático, aún cuando trabaje con BRUF, ya que manejo el cambio. Entonces, mi EV no lo voy a comparar con la estimación original, sino con la estimación actual de acuerdo a la configuración actual del producto que debo entregar
• El software sí puede dividirse en piezas: si tengo una lista de componentes a realizar, un diseño de alto nivel y una lista de funcionalidades, es que cada una de esas tiene alguna entidad propia. Y como tal, puedo decir que cada una de ellas está implementada o no está.

Claramente, en un proyecto ágil 'puro', donde no se cierren los requerimientos al principio, el earned value no tiene sentido. Pero como argumenté en otro post, me veo obligado a trabajar con lo que Ambler llama BRUF.

Y así tengo un gráfico con una linea que representa el valor actual del producto a construir (es decir, la sumatoria del valor de todos los componentes que representan la configuración actual del producto a construir) y una linea que representa el valor ganado (la valorización de aquellos componentes terminados y útiles para la configuración actual del software). Esto implica, claro, que el valor ganado puede bajar y que el objetivo no es estático. Acá hay un ejemplo del gráfico en cuestión:




Por supuesto, hay más datos que tal vez valgan la pena volcar en el gráfico (la valorización de las tareas que no aportan valor directamente al producto, por ejemplo), pero por ahora lo uso así.

La forma de medir el avance de un proyecto siempre es un tema complicado. Lo que subyace, me parece, es uno de los dos grandes problemas que también subyace al tema de las estimaciones: no tenemos una buena forma de medir el tamaño del producto de nuestro trabajo (como nota al margen, no creo que lo ignoremos por tontos, sino por recién llegados).

Y esto que tiene que ver con el earned value?. Bueno, para mí es el earned value: es el valor que logré ganar. Ah... que la definición era otra?. Bueno, podría ser. Ya comenté que soy liberal?

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.