Por Qué las Métricas DORA Importan Más que la Velocidad
Cada planificación de sprint a la que he asistido tiene el mismo ritual. Alguien muestra el gráfico de velocidad, el equipo debate si los 42 puntos del último sprint fueron "buenos", y todo el mundo se compromete a llegar a 45 esta vez. Dos semanas después, el ciclo se repite. Nadie hace la pregunta que importa: ¿estamos mejorando en el lanzamiento de software?
La velocidad mide actividad. No dice nada sobre si esos puntos se tradujeron en valor, sobre si el código fue estable, o sobre si el equipo está mejorando. He visto equipos con velocidad disparada que no podían lanzar una función fiable para salvar su vida. Y equipos pequeños con un throughput modesto que desplegaban con confianza varias veces al día con incidentes casi cero.
¿La diferencia? El segundo grupo estaba siguiendo las métricas DORA.
¿Qué Son las Métricas DORA?
En 2018, Nicole Forsgren, Jez Humble y Gene Kim publicaron Accelerate: The Science of Lean Software and DevOps. El libro destiló años de investigación en cuatro métricas que predicen el rendimiento en la entrega de software. No opiniones — indicadores respaldados por datos y validados en miles de organizaciones.
Frecuencia de Despliegue — con qué frecuencia tu equipo despliega a producción. Los equipos de élite despliegan bajo demanda, varias veces al día. Los de bajo rendimiento despliegan mensualmente o menos. Esto captura tu capacidad de lanzar cambios pequeños e incrementales en lugar de lanzamientos grandes y arriesgados.
Lead Time para Cambios — el tiempo desde que se hace commit del código hasta que está corriendo en producción. Equipos de élite: menos de una hora. Bajo rendimiento: de uno a seis meses. Cada cuello de botella en tu pipeline — revisión de código, CI/CD, pruebas, aprobaciones — aparece aquí.
Tiempo Medio de Restauración (MTTR) — cuando producción falla, ¿cuánto tiempo se tarda en recuperarse? Los equipos de élite se restauran en menos de una hora. Los de bajo rendimiento tardan una semana o más. Esto refleja directamente tu monitoreo, alertas y respuesta a incidentes.
Tasa de Fallos en Cambios — qué porcentaje de despliegues causa un fallo en producción. Los equipos de élite se mantienen entre 0-15%. Los de bajo rendimiento superan el 46%. Esto captura la calidad del código, la cobertura de pruebas y la fiabilidad del pipeline.
El hallazgo contraintuitivo: la velocidad y la estabilidad no son compromisos. Los equipos de mayor rendimiento son a la vez los más rápidos y los más estables. Despliegan con más frecuencia, se recuperan más rápido y rompen menos.
Por Qué la Velocidad Te Falla
Es un número relativo e interno. Los story points significan cosas diferentes para diferentes equipos. Una velocidad de 60 no te dice nada sin un contexto profundo sobre lo que representan esos puntos. No hay ningún benchmark externo.
Incentiva el comportamiento equivocado. Cuando el liderazgo observa la velocidad, los equipos la optimizan. Inflan las estimaciones, dividen historias para aumentar los recuentos y evitan el refactoring porque no produce puntos "visibles". La métrica se convierte en un objetivo, y una vez que una métrica se convierte en objetivo, deja de ser una buena métrica — la Ley de Goodhart.
Mide outputs, no outcomes. ¿Un sprint donde el equipo quema 50 puntos pero rompe producción dos días? La velocidad dice gran sprint. DORA dice desastre.
Cómo Empezar a Seguirlas
No necesitas una plataforma. Empieza con algo simple.
Frecuencia de Despliegue. Cuenta los despliegues a producción por semana en tus logs de CI/CD. Si despliegas menos de una vez a la semana, tus lanzamientos son demasiado grandes, tus ramas viven demasiado tiempo o tu proceso de despliegue es demasiado doloroso.
Lead Time para Cambios. Timestamp del merge commit menos el primer commit en la rama. Si es más de una semana, encuentra la restricción: ¿retrasos en revisión de código? ¿CI lento? ¿Cuello de botella de QA manual?
MTTR. Registra los incidentes de producción: cuándo se detectaron, cuándo se resolvieron. Incluso una hoja de cálculo funciona. Apunta a menos de 24 horas inicialmente; menos de una hora es el nivel de élite.
Tasa de Fallos en Cambios. Despliegues que causaron incidentes dividido por los despliegues totales. Por debajo del 15% es élite. Por encima del 30% significa que tu pipeline de pruebas tiene agujeros.
La Conversación Cambia
Cuando los equipos cambian a las métricas DORA, las conversaciones se desplazan. En lugar de "¿cumplimos con nuestro compromiso de sprint?" preguntan "¿por qué se disparó nuestro lead time la semana pasada?" En lugar de debatir 3 puntos versus 5, los ingenieros investigan por qué falló el despliegue del jueves.
Las métricas DORA son indicadores adelantados. Una tasa de fallos en cambios creciente te advierte antes de la próxima interrupción. Un lead time que aumenta señala un cuello de botella antes de que se convierta en una crisis. La velocidad es un indicador rezagado del esfuerzo en el mejor caso — una métrica de vanidad en el peor.
Los story points todavía pueden ser útiles para la planificación del sprint dentro de un equipo. Pero nunca deberían ser la métrica que reportas al liderazgo, usas para comparar equipos, o tratas como salud de ingeniería. Para eso están las métricas DORA.
Hacerlo Persistente
Sigue las cuatro métricas semanalmente. Ponlas en un dashboard visible. Discute tendencias en las retros. Establece objetivos direccionales: "lead time por debajo de 3 días este trimestre" es útil. "Aumentar la velocidad en un 20%" no lo es.
Para la investigación más profunda, lee Accelerate de Forsgren, Humble y Kim. Es el libro más basado en datos sobre la entrega de software que he encontrado, y es suficientemente corto para un fin de semana.
En Conectia, cuando integramos ingenieros senior en el equipo de un cliente, una de las primeras cosas que miramos juntos es cómo el equipo mide su propio rendimiento. Los ingenieros que entienden las métricas DORA no solo escriben código — mejoran el sistema que entrega el código. Esa mentalidad es lo que separa a un desarrollador que ocupa un puesto de uno que eleva la capacidad del equipo.
¿Buscas ingenieros que se preocupen por el rendimiento de la entrega, no solo por las líneas de código? Habla con un CTO — nuestros ingenieros senior de LATAM traen las prácticas y la mentalidad que mueven tus métricas DORA en la dirección correcta.
