Cómo medir el progreso en proyectos de desarrollo de software que usan métodos Ágiles.

photo © 2007 Danny Hope | more info (via: Wylio)

El siguiente artículo está basado en uno publicado por Tamara Sulaimán y Hubert Smiths que apareció en la revista electrónica "Methods & Tools", y es el primero de algunos artículos sobre temas ágiles que ire presentando en entregas posteriores.

Introducción.

La administración del Valor ganado (EVM) es una técnica de administración de proyectos que permite medir la integración del desempeño, el costo y el cronograma comparándolos contra el desempeño planeado el proyecto. El resultado es un conjunto de métricas que ofrecen alertas tempranas a problemas de desempeño del proyecto, permitiendo que se hagan ajustes en forma oportuna. 

Además el EV ayuda a mejorar la definición del alcance del proyecto, ofrece métricas valiosas para comunicar a los interesados el avance logrado  y permite mantener al equipo de trabajo enfocado.

A pesar de estar los beneficios que se pueden obtener de las técnicas de EVM estas  han tardado en ser asimiladas, especialmente en las consultorías dedicadas al desarrollo de software, ya que existe una percepción de que estas técnicas son difíciles de implementar.

Por otro lado los métodos ágiles de desarrollo de software han demostrado su eficacia: permiten que el software se desarrolle más rápido, con mejor calidad y cubriendo mejor las cambiantes expectativas del negocio y las condiciones del mercado. Pero, según los autores del artículo, existía hasta hace poco la opinión de que estas técnicas eran demasiado difíciles de implementar de manera efectiva en proyectos de tipo ágil ya que el  EVM no permitía hacer frente a cambios frecuente en los requerimientos.

Sin embargo estas técnicas han sido adoptadas en proyectos ágiles y según los autores se ha demostrado su efectividad (1).

Los autores proponen al AgileEVM como una adaptación de las técnicas tradicionales, pero ligera y fácil de usar (ideal para proyecto Ágiles), destacando además que la técnica puede usarse para proyectos simples (un solo equipo, duración breve) o proyectos complejos (equipos a nivel de un programa o portafolio).

En un artículo de 1998, Fleming y Koppelman (2) afirmaban que " el beneficio más importante de emplear Valor ganado son las lecturas de costo eficiencia que ofrece..." La administración del Valor ganado ha sido reconocida como una técnica de administración de proyectos desde 1960.

A pesar de esto, tradicionalmente se ha considerado difícil predecir con precisión el costo final de un proyecto de desarrollo de software. El desempeño del proyecto (con equipos que pueden ir adelantados o atrasados respecto al cronograma o el presupuesto) no puede reflejarse fácilmente a una previsión de costos.

En resumen el EVM integra el desempeño técnico, el programa y el costo real, proporcionando métricas para el trabajo realizado. Al comparar el valor ganado (EV) con el valor planeado (PV) el avance real del proyecto se compara con el progreso esperado, generando información valiosa.

Métodos ágiles y scrum.

Los métodos ágiles de desarrollo de software han evolucionado durante los últimos quince como una respuesta a los pesados procesos centrados en documentos usuales en el desarrollo de software. Los principios básicos de los métodos ágiles son:

• Son interactivos e incrementales: el software no es desarrollado en un esfuerzo de muchos meses, si no en una serie de interacciones cortas (2 a 4 semanas).
• Centrados en la gente: todo el equipo es responsable de planear y entregar las entregas incrementales. Los equipos son pequeños, de entre 7 y 10 personas, y se les anima a ser auto organizados.
• Emiten el cambio: los métodos ágiles emiten camisa los requerimientos al final de cada interacción, facilitando ajustando mejor el proceso de entrega a las necesidades del cliente.
• Enfoque de negocio: en cada iteración sólo se implementan las características que son de mayor importancia para el negocio.
• Inspección periódica de los productos y procesos: al final de cada iteración se demuestran las características del producto se determina cómo debe continuar el proyecto. También, al final de cada iteración el equipo evaluar la forma en que se ha trabajado y determina las mejoras que se puedan hacer al proceso.

