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?