6 min de lectura
Medición de métricas DORA
Recopilación de datos: manual frente a automatizada
La recopilación de datos automatizada es la mejor manera de evitar métricas inexactas que puedan llevar a tomar decisiones empresariales incorrectas. Sin embargo, debido a ciertas limitaciones, es posible que no se puedan automatizar todos los parámetros necesarios para calcular una métrica. En tales casos, acuerde un enfoque manual que sea razonable y esté alineado con los estándares de la industria.
Tiempo de Entrega:
Se mide en función del tiempo que tarda una funcionalidad en pasar desde la solicitud de negocio hasta la producción. Esto se puede medir empleando múltiples herramientas en cada paso.
- Automatice las pruebas y los despliegues (pipelines de CI/CD).
- Reduzca el tamaño de los lotes (cambios más pequeños y frecuentes).
- Mejore los procesos de revisión y aprobación de código.
- Monitoree los cuellos de botella (p. ej., ciclos de QA largos, aprobaciones manuales)
Método manual:
Cuando las herramientas/complementos requeridos no estén disponibles para el cálculo automatizado del tiempo de entrega, se puede adoptar un enfoque manual. Puede calcular manualmente el Tiempo de Entrega en Azure DevOps (ADO) o sistemas similares utilizando extracciones de datos sin procesar. A continuación, se muestra un enfoque paso a paso:
Extracción de Datos
- Origen: Consulta de elementos de trabajo de ADO o API.
Alcance:
- Filtre por Funcionalidades/Historias de Usuario marcadas como Completadas (es decir, desplegadas en Producción).
Extraiga:
- Fecha de Creación (cuando se solicitó el elemento de trabajo).
- Fecha de Cierre/Finalización (cuando se marcó como "Completado").
Fórmula para el tiempo de entrega de la funcionalidad/historia de usuario:
- Tiempo de Entrega (por elemento) = Fecha de Cierre - Fecha de Creación
Fórmula para el Promedio a Nivel de Proyecto
- Tiempo medio de entrega = Suma del tiempo de entrega por elemento ÷ Número total de elementos
* Nota: En los casos en que las características planificadas se creen con antelación, la métrica de tiempo de entrega no reflejaría la realidad y, en esos casos, el tiempo de ciclo se puede utilizar como métrica alternativa.
Frecuencia de despliegue:
- Cuente el número de despliegues en producción durante un período determinado (por ejemplo, por día, semana o mes).
Extracción de datos:
- Utilice herramientas de CI/CD (por ejemplo, GitHub Actions) para registrar el recuento de despliegues.
Fórmula para la frecuencia de despliegue:
- Número total de despliegues/Número de meses
Fórmula para el promedio a nivel de proyecto:
- Número de despliegues del proyecto/Número de meses
*Nota: Según la definición de la industria, los despliegues de correcciones rápidas (hotfixes) están excluidos del recuento de despliegues.
Tasa de error en los cambios:
¿Qué se considera un "despliegue fallido"?
- Reversiones (volver a una versión anterior debido a problemas).
- Correcciones rápidas (parches urgentes posteriores al despliegue).
Método de seguimiento:
- Intégrese con los fallos de despliegue de la tubería de CI/CD (por ejemplo, Jenkins, GitHub Actions) para señalar los errores.
- Utilice herramientas de gestión de incidentes (por ejemplo, ADO, Jira, ServiceNow).
Fórmula para la tasa de error en los cambios:
- Número de cambios fallidos ÷ Número total de cambios × 100.
Método manual:
Para calcular el número de cambios fallidos, se puede utilizar el recuento de incidentes de soporte clasificados como “Error de software”. Esto, dividido por el número total de cambios publicados, nos da la tasa de error en los cambios.
Las organizaciones deben clasificar los incidentes periódicamente para que la métrica sea precisa.
Tiempo medio de restauración (MTTR):
¿Qué se considera "tiempo de recuperación"?
- Inicio: Cuando se detecta el fallo (se activa la alerta).
- Fin: Cuando el sistema se restaura por completo (por ejemplo, reversión completada, revisión rápida implementada).
Método de seguimiento:
- Herramientas de gestión de incidencias (p. ej., ADO, Jira).
- Sistemas de monitorización (p. ej., CloudWatch, Prometheus) para registrar los tiempos de resolución.
Fórmula para calcular el MTTR:
- Suma de los tiempos de restauración ÷ Número de fallos
Método manual:
La suma de los tiempos de restauración se puede obtener en función de las incidencias de soporte clasificadas como «error de software». La diferencia en días entre la «fecha de creación» y la «fecha de cierre» se puede utilizar como numerador.
El recuento de incidencias clasificadas como «error de software» se puede utilizar como denominador.
Conexión de ADO, CI/CD y sistemas de monitorización
Recopilar estas métricas periódicamente y optimizarlas ayuda a las organizaciones a lograr eficiencia en la forma en que lanzan software.
Disponer de herramientas eficaces y complementos, e integrarlos, ayuda a automatizar la mayoría de estas tareas, a generar métricas y a tomar las decisiones adecuadas.
Azure DevOps (ADO) proporciona los Metadata necesarios para capturar los datos sin procesar con el fin de calcular estas métricas. El equipo de DevOps necesita una evaluación cuidadosa teniendo en cuenta las necesidades empresariales futuras.
Herramientas de visualización y paneles
Azure DevOps (ADO) ofrece capacidades de paneles con estos Metadata y widgets para capturar algunas de estas métricas. Sin embargo, es fundamental garantizar que los Metadata estén actualizados para cada elemento de trabajo con el fin de generar métricas precisas.
Se pueden emplear herramientas alternativas como Power BI o Grafana para mejorar la visualización y los informes destinados a los interesados.
Retos y consideraciones para las organizaciones
Recopilación de datos y uso de herramientas
Integridad de los datos y limitaciones de las herramientas
Desafíos:
- Fuentes de datos incoherentes: las canalizaciones de DevSecOps extraen datos de herramientas dispares (sistemas de CI/CD, escáneres, sistemas de seguimiento de incidencias), lo que genera cronogramas discrepantes, falsos positivos o lagunas.
- Sesgo en la elaboración manual de informes: las métricas elaboradas por personas (p. ej., informes de incidencias) a menudo carecen de estandarización, lo que distorsiona tendencias como el MTTR (tiempo medio de recuperación).
Solución:
- Aplicar la trazabilidad: utilizar Metadata inmutables (p. ej., identificadores de canalización de Azure DevOps, confirmaciones de Git) para extraer datos relacionados con los cambios de código.
- Validar mediante la correlación entre herramientas: combinar los datos de SonarQube (calidad del código) y ADO para señalar anomalías, y las normas del sector para validar los datos de las métricas.
Disponibilidad de herramientas y complementos
Reto:
- Es posible que las organizaciones no tengan acceso a herramientas de DevSecOps integradas (p. ej., escáneres SAST/DAST, sistemas de seguimiento de implantaciones) o que tengan dificultades con los costes de las licencias.
Solución:
- Utilice el Azure DevOps Marketplace para obtener complementos (p. ej., OWASP ZAP, SonarQube).
- Utilice alternativas de código abierto cuando los presupuestos sean limitados.
Configuración de ADO para la captura de Metadata
Reto:
- Los datos sin procesar de ADO (compilaciones, versiones, elementos de trabajo) requieren un etiquetado y vinculación adecuados para generar métricas como Lead Time o Deployment Frequency.
Solución:
- Haga obligatorios los campos en los elementos de trabajo y las actualizaciones periódicas
- Utilice ADO Analytics Views o conectores de Power BI para consultar los Metadata de la canalización.
Actualizaciones eficaces en los cambios de estado de los elementos de trabajo
Reto:
- Las actualizaciones manuales de estado (por ejemplo, Hecho → Aprobado) retrasan métricas como Cycle Time.
Solución:
- Automatice las transiciones mediante webhooks de ADO o Azure Functions (por ejemplo, actualización automática cuando se combinan las solicitudes de incorporación de cambios).
- Asignar estados a puertas de DevSecOps (por ejemplo, estado de Revisión de Seguridad antes del despliegue).
Datos insuficientes para generar métricas
Reto:
- Datos dispersos (p. ej., despliegues poco frecuentes, baja cantidad de incidentes por proyecto) que sesgan las tendencias.
Solución:
- Defina umbrales mínimos (p. ej., «Realizar seguimiento solo si hay >5 incidentes en la categoría de errores de software»).
Métricas que no son concluyentes para la toma de decisiones
Reto:
- Las métricas vanidosas (p. ej., «tiempo medio de restauración de 120 días») no impulsan la acción.
Solución:
- Concéntrese en métricas orientadas a resultados respaldadas por datos suficientes
Resistencia y uso indebido organizacional
Resistencia organizacional
Desafíos:
- Miedo a la exposición: Los equipos pueden resistirse a las métricas que destacan las ineficiencias (p. ej., una tasa de fallo de cambios alta debido a rechazos de seguridad).
- Sobrecarga de herramientas: Introducir nuevas herramientas de DevSecOps, metadata que debe capturarse y complementos (p. ej., escáneres SAST) puede generar rechazo si se percibe como disruptivo o innecesario.
- Incentivos desalineados: El liderazgo recompensa una métrica por encima de otra. El «tiempo de entrega» por sí solo puede inducir a error
Estrategias de mitigación:
- Enmarque las métricas como herramientas de mejora:
- Haga hincapié en cómo estas métricas ayudan a la organización a largo plazo y a comparar o medir el rendimiento
- Métricas piloto:
- Comience con proyectos no críticos para demostrar el valor antes de la implementación en toda la organización y concéntrese en las métricas que ofrecen valor empresarial.
Objetivos a largo plazo de la organización frente a los resultados derivados de las métricas
Reto:
- Desalineación: La optimización de métricas a corto plazo (p. ej., mejorar la frecuencia de despliegue) puede entrar en conflicto con los objetivos a largo plazo (p. ej., reducción de la deuda técnica, madurez del cumplimiento reglamentario).
- Métricas vanidosas frente a entrega de valor: Los equipos pueden priorizar las métricas que se ven bien por encima de los resultados significativos.
Solución:
Asigne métricas en cascada a temas estratégicos:
- Mapee las métricas (p. ej., tiempo de entrega) a los objetivos empresariales (p. ej., «Menor tiempo de comercialización para productos críticos para el cumplimiento reglamentario»).
Reto:
Trampa de las métricas al definir la hoja de ruta: Centrarse demasiado en una métrica (p. ej., tiempo medio de restauración) puede ignorar problemas sistémicos (p. ej., automatización de pruebas inadecuada).
Solución:
Portafolios de métricas ponderadas:
- Equilibre las métricas con los objetivos a largo plazo de la organización (p. ej., Frecuencia de implementación), la estabilidad (Tasa de fallos de cambio) por encima del tiempo de entrega
Equilibrio de métricas con la cultura de equipo
Los riesgos culturales del exceso de métricas
Desafíos:
- Miedo a la medición: los equipos pueden percibir las métricas como vigilancia, lo que genera estrés y agotamiento.
- Manipulación del sistema: la presión por alcanzar objetivos (p. ej., Frecuencia de implementación) puede incentivar atajos (p. ej., omitir análisis de seguridad).
- Asfixia de la innovación: un enfoque excesivo en las métricas puede desincentivar la experimentación (p. ej., el miedo a que las implementaciones fallidas afecten la Tasa de fallos de cambio).
Solución:
- La seguridad psicológica es lo primero:
- Enfatice que las métricas son herramientas de diagnóstico, no evaluaciones de desempeño.
- Celebre el "aprendizaje a partir de los fallos" (p. ej., revisiones posteriores a incidentes que mejoran el MTTR).
- Diseño de métricas liderado por el equipo:
- Involucre a los ingenieros en la selección de métricas (p. ej., permítales elegir entre el Tiempo de entrega o el Tiempo de ciclo como su prioridad frente a la Tasa de fallos de cambio).
Métricas frente a la capacidad del equipo y necesidades de capacitación
Brechas de capacidad que bloquean las métricas
Reto:
Los equipos carecen de habilidades para mejorar las métricas clave (p. ej., Tiempo de entrega lento debido al desconocimiento de las herramientas de seguridad)
Soluciones:
- Segmentación de métricas basada en habilidades:
- Ejemplo: realizar un seguimiento del Tiempo de entrega por separado para los equipos que adoptan nuevas herramientas SAST
- Capacitación justo a tiempo:
- Automatice los activadores de capacitación (p. ej., si la Tasa de canalizaciones fallidas por motivos de seguridad es >15 %, asigne capacitación modular).
- Métricas de tutoría:
- Mida el % de sesiones de programación en pareja para impulsar el intercambio de conocimientos.
Métricas que ignoran el crecimiento del equipo
Desafío:
- Poner demasiado énfasis en las métricas de resultados (p. ej., Frecuencia de Despliegue) devalúa la creación de capacidades.
Soluciones:
- Equilibre las Métricas de Resultados y de Crecimiento:
- Combine la Frecuencia de Despliegue con el % de Equipo que Contribuye al Código de la Pipeline.
- Métricas de Desarrollo Profesional:
- Ejemplo: Haga un seguimiento del % de Ingenieros que Lideran Revisiones de Seguridad para fomentar el sentido de pertenencia.
Referencias
- Accelerate, por Forsgren, Humble y Kim
- Documentación de Azure DevOps
- Informes de investigación y evaluación de DevOps (DORA)
