Métricas Agiles.
Las métricas EVM tradicionales, como el índice de rendimiento de programación (SPI) y el índice de rendimiento de costes (CPI), se pueden traducir fácilmente en términos ágiles. Por ejemplo, si el equipo planeó completar 30 puntos de historia en una iteración, pero solo completó 25, entonces el SPI es 25/30 o 0.83 (el equipo está trabajando a solo el 83% de la tarifa planificada). Del mismo modo, el CPI es el valor ganado (valor de las características completadas) hasta la fecha dividido por los costos reales o, $2.2M / $2.8M a 0.79. Esto significa un resultado de sólo 79 centavos en el dólar en comparación con el plan (pero, por supuesto, esto supone que la predicción sigue siendo correcta.)
Análisis de variación
- A medida que el equipo trabaja, el director del proyecto puede producir diversos análisis de variación, por ejemplo:
- Exactitud de los estimados del equipo
- Entrega en un sprint o según un hito establecido
- Desempeño del equipo en relación con los objetivos
- Los resultados de un análisis de variación se pueden compartir como parte de una retrospectiva con la intención de que sirvan para:
- Sentar una base para la solución de problemas
- La identificación de lecciones aprendidas
- Proponer experimentos de mejoras para iteraciones subsecuentes
Métricas en Proyectos Ágiles.
Usar ágil significa mirar nuevas métricas que importan al equipo y a la administración. Estas métricas importan porque se centran en el valor del cliente.
Un problema con los informes de estado es la capacidad del equipo para predecir la finalización o usar el estado del semáforo para describir el proyecto. Por ejemplo, los líderes del proyecto describen el proyecto como “90% hecho”. En ese momento, el equipo intenta integrar las piezas en un producto. El equipo descubre los requisitos o sorpresas que faltan, o descubre que el producto no integra la forma en que pensaban que lo haría.
El problema con las mediciones predictivas es que a menudo no reflejan la realidad. A menudo sucede que una luz de estado del proyecto es verde hasta 1 mes antes de la fecha de lanzamiento; esto se conoce a veces como un proyecto de sandía (verde en el exterior, rojo en el interior). A menudo, las luces de estado del proyecto se vuelven rojas sin aparentemente ninguna advertencia, porque no hay datos empíricos sobre el proyecto hasta 1 mes antes de la fecha de lanzamiento.
Las métricas de proyectos ágiles contienen información significativa que proporciona un histórico, ya que los proyectos ágiles ofrecen valor (trabajo terminado) de forma regular. Los equipos de proyecto pueden utilizar estos datos para mejorar las previsiones y la toma de decisiones. Las mediciones sustitutas, como el porcentaje realizado, son menos útiles que las mediciones empíricas, como las operaciones terminadas.
Además de las medidas cuantitativas, el equipo puede considerar la recopilación de medidas cualitativas. Algunas de estas medidas cualitativas se centran en las prácticas que el equipo ha elegido y evalúan qué tan bien utiliza el equipo esas prácticas, por ejemplo, la satisfacción empresarial con las características entregadas, la moral del equipo; y cualquier otra cosa que el equipo quiera rastrear como una medida cualitativa.
Agile favorece mediciones empíricas y basadas en valores en lugar de mediciones predictivas. Las medidas ágiles dicen lo que el equipo ofrece, no lo que el equipo predice que entregará. Las líneas base son a menudo un artefacto de intento de predicción. En ágil, el equipo limita su estimación a las próximas semanas como máximo. En ágil, si hay baja variabilidad en el trabajo del equipo y si los miembros del equipo no son multitarea, la capacidad del equipo puede llegar a ser estable. Esto permite una mejor predicción para las próximas dos semanas.
Algunos proyectos basados en iteraciones usan gráficos de quemado para ver hacia dónde va el proyecto con el tiempo. Muchos equipos ágiles utilizan puntos de historia para estimar el esfuerzo.
Los gráficos de Burnup muestran el trabajo completado, los equipos pueden determinar cómo ver sus datos. Cuando un equipo ve lo que aún no ha completado mientras funciona a través de una iteración, el equipo puede desanimarse y posiblemente apresurarse a completar el trabajo sin cumplir con los criterios de aceptación. Sin embargo, el equipo podría tener cualquier número de buenas razones para no completar el trabajo como esperaba. Los Burnups permiten a los equipos ver lo que han logrado, lo que ayuda al equipo a proceder a la siguiente pieza de trabajo.
Ya sea que los equipos usen gráficos de burndown o burnup, ven lo que han completado a medida que avanza la iteración. Al final de la iteración, podrían basar su siguiente medida de capacidad (cuántas historias o puntos de historia) en lo que completaron en esta iteración. Esto permite al dueño del producto junto con el equipo a replanificar lo que es más probable que el equipo realice correctamente en la siguiente iteración.
La velocidad, la suma de los tamaños de punto de la historia para las características realmente completadas en esta iteración, permite al equipo planificar su siguiente capacidad con mayor precisión mirando su rendimiento histórico.
Los equipos ágiles basados en flujo utilizan diferentes medidas: tiempo de entrega (el tiempo total que se tarda en entregar un artículo, medido desde el momento en que se agrega a la placa hasta el momento en que se completa), tiempo de ciclo (el tiempo necesario para procesar un elemento) y tiempo de respuesta (el tiempo que un elemento espera hasta que se inicia el trabajo). Los equipos miden el tiempo de ciclo para ver cuellos de botella y retrasos, no necesariamente dentro del equipo.
El tiempo de entrega es útil para comprender el tiempo de ciclo desde el primer vistazo a una característica determinada hasta el tiempo que se tardó en liberarlo al cliente. Los límites de trabajo en curso (WIP) en la parte superior de cada columna, que se muestran en los cuadros aquí, permiten al equipo ver cómo tirar del trabajo en todos los ámbitos. Cuando el equipo ha cumplido con sus límites de WIP, el equipo no puede tirar del trabajo de la izquierda a la siguiente columna. En su lugar, el equipo trabaja desde la columna más completa a la derecha y pregunta: “¿Qué hacemos como equipo para mover este trabajo a la siguiente columna?“.
Cada característica es única, por lo que su tiempo de ciclo es único. Sin embargo, el dueño de un producto puede notar que las características más pequeñas tienen tiempos de ciclo más pequeños.
Estas métricas son útiles para las mediciones del momento. Ayudan a un equipo a entender cuánto más trabajo tienen y si el equipo podría terminar a tiempo.
Medir los puntos de la historia no es lo mismo que medir historias o características completadas. Algunos equipos intentan medir los puntos de la historia sin completar la característica o la historia real. Cuando los equipos miden solo los puntos de la historia, miden la capacidad, no el trabajo terminado, lo que viola el principio de “la medida principal del progreso es el software de trabajo“.
Cada equipo tiene su propia capacidad. Cuando los equipos proporcionan sus propias unidades de medida, los equipos son más capaces de evaluar y estimar y entregar su trabajo. La desventaja de la estimación relativa es que no hay manera de comparar equipos o agregar velocidad entre equipos.
El equipo puede medir el trabajo completado en un gráfico de quemado/burnup de características y en un gráfico de trabajos pendientes del producto.
Los gráficos de grabación/quemado de características pueden mostrar que los requisitos crecieron durante el proyecto. La línea completa de características muestra que el equipo completa las características a un ritmo regular. La línea de características totales muestra cómo han cambiado las características totales del proyecto con el tiempo. La línea de quemado restante de las entidades muestra que la tasa de finalización de entidades varía. Cada vez que se agregan entidades al proyecto, cambia la línea de quemado.
- El valor obtenido en ágil se basa en entidades terminadas.
- El gráfico de trabajo pendiente del producto muestra el trabajo completado en comparación con el trabajo total esperado en hitos de intervalo o iteraciones.
- Un equipo solo puede terminar una historia a la vez.
- Para completar una característica grande que contiene varias historias, el equipo tendrá historias restantes por completar y es posible que no complete toda esa característica hasta que hayan transcurrido varios períodos de tiempo más.
- El equipo puede mostrar su valor completado con un gráfico de trabajo pendiente del producto.
- Si un equipo necesita medir el valor ganado, puede considerar el uso de este gráfico de quemados.
Un diagrama de flujo acumulativo, muestra el trabajo en curso en un conjunto.
- Si un equipo tiene muchas historias esperando la prueba, la banda de pruebas se hinchará.
- La acumulación de trabajo se puede ver de un vistazo.
- Los equipos tienen problemas para acumular trabajo: el equipo tiene trabajo en curso en lugar de trabajo completado.
- Cuando los equipos tienen mucho trabajo en curso, retrasan su entrega general de características.
- Cuanto más tiempo tarde un equipo en entregar, más presión tendrá un equipo para más características en el mismo período de tiempo.
Valor ganado ágil.
- La gestión del valor ganado se centra en predecir el tiempo que tomará completar el proyecto y el costo final incurrido.
- El análisis del valor ganado usa imágenes en forma de gráficos para informar el estatus.
Risk burndown chart.
- Es un herramienta que se puede utilizar para comunicar a los interesados del negocio y al Equipo de Scrum la información relacionada con los riesgos.
- Para evaluar los riesgos y crear este gráfico es necesario utilizar el valor monetario esperado (EVM).
