Métricas DORA 2026: cómo calcular las cinco

Un panel dice que la frecuencia de despliegue se duplicó este trimestre. Después alguien nota que el pipeline ahora también reporta los despliegues a staging y cuenta cada reintento, y que el número real no se movió. Cambió la forma de contar; la entrega siguió igual.

DORA es fácil de citar y difícil de calcular: la página oficial define cada métrica en una frase y deja la aritmética por tu cuenta. Esta guía pone las fórmulas, calcula las cinco sobre un registro pequeño y deja por escrito las reglas de conteo que deciden si tu número significa algo.

¿Cuáles son las cinco métricas DORA en 2026?

Las métricas DORA son cinco: tres de rendimiento y dos de inestabilidad. Se calculan con despliegues a producción de una aplicación o servicio y se leen en conjunto, en lugar de optimizar una sola. Las definiciones salen de la guía de métricas DORA, actualizada el 2026-01-05. La última columna es la fórmula que usamos aquí, porque la guía no publica ninguna.

Dos detalles de esta tabla suelen pasarse por alto. La recuperación está en el grupo de rendimiento, y las métricas son cinco: la página de historia registra que el tiempo medio de recuperación se renombró y redefinió en 2023 para dejar de contar fallos de causa externa, como la caída de un centro de datos. El retrabajo llegó en 2024.

flowchart TD
  accTitle: Las cinco métricas DORA y su fuente común
  accDescr: Un registro de despliegues a producción de un servicio, con hora de despliegue, horas de commit, resultado y hora de restablecimiento, alimenta cinco métricas. Rendimiento: tiempo de entrega de cambios, frecuencia de despliegue y tiempo de recuperación de despliegues fallidos. Inestabilidad: tasa de fallos de cambios y tasa de retrabajo de despliegues.
  L[(Despliegues a producción de un servicio: hora de despliegue, commits, resultado, restablecimiento)]
  L --> T[Rendimiento]
  L --> I[Inestabilidad]
  T --> T1[Tiempo de entrega de cambios]
  T --> T2[Frecuencia de despliegue]
  T --> T3[Tiempo de recuperación de despliegues fallidos]
  I --> I1[Tasa de fallos de cambios]
  I --> I2[Tasa de retrabajo de despliegues]

DORA también dice que las métricas sirven para medir “una aplicación o servicio a la vez”. Una frecuencia única para toda la organización mezcla sistemas que no tienen relación entre sí.

¿Cómo se calcula cada métrica DORA?

Cada métrica se reduce a un conteo o a una mediana sobre despliegues a producción. Todas necesitan los mismos datos: hora del despliegue, horas de los commits, una marca de resultado y, en los fallos, la hora en que se restableció el servicio. La tabla anterior trae las fórmulas; las decisiones detrás de ellas merecen una frase cada una.

El tiempo de entrega y la recuperación usan la mediana porque ambas distribuciones tienen colas largas. La guía de DORA no elige entre mediana y media; una implementación muy usada mide desde el commit hasta el fin del despliegue y toma la mediana entre despliegues. Al principio deja la media al lado: si queda muy por encima, unos pocos cambios esperaron muchísimo.

La recuperación necesita un punto de partida. Recomendamos contar desde que el despliegue fallido llegó a los usuarios hasta que el servicio se restableció, sea por rollback, corrección o apagando un flag. Partir desde la detección da números más cortos y esconde las alertas lentas. Sirve cualquiera si la mantienes.

¿Cómo se ve un ejemplo con 18 despliegues?

Toma un servicio durante 28 días. El pipeline registró 24 eventos de despliegue. Cinco fueron a staging y se excluyen. Una ejecución a producción falló antes de mover tráfico y se repitió doce minutos después, así que cuenta una sola vez. Quedan 18 despliegues a producción. El registro es ilustrativo y cada despliegue lleva un solo cambio.

