¿Qué son las métricas DORA? Los 4 indicadores clave
Resumen
Las métricas DORA cuantifican la entrega de software en cuatro dimensiones: velocidad de despliegue, tiempo desde commit a producción, estabilidad del código, y velocidad de recuperación ante problemas. Elite vs bajo rendimiento difieren 180x en despliegue y 2,500x en recuperación.
¿Qué son las métricas DORA? Los 4 indicadores clave
Que son las metricas DORA en realidad muy simple: cuatro medidas que cuantifican el desempeño de entrega de software. Específicamente miden: Frecuencia de Despliegue, Tiempo de Entrega para Cambios, Tasa de Fallos, y Tiempo para Restaurar Servicio. Desarrolladas por Nicole Forsgren, Jez Humble y Gene Kim, validadas en decenas de miles de equipos de ingeniería, adquiridas por Google en 2018. Este resumen cubre qué rastrea cada métrica, los benchmarks reales, y dónde el modelo deja de funcionar.
De dónde vinieron las métricas DORA y por qué la investigación importa
El programa DORA comenzó en 2014 con una pregunta específica: ¿qué hacen diferente los equipos de software de alto rendimiento respecto a todos los demás? El equipo de investigación realizó encuestas anuales de decenas de miles de desarrolladores en distintas industrias, buscando las prácticas que predecían resultados sólidos en la entrega de software.
El hallazgo que hizo que la investigación se mantuviera vigente fue contraintuitivo. Los equipos élite no sacrificaban velocidad por estabilidad. Desplegaban más rápido y tenían menos incidentes en producción. Ese resultado desmentía la justificación estándar para ralentizar los ciclos de lanzamiento: si desplegamos menos frecuentemente, romperemos menos cosas.
Los datos decían lo opuesto. Los equipos que desplegaban con frecuencia construían bucles de retroalimentación mejores, detectaban problemas más rápidamente, y se recuperaban más rápido cuando algo iba mal. La velocidad y la estabilidad no estaban en oposición. Estaban correlacionadas.
Google adquirió el programa DORA en 2018. El equipo ahora publica un informe anual State of DevOps, actualizó su modelo en 2025 con una quinta métrica (Rework Rate), y mantiene la investigación como una iniciativa abierta en dora.dev.
Las cuatro medidas y qué rastrea realmente cada una
El modelo fue actualizado en 2025 para agregar Rework Rate como una quinta métrica, pero los cuatro indicadores originales permanecen como base para la mayoría de herramientas y discusiones de equipos.
Frecuencia de Despliegue
Qué tan a menudo tu equipo sube a producción. Esa es la definición completa.
Los equipos élite despliegan a demanda: múltiples veces al día cuando algo está listo. Los de bajo rendimiento despliegan una vez al mes o menos, a veces una vez cada pocos meses. Para un desarrollador solo, cualquier cadencia de envío consistente semanal te coloca solidamente en el rango de alto rendimiento solo con esta métrica.
La frecuencia de despliegue es un proxy de confianza en el pipeline. Los equipos que despliegan con poca frecuencia generalmente tienen infraestructura frágil, puertas de prueba manual pesadas, o cadenas de aprobación organizacionales que ralentizan los lanzamientos. Los equipos que envían múltiples veces al día han automatizado la mayoría de esos cuellos de botella. La frecuencia es un síntoma, no la causa.
Tiempo de Entrega para Cambios
El tiempo desde que un commit llega al control de versiones hasta que ese mismo cambio está activo en producción.
La mayoría de esta duración no es escribir código. Es esperar: esperar a que la cola de pull requests se despeje, esperar a que los pipelines de CI/CD terminen, esperar un slot de despliegue, esperar a que alguien con acceso dispare el lanzamiento. Un tiempo de entrega de pocas horas significa que el flujo es apretado y en gran medida automatizado. Un tiempo de entrega medido en semanas significa que algo estructural está añadiendo fricción en uno o más de esos puntos de transición.
Para desarrolladores solo, el tiempo de entrega es lo que se interpone entre hacer push a un commit y que los usuarios vean el resultado. A veces es un pipeline de despliegue que toma doce minutos. A veces es la vacilación interna sobre si un cambio es lo suficientemente estable para enviar.
El porcentaje de despliegues que causan un problema lo suficientemente grave como para requerir un hotfix, rollback, o respuesta a incidentes.
Esta es la señal de calidad en el modelo DORA. El informe 2024 State of DevOps sitúa a los equipos élite alrededor del 5% de tasa de fallos en cambios. Los de bajo rendimiento corren entre 46 y 63%. Si aproximadamente la mitad de tus despliegues requieren intervención inmediata, tu cobertura de pruebas y proceso de revisión tienen gaps estructurales significativos.
La tasa de fallos en cambios no mide la calidad del código en abstracto. Mide si los cambios que envías se comportan como se espera en el entorno de producción específico. Una suite de pruebas que pasa localmente pero no cubre los caminos de integración que fallan en producción no va a mover este número.
Tiempo para Restaurar Servicio
Cuando un despliegue causa un incidente, ¿cuánto tiempo toma antes de que el servicio esté restaurado?
Esto fue originalmente etiquetado como Mean Time to Recovery (MTTR). El equipo DORA actualizó el framing en 2025 a Failed Deployment Recovery Time, rastreando específicamente la recuperación de incidentes causados por despliegues en lugar de fallos de infraestructura u outages de terceros. La distinción importa porque los incidentes causados por despliegues están completamente bajo el control del equipo, lo que los convierte en el blanco correcto para mejora de procesos.
Los equipos élite restauran servicio en menos de una hora. Los de bajo rendimiento pueden tomar días hasta una semana. Si eres un desarrollador solo, esta métrica es principalmente sobre si tienes alertas en lugar. Los equipos sin infraestructura de alertas se enteran de fallos por quejas de usuarios en lugar de señales automatizadas, lo que añade horas a cualquier tiempo de recuperación.
Cómo se ven realmente los niveles de desempeño
El informe State of DevOps agrupa equipos en cuatro niveles según sus números DORA. Estos son rangos aproximados del informe 2024, no cortes duros:
Equipos Élite: despliegan múltiples veces al día con menos de 1 hora de entrega, bajo 5% de fallos, recuperación menor a 1 hora.
Alto Rendimiento: despliegues diarios a semanales, 1-7 días de entrega, 5-10% de fallos, recuperación bajo 1 día.
Rendimiento Medio: despliegues semanales a mensuales, 1 semana a 1 mes de entrega, 10-15% de fallos, 1-7 días de recuperación.
Bajo Rendimiento: despliegues mensuales o menos, 1-6 meses de entrega, 46-63% de fallos, 1 semana a 6 meses de recuperación.
La brecha entre élite y bajo no es incremental. Según el informe 2024, los equipos de bajo rendimiento pueden tomar más de 180 veces más tiempo para desplegar y más de 2,500 veces más tiempo para recuperarse de incidentes comparado con equipos élite. Estas no son diferencias marginales.
Alcanzar el nivel élite es alcanzable con inversión sostenida en automatización CI/CD, cobertura de pruebas, y herramientas de observabilidad. No sucede escribiendo código más rápido. Sucede removiendo los pasos manuales y períodos de espera entre hacer commit de código y tenerlo corriendo en producción de forma confiable.
Cómo las herramientas de desarrollo IA están moviendo los números DORA en 2026
Para 2026, las herramientas de coding IA son lo suficientemente comunes como para afectar las métricas DORA de formas que vale la pena rastrear específicamente.
Los equipos usando Cursor, GitHub Copilot, o herramientas similares están escribiendo código más rápido, lo que tiende a empujar la frecuencia de despliegue hacia arriba. El tiempo de entrega también se ha acortado en muchos equipos porque se produce más código por desarrollador por semana, lo que significa más commits fluyendo a través del pipeline.
La tasa de fallos en cambios ha ido en ambas direcciones. Los equipos con procesos de revisión sólidos y cobertura de pruebas han mantenido sus tasas de fallos estables mientras envían más. Los equipos que envían código generado por IA sin revisión adecuada han visto que las tasas de fallos aumenten. El modelo DORA no le importa cómo se escribe el código. Mide qué sucede después de que el código se envía a producción.
El informe DORA 2024 State of DevOps encontró que el 41% de los equipos encuestados reportaron usar herramientas de desarrollo asistidas por IA. Esos equipos mostraron una frecuencia de despliegue más alta sin un aumento proporcional en la tasa de fallos cuando la adopción de IA estaba emparejada con pipelines de prueba automatizada y revisión.
Voilà, acá es donde se tranca en la práctica: la IA acelera el frente del pipeline significativamente. DORA te dice si esa aceleración se está absorbiendo limpiamente o está creando inestabilidad aguas abajo.
Herramientas para rastrear métricas DORA sin excederte en stack
La mayoría de equipos comienzan midiendo métricas DORA extrayendo datos de herramientas que ya usan: GitHub o GitLab para eventos de despliegue y timestamps de commits, PagerDuty u OpsGenie para datos de tiempo de recuperación, y el sistema de gestión de incidentes para conteos de tasa de fallos en cambios.
Varias plataformas han construido dashboards DORA específicamente alrededor de estas cuatro métricas:
Para un desarrollador solo sin presupuesto de herramientas: un script que registre el timestamp de cada despliegue a producción y cada evento de recuperación te da frecuencia de despliegue y tiempo de recuperación sin costo de infraestructura. El tiempo de entrega puede aproximarse desde timestamps de commits en el Git log.
Dónde las métricas DORA tienen límites reales
Medir DORA es útil. Tratarlo como la imagen completa del desempeño de ingeniería crea varios puntos ciegos específicos que vale la pena nombrar.
Acumulación de deuda técnica. Una frecuencia de despliegue alta con una tasa de fallos en cambios baja no te dice nada sobre si la base de código se está volviendo más difícil de trabajar con el tiempo. Un equipo puede alcanzar números DORA élite mientras acumula constantemente el tipo de deuda que hace que cada nueva característica sea más lenta de enviar. DORA mide la salida de entrega; no mide el estado de lo que estás entregando.
Alineación de resultados. La frecuencia de despliegue mide salida, no resultados. Enviar cinco veces al día no importa si ninguno de esos cambios mueve una métrica que el producto o negocio le importa. Banderas de características, infraestructura de testing A/B, y rastreo de métricas de negocio están completamente fuera del modelo DORA.
Sostenibilidad. El equipo de investigación DORA añadió una dimensión de experiencia de desarrollador al framework en 2023, reconociendo que el desempeño alto sostenible requiere ingenieros que no estén corriendo en burnout. Las cuatro métricas centrales no rastrean si alcanzar números élite está viniendo a costa de algo más.
Usa DORA como herramienta de diagnóstico de línea de base, no como scoreboard. Las preguntas que las métricas plantean son a menudo más accionables que los números mismos. Una tasa de fallos en cambios del 30% es menos útil que saber qué tipos de cambios fallan más frecuentemente y por qué.
Dónde comenzar si nunca has rastreado esto antes
Un side project de seis meses sin datos DORA es normal. La mayoría de equipos pequeños y desarrolladores solo nunca han medido nada de esto.
Si estás comenzando desde cero, elige frecuencia de despliegue y tiempo de entrega primero. Ambos son fáciles de extraer desde timestamps de commits de Git y logs de despliegue, y te dan retroalimentación inmediata sobre si tu pipeline tiene fricción innecesaria. Un tiempo de entrega de tres días para un cambio que toma cuarenta minutos escribir es una señal que vale la pena investigar.
La tasa de fallos en cambios y el tiempo para restaurar requieren que incidentes se acumulen antes de que los números signifiquen algo. Cuando algo se rompe en producción, registra el timestamp en que fue detectado y el timestamp en que fue resuelto. Esos datos se componen con el tiempo.
Un hábito práctico: después de cualquier incidente en producción, haz dos preguntas. ¿Cuánto tiempo tomó detectar este problema? ¿Cuánto tiempo desde la detección hasta la resolución? Esos dos números son los inputs para tiempo para restaurar. Rastreándolos consistentemente durante seis meses te da suficiente historial para saber si tu proceso de recuperación está mejorando o permaneciendo plano.
Tres razones para medir métricas DORA incluso como dev solo, una razón para no molestarse: las métricas hacen la fricción invisible visible, crean accountability para inversiones en automatización, y te dan algo concreto para mejorar entre trabajo de features. La razón para no molestarse: si eres pre-lanzamiento sin usuarios reales en producción, los números no significan mucho aún. Comienza a medir cuando estés enviando a usuarios reales regularmente.
No es una idea perfecta. Es una idea factible.