Una pregunta de entrevista: ¿cuántas métricas tiene DORA? La respuesta «cuatro» suena firme y es incorrecta desde 2025. Son cinco, una de las antiguas cambió de nombre, los niveles de Elite a Low quedaron abolidos y la propia DORA ya no es sigla de nada: el acrónimo se desligó y el informe anual pasó de llamarse Accelerate State of DevOps a State of AI-assisted Software Development.
Nada de esto es cosmético. Cada cambio viene justo de donde las métricas rompen equipos con más frecuencia.
Cinco métricas en lugar de cuatro
La quinta es deployment rework rate: la proporción de despliegues que nadie planificó y hubo que sacar por un incidente en producción. Capta lo que las cuatro anteriores no veían. Un equipo con una cadencia decente de releases y un change fail rate bajo puede gastar la mitad de sus despliegues limpiando las consecuencias de los anteriores, y con las cuatro métricas viejas ese equipo parece sano.
MTTR desapareció como nombre. En su lugar está failed deployment recovery time: la recuperación tras un despliegue que exigió intervención inmediata. La formulación es más estrecha que antes: la métrica habla de un despliegue, no de cualquier incidente.
Viene después el detalle en el que tropieza casi toda repetición del tema. Las cinco métricas se reparten en dos grupos, y el reparto es contraintuitivo:
| Grupo | Métricas |
|---|---|
| Throughput | change lead time, deployment frequency, failed deployment recovery time |
| Instability | change fail rate, deployment rework rate |
El tiempo de recuperación está en el rendimiento, no en la estabilidad. La lógica es sencilla: sacar un fix también es mover un cambio a través del sistema, y la velocidad la fija la misma tubería. En instability quedan dos métricas sobre lo mal que salen los propios despliegues. El tiempo de recuperación baja menos por un «proceso de respuesta» aparte que por lo mismo que acelera un release normal, más la capacidad de encontrar rápido la causa: sobre las herramientas de esa búsqueda hay un análisis aparte.
Los niveles ya no existen
Elite, High, Medium y Low quedaron retirados. El informe de 2025 —un análisis de clústeres sobre las respuestas de casi cinco mil personas— dio siete perfiles de equipo en los que rendimiento, estabilidad y bienestar de las personas se entrelazan. En un extremo están los «harmonious high-achievers», fuertes tanto en entrega como en bienestar. En el otro, equipos con «foundational challenges» y equipos encerrados en un «legacy bottleneck», donde los sistemas inestables van minando la moral.
El cambio de etiqueta no es lo importante. Los umbrales de los niveles se recalculaban cada año desde cero: «Elite» de 2019 y «Elite» de 2023 son cifras distintas. Un equipo que año tras año reportaba «somos High» se comparaba con un blanco móvil. Ahora no hay blanco, hay un perfil que incluye el desgaste.
Dónde las métricas rompen al equipo
DORA nombra dos maneras de arruinar una medición, y ambas viven en el panel típico de una plataforma.
La primera: convertir la métrica en objetivo. La ley de Goodhart no falla nunca: el encargo «subir la deployment frequency» se cura partiendo un release en cinco vacíos. El número sube, la entrega se queda igual. El movimiento sano va al revés, bajar el precio de un release para que la frecuencia suba sola: los despliegues canary y el despliegue atómico mueven a la vez frecuencia y change fail rate, porque cambian la mecánica y no el informe.
La segunda: comparar lo incomparable. DORA recomienda aplicar las métricas a una sola aplicación o servicio y advierte contra las comparaciones entre sistemas de naturaleza distinta. Fundir las métricas de varios equipos en una clasificación común es exactamente aquello para lo que suele montarse un panel.
De ahí la regla práctica: las cinco métricas miden el sistema de entrega, no a las personas. La tendencia de un equipo a lo largo del tiempo es un uso válido. Una tabla de posiciones entre equipos, no.
Dónde encaja SPACE
El SPACE framework (Forsgren, Storey, Maddila, Zimmermann, Houck, Butler; ACM Queue, febrero de 2021) responde a otra pregunta: no «a qué velocidad va el sistema», sino «cómo lo viven las personas». Cinco dimensiones: Satisfaction, Performance, Activity, Communication, Efficiency & flow. La tesis central de los autores es que la productividad no se reduce a una sola métrica, hacen falta varias dimensiones a la vez.
La dimensión más peligrosa es Activity. Commits, pull requests y despliegues son lo más fácil de contar y por eso llegan los primeros al informe de arriba. La actividad es contexto, no objetivo: «muchos commits» no equivale a «mucho valor», y retocar ese número es trivial.
Hasta 2025 los dos modelos se repartían el trabajo: DORA medía los resultados de la entrega y SPACE, cómo se sentía. Los perfiles de equipo borraron esa frontera. El bienestar está ahora dentro del mismo modelo con el que se mide la entrega.
Qué hacer con las cifras de las presentaciones
«Los equipos elite despliegan 208 veces más a menudo y tienen un lead time 106 veces más corto»: las cifras son reales, del Accelerate State of DevOps 2019. Tienen siete años, y los clústeres que describen quedaron abolidos. Una cifra así en una diapositiva de 2026 caracteriza el año en que se montó la diapositiva, no al sector.
La comprobación lleva cinco minutos. Si una métrica del panel se llama MTTR, si las métricas son cuatro y los equipos están repartidos en una escala de Elite a Low, la medición sigue una edición que los autores ya sustituyeron. Corregir nombres es barato. Sale más caro desprenderse de la costumbre de comparar equipos entre sí: la engendró precisamente aquella tabla.