¿Qué son las métricas DORA y por qué importan al elegir un squad de desarrollo?

Las métricas DORA son los cuatro indicadores que la industria del software usa para medir, de forma objetiva, qué tan rápido y confiable entrega un equipo de ingeniería: frecuencia de despliegue, lead time for changes (tiempo desde el commit hasta producción), tasa de fallos de cambio y tiempo de restauración del servicio. Las definió el equipo de investigación DORA (DevOps Research and Assessment), hoy parte de Google Cloud, y se convirtieron en el estándar de facto para comparar el desempeño de entrega de un equipo sin depender de lo que ese equipo dice de sí mismo.

Ninguna de las cuatro mide líneas de código ni horas trabajadas —miden el resultado real: con qué frecuencia el equipo logra poner cambios en producción, cuánto tarda un cambio en llegar ahí, qué porcentaje de esos cambios rompe algo, y cuánto tarda el equipo en arreglarlo cuando pasa. Es la diferencia entre preguntar “¿cuántas horas trabajaron?” y preguntar “¿qué tan seguido entregan valor sin romper nada?”.

¿Qué mide cada una de las 4 métricas DORA?

• Frecuencia de despliegue (Deployment Frequency) — con qué frecuencia el equipo pone código nuevo en producción: varias veces al día, una vez por semana, una vez al mes.
• Lead time for changes — el tiempo que pasa desde que se hace un commit hasta que ese cambio está corriendo en producción.
• Tasa de fallos de cambio (Change Failure Rate) — el porcentaje de despliegues que termina causando un incidente, un rollback o un hotfix en producción.
• Tiempo de restauración del servicio (Time to Restore Service) — cuánto tarda el equipo en recuperar el servicio después de una falla en producción.

¿De dónde salen estas métricas y quién las definió?

El programa de investigación DORA lo fundaron Nicole Forsgren, Jez Humble y Gene Kim, y empezó a publicar el State of DevOps Report en 2013 —originalmente en conjunto con Puppet—. La síntesis de esa investigación llegó en 2018 con el libro Accelerate: The Science of Lean Software and DevOps, que conectó por primera vez estas cuatro métricas con resultados de negocio medibles (rentabilidad, productividad, participación de mercado) usando métodos estadísticos rigurosos, no opinión de industria. Google adquirió el programa poco después, y DORA opera hoy como un equipo de investigación dentro de Google Cloud.

¿Qué diferencia a un equipo de alto desempeño de uno de bajo desempeño?

La brecha es mucho más grande de lo que la intuición sugiere. Según el Accelerate State of DevOps Report 2019 de DORA/Google Cloud, los equipos de desempeño “elite” tenían 973 veces más probabilidades de desplegar bajo demanda y se recuperaban de una falla en producción 6.570 veces más rápido que los equipos de bajo desempeño. No es una diferencia de grado —es una diferencia de categoría.

El reporte más reciente, DORA State of AI-assisted Software Development 2025 (casi 5.000 profesionales de tecnología encuestados), muestra que esa brecha sigue vigente: solo el 19% de los equipos alcanza el nivel “elite”, apenas el 16,2% despliega bajo demanda, y el 23,9% todavía despliega menos de una vez al mes. La adopción de IA en desarrollo llegó al 90% en ese mismo reporte —pero más volumen de código escrito no mueve estos números solo: sin las prácticas de base (control de versiones, testing automatizado, feedback rápido) que las métricas DORA miden, un equipo simplemente produce más rápido lo mismo que ya venía produciendo.

¿Por qué importan estas métricas al elegir un squad externo, y no solo puertas adentro?

Puertas adentro, un equipo de ingeniería tiene manager, historial y visibilidad diaria. Con un squad externo esa visibilidad no existe de entrada: la empresa evalúa un perfil, unas referencias y una demo, y confía en que lo que ese equipo dice de sí mismo sea cierto. Ese es exactamente el problema que las métricas DORA resuelven —reemplazan lo autodeclarado (“somos senior”, “trabajamos ágil”, “entregamos rápido”) por evidencia que se puede verificar mirando el repositorio: cuántos despliegues hubo, cuánto duraron, cuántos rompieron algo, cuánto tardaron en arreglarlo.

¿Zenit mide algo parecido a esto?

ZenitRank sigue la misma lógica de fondo que las métricas DORA: reemplazar la reputación autodeclarada por evidencia objetiva de entrega —cumplimiento de milestones, evidencia de GitHub, consistencia de un proyecto al siguiente— en vez de estrellas o testimonios que nadie puede auditar. No es casualidad: es el mismo problema (cómo confiar en la capacidad de entrega de un equipo que no ves trabajar todos los días) resuelto con el mismo principio.

Ese mismo principio —evidencia en vez de reportes de estado— es la razón por la que Kaizen arma el match cruzando historial real de entregas, no solo un formulario de disponibilidad, y por la que cada milestone que ejecuta un squad en Zenit queda documentado con evidencia de GitHub, no con un update escrito a mano.

Las métricas DORA no son una certificación que un equipo se cuelga una vez y ya —son una fotografía continua de cómo entrega, proyecto a proyecto. Esa es la pregunta que vale la pena hacer antes de contratar un squad externo: no “¿qué dicen de sí mismos?”, sino “¿qué evidencia queda de lo que entregaron la última vez?”.