,
6 minutos de lectura
Medición de los indicadores DORA
Recopilación de datos: manual frente a automatizada
La recopilación automatizada de datos es la mejor forma de evitar métricas inexactas que, a su vez, den lugar a decisiones empresariales erróneas. Sin embargo, es posible que no se pueda automatizar todos los parámetros que intervienen en el cálculo de una métrica debido a ciertas limitaciones. En tales casos, conviene acordar un enfoque manual que sea razonable y se ajuste a los estándares del sector.
Plazo de entrega:
Se mide en función del tiempo que tarda una función en pasar de la solicitud empresarial a la fase de producción. Esto se puede medir utilizando varias herramientas en cada etapa.
- Automatizar las pruebas y las implementaciones(flujos de CI/CD).
- Reducir el tamaño de los lotes(cambios más pequeños y más frecuentes).
- Mejorar los procesos de revisión y aprobación del código.
- Supervisar los cuellos de botella(por ejemplo, QA prolongados, aprobaciones manuales)
Método manual:
Cuando no se disponga de las herramientas o complementos necesarios para el cálculo automático del tiempo de entrega, se puede recurrir a un método manual. Puede calcularmanualmente el tiempo de entregaen Azure DevOps (ADO) o en sistemas similares utilizando extractos de datos sin procesar. A continuación se describe el procedimiento paso a paso:
Extracción de datos
- Fuente: Consulta de elementos de trabajo de ADO o API.
Ámbito de aplicación:
- Filtrar porcaracterísticas/historias de usuario marcadascomo«Hechas» (es decir, implementadas en producción).
Extracto:
- Fecha de creación(fecha en la que se solicitó el elemento de trabajo).
- Fecha de cierre/finalización(cuando se marca como «Hecho»).
Fórmula para calcular el tiempo de entrega de una característica o historia de usuario:
- Plazo de entrega ( por artículo) = Fecha de cierre - Fecha de creación
Fórmula para calcular la media a nivel de proyecto
- Plazo medio de entrega = Suma (plazo de entrega por artículo) ÷ Número total de artículos
* Nota: En los casos en que las funciones previstas se crean con antelación, la métrica del plazo de ejecución no reflejaría fielmente la realidad; en tales casos, se puede utilizar el tiempo de ciclo como métrica alternativa.
Frecuencia de implementación:
- Cuenta el número de implementaciones en producción durante un periodo determinado (por ejemplo, por día, semana o mes).
Extracción de datos:
- Utiliza herramientas de CI/CD (por ejemplo, GitHub Actions) para registrar el número de implementaciones.
Fórmula para calcular la frecuencia de implementación:
- Número total de despliegues/Número de meses
Fórmula para calcular la media a nivel de proyecto:
- Número de implementaciones del proyecto / Número de meses
*Nota: Según la definición del sector, las implementaciones de hotfixes no se incluyen en el recuento de implementaciones.
Índice de fallos:
¿Qué se considera una «implementación fallida»?
- Reversiones (revertir una versión debido a problemas).
- Correcciones de emergencia (parches urgentes posteriores a la implementación).
Método de seguimiento:
- Integrar con los errores de implementacióndel proceso de CI/CD (por ejemplo, Jenkins, GitHub Actions) para señalarlos.
- Utiliza herramientas de gestiónde incidencias (por ejemplo, ADO, Jira, ServiceNow).
Fórmula para calcular la tasa de fallos:
- 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 incidencias de soporte clasificadas como «errorde software».Si dividimos esta cifra entre el número total de cambios publicados, obtenemos el CFR.
Las organizaciones deben clasificar los incidentes periódicamente para que la métrica sea precisa.
Tiempo medio de reparación (MTTR):
¿Qué se considera «tiempo de recuperación»?
- Inicio:Cuando se detecta el fallo (se activa la alerta).
- Fin:Cuando el sistema se haya restablecido por completo (por ejemplo, una vez completada la reversión o implementada la corrección).
Método de seguimiento:
- Herramientas de gestión de incidencias(por ejemplo, ADO, Jira).
- Sistemas de monitorización(por ejemplo, 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 calcular a partir de los incidencias de soporte clasificadas como«error de software». La diferencia entre la «fecha de creación» y la «fecha de cierre», expresada en días, puede utilizarse como numerador.
El número de incidentes clasificados como «errordesoftware»puede utilizarse como denominador.
Integración de ADO, CI/CD y sistemas de monitorización
Recopilar estos datos periódicamente y optimizarlos ayuda a las organizaciones a mejorar la eficiencia en sus procesos de lanzamiento de software.
Contar con herramientas y complementos eficaces, y saber 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 para capturar los datos sin procesar necesarios para calcular estas métricas. El equipo de DevOps debe realizar una evaluación minuciosa teniendo en cuenta las necesidades futuras de la empresa.
Herramientas de visualización y paneles de control
Azure DevOps (ADO) ofrece funciones de panel de control con estos metadata y widgets para capturar algunas de estas métricas. Sin embargo, es esencial garantizar que metadata actualicen para cada elemento de trabajo a fin de generar métricas precisas.
Se pueden utilizar herramientas alternativas como Power BI o Grafana para mejorar la visualización y la elaboración de informes destinados a las partes interesadas.
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:los flujos de trabajo de DevSecOps extraen datos de herramientas dispares (sistemas de CI/CD, escáneres, sistemas de seguimiento de incidencias), lo que da lugar a cronologías que no coinciden, falsos positivos o lagunas.
- Sesgo en los informes manuales:las métricas recopiladas manualmente (por ejemplo, los informes de incidencias) suelen carecer de estandarización, lo que distorsiona tendencias comoel MTTR(tiempo medio de recuperación).
Solución:
- Garantizar la trazabilidad:utiliza metadata inmutables metadata por ejemplo,los ID de los pipelines de Azure DevOps o las confirmaciones de Git) para extraer datos relacionados con los cambios en el código.
- Validación mediante correlación entre herramientas:combinar datos de SonarQube (calidad del código), ADO para detectar anomalías y estándares del sector para validar los datos de las métricas
Disponibilidad de herramientas y complementos
Desafío:
- Es posible que las organizaciones no dispongan de acceso a herramientas integradas de DevSecOps (por ejemplo, escáneres SAST/DAST o sistemas de seguimiento de implementaciones) o que tengan dificultades para hacer frente a los costes de las licencias.
Solución:
- AprovechaAzure DevOps Marketplacepara obtener complementos (por ejemplo,OWASP ZAP,SonarQube).
- Recurre aalternativas de código abierto cuando el presupuesto sea limitado.
Configuración de ADO para la captura de Metadata
Desafío:
- Los datos sin procesar de ADO (compilaciones, versiones, elementos de trabajo) deben etiquetarse y vincularse adecuadamente para generar métricas comoel tiempo de entregaola frecuencia de implementación.
Solución:
- Aplicar campos obligatoriosen los elementos de trabajo y actualizaciones periódicas
- Utilizalas vistas de ADO Analyticsolos conectores de Power BIpara consultar metadata del proceso.
Actualizaciones efectivas de los cambios en el estado de los elementos de trabajo
Desafío:
- Las actualizaciones manuales del estado (por ejemplo, «Hecho» → «Aprobado») retrasan métricas comoel tiempo de ciclo.
Solución:
- Automatiza las transicionesmediantewebhooksde ADO oAzure Functions(por ejemplo, actualización automática al fusionar las solicitudes de incorporación de cambios).
- Asignar estados alas etapas de DevSecOps(por ejemplo, el estado «Revisión de seguridad» antes de la implementación).
No hay datos suficientes para generar métricas
Desafío:
- Los datos dispersos (por ejemplo, implementaciones poco frecuentes, bajo número de incidencias por proyecto) distorsionan las tendencias.
Solución:
- Establecer umbrales mínimos(por ejemplo, «Realizar un seguimiento solo si hay más de 5 incidencias de la categoría de errores de software»).
Métricas que no permiten tomar decisiones
Desafío:
- Las métricas de vanidad (por ejemplo, «un MTTR de 120 días») no impulsan la acción.
Solución:
- Centrarse enindicadores orientados a los resultadosy respaldados por datos suficientes
Resistencia organizativa y uso indebido
Resistencia organizativa
Desafíos:
- Miedo a quedar en evidencia:los equipos pueden mostrarse reacios a aceptar métricas que pongan de manifiesto ineficiencias (por ejemplo,unaelevadatasa de fallos en los cambiosdebido a rechazos por motivos de seguridad).
- Sobrecarga de herramientas:la introducción de nuevas herramientas de DevSecOps, metadata recopilar y los complementos (por ejemplo, los escáneres SAST) pueden generar rechazo si se perciben como algo perturbador o innecesario.
- Incentivos desalineados:los directivos priorizan un indicador frente a otro. El «tiempo de entrega» por sí solo puede llevar a conclusiones erróneas
Estrategias de mitigación:
- Las métricas de marcos como herramientas de mejora:
- Destaca cómo estos indicadores ayudan a la organización a largo plazo y permiten comparar o medir el rendimiento
- Métricas del programa piloto:
- Empieza con proyectos no críticos para demostrar su valor antes de implantarlos en toda la organización y céntrate en los indicadores que aportan valor empresarial.
Objetivos a largo plazo de la organización frente a resultados derivados de los indicadores
Desafío:
- Desalineación:La optimización de métricas a corto plazo (por ejemplo, mejorarla frecuencia de implementación) puede entrar en conflicto con los objetivos a largo plazo (por ejemplo, la reducción de la deuda técnica o la madurez en materia de cumplimiento normativo).
- Métricas de vanidad frente a la generación de valor:es posible que los equipos den prioridad a métricas que parecen buenas en lugar de a resultados significativos.
Solución:
Relacionar las métricas con los temas estratégicos:
- Relaciona los indicadores clave (por ejemplo,el plazo de entrega) con los objetivos empresariales (por ejemplo, «Acelerar la comercialización de productos para los que el cumplimiento normativo es fundamental»).
Desafío:
La trampa de las métricas al definir la hoja de ruta: centrarse excesivamente en una sola métrica (por ejemplo,el MTTR) puede llevar a pasar por alto problemas sistémicos (por ejemplo, una automatización de pruebas insuficiente).
Solución:
Carteras métricas ponderadas:
- Equilibrar los indicadores con los objetivos a largo plazo de la organización (por ejemplo, la frecuencia de implementación), la estabilidad (índice de fallos en los cambios) y el plazo de ejecución
Equilibrar los indicadores con la cultura del equipo
Los riesgos culturales del uso excesivo de métricas
Desafíos:
- El miedo a la evaluación:los equipos pueden percibir las métricas como una forma de vigilancia, lo que puede provocar estrés y agotamiento.
- Manipular el sistema:la presión por cumplir los objetivos (por ejemplo,la frecuencia de implementación) puede fomentar el uso de atajos (por ejemplo, saltarse los análisis de seguridad).
- La asfixia de la innovación:un enfoque excesivo en las métricas puede desalentar la experimentación (por ejemplo, el temor a que los fallos en las implementaciones afecten ala tasa de fallos en los cambios).
Solución:
- La seguridad psicológica es lo primero:
- Recalca que los indicadores sonherramientas de diagnóstico, no evaluaciones del rendimiento.
- Celebra el «aprendizaje a partir de los errores» (por ejemplo, análisis posteriores a los incidentes que mejoranel MTTR).
- Diseño de métricas dirigido por el equipo:
- Involucre a los ingenieros en la selección de los indicadores (por ejemplo, deje que elijan entreel tiempo de entregaoel tiempo de ciclocomo prioridad frente a la tasa de fallos en los cambios).
Métricas frente a la capacidad del equipo y las necesidades de formación
Las deficiencias en las capacidades que obstaculizan las métricas
Desafío:
Los equipos carecen de las habilidades necesarias para mejorar los indicadores clave (por ejemplo,plazos de entregaprolongados debido a la falta de familiaridad con las herramientas de seguridad)
Soluciones:
- Segmentación métrica basada en habilidades:
- Ejemplo: Realizar un seguimiento por separadodel plazo de entregapara los equipos que adoptan nuevas herramientas SAST
- Formación a medida:
- Automatizar los desencadenantes de formación (por ejemplo, sila tasa de fallos en el proceso debido a problemas de seguridades superior al 15 %, asignar formación modular).
- Indicadores de tutoría:
- Mide el porcentaje de sesiones de programación en parejapara fomentar el intercambio de conocimientos.
Métricas que no tienen en cuenta el crecimiento del equipo
Reto:
- El excesivo énfasis en los indicadores de resultados (por ejemplo,la frecuencia de implementación) resta importancia al desarrollo de capacidades.
Soluciones:
- Equilibrar los indicadores de resultados y de crecimiento:
- Relacionarla frecuencia de implementacióncon el porcentaje del equipo que contribuye al código del pipeline.
- Indicadores de trayectoria profesional:
- Ejemplo: Realizar un seguimiento del porcentaje de ingenieros que dirigen revisiones de seguridadpara fomentar el sentido de la responsabilidad.
Referencias
- Accelerate, de Forsgren, Humble y Kim
- Documentación de Azure DevOps
- Informes de Investigación y Evaluación de DevOps (DORA)
