Resumen: las métricas ágiles proporcionan información sobre la productividad en las distintas fases de un ciclo de vida de desarrollo de software. Esto ayuda a evaluar la calidad de un producto y realizar un seguimiento del rendimiento de un equipo.
Las métricas son un tema complicado.
Por un lado, todos hemos estado en un proyecto en el que no se ha supervisado ningún tipo de dato, y era complicado decir si íbamos cumpliendo los objetivos para la publicación o si éramos más eficientes según avanzaba el proyecto. Por otro lado, muchos hemos tenido la mala suerte de participar en proyectos en los que las estadísticas se usaban como un arma, enfrentando a un equipo frente a otro o justificando el trabajo obligatorio del fin de semana. Así que no es ninguna sorpresa que la mayoría de los equipos tengan una relación de amor-odio con las métricas.
Sin embargo, no tiene que ser de este modo. Supervisar y compartir métricas ágiles sólidas puede reducir la confusión y arrojar luz sobre el progreso (y retrasos) del equipo a lo largo del ciclo de desarrollo. Te explicamos cómo a continuación.
Conoce tu trabajo
El estado "Finalizado" solo cuenta la mitad de la historia. Se trata de crear el producto correcto, en el momento oportuno y para el mercado adecuado. Para no desviarse del camino a lo largo del programa, hay que recopilar y analizar datos relevantes durante el proceso. En todos los programas ágiles, es importante hacer un seguimiento tanto de las métricas empresariales como de las ágiles. Las métricas empresariales informan de la adecuación de la solución al mercado, mientras que las métricas ágiles miden aspectos del proceso de desarrollo.
"Las métricas empresariales de un programa deben basarse en su hoja de ruta."
En cada iniciativa de la hoja de ruta, debes incluir varios indicadores clave del rendimiento (KPI) que estén ligados a los objetivos del programa. Además, debes incluir criterios de éxito para cada requisito del producto, como la tasa de adopción por parte de los usuarios finales o el porcentaje de código cubierto por las pruebas automatizadas. Estos criterios de éxito alimentan las métricas ágiles del programa. Y cuanto más aprendan los equipos, mejor se adaptarán y evolucionarán.
Cómo usar métricas KPI ágiles para optimizar la entrega
Trabajo pendiente de los sprints
Los equipos de scrum organizan el desarrollo en sprints con un tiempo asignado. Al inicio del sprint, el equipo plantea un pronóstico de la cantidad de trabajo que puede completar durante el sprint. Un informe de evolución de sprints supervisa la finalización del trabajo a lo largo del sprint. El eje de abscisas representa el tiempo y el eje de ordenadas se refiere a la cantidad de trabajo que queda por completar, medido en puntos de historia u horas. El objetivo es haber finalizado todo el trabajo previsto al final del sprint.
Un equipo que cumple permanentemente las previsiones es un indicador atractivo de la metodología ágil en la organización. Sin embargo, no caigas en la tentación de alterar las cifras declarando la finalización de un elemento antes de que esté terminado de verdad. Puede parecer positivo a corto plazo, pero a largo plazo únicamente lastra el aprendizaje y la mejora.
- El equipo termina antes de tiempo todos los sprints porque no están asumiendo trabajo suficiente.
- El equipo no cumple las previsiones sprint tras sprint porque está asumiendo demasiado trabajo.
- La línea de evolución marca caídas pronunciadas en lugar de una evolución más gradual debido a que el trabajo no se ha dividido granularmente.
- El propietario del producto añade o cambia el alcance en mitad del sprint.
Trabajo pendiente de epics y publicaciones
Los diagramas de trabajo pendiente de epics y versiones sirven para realizar el seguimiento del progreso del desarrollo a lo largo de una muestra más amplia de trabajo que en el diagrama de trabajo pendiente de sprints, y guía el desarrollo de los equipos de scrum y kanban. Dado que un sprint (en los equipos de scrum) puede contener trabajo de varios epics y versiones, es importante supervisar el progreso de los sprints individuales, así como de los epics y las versiones.
La "corrupción del alcance" es la inyección de nuevos requisitos en un proyecto ya definido. Por ejemplo, si un equipo entrega un nuevo sitio web a la empresa, un ejemplo de corrupción del alcance sería pedir nuevas funciones después de que se haya realizado el esquema de los requisitos iniciales. Aunque tolerar la corrupción del alcance durante un sprint es una mala práctica, los cambios en el alcance en los epics y las versiones son una consecuencia natural de un desarrollo ágil. A medida que el equipo avance por el proyecto, el propietario del producto puede decidir asumir o retirar trabajo en función del aprendizaje. Los gráficos de trabajo pendiente de los epics y las versiones informan a todo el mundo del flujo de trabajo dentro del epic y de la versión.
- Las previsiones de epics o versiones no se actualizan a medida que el equipo avanza por el trabajo.
- No se observa progreso después de varias iteraciones.
- La corrupción del alcance crónica, que pueden indicar que el propietario del producto no entiende completamente el problema que esa parte del trabajo intenta solucionar.
- El alcance aumenta con mayor rapidez que la capacidad de absorción del equipo.
- El equipo no está lanzando versiones incrementales a lo largo del desarrollo de un epic.
Velocidad
La velocidad es la cantidad media de trabajo que un equipo de scrum lleva a cabo durante un sprint, medida en puntos de historia u horas, y es muy útil para los pronósticos. El propietario del producto puede usar la velocidad para predecir la rapidez con la que un equipo puede recorrer el backlog, debido a que el informe supervisa el trabajo previsto y el completado a lo largo de varias iteraciones. Cuantas más iteraciones se contemplen, más precisa será la previsión.
Digamos que el propietario del producto desea completar 500 puntos de historia del backlog. Sabemos que el equipo de desarrollo generalmente completa 50 puntos de historia en cada iteración. Es razonable que el propietario del producto suponga que el equipo necesitará 10 iteraciones (más o menos) para finalizar el trabajo requerido.
Es importante supervisar la evolución de la velocidad a lo largo del tiempo. Los nuevos equipos seguramente vean un aumento en velocidad a medida que el equipo optimice las relaciones y los procesos de trabajo. Los equipos existentes pueden supervisar su velocidad para garantizar un rendimiento coherente a lo largo del tiempo, y pueden confirmar si un cambio en un proceso concreto ha mejorado algo o no. Un descenso de la velocidad media generalmente es un indicador de que alguna parte del desarrollo del equipo se ha vuelto ineficiente y debería tratarse en la siguiente retrospectiva.
Si la velocidad experimenta muchas variaciones en un largo periodo de tiempo, revisa las prácticas de estimación del equipo. En la retrospectiva del equipo, pregunta lo siguiente:
- ¿Hay dificultades de desarrollo que no tuvimos en cuenta al estimar el trabajo? ¿Cómo podemos dividir mejor el trabajo para detectar algunas de estas dificultades?
- ¿Hay presión empresarial externa que empuja al equipo más allá de sus límites? ¿Se están sacrificando las buenas prácticas de desarrollo debido a ello?
- Como equipo, ¿somos demasiado optimistas al realizar previsiones de los sprints?
La velocidad de cada equipo es única. Si el equipo A tiene una velocidad de 50 y el equipo B tiene una velocidad de 75, no significa que el rendimiento de B sea mayor. Dado que la cultura de estimación de cada equipo es única, su velocidad también lo será. No caigas en la tentación de comparar la velocidad de varios equipos. Mide el nivel de esfuerzo y los resultados del trabajo en función de la interpretación única que cada equipo hace de los puntos de historia.
Gráfico de control
Los gráficos de control se centran en el tiempo del ciclo de las incidencias individuales, es decir, el tiempo total para pasar de "en curso" a "finalizado". Los equipos con duraciones del ciclo más cortas seguramente tengan mayor rendimiento, y los equipos con duraciones del ciclo homogéneas en numerosas incidencias son más predecibles. Si bien la duración del ciclo es una métrica fundamental para los equipos de kanban, los equipos de scrum también pueden sacar partido una duración del ciclo optimizada.
Medir la duración del ciclo es un modo flexible y eficiente de mejorar los procesos de un equipo porque los resultados de los cambios se detectan casi instantáneamente, de modo que se permiten ajustes inmediatos. El objetivo final es tener una duración del ciclo corta y homogénea, independientemente del tipo de trabajo (nueva funcionalidad, deuda técnica, etc.).
Los gráficos de control pueden parecer demasiado variables al principio. No te preocupes demasiado con cada dato que se salga de la norma. Busca tendencias. Estas son dos áreas a las que estar atentos:
- Aumento de la duración del ciclo: el aumento de la duración del ciclo mina la metodología ágil lograda con tanto esfuerzo por parte del equipo. En la retrospectiva del equipo, dedica tiempo a entender el motivo de este aumento. Existe una excepción: si la definición que hace el equipo de "finalizado" ha aumentado, la duración del ciclo probablemente aumente también.
- Duración del ciclo heterogénea: el objetivo es tener una duración del ciclo homogénea de los elementos de trabajo que tengan valores de punto de historia similares. Filtra el gráfico de control para cada valor de punto de historia para comprobar la homogeneidad. Si la duración del ciclo es heterogénea en valores de punto de historia grandes y pequeños, dedica tiempo en la retrospectiva a examinar los aspectos que se han pasado por alto y a mejorar las estimaciones futuras.
Diagrama de flujo acumulado
El diagrama de flujo acumulado debería ser una curva suave de izquierda a derecha. Las burbujas o huecos en cualquier color indican limitaciones y cuellos de botella. Cuando veas uno de estos casos, busca maneras de suavizar las bandas de color en todo el diagrama.
- Las incidencias que causan bloqueos crean enormes copias de seguridad en algunas partes del proceso y muy escasas en otros.
- Crecimiento incontrolado del backlog a lo largo del tiempo. Esto es el resultado de que los propietarios del producto no cierren incidencias obsoletas o de que las incidencias con prioridad más baja no se traten nunca.
Métricas adicionales
Las buenas métricas no están limitadas a los informes mencionados anteriormente. Por ejemplo, la calidad es una métrica importante para los equipos ágiles y hay varias métricas tradicionales que pueden aplicarse al desarrollo ágil:
- ¿Cuántos defectos se encuentran?
- durante el desarrollo?
- después de la publicación al cliente?
- por personas ajenas al equipo?
- ¿Cuántos defectos se aplazan para una versión futura?
- ¿Cuántas solicitudes de servicio al cliente están llegando?
- ¿Cuál es el porcentaje de cobertura de las pruebas automatizadas?
Los equipos ágiles también deben tener en cuenta la frecuencia de las publicaciones y la velocidad de entrega. Al final de cada sprint, el equipo debe publicar software a producción. ¿Con qué frecuencia ocurre eso? ¿Se están lanzando la mayoría de las compilaciones de versiones? En esta línea, ¿cuánto tarda el equipo en publicar una corrección urgente a producción? ¿La publicación es fácil para el equipo o requiere actuaciones heroicas?
Consulta información útil en su contexto
Con la información útil, los equipos pueden acceder a métricas cuando las necesitan: durante la planificación de sprints, en la reunión rápida diaria o cuando quieren optimizar las entregas. Puedes consultar la información útil en la esquina superior derecha de las vistas de tablero, backlog e implementaciones de Jira.
La información útil proporciona una instantánea visual de las siguientes métricas:
- Progreso del sprint
- Desglose de tipos de incidencias
- Compromiso con el sprint
- Frecuencia de implementación
- Tiempo del ciclo
Utiliza estas métricas para optimizar continuamente el rendimiento del equipo. Descubre más detalles sobre la información útil.
Conclusión
Las métricas y los KPI ágiles son solo una parte de los elementos necesarios para crear la cultura de equipo. Aportan un análisis cuantitativo del rendimiento del equipo y proporcionan objetivos mensurables. Aunque son importantes, tampoco te obsesiones con ellas. Escuchar el feedback del equipo durante las retrospectivas es igual de importante para aumentar su confianza, la calidad del producto y la velocidad de desarrollo en todo el proceso de publicación. Usa feedback cuantitativo y cualitativo para impulsar los cambios.
Recursos relacionados
