Ressenya d'«Accelerate»: la ciència darrere de DevOps i els equips d'alt rendiment

La majoria de llibres sobre enginyeria de programari són opinió disfressada de consell. «Accelerate: The Science of Lean Software and DevOps», de Nicole Forsgren, Jez Humble i Gene Kim, no n'és un. Publicat el 2018, es fonamenta en quatre anys de recerca estadística rigorosa a través dels State of DevOps Reports, amb desenes de milers de professionals enquestats. Les afirmacions s'aguanten sobre dades, no sobre anècdotes.

Si dirigeixes un equip d'enginyeria i encara no l'has llegit, deixa aquesta ressenya a mitges i ves a comprar-lo. Després torna. Ho dic de debò: és el llibre més útil que he recomanat mai a tots els responsables d'enginyeria amb qui treballo.

Les quatre mètriques d'Accelerate (les DORA) són: la freqüència de desplegament — cada quan poses codi a producció; el lead time dels canvis — el temps que passa des del commit fins que el codi corre a producció; el temps mitjà de recuperació (MTTR) — quant trigues a recuperar el servei després d'una fallada a producció; i la taxa de fallades per canvi — quina part dels desplegaments provoca una fallada. Dues mesuren velocitat, dues mesuren estabilitat, i la troballa central del llibre és que els millors equips puntuen alt a totes quatre alhora.

La tesi central: com lliures programari prediu com va el negoci

L'argument central del llibre és senzill i potent: el rendiment en el lliurament de programari prediu el rendiment de l'organització. Els equips que lliuren programari més de pressa i amb més qualitat treballen, a més, en organitzacions més rendibles, amb més quota de mercat i amb empleats més satisfets.

No és correlació disfressada de causalitat. L'equip de Forsgren va fer servir anàlisi de clústers i modelització d'equacions estructurals per establir relacions predictives. Els equips d'alt rendiment no és que casualment treballin en empreses d'èxit: les seves pràctiques d'enginyeria contribueixen directament als resultats de negoci.

Això importa perquè et dona munició. La pròxima vegada que algú de direcció et pregunti per què cal invertir en CI/CD o reduir la fricció dels desplegaments, tindràs recerca revisada per parells per defensar-ho.

Les quatre mètriques DORA: velocitat i estabilitat no estan renyides

El llibre defineix quatre mètriques que distingeixen de manera fiable els equips d'alt rendiment dels de baix rendiment. Amb el temps s'han convertit en l'estàndard del sector com a mètriques DORA (DevOps Research and Assessment):

1. Freqüència de desplegament. Cada quan desplega a producció el teu equip. Els equips d'alt rendiment despleguen sota demanda, diverses vegades al dia. Els de baix rendiment, entre un cop al mes i un cop cada sis mesos.

2. Lead time dels canvis. El temps des del commit fins que el codi corre a producció. Els d'alt rendiment el mesuren en menys d'una hora. Els de baix rendiment triguen entre un mes i sis mesos.

3. Temps mitjà de recuperació (MTTR). Quan alguna cosa es trenca a producció, quant es triga a recuperar el servei? Alt rendiment: menys d'una hora. Baix rendiment: entre una setmana i un mes.

4. Taxa de fallades per canvi. Quin percentatge de desplegaments provoca una fallada a producció? Alt rendiment: 0-15%. Baix rendiment: 46-60%.

El que sorprèn és com aquestes mètriques es reforcen entre si. Els equips que despleguen més sovint tenen una taxa de fallades més baixa, no més alta. Les entregues petites i freqüents són intrínsecament més segures que els desplegaments big-bang. Això és contraintuïtiu per als gestors que pensen que anar més a poc a poc és anar més segur, i les dades desmunten aquest supòsit.

Les 24 capacitats: un diagnòstic sobre el qual pots actuar

Més enllà de les mètriques, el llibre identifica 24 capacitats, agrupades en cinc categories, que impulsen el rendiment en el lliurament de programari:

Capacitats de lliurament continu

• Control de versions per a tots els artefactes de producció
• Processos de desplegament automatitzats
• Integració contínua
• Desenvolupament trunk-based
• Automatització de proves
• Gestió de dades de prova
• Seguretat des del principi (shift left)
• Arquitectura feblement acoblada