Definiciones.

Algunos de los términos usados en el artículo son:

Métodos ágiles: colección de métodos de desarrollo de software que han sido elaborados a partir del manifiesto ágil. Por ejemplo: Extreme Programming (XP), Scrum y Feature Driven Development.

Dueño del producto: es la persona responsable del éxito del producto en el mercado, por tanto, quién puede priorizar las necesidades en las características del producto.

Equipo de entrega: grupo de personas responsables de la entrega de los artefactos que componen el producto. También son responsables de que la entrega se haga con la calidad acordada así como de determinar y estimar las tareas necesarias para obtener el producto final.

Backlog del producto: una lista presa de características que componen el producto tal y como lo desea su dueño.

Iteración o Sprint: Periodo de una a cuatro semanas en que el equipo del equipo produce características del producto aceptadas por usuario.

Característica: componente del producto que se reconoce y valora.

¿Qué es AgileEVM?

AgileEVM es una aplicación adaptada de EVM que utiliza los artefactos de Scrum como entradas, junto con los cálculos tradicionales de EVM, y se expresa también en parámetros tradicionales de EVM. AgileEVM requiere un conjunto mínimo de parámetros de entrada: el costo real de un proyecto, un backlog estimado del producto, un plan de liberación que proporciona información sobre el número de iteraciones y la velocidad en la liberación. Las estimaciones pueden ser en horas, puntos de la historia, días de equipo o cualquier otra estimación de tamaño consistente . El factor crítico es que debe ser una estimación numérica de algún tipo.

En el artículo se usaron puntos de historia como una medida del tamaño de la historia y la velocidad.

¿Qué ofrece AgileEVM que no se obtiene en la burndown chart?

Los métodos ágiles no definen cómo manejar y dar seguimiento de los costos para evaluar el retorno de inversión esperado. Por tanto las gráficas burn-down y burn-up (como las utilizadas en Scrum) no proporcionan información de costos del proyecto de un vistazo. Las métricas ágiles no proporcionan estimaciones de costos al terminar una liberación ni indicadores de costos para apoyar la toma de decisiones del negocio. AgileEVM proporciona esta información, y por lo tanto es una extensión excelente a la información proporcionada por por los gráficos burn-down.

¿Cuál es la línea de base?

Los autores proponen tres puntos de datos para establecer la línea base inicial:

1. El número de iteraciones planificadas en una liberación;
2. El número total de puntos de historia previstas en una liberación;
3. El presupuesto previsto para la liberación.

Para el cálculo de las métricas AgileEVM, se requieran además cuatro medidas:

1. El total de storypoints completados;
2. El número de iteraciones completadas;
3. El costo total real;
4. El total de puntos de historia agregados o eliminados del plan de liberación.

¿Cómo calcular el Valor planeado, Valor ganado y costo real?

La comparación del Valor Ganado (EV) en contra el Valor planeado (PV) constituye el núcleo de la EVM.

El Valor planeado es el valor del trabajo previsto para una fecha determinada. Es todo el presupuesto para el trabajo a realizar en la fecha prevista. En la terminología Scrum: es la suma de los tamaños de la características estimadas para todas las funciones hasta la fecha prevista.

El Valor ganado es el valor del trabajo realizado en la misma fecha que se utiliza para PV. Valor ganado no es sinónimo de costo real, ni tampoco se refieren al valor de negocio. El valor ganado se refiere a prestaciones técnicas (trabajo) "ganado" contra la línea base o el trabajo previsto. En la terminología Scrum: es la suma de los puntos de historia estimados para las características hasta la fecha de cálculo.

El coste real es lo que el nombre implica: el costo en dinero para completar un conjunto de características.

Un ejemplo para aclarar estos tres conceptos. Con un presupuesto total de $ 175.000, y habiendo completado uno de cuatro iteraciones, tenemos este backlog de productos y los datos reales:

