Al ajuste de las metas le sigue inevitablemente el seguimiento de su realización. Esta es una de las principales responsabilidades de todo gestor de proyectos, y los responsables de desarrollo de software no son una excepción.
Los gestores de proyectos utilizan KPI específicos para gestionar eficazmente los proyectos de desarrollo de software. La velocidad de desarrollo, la duración del ciclo y el plazo de entrega son todos ellos ejemplos de KPI que pueden utilizarse para el seguimiento de proyectos de software.
Estos KPI para el desarrollo de software son su caja de herramientas de datos objetivos para el seguimiento de cada paso en el ciclo de vida de desarrollo de software para identificar los cuellos de botella y trabajar hacia la mejora continua.
Veamos cómo los equipos de desarrollo de software pueden optimizar el proceso de desarrollo con la ayuda de los 25 principales KPI (indicadores clave de rendimiento) de desarrollo de software para impulsar la toma de decisiones.
25 KPI de desarrollo de software
Existen innumerables KPI adaptados a los objetivos específicos de la empresa y a los proyectos en curso. Aquí están los 25 principales que son transversales para mantener a su equipo de desarrolladores por delante de los objetivos.
1. Velocidad de desarrollo
Mejore las futuras estimaciones de Sprints creando informes de velocidad precisos y visualmente atractivos en ClickUp
Mida el rendimiento del equipo de desarrollo de software con la velocidad de desarrollo. Indica el trabajo total que su equipo puede realizar durante un sprint (un periodo fijo durante el cual deben completarse las tareas).
Dentro de un sprint, utilice puntos de historia para calcular el esfuerzo necesario para completar una tarea en una escala del uno al diez, siendo uno el más rápido y diez el más complicado. Midiendo cada sprint y cada punto de historia, puede comprender la velocidad media de su equipo de desarrollo en tres sprints.
Sin esta métrica, será difícil planificar, establecer prioridades, asignar recursos y ajustar expectativas realistas para futuros proyectos.
velocidad de desarrollo = Total de puntos de historia completados en un sprint_
2. Duración del ciclo
Seguimiento de la duración del ciclo en ClickUp Duración del ciclo es una métrica de DevOps Research and Assessment (DORA) para medir el tiempo empleado en realizar una tarea concreta. Cuantifica el rendimiento del equipo y estima el tiempo necesario para finalizar tareas futuras.
Por ejemplo, en el desarrollo de software, la duración del ciclo puede referirse al tiempo que se tarda en resolver un error, desde que se asigna a un desarrollador y se somete a pruebas de estabilidad y código hasta que se corrige y aprueba por parte del control de calidad.
Esta métrica ayuda a evaluar la productividad del equipo de desarrolladores e identifica áreas de mejora. Se puede comparar la duración del ciclo de cada tarea con la duración deseada para analizar dónde tiene carencias el equipo.
duración del ciclo = Hora de finalización - Hora de inicio
3. Cobertura del código
La cobertura de código, también llamada cobertura de pruebas, mide el porcentaje de código probado. Esta métrica DevOps mide la calidad del software con fines de producción y pruebas.
Da prioridad al desarrollo basado en pruebas (TDD) e identifica errores en los códigos. Cuanto mayor sea la cobertura del código, menores serán las incidencias.
cobertura del código = (Número de líneas de código ejecutadas por las pruebas / Número total de líneas de código) X100_
4. Frecuencia de despliegue
La implantación de metodologías ágiles puede dificultar la medición del rendimiento de la empresa, ya que todo el equipo debe hacer un seguimiento de métricas ágiles a lo largo del ciclo de desarrollo. Al realizar el seguimiento del rendimiento de herramientas de desarrollo de software y procesos bajo dicho proceso, puede depender del KPI de frecuencia de despliegue.
Determina la velocidad a la que el equipo de despliegue despliega el código en diferentes departamentos, como puesta en escena, pruebas y producción. Este KPI se encuentra entre las cuatro métricas de DORA y está interrelacionado con otros, como la tasa de fallos en los cambios, el plazo de entrega de los cambios y el tiempo medio de recuperación.
Este KPI de software proporciona información sobre la eficiencia y agilidad del equipo de desarrollo, establece puntos de referencia para mejorar las prácticas de despliegue y ayuda a la mejora continua.
frecuencia de despliegue = Número total de despliegues / Periodo de tiempo
5. Puntuación del promotor neto
El Net Promoter Score (NPS) mide la satisfacción del cliente en una escala de cero a diez, en la que cero describe la peor experiencia del usuario y diez la mejor.
Las personas que puntúan el software entre cero y seis se denominan detractores, siete y ocho son pasivos, y los que lo puntúan nueve o diez son promotores. Si el número de promotores supera al de detractores, entonces el software funciona bien.
net Promoter Score = (% promotores) - (% detractores)_
6. Tiempo medio entre fallos (MTBF)
Cuando se trata de medir la fiabilidad del software, la métrica MTBF cuantifica el tiempo medio entre dos fallos del software.
En el desarrollo de software, donde los fallos son inevitables, la métrica MTBF es fundamental para evaluar las tareas de software y desarrollar estrategias de reparación.
Tiempo medio entre fallos (MTBF) = Tiempo total de actividad/Número total de averías
7. Cambio Tasa de fallos
La medición de la calidad del software es compleja debido a su subjetividad. La métrica de la tasa de fallos en los cambios da una idea de la calidad del software calculando el porcentaje de implantaciones que conducen a un fallo en la producción.
Una tasa baja de fallos en los cambios indica menos incidencias y una alta calidad. Por el contrario, una tasa alta significa más incidencias y la necesidad de que el equipo renueve el código.
CFR = (Número de cambios fallidos/Número de cambios)/100
Es sencillo conectar ClickUp a través de integraciones Git para cosas como solicitudes de validación (pull requests)
8. Tamaño de la solicitud de validación (PR)
El tamaño de la solicitud de validación es una métrica de desarrollo de software que mide el número de cambios en el código en una sola solicitud de validación, lo que refleja el tamaño o el alcance de los cambios que introduce un desarrollador.
Las solicitudes de extracción pequeñas son más fáciles de revisar y procesar, lo que facilita una integración más rápida, proporciona información más específica y reduce el riesgo de errores. Por el contrario, los pull requests grandes tardan más en entenderse, revisarse y corregirse.
9. Ratio de detección de defectos (DDR)
El ratio DDR mide el número de defectos encontrados antes de la publicación en comparación con los encontrados después de la publicación.
Utilice la métrica DDR para evaluar el número de defectos no detectados por su equipo de pruebas y encontrados por los clientes, lo que repercute negativamente en su experiencia.
ratio de Detección de Defectos = (Defectos encontrados en una fase + Total de defectos) X 100_
10. Rotación de código
Los códigos necesitan revisiones frecuentes con las actualizaciones de software y la introducción de nuevas funciones. La métrica de rotación de código mide el número de veces que un código de software requiere iteración durante un periodo específico. Una mayor rotación del código indica un mayor mantenimiento y riesgo.
Por ejemplo, los equipos DevOp suelen funcionar con una tasa media de rotación de código del 25%, lo que indica que los códigos son eficientes en un 75%.
tasa de rotación de código = Total de líneas de código al principio - (Líneas añadidas + líneas eliminadas + líneas modificadas)/ Total de líneas de código X 100_
11. Simplicidad del código
Un código sencillo ejecutado con éxito es superior a un código complejo que exige iteraciones constantes. La simplicidad del código puede medirse utilizando varias métricas como la complejidad ciclomática, la duplicación de código, la rotación de código, etc.
Una buena simplicidad del código indica que el código consumirá menos tiempo, requerirá menos iteraciones y tendrá menos incidencias.
No existe una fórmula directa para medir la simplicidad del código, como la complejidad ciclomática, ya que se trata de una métrica más cualitativa que cuantitativa.
12. Flujo acumulativo
Utilice informes como flujos acumulativos o gráficos de agotamiento para comprender el progreso de su sprint
Los responsables de desarrollo de software a menudo quieren saber en qué fase se encuentran los proyectos de desarrollo de software. El flujo acumulativo demuestra, mediante diagramas visuales, si una tarea está aprobada, en curso o en la fase de backlog.
Diferentes colores representan diferentes estados. Además, la anchura de la banda indica la duración del ciclo. Este KPI de desarrollo de software le permite medir el estado de desarrollo del software, identificar los cuellos de botella y calcular el esfuerzo necesario para completar los elementos pendientes.
Lea también *Cómo es el día de un desarrollador de software*
13. Valoración de errores
La tasa de errores indica el número de incidencias identificadas durante las pruebas de software. La mayoría de los equipos de desarrollo de software utilizan esta métrica para comparar las tasas de errores entre proyectos, equipos y plazos, establecer puntos de referencia y fijar ajustes realistas para reducir los errores.
Puede observarse desde dos ángulos: el número total de errores detectados y la gravedad de las incidencias identificadas.
tasa de errores = (Número de errores detectados/ Número total de líneas de código) X 100_
14. Desglose de sprints
Visualice los (elaboración de) informes de sprint en ClickUp con gráficos de Burnup y Burndown
Mida el número total de tareas ejecutadas dentro de un sprint con la métrica de burndown de sprint. Es uno de los KPI clave de la ingeniería de software que determina el trabajo terminado durante los sprints. Reajuste el rendimiento del equipo si los resultados no coinciden con las expectativas.
Las empresas a menudo utilizan gráficos de sprint burndown y miden el tiempo y la cantidad de trabajo a completar en puntos de historia para comprobar las desviaciones del progreso ideal.
15. Burndown de lanzamiento
El desglose de la versión Métrica KPI mide el progreso del lanzamiento del producto y predice cuántos sprints se tardará en completar una versión basándose en sprints anteriores.
Utilice un gráfico de desglose de lanzamientos para calibrar si las operaciones se están ejecutando a tiempo o con retraso y demuestre el progreso del proyecto a las partes interesadas.
16. Eficacia del flujo
La métrica del indicador clave de rendimiento de la eficiencia del flujo realiza un seguimiento de la proporción de tiempo total y activo para dar una idea del periodo de inactividad y optimizar el flujo de trabajo.
eficiencia de flujo = (Tiempo de valor añadido / Plazo de entrega) X 100_
Tiempo de valor añadido = Tiempo dedicado a actividades que contribuyen directamente a las necesidades del cliente, como código fuente/pruebas.
Plazo de entrega total = Tiempo que transcurre desde que un elemento de trabajo entra en el sistema Kanban hasta que se entrega al cliente.
17. Tiempo medio de reparación (MTTR)
El tiempo medio de reparación se refiere al tiempo total que tarda un sistema en reparar un problema o fallo. Incluye el tiempo de reparación y prueba para incorporar todo el tiempo que se tarda hasta que el software es totalmente funcional.
Un MTTR alto en proyectos de desarrollo de software puede provocar tiempos de inactividad no planificados.
El MTTR evalúa la fiabilidad y disponibilidad de sus sistemas y equipos e identifica áreas de mejora y tendencias en los fallos para que sus desarrolladores de software puedan optimizar las estrategias de mantenimiento.
MTTR = Tiempo total de mantenimiento / Número de reparaciones
18. Tiempo de cola
El tiempo de espera es el tiempo de procesamiento desde que se emite un problema hasta que se resuelve. Se refiere al periodo en el que el ticket está todavía en la cola y sin atender o resolver.
Los tiempos de espera prolongados pueden deberse a la falta de especialistas en control de calidad, a una comunicación interna deficiente o a herramientas y compatibilidad insuficientes. Este KPI muestra lo optimizado que está el pipeline; por lo tanto, cuanto más bajo sea, mejor.
19. Tasa de compleción del alcance
Cuanto más rápido sea el proceso de completado de tickets, más positivamente se reflejará en la eficiencia del equipo de desarrollo de software. La tasa de finalización del alcance es una métrica que determina el número total de tickets completados dentro de un sprint.
Una tasa de finalización del alcance baja indica procesos no optimizados, objetivos poco realistas o muy pocos miembros del personal.
20. Alcance añadido
El alcance añadido es una métrica fundamental para todos los directores de desarrollo de software, ya que cuenta el número total de puntos de historia añadidos tras el inicio del sprint.
Un alto porcentaje de alcance añadido indica una falta de planificación para determinar los retos futuros. Interrumpe el plan del sprint al reducir la posibilidad de realizar nuevos trabajos.
Para reducir el alcance añadido, elimine las funciones que requieren más tiempo del que su equipo puede dedicar. También puedes elaborar una previsión de mantenimiento que indique el tiempo y el esfuerzo necesarios para mantener la función en funcionamiento a largo plazo.
21. Plazo de entrega
Personalice los gráficos de Plazo de entrega con ClickUp para realizar un seguimiento de las métricas críticas del proyecto
El Plazo de entrega mide el tiempo total de una tarea desde que se solicita hasta que se completa. A diferencia de la duración del ciclo para equipos de desarrollo de software, también tiene en cuenta el tiempo de espera, las aprobaciones y las revisiones necesarias antes de completar la tarea.
Un Plazo de entrega menor indica un plazo de comercialización más rápido, una mayor agilidad y una utilización eficiente de los recursos. Juntos, estos factores contribuyen a una mayor satisfacción del cliente.
plazo de entrega = fecha de despliegue - fecha de confirmación
22. Esfuerzo malgastado
La métrica del esfuerzo malgastado mide el tiempo y los recursos empleados en tareas que no contribuyen al proyecto final o a los objetivos de la empresa.
Por ejemplo, si el equipo trabajó en una función de software que se consideró irrelevante después de dos semanas, el esfuerzo malgastado sería la cantidad pagada a todos los desarrolladores por su trabajo en esas dos semanas.
Aumentar la productividad y reducir el plazo de comercialización, medir los KPI para el desarrollo de software, como el esfuerzo desperdiciado, y encontrar formas de reducirlo para el intento correcto del proyecto.
esfuerzo malgastado = (Esfuerzo total malgastado / Esfuerzo total) X 100
23. Interrupciones
Las métricas de interrupción miden el número total de tareas interrumpidas en un periodo determinado. También se puede medir el número total de interrupciones dentro de una tarea para tener una idea más clara.
Las interrupciones afectan directamente al rendimiento y deben medirse para no salirse de unos cronogramas realistas. Algunos ejemplos de interrupciones son los problemas técnicos, los fallos del sistema, las interrupciones personales o las debidas a la falta de disponibilidad de recursos.
índice de interrupciones = (Número total de interrupciones / Tiempo total trabajado) X 100_
24. Contratación y tiempo de rampa
Necesita recursos adecuados para ejecutar su ciclo de vida de desarrollo de software. La contratación de un equipo de desarrolladores cualificados a veces lleva tiempo, lo que subraya la necesidad de establecer expectativas realistas de realización de tareas.
El tiempo de contratación define el periodo desde que el candidato solicita un trabajo hasta que lo acepta. Con esto, cuenta el tiempo de rampa, que se refiere al tiempo entre el momento en que el candidato es contratado para un rol y el momento en que se vuelve plenamente productivo en él.
Tenga en cuenta estos dos marcadores a la hora de estimar el ciclo de vida del desarrollo de software.
25. Fecha prevista de entrega
Las partes interesadas a menudo exigen una fecha de envío estimada para la finalización del software, y este KPI ayuda a los departamentos multifuncionales a planificar su trabajo.
La fecha de entrega puede cambiar a medida que progresan las operaciones y puede modificarse cuando se produzcan cambios.
Lea también: ¿Cuál es la diferencia entre_ OKR y KPI 🎯
Impacto de la garantía de calidad en los KPI de desarrollo de software
La garantía de calidad debe ser fundamental para medir las métricas de desarrollo de software, desde la identificación de fallos de seguridad hasta las pruebas del software para la identificación de errores.
Un proceso de pruebas estructurado y fiable garantiza que el equipo de desarrollo corrija todos los errores y problemas antes de que el cliente utilice su producto/software.
Además, una entrega de calidad óptima reduce el tiempo de reelaboración del código y disminuye la tasa de errores y el índice de detección de fallos. Por eso recomendamos optimizar la garantía de calidad para que los procesos de desarrollo de software sean rápidos y fluidos.
Mida los KPI de desarrollo de software para maximizar sus posibilidades de cumplimiento del proyecto
El desarrollo de software es un proceso iterativo que requiere un seguimiento y ajustes frecuentes para garantizar el intento correcto del proyecto. El ajuste de los KPI de desarrollo de software mantiene a todos responsables y asegura que los esfuerzos de desarrollo de software se centran en los objetivos de la empresa.
Sirven como la Estrella del Norte para los equipos de desarrollo de software, midiendo el progreso diario y ayudando a los líderes y gerentes a entender mejor el panorama general.
Integre el software de gestión de proyectos de ClickUp con el proceso de entrega de software para medir el progreso, realizar un seguimiento de los KPI, ajustarlos según sea necesario y optimizar su proceso de desarrollo. Regístrese gratis, gratuito/a en ClickUp para ajustar y hacer un seguimiento de sus KPI de desarrollo de software.