Capacitats d'arquitectura

• Els equips poden desplegar de manera independent, sense coordinar-se
• Els equips poden fer proves de manera independent
• Sistemes feblement acoblats i ben encapsulats

Capacitats de producte i procés

• Bucles de feedback amb el client
• Visibilitat del flux de valor
• Treballar en lots petits
• Experimentació de l'equip

Gestió lean i monitoratge

• Processos lleugers d'aprovació de canvis
• Monitoratge i observabilitat
• Notificació proactiva de fallades
• Límits de WIP

Capacitats culturals

• Cultura organitzativa de Westrum (generativa vs. patològica)
• Cultura d'aprenentatge
• Col·laboració entre equips
• Satisfacció amb la feina
• Lideratge transformacional

La gràcia d'aquest marc és que és accionable. Pots avaluar el teu equip capacitat per capacitat i identificar àrees concretes de millora. Converteix el «hem de millorar» en «hem de millorar l'automatització de proves i avançar cap al desenvolupament trunk-based».

Com fer la teva pròpia avaluació de capacitats

Aquí és on el llibre passa de lectura interessant a eina pràctica. Així és com l'he fet servir:

1. Puntua cada capacitat de l'1 al 5. Fes que l'equip ho faci per separat i després compareu. Les diferències entre com percep una capacitat la direcció i com la perceben els enginyers de trinxera solen ser la troballa més reveladora.

2. Identifica els colls d'ampolla. No cal ser un 5 en tot. Busca les capacitats on puntues més baix i que tenen més palanca sobre les teves mètriques de lliurament. Normalment són l'automatització de CI/CD, la cobertura de proves i la freqüència de desplegament.

3. Fixa objectius de millora trimestrals. Tria 2-3 capacitats per trimestre. Defineix en concret què vol dir pujar-hi un punt. «Passar de desplegaments manuals a desplegaments automàtics a staging» és una millora de capacitat que pots mesurar.

4. Mesura les mètriques DORA abans i després. Et donen una manera objectiva de verificar si les millores de capacitats mouen l'agulla de debò.

He vist equips passar de desplegar un cop per setmana a desplegar cada dia en un trimestre, centrant-se específicament en el pipeline de CI i en l'automatització dels desplegaments. Només el guany en confiança dels desenvolupadors ja justifica la inversió.

Què ha envellit bé al cap de cinc anys

Les mètriques DORA són ara l'estàndard del sector. Google les va adoptar, va crear l'equip DORA i publica cada any els State of DevOps Reports, que continuen validant i ampliant la recerca original. Les mètriques són dins d'eines com Sleuth, LinearB i Jellyfish. Quan parlo amb altres CTO, les mètriques DORA són el llenguatge comú que fem servir.

Les troballes culturals són més vigents que mai. L'èmfasi en la cultura generativa de Westrum — confiança alta, la informació flueix, responsabilitats compartides, la novetat és benvinguda — encara ha guanyat importància des que els equips distribuïts es van convertir en la norma després del 2020. Les organitzacions patològiques (orientades al poder, poca cooperació, el fracàs es castiga) no poden sostenir un alt rendiment per molt bones eines que tinguin. Ho he vist passar desenes de vegades.

El desenvolupament trunk-based ha guanyat. El llibre el defensava quan molts equips encara treballaven amb branques de llarga durada. Avui el sector s'ha decantat majoritàriament per les branques curtes i els merges freqüents, i les dades continuen avalant aquest enfocament.

L'arquitectura importa més que les eines. La troballa que les arquitectures feblement acoblades permeten un alt rendiment independentment de la tecnologia escollida continua sent certa. Els equips que poden desplegar de manera independent superen els que no poden, tant si fan servir Kubernetes com Heroku.

Què no ha envellit tan bé

Les categories de ritme han quedat desfasades. Les classificacions originals — «elit, alt, mitjà, baix» — tenien llindars numèrics concrets que ja no reflecteixen la realitat del sector. Les expectatives de freqüència de desplegament han canviat dràsticament. El que era «elit» el 2018 avui és el mínim exigible per a molts equips.

