Las métricas DORA son las medidas estándar de la industria para el desempeño de la entrega de software, popularizadas por el programa DevOps Research and Assessment de Google. Leanmote sigue las cuatro sin configuración adicional, en la pestaña Rendimiento de Entrega de Software del dashboard de Desempeño de Entregas.
Las cuatro métricas DORA
Frecuencia de Despliegue (Deployment Frequency) — cada cuánto shipeas a producción. Una métrica de velocidad.
Tiempo de Entrega de Cambios (Lead Time for Changes) — cuánto tarda un cambio en llegar a producción. Otra métrica de velocidad.
Tiempo Medio de Recuperación (MTTR) — con qué rapidez restableces el servicio después de un incidente. Una métrica de estabilidad.
Tasa de Fallos de Cambios (Change Failure Rate) — qué porcentaje de los despliegues causa incidentes. Una métrica de calidad.
Leídas en pares, las cuatro métricas equilibran velocidad contra estabilidad. El objetivo es mejorar una sin romper la otra.
Por qué importan
La investigación de DORA correlaciona estas cuatro métricas con el desempeño general de la entrega de software y, de forma indirecta, con resultados de negocio. Los equipos que puntúan bien en las cuatro tienden a shipear más rápido y a recuperarse antes que sus pares. Seguirlas te da una referencia defendible y validada externamente.
Qué necesita Leanmote para calcularlas
Una integración de control de versiones (GitHub, GitLab, Azure DevOps) es el único requisito. Las cuatro métricas se derivan de tus repositorios:
Frecuencia de Despliegue — pull requests mergeados por día, o despliegues de GitHub por día si activas esa fuente (más abajo).
Tiempo de Entrega de Cambios — tiempo desde el primer commit (o la apertura del PR, según el método que configures) hasta el merge.
Tasa de Fallos de Cambios — proporción de PRs mergeados que se leen como trabajo correctivo, o proporción de despliegues a producción fallidos en modo despliegue.
Tiempo Medio de Recuperación — tiempo entre un PR mergeado y el hotfix o revert que lo siguió en el mismo repositorio.
No necesitas conectar una herramienta de gestión de incidentes: Leanmote infiere las señales de falla y de recuperación desde tus repositorios. Eso mantiene las cuatro métricas disponibles desde el primer día, a costa de algo de precisión — mira el artículo de cada métrica para saber exactamente qué se cuenta.
Dos formas de contar un despliegue
Por defecto Leanmote cuenta un pull request mergeado como un despliegue. Es un buen sustituto para los equipos que despliegan al mergear, y uno flojo para los que juntan varios merges en una release programada.
Si despliegas por GitHub, el propietario de la organización puede contar los despliegues en sí, en Configuración → Módulos → Desempeño de Entregas con Medir despliegues desde GitHub. Entonces:
La Frecuencia de Despliegue cuenta los despliegues a producción de GitHub.
La Tasa de Fallos de Cambios cuenta los despliegues a producción que GitHub reporta como fallidos.
El Tiempo de Entrega de Cambios y el Tiempo Medio de Recuperación siguen basados en el merge: el cambio de fuente no los afecta.
Al activarlo se trae automáticamente hasta un año de historial de despliegues, con un aviso de progreso en el dashboard mientras corre.
Cómo leer DORA en una revisión
Mira primero la Frecuencia de Despliegue — la dirección de las últimas 4 semanas.
Emparéjala con el Tiempo de Entrega. Despliegues frecuentes con tiempo de entrega en alza significa que los lotes están creciendo.
Valida la calidad con la Tasa de Fallos de Cambios. Si la velocidad sube y la tasa de fallos también, estás cambiando una cosa por la otra.
Cierra con el MTTR. Una tasa de fallos alta se tolera mejor cuando la recuperación es rápida.
Antes de comparar períodos, verifica si la fuente de despliegues cambió en el medio: las dos fuentes no son intercambiables.
Artículos relacionados
Frecuencia de Despliegue
Tiempo de Entrega de Cambios
Tiempo Medio de Recuperación
Tasa de Fallos de Cambios
Dashboard de Desempeño de Entregas