Característica	Estimados (storypoints)	Completados (storypoints)	Costo real (1000s de dólares)
Pantalla de bienvenida	10	10	15
Pantalla de anuncios	20	20	30
Pantalla de registro	10	10	20
Google Ads personalizados	20
Navegador de catálogo	20
Editor de catálogo	10
Navegador de canastilla de compras	5
Editor de canastilla de compras	25
Proceso de validación de compra	20
Cálculo del recibo	10
Verificación de tarjeta de crédito	10
Manejo de pago con PayPal	20
Cobro de confirmación de orden	20
Totales	200	40	65

Con este información (que debe estar ya disponible en cualquier proyectos Scrum) se pueden calcular los valores base propuestos:

• El porcentaje completado esperado equivale al número de iteraciones completadas divididas entre el número de iteraciones planificadas (en nuestro ejemplo, después de una iteración se debe en un 25% completado);

• El Valor planeado de una iteración dada es el porcentaje completado esperado multiplicado por el presupuesto total (25% de $ 175.000 = 43.75 mil dólares);

• El porcentaje completado real equivale al número total de storypoints completado dividido entre el número total de storypoints previsto (40/200 = 20% de avance);

• El Valor ganado se calcula multiplicando el porcentaje completado real por el presupuesto total (20% de $ 175,000 = $ 35.000)

AgileEVM funciona comparando el plan que la liberación actual (tomando en cuenta los cambios en los requerimientos) contra el trabajo realmente efectuado. Podemos ver a simple vista que nuestro proyecto está en problemas: el valor ganado es menor que el valor planeado (EV = $ 35.000 y PV = 43,750 dólares).

Es importante señalar que en el cálculo de AgileEVM no hay valor para la realización parcial. El backlog de productos está hecho o no (0 o 100%.) De acuerdo con la terminología Agile: un elemento del backlog sólo esta "completo" y se otorgan los puntos de historia cuando el cliente acepta el artículo.

Análisis de las métricas de AgileEVM - el Índice de Rendimiento Costo y el Índice de Rendimiento del calendario.

El Índice de Rendimiento del Costo (CPI) es una medida de eficiencia. Muestra que tan eficiente ha sido en realidad el gasto comparado con la forma en que se planeaba gastar. Se calcula dividiendo el valor ganado entre el costo real. En nuestro ejemplo, el CPI es de 35.000 / 65.000 = 0,53.

Un valor de uno en el CPI indica que el presupuesto se esta usando para realizar el trabajo a la velocidad que se había planeado gastarlo.

Un CPI menor que uno significa se está gastando en forma poco eficiente debido a que el Valor ganado es mayor que el costo real (AC).

CPI > 1	CPI = 1	CPI < 1
Bajo presupuesto	Dentro del presupuesto	Sobre el presupuesto
EV > AC	EV = AC	EV < AC

El estimado al terminar (EAC) es la previsión de la cantidad total que se tendrá que gastar para completar el trabajo previsto, basado en el trabajo efectivo realizado. La forma más fácil de calcularlo consiste en dividir el presupuesto total entre el CPI. Aunque este no es el cálculo más exacto, es lo suficientemente preciso para identificar las tendencias en el tiempo que permitan tomar medidas correctivas. Nuestro estimado al terminar (EAC) es de 175.000 dólares / 0,53 = $ 330 188 que predicen un 47% más de presupuesto. 


El Índice de Rendimiento del cronograma (SPI) compara el Valor ganado contra el Valor planeado y se calcula dividiendo el Valor planeado entre el Valor Ganado (nuestro SPI es de 35.000 / 43.750 = 0,8 - que significa un 20% de retraso). El análisis del SPI es comparable con el análisis del CPI: 

SPI > 1	SPI = 1	SPI < 1
Adelantado	A tiempo	Retrasado
EV > PV	EC = PV	EV < PV

Un estimado de finalización se puede realizar dividiendo el SPI entre las iteraciones planeadas, en nuestro ejemplo, se tiene previsto terminar el trabajo en 4 iteraciones, se puede esperar que se requieren: 4 / 0,8 = 5 iteraciones.

Los métodos ágiles me permiten cambiar el backlog después de cada iteración, ¿AgileEVM lo permite?

