Tiempo de lectura: 13 minutos
El enfoque ágil para el desarrollo de software ha sido durante mucho tiempo una práctica común. Según la encuesta en línea de HP, el 16% de los profesionales de TI optan por la metodología ágil pura, el 51% se inclinan por la ti y el 24% adoptan un enfoque híbrido ágil. Hoy en día, el desarrollo en cascada se menciona con mayor frecuencia como un diferenciador ágil, lo que no es ágil. Hemos discutido ampliamente las principales diferencias en nuestro documento técnico sobre metodologías ágiles de gestión de proyectos.
A pesar de la adaptabilidad y flexibilidad de la gestión ágil y su rápida respuesta a los cambios, el flujo de trabajo puede mantenerse centralizado y controlado. Los KPI ágiles (indicadores clave de rendimiento) proporcionan orientación para la planificación estratégica, la evaluación y la mejora de los procesos operativos.
Los sistemas tradicionales de gestión del valor tienden a centrarse en la finalización de tareas dentro del marco de un cronograma y un costo categóricos. Sin embargo, con agile, los clientes y los miembros del equipo ven resultados inmediatos y ajustan los plazos y el esfuerzo para entregar un producto que se corresponda con los requisitos de programación. ¿Qué herramientas y técnicas exige ese conocimiento? Este es nuestro resumen de la evaluación del rendimiento de las métricas de desarrollo ágil.
KPI de desarrollo de software ágil
En este artículo, no vamos a explorar todas las métricas de desarrollo ágil y los KPI posibles. Además de eso, puede inventar sus propios modelos que se adapten mejor a su proyecto. Sin embargo, describiremos los KPI más comunes utilizados en múltiples aspectos de desarrollo de software:
- Velocidad
- Reducción de velocidad
- Reducción de lanzamiento
- Tiempo de ciclo
- Flujo acumulativo
- Eficiencia de flujo
- Cobertura de código mediante pruebas automatizadas
- Automatización de pruebas contra pruebas manuales
- Complejidad ciclomática McCabe (MCC)
- Pérdida de código
Estos son los clave que debe explorar primero
Medir el trabajo en curso
Velocity
Velocity mide la cantidad de trabajo (una serie de características) completado en un sprint. Aunque no es una herramienta de predicción o comparación, velocity proporciona a los equipos una idea de cuánto trabajo se puede hacer en el siguiente sprint.
El índice de velocidad es único para cada equipo y debe configurarse para evaluar cuán realista es el compromiso. Por ejemplo, si el atraso del proyecto tiene 200 puntos de historia y, en promedio, el equipo completa 10 puntos de historia por sprint, significa que el equipo necesitará aproximadamente 20 sprints para completar el proyecto.
Cuanto más tiempo realice un seguimiento de la velocidad, mayor será la precisión de la correspondencia entre obligaciones y costos
Para un equipo que acaba de adoptar la metodología ágil o incluso se embarcó en un nuevo producto, las estimaciones de velocidad de los primeros sprints probablemente serán erráticas. Pero a medida que los equipos adquieran experiencia, la velocidad alcanzará su punto máximo y luego alcanzará una meseta de flujo predecible y expectativa de rendimiento. Una disminución en el flujo constante indicará problemas en el desarrollo y revelará la necesidad de cambio.
Consejos para usar la métrica de velocidad
Inconsistencia de combate después de 3-5 sprints. Si la velocidad sigue siendo inconsistente después de un largo período de tiempo, considere evaluar los factores externos e internos que impiden una estimación clara.
Altera el seguimiento de velocidad siguiendo los cambios de equipo y tarea. Cuando un miembro del equipo abandona el proyecto o se agregan más miembros/tareas, vuelva a calcular la velocidad o reinicie el cálculo por completo.
Tres sprints son suficientes para las previsiones tempranas. Para predecir el rendimiento futuro, utilice el promedio de los tres sprints anteriores.
Gráfico de quemado de Sprint
El gráfico de quemado de sprint muestra la cantidad de trabajo que queda por hacer antes del final de un sprint. La herramienta es particularmente valiosa porque muestra el progreso hacia el objetivo en lugar de enumerar los elementos completados. También es muy útil para descubrir errores de planificación que un equipo cometió al comienzo de un sprint.
En el gráfico de abajo, la línea negra representa la línea pronosticada (tendencia ideal) que muestra a qué velocidad el equipo necesita quemar puntos de historia para completar el sprint a tiempo. La línea azul indica la cantidad total de trabajo y su progreso a lo largo del sprint. Se puede ver que durante los días cinco y seis, un equipo no logró lograr el progreso previsto. Sin embargo, en el séptimo día, se abordó la cuestión y el trabajo volvió a encarrilarse. Estas actualizaciones continuas permiten a los equipos abordar los problemas emergentes durante las reuniones diarias.
Además del rendimiento del trabajo en sí, los gráficos de quemado pueden revelar problemas de planificación
Consejos para acercarse a la quema de sprint
Los puntos de historia deben ser uniformes. Si el flujo de trabajo no es coherente, es posible que algunas tareas se hayan dividido en trozos desiguales. El alcance de la desviación entre una tendencia ideal y la realidad pone claramente de relieve este problema.
Cuenta para tareas no planificadas. El gráfico de quemado es útil para comprender el alcance de las tareas ocultas y no rastreadas. Si la cantidad de trabajo está aumentando en lugar de disminuir, el proyecto tiene muchas tareas no estimadas o no planificadas que deben abordarse.
Usa una tabla de quemado para evaluar la confianza del equipo. Teniendo en cuenta las tarifas actuales, pregunte a su equipo qué tan seguros están de completar el sprint a tiempo. Cuanto más tiempo apliques esta métrica, más precisas serán tus estimaciones de sprint.
Estimar el lanzamiento con un gráfico de quemado
Un gráfico de quemado de lanzamiento indica la cantidad de trabajo que debe completarse antes de un lanzamiento. El gráfico ilustra la visión general del progreso y le permite implementar cambios para garantizar la entrega a tiempo.
Una versión tradicional del gráfico es similar al gráfico de quemado de sprints, pero ofrece una visión general de todo el proyecto donde el eje y es sprints y el eje x es una medida del trabajo restante (días, horas o puntos de historia). Pero, ¿qué pasa si se agrega más trabajo al proyecto o su trabajo estimado no cumple con las expectativas?
En la tabla de abajo, un equipo planeó completar un proyecto en cuatro sprints e inicialmente tenía 45 puntos de historia. Mientras que el progreso fue según lo planeado durante el primer y segundo sprints, en el tercer sprint el trabajo estimado aumentó, lo que se refleja en el eje y en valores negativos. Durante el tercer sprint, aparecieron 5 nuevos puntos de historia. No se completaron y el cuarto sprint agregó otros 5 puntos de historia. Por lo tanto, el progreso y el tiempo de liberación tuvieron que ser ajustados.
La liberación gráfico de la evolución es super efectivo para situaciones con un montón de cambios de requisitos y permite a un equipo a mantenerse en la pista durante cada sprint
¿Cómo puede la liberación gráfico de la evolución de ayuda?
Predicción en tiempo real sobre el lanzamiento. Una vez que su proyecto sufre cambios, lo que sucede cada vez con productos de desarrollo iterativo, debe ver cómo estos cambios afectan la fecha de lanzamiento. El gráfico de reducción de lanzamientos permite predecir la fecha de lanzamiento en tiempo real de acuerdo con las actualizaciones en el ámbito de trabajo.
Predicciones de plazos. Puede estimar si el equipo puede completar el lanzamiento de un producto a tiempo o anticipar que la fecha límite debe avanzar aún más teniendo en cuenta las tareas agregadas.
Estimación del número de sprints. Evaluar cuántos sprints se requieren para terminar el trabajo también es un factor importante a considerar con el gráfico de quema de lanzamientos.
Evaluación del estado del proceso y búsqueda de cuellos de botella
Tiempo de ciclo
La métrica de tiempo de ciclo describe cuánto tiempo se pasó en una tarea, incluso cada vez que el trabajo tuvo que reabrirse y completarse de nuevo. El cálculo del tiempo de ciclo proporciona información sobre el rendimiento general y permite estimar la finalización de tareas futuras. Si bien el tiempo de ciclo más corto ilustra un mejor rendimiento, los equipos que entregan dentro de un ciclo consistente son los que más valoran.
Utilizando el gráfico de abajo, puede identificar el tiempo promedio que lleva completar una tarea, dibujar una mediana o una línea de límite de control que no se debe cruzar y observar qué tareas tardaron inusualmente en terminarse.
La desviación estándar dibuja una línea entre el número de días normal y no recomendado para completar la tarea
También puede apilar todos los ciclos para un período en particular y obtener información al compararlo con otros datos. Al realizar una investigación adicional, puede sacar conclusiones sobre la calidad del trabajo.
Aquí puede ver que el número de tareas completadas de marzo a junio ha crecido al igual que el número de errores
Cómo usar el tiempo de ciclo
Buscar similitudes. Una buena práctica es encontrar elementos similares que tardan tiempos de ciclo impredecibles en completarse, revelando problemas recurrentes, ya sea en ingeniería o administración.
Predicciones de sorteos. Puede tomar decisiones basadas en datos prediciendo el tiempo necesario para completar tareas nuevas en función de tareas similares del pasado.
Sigue el ritmo. El gráfico describe cómo mantener el mismo ritmo de trabajo y define si hay problemas internos que reducen la velocidad del trabajo.
Diagrama de flujo acumulativo (CFC)
La métrica de flujo acumulativo se describe en el área del gráfico que muestra el número de diferentes tipos de tareas en cada etapa del proyecto, con el eje x que indica las fechas y el eje y que muestra el número de puntos de historia. Su objetivo principal es proporcionar una visualización fácil de cómo se distribuyen las tareas en diferentes etapas. Las líneas en el gráfico deben permanecer más o menos uniformes, mientras que la banda con las tareas «hechas» debe crecer continuamente.
El gráfico revela una gran cantidad de información crítica, como cuellos de botella repentinos o aumentos en cualquiera de las bandas
El CFC será de gran utilidad para los equipos Kanban como una visualización simple del trabajo del equipo. El gráfico también se corresponde con el flujo de trabajo de tres pasos de Kanban. Aquí también mapeas tres categorías de tareas principales: tareas pendientes, en curso y completadas.
Además, el gráfico ayuda a identificar cuándo se superan los límites de trabajo en curso (WIP). Al ser una de las herramientas más valiosas en el desarrollo ágil, los límites de WIP están diseñados para cultivar la cultura de terminar el trabajo y eliminar la multitarea al establecer la cantidad máxima de trabajo para cada estado de proyecto.
¿Qué cuestiones señala el CFC?
- El crecimiento del backlog indica las tareas no resueltas que tienen una prioridad demasiado baja para abordar en este momento o que están obsoletas
- El flujo inconsistente y los cuellos de botella repentinos indican qué áreas deben suavizarse en las etapas posteriores
- El ancho de cada banda muestra el tiempo promedio del ciclo
- La ampliación significativa del área «En progreso» puede significar que el equipo no podrá terminar todo el proyecto en tiempo
Eficiencia de flujo
La eficiencia de flujo es una métrica muy útil en el desarrollo Kanban que en su mayoría se pasa por alto por el desarrollo equipo. Si bien la eficiencia del flujo complementa el flujo acumulativo, proporciona información sobre la distribución entre el trabajo real y los períodos de espera. Es un caso raro cuando un desarrollador trabaja en una cosa a la vez sin esperar. La realidad suele ser más compleja. Y «trabajo en curso» es un nombre que no siempre coincide con el estado.
Por ejemplo, el código puede tener muchas dependencias y no puede comenzar a trabajar con alguna función antes de que se termine otra, o sus prioridades cambien, o esté esperando la aprobación de un stakeholder. Medir cuánto tiempo espera para trabajar puede ser incluso más útil que simplificar los procesos relacionados con el trabajo real.
Al observar los indicadores de eficiencia más bajos, puede comprender los principales cuellos de botella
Cómo usar la fórmula de cálculo de eficiencia de flujo
. A menos que aplique algún software de gestión de proyectos que incorpore estas métricas, puede calcular la eficiencia del flujo con esta sencilla fórmula: Trabajo/(trabajo+espera) * 100%. Luego puede visualizarlo digitalmente o incluso dibujar el gráfico en su pizarra de oficina.
Defina su eficiencia de flujo normal. Al igual que con todas las demás métricas, es imposible reclamar cifras normales para todos los proyectos. Algunos dicen que la marca del 15 por ciento está bien para la mayoría de los proyectos, lo que básicamente significa que un punto de la historia u otro elemento de trabajo espera un 85 por ciento contra un 15 por ciento de tiempo de procesamiento. David J. Anderson, un experto en administración de la Escuela de Administración de LeanKanban, sugiere que el objetivo para la mayoría de los equipos debería ser del 40 por ciento o más.
Descomponga los detalles del trabajo antes de fijar la eficiencia del flujo. El gráfico le permitirá ver los períodos de tiempo exactos en los que su eficiencia fue la más baja. Y estos datos deben analizarse con mucho cuidado, ya que la causa real y su remedio no se revelan tan fácilmente. Antes de iniciar acciones intensivas, haga una investigación exhaustiva de las causas.
Aumente la eficiencia del flujo con el análisis de bloqueadores. Un buen medio para darse cuenta del punto anterior es aumentar la eficiencia de su flujo con el análisis de agrupamiento de bloqueadores. Si algún trabajo está bloqueado, merece una pegatina de color u otra forma de señal visual para llamar la atención del equipo sobre estos bloqueadores y que puedan reaccionar ante ellos.
Puede marcar cuántos días se bloquea parte del trabajo y priorizar la resolución
Por lo general, los bloqueadores se acumulan en clústeres, ya que tienen muchas dependencias entre sí. Se puede realizar un mejor análisis de bloqueadores si los agrupa a partir de similitudes de alto nivel, como bloqueadores internos y externos, y luego especifica más por diseño, contenido faltante u otras características faltantes. El análisis de bloqueadores es una forma sencilla de investigar los valles en eficiencia de flujo.
Medir la calidad del código
Cobertura del código
La cobertura del código define cuántas líneas de código o bloques se ejecutan mientras se ejecutan pruebas automatizadas. La cobertura de código es una métrica crítica para la práctica de desarrollo basado en pruebas (TDD) y la entrega continua. Tradicionalmente, la métrica se interpreta mediante un enfoque simple:Cuanto mayor sea la cobertura de código, mejor. Para medir esto, necesitarás una de las herramientas disponibles, como un mono. Pero todos funcionan prácticamente de la misma manera: A medida que ejecuta pruebas, la herramienta detectará cuáles de las líneas de código se llaman al menos una vez. El porcentaje de líneas llamadas es la cobertura de tu código.
Los monos, por ejemplo, desglosarán la cobertura de código en cada medida de archivo y resaltarán las líneas cubiertas y descubiertas
Cómo usar la cobertura de código
Enfóquese en las líneas descubiertas y no sobrestime las cubiertas. Si la línea de código se llama una o más veces, no significa necesariamente que la función que admite funcione perfectamente y los usuarios permanezcan satisfechos. Llamar a una línea de código no siempre es suficiente para cerrar la tarea de prueba. Por otro lado, el porcentaje de líneas descubiertas muestra lo que no se ha cubierto en absoluto y puede merecer pruebas.
Prioriza el código cubierto y no apuntes al 100%. Si bien esto parece contradictorio, la cobertura del 100 por ciento no significa que haya probado el código correctamente. Tu proyecto tiene el código que importa y el resto de una base de código. Como la automatización de pruebas suele ser una iniciativa costosa, debe priorizar las características y los trozos de código correspondientes.
Automatización de pruebas en comparación con pruebas manuales
Esta medición define cuántas líneas de código dentro de una función ya están cubiertas con pruebas automatizadas en comparación con las que se prueban manualmente. Esto sigue directamente la métrica anterior, pero tiene un caso de uso específico. La proporción de automatización de pruebas en comparación con las pruebas manuales solo se utiliza cuando se necesita automatización crítica para cubrir regresiones. Las pruebas de regresión se realizan para verificar si algo se rompió después de las actualizaciones de funciones. Y si su producto experimenta mejoras constantes, lo que debería, las pruebas de regresión deben automatizarse. Si no lo es, sus especialistas de control de calidad manual tendrán que repetir los mismos escenarios de prueba repetidamente después de cada confirmación de actualización.
Puede utilizar los mismos instrumentos utilizados para la cobertura de código para dibujar esta métrica
Describir la cobertura de pruebas automatizadas por función le permitirá priorizar las características que 1) pueden sufrir regresión después de las actualizaciones y 2) para las que las pruebas automatizadas son críticas. Por lo general, no tiene suficiente tiempo y recursos humanos para cubrir todo mediante pruebas automatizadas a la vez, a menos que trabaje dentro del marco de desarrollo basado en pruebas. Por lo tanto, es mejor priorizar las funciones que seguramente afectarán la experiencia del usuario.
Complejidad ciclomática McCabe (MCC) del código
Las mediciones de complejidad de código se utilizan para evaluar los riesgos de problemas durante la prueba y el mantenimiento del código. Cuanto mayor sea la complejidad del código, más difícil será asegurarse de que tenga un número aceptable de errores y mantenga una alta capacidad de mantenimiento. El enfoque más común para medir la complejidad de código es la Métrica de Complejidad Ciclomática de McCabe (MCC). Una de las fórmulas para dibujar resultados de complejidad para MCC es la siguiente:
MCC = aristas-nodos + instrucciones de retorno
MCC en la imagen es igual a 3
Con esta métrica, los desarrolladores no estiman la complejidad de su código mirándola subjetivamente. A medida que los conjuntos de habilidades de los ingenieros difieren, sus evaluaciones varían, lo que hace que la refactorización de código o la corrección de errores sean más difíciles a largo plazo. Hay muchas herramientas de medición MCC en el mercado que se pueden combinar con otras métricas de complejidad de código, como la profundidad de la jerarquía de código y el número de líneas de código.
Especificaciones y trampas de uso de MCC
Equilibre la percepción humana y mecánica de la complejidad del código. Una de las principales razones para usar MCC es hacer que el código sea legible para otros desarrolladores. La legibilidad del código reduce los riesgos de incorporación a largo plazo de nuevos desarrolladores que tienen que lidiar con código heredado. También simplificará la refactorización en el futuro. El problema aquí es que el modelo MCC puede considerar inaceptables algunos métodos complejos pero legibles. Y si obliga a un desarrollador a refactorizar métodos complejos en muchos sub-métodos, puede lograr los resultados opuestos: Muchos métodos con lógicas simples pueden volverse aún más difíciles de comprender para un humano que un método único pero complejo.
No convierta a MCC en una métrica restrictiva. Algunas organizaciones practican la terminación de confirmaciones de código que no pasan la prueba MCC. Si bien esto puede aumentar potencialmente la simplicidad del código, es natural tener código complejo en los niveles de clases, métodos y funciones. Bloquearlos por completo no siempre es beneficioso. Una buena práctica es establecer KPI de complejidad de código general para los desarrolladores, lo que los animará a abordar la codificación de manera más consciente y pensar en la simplicidad.
Aplicar MCC para revisión de código. Otra práctica valiosa para las pruebas MCC es aplicarla durante las revisiones de código para reducir el alcance del trabajo a revisar fragmentos de código específicos donde los riesgos de defectos son más altos.
Pérdida de código
La pérdida de código es una visualización muy útil de las tendencias y fluctuaciones que ocurren en una base de código, tanto en términos del proceso general como del tiempo antes de una versión. La rotación mide cuántas líneas de código se agregaron, eliminaron o modificaron. A veces, los gráficos muestran las tres mediciones.
Este ejemplo de Microsoft incluye los tres parámetros, pero puede usarlos selectivamente
Aunque el seguimiento de la rotación de código puede parecer una métrica algo primitiva, permite evaluar la estabilidad del código en diferentes etapas de desarrollo. Debe esperar la estabilidad más baja durante los primeros sprints y la estabilidad más alta, con la rotación más baja concomitante, justo antes de un lanzamiento. Si su código es altamente inestable y la fecha de lanzamiento se acerca, haga sonar la alarma.
Casos de uso de pérdida de código
Busque regularidades. Los picos regulares en los cambios de código pueden revelar que el enfoque de generación de tareas no está lo suficientemente enfocado y produce muchas tareas grandes de forma recurrente.
Picos irregulares pero altos requieren investigación. Si tiene picos irregulares pero potentes en los cambios de código, puede investigar qué tareas causaron tales picos sísmicos en su código y reconsiderar el nivel de dependencias, especialmente si el número de líneas de código nuevas también aumentó el número de líneas cambiadas.
Presta atención a las tendencias. La estabilidad de su producto se vuelve bastante crítica antes de un lanzamiento. Como mencionamos, la tasa de abandono debería tener una tendencia decreciente cuanto más cerca esté tu equipo de un lanzamiento. Una tendencia creciente significa una posible inestabilidad del producto después de un lanzamiento porque es probable que el nuevo código no se someta a pruebas suficientes.
Apunta al progreso, no a controlar
Al igual que cualquier otro indicador de rendimiento, las métricas ágiles no siempre tienen respuestas distintas ni consejos prácticos que sellen tu éxito. Sin embargo, debe usar el conocimiento que proporcionan para iniciar una discusión, realizar una evaluación y ofrecer su propio plan para lidiar con problemas problemáticos.
Aunque las métricas proporcionan información numérica sobre el rendimiento de un equipo y la satisfacción general con el trabajo, no te fijes en ellas. Teniendo en cuenta que las métricas ágiles no están estandarizadas, no tiene sentido comparar los éxitos de diferentes equipos. Más bien, asegúrate de aceptar los comentarios de tu equipo, iniciar discusiones regulares y nutrir una atmósfera de objetivos y apoyo comunes.