flowchart TD
  accTitle: Cómo se cuentan los despliegues del ejemplo
  accDescr: 24 eventos de despliegue en el pipeline. Se excluyen 5 despliegues a staging y quedan 19. Una ejecución a producción falló antes de mover tráfico y se repitió, así que el par cuenta una vez y quedan 18 despliegues a producción.
  A[24 eventos de despliegue en el pipeline] --> B{¿Llegó a producción?}
  B -->|no: 5 ejecuciones en staging| X[Excluidas]
  B -->|sí: 19 ejecuciones| C{¿Se movió tráfico?}
  C -->|no: falló en el pipeline, se repitió 12 min después| Y[Cuenta una vez con su repetición]
  C -->|sí| D[18 despliegues a producción]
  Y --> D

Ahora los cinco cálculos.

xychart-beta
  accTitle: Tiempo de entrega por despliegue en el ejemplo
  accDescr: Gráfico de barras con el tiempo de entrega en horas de los despliegues D01 a D18, entre 0,5 y 70 horas, con una línea plana en la mediana de 15 horas.
  title "Tiempo de entrega por despliegue (ilustrativo)"
  x-axis ["D01", "D02", "D03", "D04", "D05", "D06", "D07", "D08", "D09", "D10", "D11", "D12", "D13", "D14", "D15", "D16", "D17", "D18"]
  y-axis "Horas" 0 --> 75
  bar [20, 6, 52, 14, 9, 0.5, 30, 18, 7, 26, 11, 70, 16, 5, 22, 2, 40, 12]
  line [15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15]

Tres cosas merecen una segunda mirada. La tasa de fallos y la de retrabajo difieren (3 frente a 2) porque el flag de D11 corrigió un fallo sin desplegar: es fallo, no retrabajo. Los despliegues D06 y D16 están dentro de los 18, porque son despliegues como cualquier otro. Y la mediana de 35 minutos descansa en tres eventos, uno mucho más largo que los otros dos, así que reporta el conteo y el caso más lento al lado.

Una caída de base de datos sin un cambio previo no aparecería en estos números. Pertenece al reporte de confiabilidad, junto a tus SLO.

¿Qué cuenta como un despliegue?

Para DORA, un despliegue es un cambio que llega a producción. Todo lo demás es una decisión que tomas una vez y dejas escrita, porque un pipeline cuenta lo que registre. Estas son las reglas que recomendamos; la guía de DORA resuelve pocas, así que tómalas como valores por defecto discutibles.

La última fila hace más daño que las demás. Si los incidentes dejaron de llegar desde tu herramienta de guardias en la tercera semana, la tasa de fallos cae a 0 % y la tendencia mejora. Concilia los despliegues con los incidentes conocidos antes de creerle a un buen mes.

¿Qué pasó con los niveles elite, alto, medio y bajo?

La guía actual de DORA no publica umbrales de nivel elite, alto, medio o bajo. Lo más cercano que dice es que los equipos de mejor desempeño rinden bien en las cinco métricas y los de peor desempeño rinden mal. Artículos antiguos y varios proveedores siguen vendiendo los cuatro niveles con cifras fijas.

Los umbrales no forman parte de la guía actual, y la página de historia de DORA tampoco los menciona. El anuncio de DORA 2025 describe un análisis de clústeres con “siete perfiles o arquetipos de equipo comunes”, cada uno con su mezcla de desempeño, estabilidad y bienestar. Nombra dos, “Foundational challenges” y “Harmonious high achievers”. Cada perfil se detalla en el capítulo sobre los siete perfiles de equipo del informe completo.

Los benchmarks de los proveedores salen de sus propios clientes y definiciones. Tu tendencia de seis meses, con reglas fijas, dice más que tu posición en la tabla de otra empresa.

¿El churn de código es lo mismo que la tasa de retrabajo de despliegues?

El churn de código y los commits revertidos son señales de código, mientras que la tasa de retrabajo es una proporción de despliegues; no son intercambiables. El retrabajo pregunta cuántos despliegues a producción existieron solo por un incidente. El churn pregunta cuánto código recién escrito se volvió a cambiar, algo que también ocurre en una refactorización sana.