Sí, el método AgileEVM considera los cambios en el backlog que pueden ocurrir después de cada iteración. Mediante los cambios en el backlog (storypoints agregados o eliminados cuando se agregan o eliminan características), se establece una nueva línea base después de cada iteración. El efecto de la re-calcular el AgileEVM después de cada iteración, es una validación del backlog modificado contra el plan de liberación. Se está validando que será capaz de completar todo el trabajo previsto para la liberación dentro del tiempo y presupuesto previstos. Esto le da al propietario del producto (que es el "dueño" del backlog) información inicial sobre los efectos de sus cambios, con tiempo suficiente para reconsiderar si los cambios afectan al plan de liberación de forma negativa.

¿Con qué frecuencia debe ser medido el Valor ganado?

Los límites de cada iteración son adecuados para calcular el AgileEVM. Se puede hacer con más frecuencia, pero solo es recomendable para cuando la liberación contiene sólo unas pocas iteraciones. El EVM ha demostrado ser estadísticamente correcto cuando el 15% de las características planeadas se han completado, lo que hace al EVM y al AgileEVM una métrica importante para informar a las partes interesadas. Sólo debe que cuidarse el contar con los valores acumulados correctos dentro de los límites de cada iteración.

¿Cómo puede realizarse el cálculo de EVM considerando todos los equipos de trabajo en un programa?

Cuando los equipos de trabajo en un programa son comparables en tamaño y velocidad, entonces los cálculos de Valor ganado se pueden hacer para todo el programa.

Sin embargo es muy frecuente que los equipos no sean comparables por que poseen características diferentes. En este caso la recomendación es calcular el Valor ganado para cada equipo, y sumarlos a un Valor ganado total. El siguiente ejemplo muestra la forma en que lo hizo para un programa con tres equipos. También muestra como se calculó el Valor planeado para cada equipo y se agregó para obtener el Valor planeado total. El resto de los cálculos de EVM siguen siendo los mismos, con la advertencia de que el costo real (Actual Cost) debe ser el costo real del trabajo de todos los equipos para poder calcular el CPI total del programa. El CPI y el estimado al terminar (ETC) son indicadores útiles que indican cuál es el desempeño del programa en general, pero no advierte en caso de que un equipo en particular pueda estar en problemas.

Equipo	Presupuesto total	Valor planeado	Valor ganado	Costo real (Actual Cost)	CPI	SPI	Estimado al terminar
Equipo A	$ 300k	$ 150k	$ 150k	$ 150k	1	1	$ 300k
Equipo B	$1,000k	$ 575k	$ 500k	$ 625k	.8	.86	$ 1,250k
Equipo C	$ 800k	$ 175k	$ 200k	$ 180k	1.11	1.14	$ 720k
Total del programa	$ 2,100k	$ 900k	$ 850k	$ 955k	.89	.94	$ 2,360k

En este ejemplo, puede verse que el total del programa requerirá un presupuesto adicional de 11% (1-CPI), o $ 260.000, y un 6% más de tiempo. Al observar los resultados de cada equipo, se puede ver que el equipo A está funcionando de acuerdo al costo y al plan. El equipo B esta 20% por encima del presupuesto previsto, con un 14% de retraso. Equipo C está trabajando mejor que lo planeado, esta 11% por debajo del presupuesto y adelantado en el programa un 14%.

Conclusión

Al usar estas simples medidas de rendimiento junto con las métrica ágiles típicas (las gráficas de Iteration burn-down y release burn-up, por ejemplo) se obtienen elementos que facilitan un análisis objetivo que se puede compartir con los equipos, la gerencia y clientes. Las señales de advertencia temprana de que se obtienen con los indicadores AgileEVM, permiten validar los cambios en los planes de liberación y proporcionan la oportunidad de tomar decisiones de negocio prioritarias.


(1) Agile EVM Research Paper; http://www.solutionsiq.com/agile_index.html
(2) Earned Value Project Management, A Powerful Tool for Software Projects;
http://www.stsc.hill.af.mil/crosstalk/1998/07/value.asp