Cualquiera que lleve un rato en software ha vivido esta discusión: “deployar más seguido es más riesgoso”, “si vamos rápido vamos a romper cosas”, “tenemos que elegir entre estabilidad y velocidad”. Es una de las creencias más arraigadas del oficio. Y resulta que es falsa — no por opinión, sino por datos.
Eso lo demostró un libro de 256 páginas publicado el 27 de marzo de 2018 por IT Revolution Press: Accelerate: The Science of Lean Software and DevOps, escrito por Nicole Forsgren, Jez Humble y Gene Kim. Ganó el premio Shingo de Investigación y Publicación Profesional en 2019. Y a diferencia de prácticamente cualquier otro libro de management de software que hayas leído, este no se basa en opiniones — se basa en cuatro años de encuestas a miles de equipos en cientos de empresas, analizadas con métodos estadísticos serios.
Si tu jefe te dice “no podemos deployar más seguido porque rompemos cosas”, este es el libro que pones sobre su escritorio.
Quién es la gente detrás del libro
Estos tres no llegaron a este tema por casualidad — cada uno trae una pieza del rompecabezas:
Nicole Forsgren es la pieza que faltaba. PhD en Management Information Systems por la University of Arizona (Eller College), ex-profesora en Utah State, ex-ingeniera de software en IBM. Lo importante: es la única autora con entrenamiento formal en investigación cuantitativa. Es ella quien metió rigor académico —encuestas validadas, modelado de ecuaciones estructurales, análisis de constructos latentes— a un campo que llevaba décadas operando con anécdotas. Tras la adquisición por Google, pasó a ser VP of Research & Strategy en GitHub (2020), y actualmente es Partner en Microsoft Research.
Jez Humble es coautor de Continuous Delivery (2010, con Dave Farley) — el libro que, literalmente, definió el término. Pasó por ThoughtWorks, hoy trabaja en el equipo DORA dentro de Google Cloud. La pieza práctica: él es quien ha visto pipelines de CD funcionando en cientos de equipos.
Gene Kim es el evangelista. Autor de The Phoenix Project (2013) y The DevOps Handbook (2016), fundador de IT Revolution Press. Es la persona que ha contado la historia del DevOps a la industria. Si has ido a un DevOps Enterprise Summit, fue él quien lo organizó.
Los tres juntos fundaron DORA (DevOps Research and Assessment) en 2015. Tres años después, Google Cloud los adquirió en diciembre de 2018. Hoy DORA sigue publicando reportes anuales bajo el paraguas de Google.
Cómo se hizo la investigación (la parte que casi nadie lee)
La razón por la que Accelerate no es “otro libro de opinión” está en el apéndice —que muy poca gente lee y que probablemente sea la sección más importante del libro—. Ahí Forsgren explica la metodología:
- Encuestas cuantitativas anuales (los State of DevOps Reports) desde 2014, con decenas de miles de respuestas acumuladas.
- Constructos latentes: en vez de preguntar “¿son ustedes buenos?”, se construyen escalas validadas con múltiples preguntas que miden el mismo concepto desde distintos ángulos.
- Structural Equation Modeling (SEM): una técnica estadística que permite establecer causalidad entre variables, no sólo correlación. Es la diferencia entre “estos dos números van juntos” y “este causa al otro”.
Si esto te suena a paper académico, es porque lo es. Esa es la novedad. Antes de Accelerate, la mayoría de la literatura de DevOps eran charlas de conferencia y posts de blog. Después de Accelerate, hay un benchmark.
“Our research has found that there is no tradeoff between improving performance and achieving higher levels of stability and quality. Rather, high performers do better at all of these measures.”
(Nuestra investigación encontró que no hay trade-off entre mejorar rendimiento y lograr mayores niveles de estabilidad y calidad. Más bien, los high performers son mejores en todas estas medidas.)
— Forsgren, Humble & Kim, Accelerate, capítulo 2.
Esa frase, respaldada por los datos, rompe la creencia central que tiene mucha industria: que ir rápido y ser estable están en conflicto. Los high performers van rápido Y son estables. Los low performers van lento Y son inestables. La tensión no existe — es un mito que justifica no mejorar.
Las cuatro métricas que cambiaron todo
Si alguien te dice “implemento DORA en mi equipo”, probablemente está hablando de estas cuatro. Son las únicas métricas que el libro defiende como predictoras de performance organizacional:
Las cuatro juntas miden cosas que realmente predicen si una organización entrega software bien — eso es lo que la investigación encontró. Otras métricas que podrías querer medir (líneas de código, story points, velocity, hours billed) no aparecen en el libro porque no tienen valor predictivo. No es que sean malas — es que no te dicen si tu organización entrega bien.
En el reporte de 2021 se sumó una quinta métrica: Reliability (operational performance) — qué tan bien se mantiene el servicio en producción más allá de la frecuencia de incidentes. Útil cuando los equipos ya dominan las cuatro originales.
Los cuatro niveles de performance (con datos crudos)
Hasta el reporte de 2024, DORA clasificaba a los equipos en cuatro niveles: Elite, High, Medium, Low. La tabla siguiente, sacada del 2019 State of DevOps Report, todavía es la mejor referencia visual de qué tan grande es la brecha:
| Métrica | Elite | High | Medium | Low |
|---|---|---|---|---|
| Deployment Frequency | A demanda (varias veces al día) | Entre 1× día y 1× semana | Entre 1× semana y 1× mes | Entre 1× mes y 1× cada 6 meses |
| Lead Time for Changes | Menos de 1 hora | 1 día a 1 semana | 1 semana a 1 mes | 1 mes a 6 meses |
| MTTR | Menos de 1 hora | Menos de 1 día | Menos de 1 día | 1 semana a 1 mes |
| Change Failure Rate | 0–15% | 0–15% | 0–15% | 46–60% |
La parte demoledora del reporte de 2019 es la brecha cuantificada entre Elite y Low:
- 208× más despliegues a producción.
- 106× más rápido del commit a producción.
- 2,604× más rápido recuperándose de un incidente.
- 7× menor tasa de fallas en cambios.
Eso no es “los buenos son un poco mejores que los malos”. Eso es órdenes de magnitud. Si alguna vez te has preguntado por qué algunas empresas parecen vivir en otro plano de la realidad mientras la tuya batalla para entregar un release, es exactamente esto.
Update importante (2025): el reporte de 2025 retiró la clasificación de cuatro niveles y la reemplazó por siete perfiles de equipo — un modelo más matizado que refleja que las organizaciones reales no caben en una escala lineal. Las cuatro métricas siguen siendo el corazón. La tabla anterior sigue siendo útil como referencia histórica para entender el orden de magnitud de la brecha.
Las 24 capabilities: lo que sí mueve la aguja
La parte menos famosa del libro pero más útil en la práctica: 24 capabilities que la investigación demostró que predicen performance. Organizadas en cinco categorías:
| Categoría | # | Ejemplos |
|---|---|---|
| Continuous Delivery | 8 | Version control everything, deployment automation, trunk-based development, test automation, shift left on security |
| Architecture | 2 | Loosely coupled architecture, empowered teams |
| Product & Process | 4 | Customer feedback, value stream visibility, working in small batches, team experimentation |
| Lean Management & Monitoring | 5 | Change approval lightweight, monitoring & observability, proactive failure notification, WIP limits, visualizing work |
| Cultural | 5 | Westrum culture, supportive leadership, employee satisfaction, learning culture, collaboration |
La forma de leer esto es así: estas son las cosas que, si las tienes, mejoran tus cuatro métricas. No son opcionales decorativas — están todas ahí porque cargaron peso estadístico significativo en los modelos.
Las dos que merecen mención especial:
Trunk-Based Development
El libro fue contundente: equipos que trabajan en una rama troncal con merges diarios superan a equipos con feature branches largos. Esto va contra el folclore de Git Flow que muchísima gente sigue por costumbre. Branches de larga vida son enemigos de la velocidad y de la estabilidad — porque retrasan integración, acumulan conflictos, y esconden problemas hasta que es muy tarde.
Si tu equipo aún usa branches que viven semanas, eso es la primera mejora que podrías hacer.
Loosely Coupled Architecture
Más interesante: el dato muestra que arquitectura desacoplada tiene más peso que casi cualquier otra capability. Equipos que pueden desplegar su servicio sin coordinarse con otros equipos son drásticamente más rápidos. Acá es donde DORA conecta directamente con Bounded Contexts de DDD — no es accidente.
“Architecture and the ability of teams to test, deploy, and operate their services independently are top predictors of continuous delivery performance.”
— Forsgren et al., Accelerate, capítulo 5.
La cultura sí importa (y se mide)
Una de las contribuciones más sutiles del libro es operacionalizar cultura — convertirla en algo medible. Para eso recurren a la tipología de Ron Westrum, originalmente publicada en Quality and Safety in Health Care (2004) para hospitales, y que Accelerate aplica a equipos de software:
El hallazgo: la cultura generativa predice performance de software delivery. Y a la inversa — equipos en culturas patológicas (donde se castiga al mensajero de malas noticias) literalmente no pueden mejorar, porque la información que necesitan para mejorar no fluye hacia donde pueda usarse.
Aplicación práctica: si vives en una empresa que cuando algo se rompe, busca al culpable en vez de buscar la causa raíz, no estás en una empresa donde DORA pueda funcionar. Esa es la primera reforma — postmortems sin culpables (blameless postmortems), aprendizaje sobre castigo. Sin esto, las otras 23 capabilities no logran agarrar tracción.
La crítica honesta a DORA
Para no escribir un evangelio: tres limitaciones reales del marco.
1. Métricas se pueden gamear. Si tu jefe te dice “súbele a la deployment frequency”, puedes deployar 50 cambios triviales al día y “mejorar” sin haber mejorado nada. Las cuatro métricas son útiles cuando se miran juntas y se contextualizan — no como targets aislados que se persiguen a ciegas. Esto es la Goodhart’s Law: cuando una métrica se vuelve objetivo, deja de ser una buena métrica.
2. Aplica mejor a equipos de producto. El libro muestra resultados muy fuertes en empresas que producen software de manera continua (SaaS, productos digitales, fintech). En empresas con software embebido, regulado, o de cliclos largos (aerospacial, dispositivos médicos, banca core), el modelo aplica con matices — no es directo.
3. La adquisición por Google introduce sesgo. Desde 2018, DORA está dentro de Google Cloud. Algunos de los reportes recientes —especialmente el de 2025 enfocado en AI-assisted development— vienen con un tono que mezcla research con marketing de productos de Google. Es una crítica legítima. El libro original (2018) sigue siendo la referencia más limpia.
El playbook pragmático
Si quieres aplicar DORA en tu equipo sin convertirlo en un teatro de métricas:
| Paso | Qué hacer |
|---|---|
| 1. Mide las cuatro, sin trampas | Instrumenta deployment frequency, lead time, MTTR, CFR a partir de tus datos reales (Git + tu sistema de incidentes). No estimes — mide. |
| 2. Mira tu posición histórica | ¿En dónde caes en la tabla? Sé honesto. Esa es tu línea base. |
| 3. Elige UNA capability | No quieras hacer las 24 a la vez. Si tu lead time es alto, ataca trunk-based development. Si tu CFR es alto, mejora test automation. Una capability a la vez. |
| 4. Mide después | Tres meses, seis meses. ¿Mejoraron las métricas? Si sí, otra capability. Si no, raíz causal. |
| 5. Cultura primero, herramienta después | Si tu cultura no es generativa (al menos burocrática tirando hacia generativa), las herramientas no van a ayudar. Postmortems sin culpa, aprendizaje. |
| 6. No las uses para evaluación individual | Las cuatro métricas son organizacionales, no personales. Usarlas para evaluar individuos las corrompe inmediatamente. |
El último punto es el más importante. He visto a demasiados managers convertir DORA en un OKR personal por programador. Eso destruye el sistema. La gente empieza a optimizar la métrica en vez del trabajo. Las métricas son del equipo y del sistema, no de Pedro o María.
La frase de Forsgren que vale guardar
Si me piden quedarme con una sola frase de Accelerate:
“Improving software delivery performance matters. (…) High performers were twice as likely to exceed organizational performance goals.”
(Mejorar el rendimiento de entrega de software importa. Los high performers tenían el doble de probabilidad de superar los objetivos organizacionales.)
— Forsgren et al., Accelerate, capítulo 1.
Esa frase pone fin a una vieja disputa: ¿realmente importa cómo entregamos software, o sólo importa qué entregamos? La respuesta, con datos, es que el cómo predice el qué. Equipos que entregan software de manera profesional logran sus objetivos organizacionales. Equipos que no, no.
Lecturas que sí valen la pena
- Nicole Forsgren, Jez Humble & Gene Kim (2018), Accelerate: The Science of Lean Software and DevOps, IT Revolution Press. ISBN 978-1942788331. El libro de este post. 256 páginas. Lectura obligada al menos los primeros 5 capítulos + el apéndice metodológico.
- DORA, State of DevOps Reports — los reportes anuales, todos en PDF gratis. El de 2019 tiene los benchmarks más citados; el de 2021 introduce Reliability; el de 2025 retira los cuatro niveles y propone siete perfiles.
- Jez Humble & Dave Farley (2010), Continuous Delivery, Addison-Wesley. La base técnica de la cual sale todo lo demás.
- Gene Kim, Patrick Debois, John Willis & Jez Humble (2016), The DevOps Handbook, IT Revolution. El manual práctico, complementario a Accelerate.
- Gene Kim, Kevin Behr & George Spafford (2013), The Phoenix Project, IT Revolution. La novela de DevOps. Útil para que tu jefe entienda de qué hablas.
- Ron Westrum (2004), “A typology of organisational cultures”, Quality and Safety in Health Care, 13(Suppl II): ii22–ii27. El paper original donde Forsgren tomó el modelo de cultura.
- DORA Quick Check, dora.dev/quickcheck — herramienta gratuita de Google para autoevaluar tu equipo en las cuatro métricas. Cinco minutos.
Y si te llevas una sola idea de todo el post: lo que mides, mejora; lo que no mides, no. La industria del software pasó treinta años discutiendo cómo entregar bien sin tener manera de medirlo. DORA cerró esa discusión con datos. Ahora la única excusa para no mejorar es no quererlo.