El churn sigue siendo útil. En un estudio de 806 proyectos de código abierto que adoptaron Cursor, presentado en MSR 2026, las advertencias de análisis estático subieron 30 % y la complejidad del código cerca de 40 %, y ambas se mantuvieron después de que la ganancia de velocidad se esfumara en dos meses. Un preprint de 2026 encontró que los pull requests fusionados de agentes de IA recibieron una corrección posterior verificada en 30 días con probabilidades 1,62 veces mayores que las de los pull requests humanos en los mismos repositorios. Los dos estudian proyectos de código abierto y son correlacionales. Úsalos como motivo para mirar y revisa tus propios despliegues por incidente. Si solo tienes reverts, llama a la cifra “tasa de reverts (aproximación)”.

¿Las métricas DORA muestran si la IA está ayudando?

Muestran qué pasó con la entrega, y los datos de 2025 apuntan en dos direcciones. La investigación DORA 2025 reunió a casi 5.000 profesionales y más de 100 horas de datos cualitativos. En el resumen de Google Cloud, el 90 % usa IA en el trabajo, más del 80 % cree que aumentó su productividad y el 30 % declara poca o ninguna confianza en el código generado por IA. A diferencia del año anterior, la adopción de IA ahora tiene una relación positiva con el rendimiento de la entrega y con el desempeño del producto, y mantiene una relación negativa con la estabilidad de la entrega.

En la práctica, un tiempo de entrega que baja tras desplegar IA debería llevarte a revisar la tasa de fallos y el retrabajo de las mismas semanas. DORA plantea que la IA amplifica lo que una organización ya tiene: un equipo con una cola de revisión lenta y pocas pruebas termina metiendo más cambios en esa misma cola.

La atribución es lo difícil: un tiempo de entrega menor puede venir de tickets más pequeños, de un release nuevo o de un cambio de equipo. Necesitas datos de uso junto a los de entrega, separados por equipo y período. El artículo complementario sobre cómo medir la productividad con IA cubre ese cruce, incluido lo que la revisión y el retrabajo le hacen al ahorro aparente.

Si una métrica se mueve, ¿dónde conviene mirar?

Cuando una métrica se mueve, las otras cuatro y los registros explican por qué. Usa esta tabla como primera revisión y abre después los registros, porque cada fila también puede ser un efecto del conteo.

Preguntas frecuentes sobre las métricas DORA

¿Son cuatro o cinco métricas DORA?

Son cinco. El material antiguo lista cuatro y termina en el tiempo medio de recuperación, redefinido en 2023. En 2024 se añadió la tasa de retrabajo de despliegues.

¿Cómo se calcula la tasa de fallos de cambios?

Divide los despliegues que exigieron intervención inmediata entre todos los despliegues a producción del mismo período y servicio: en el registro de arriba, 3 ÷ 18 = 16,7 %. Define una vez qué es “intervención inmediata” (rollback, hotfix, flag apagado) y aplícala igual cada mes.

¿Cuenta un despliegue a staging?

No. El tiempo de entrega se define hasta producción, así que staging, QA y preview quedan fuera de las cinco métricas. Si los quieres, cuéntalos en un reporte aparte.

¿Conviene usar la media o la mediana para el tiempo de entrega?

La guía de DORA no prescribe ninguna. Recomendamos la mediana, con la media al lado mientras conoces la distribución.

¿Qué es un buen puntaje DORA?

La guía actual no publica umbrales numéricos. Dice que los equipos de mejor desempeño rinden bien en las cinco métricas. Compara un servicio con su propia tendencia antes de compararlo con otro.

¿Se puede medir a cada desarrollador con DORA?

No. DORA las define para una aplicación o servicio, y un despliegue es un resultado de equipo. La revisión, el diseño y los incidentes moldean los números sin figurar bajo el nombre de nadie.

¿Cada cuánto se revisan las métricas DORA?

Una vez al mes, con quienes operan el servicio. Los conteos de fallos son demasiado pequeños para leerlos cada semana.

¿Qué conviene hacer primero?

Elige un servicio y completa un registro como el de arriba con tus últimos 28 días. Quita staging, une los reintentos, vincula cada fallo con su hora de recuperación y concilia la lista con tu historial de incidentes. Si alguno de esos pasos cuesta, ya encontraste tu primer proyecto.