El cloud native és un punt de partida, no una aspiració. El llibre dedicava molt d'esforç a defensar la infraestructura al núvol i l'aprovisionament automatitzat. El 2023 això és el comportament per defecte de la majoria de startups. La frontera s'ha desplaçat cap a l'experiència de desenvolupador, el platform engineering i les plataformes internes per a desenvolupadors.

El tractament dels microserveis es queda curt. La secció d'arquitectura encerta a identificar l'acoblament feble com a crític, però no aprofundeix en la complexitat operativa que introdueixen els microserveis. El sector ha après des de llavors — de vegades a cops — que els sistemes distribuïts porten la seva pròpia categoria de problemes.

La seguretat ha guanyat pes. El «shift left on security» era una capacitat entre 24. Avui, amb els atacs a la cadena de subministrament, les vulnerabilitats de dependències i els requisits regulatoris, mereixeria un llibre sencer per a ella sola.

El balanç

«Accelerate» va donar al sector una cosa que necessitava desesperadament: respostes basades en evidència a preguntes que portàvem dècades debatent a cop d'opinió. El lliurament continu ajuda de veritat? (Sí.) La cultura importa? (Més que les eines.) Es pot desplegar més ràpid sense sacrificar qualitat? (Sí: les dues coses van de bracet, no enfrontades.)

Cinc anys més tard, les troballes centrals no només s'aguanten: s'han convertit en la base sobre la qual es mesuren les organitzacions d'enginyeria serioses. Si dirigeixes un equip i prens decisions sobre procés, eines i cultura sense haver llegit aquest llibre, vas sense mapa.

A Conectia, les mètriques DORA formen part de com avaluem la maduresa d'enginyeria quan treballem amb clients. Els nostres enginyers sènior de LATAM han construït les capacitats que descriu el llibre — pipelines de CI/CD, proves automatitzades, fluxos trunk-based — perquè són les pràctiques que les dades del llibre premien una vegada i una altra.

Llegeix el llibre. Avalua el teu equip. Tria les dues capacitats que mouran més l'agulla. Comença per aquí.

Tres preguntes que em fan sempre sobre les mètriques d'Accelerate

Quines són les quatre mètriques DevOps d'Accelerate?

Freqüència de desplegament, lead time dels canvis, temps mitjà de recuperació (MTTR) i taxa de fallades per canvi — les «quatre claus» que DORA va convertir després en l'estàndard del sector. Les dues primeres mesuren el cabal de lliurament; les dues últimes, l'estabilitat. Mesurar-les totes quatre té sentit perquè es mouen juntes: els equips que lliuren en lots més petits i més sovint també trenquen menys producció i es recuperen abans.

Les mètriques d'Accelerate continuen sent vàlides el 2026?

Les mètriques, sí; els llindars del 2018, no. L'equip DORA de Google continua validant les quatre claus a la seva recerca anual State of DevOps, i segueixen sent el llenguatge comú que fem servir els CTO per comparar el rendiment de lliurament. El que ha envellit són les franges «elit / alt / mitjà / baix»: el que el 2018 comptava com a elit avui és el mínim per a molts equips, així que compara't amb la teva pròpia línia de tendència, no amb les taules del llibre. L'altra reserva és el que les mètriques no veuen — un pipeline que es recupera de pressa perquè un humà ho ha caçat no és el mateix que un que es cura sol, una distinció que desmunto a el mite del pipeline que es cura sol.

Com es comença a mesurar les mètriques DORA?

Amb dades que ja tens. La freqüència de desplegament i el lead time surten del sistema de CI/CD i del control de versions (esdeveniments de desplegament, marques de temps commit→desplegament); el MTTR surt de la línia de temps dels incidents (de l'alerta a la resolució); la taxa de fallades per canvi necessita una sola regla honesta sobre què compta com a fallada causada per un desplegament — un rollback, un hotfix, un incident obert dins d'una finestra. Instrumenta aquestes quatre fonts, publica els números cada setmana i només llavors pensa en eines. Si el teu pipeline no els pot produir, això ja és la primera troballa — la mena de feina per on sol començar la nostra pràctica de cloud i DevOps.

---

Estàs construint un equip que pugui assumir de debò les capacitats que descriu Accelerate? Parla amb un CTO.