En pocas palabras
Cinco métricas del programa DORA para evaluar la velocidad y estabilidad de la entrega de software.
Qué problema resuelve
Falta de evidencia sobre dónde se atascan o fallan las entregas.
Cuándo utilizarlo
Mejora continua de un servicio. Ejemplo: comparar resultados antes y después de automatizar pruebas.
De la idea a la práctica
Funcionamiento, ejemplos y decisiones para pasar al siguiente nivel.
Las cinco métricas
| Métrica | Qué mide |
|---|---|
| Change lead time | Tiempo desde el commit hasta su despliegue en producción. |
| Deployment frequency | Frecuencia de despliegues en producción. |
| Failed deployment recovery time | Tiempo para recuperarse de un despliegue fallido que exige intervención inmediata. |
| Change fail rate | Proporción de despliegues que requieren intervención inmediata, como un rollback o hotfix. |
| Deployment rework rate | Proporción de despliegues no planificados realizados como consecuencia de incidentes en producción. |
La denominación actual de recuperación reemplaza al MTTR genérico y delimita el fallo a un despliegue. El retrabajo mide despliegues correctivos, no cualquier modificación de código. Conviene seguir tendencias del mismo servicio y usar las cinco métricas juntas para mejorar el proceso.
Cómo medirlas
Acuerda qué cuenta como despliegue, fallo e intervención. Relaciona commits, ejecuciones del pipeline e incidentes de una misma aplicación. Los tiempos requieren marcas consistentes y las tasas un denominador común: los despliegues del período.
Ejemplo: una línea base mensual
En un servicio se realizan 40 despliegues: cuatro requieren intervención inmediata y tres son correcciones no planificadas por incidentes. La tasa de fallo es 4/40 = 10 % y la de retrabajo 3/40 = 7,5 %. Ambas describen aspectos diferentes y pueden solaparse.
Completa la lectura con frecuencia, tiempo de commit a producción y recuperación de despliegues fallidos. Compara la evolución tras una mejora concreta, como reducir el tamaño de los cambios.
Capacidades que mueven las métricas
Las métricas son el resultado; lo que se gestiona son las capacidades. La investigación de DORA identifica, entre otras:
| Ámbito | Capacidades |
|---|---|
| Técnico | Integración continua, trunk-based development, automatización de pruebas y despliegues, arquitectura poco acoplada, observabilidad |
| Proceso | Lotes pequeños, flujo visible, aprobación de cambios ligera, retroalimentación de clientes |
| Cultura | Cultura generativa (Westrum), aprendizaje continuo, foco en el usuario, bienestar del equipo |
Elige una o dos capacidades a la vez, haz un cambio y observa la tendencia de las métricas durante varias semanas.
Lectura conjunta para gerencia
| Patrón observado | Lectura probable |
|---|---|
| Frecuencia alta, fallo alto | Se entrega rápido sin red de seguridad: pruebas o canary insuficientes |
| Frecuencia baja, fallo bajo, lead time largo | Estabilidad a costa de lotes grandes y aprobaciones pesadas |
| Recuperación lenta con fallo bajo | Pocos incidentes, pero sin práctica de rollback ni runbooks |
| Retrabajo creciente | Deuda o calidad deteriorándose; revisar hotspots |
Los informes anuales de DORA publican agrupaciones de desempeño (de bajo a élite) que sirven como orientación, pero sus umbrales cambian cada año: compara cada servicio sobre todo consigo mismo.
Antipatrones frecuentes
- Objetivos de frecuencia por equipo: se fragmentan despliegues artificialmente.
- Comparar equipos con contextos distintos (app móvil frente a core bancario).
- Medir solo velocidad e ignorar estabilidad, o al revés.
- Usar DORA para personas. Para la experiencia del equipo, complementa con SPACE.
Criterios de implementación
Mide por servicio y comparte la interpretación entre desarrollo y operaciones. Documenta el criterio de agregación de tiempos. Usa las tendencias para orientar mejoras, sin convertir una cifra aislada en una cuota o ranking individual.
Continúa en las fuentes
Documentación oficial para verificar detalles y explorar más.