Accelerate: I Punti Chiave per gli Engineering Leader

In questo articolo:

• Cos’è Accelerate e perché è importante
• Le quattro metriche chiave per la performance di consegna del software
• Cosa dice la ricerca sulle pratiche tecniche
• La cultura organizzativa e il suo ruolo nella performance di consegna
• Cosa dovrebbero fare gli engineering leader con questa ricerca
• Conclusione

La sintesi del libro Accelerate che la maggior parte delle persone condivide si concentra sulle quattro metriche. È comprensibile, perché le metriche sono la parte più immediatamente azionabile della ricerca. Ma il libro di Nicole Forsgren, Jez Humble e Gene Kim contiene un argomento più ampio che gli engineering leader devono comprendere per applicare correttamente i risultati. L’affermazione centrale è che la performance di consegna del software è sia misurabile che migliorabile, e che le pratiche tecniche e culturali che la guidano sono alla portata di qualsiasi organizzazione disposta a investirci. Questo articolo estrae i risultati più rilevanti per CTO, engineering manager e fondatori tecnici che prendono decisioni su come organizzare e migliorare i propri team.

Cos’è Accelerate e Perché è Importante

Accelerate, pubblicato nel 2018, è il prodotto di quattro anni di ricerca condotta attraverso i sondaggi State of DevOps. La ricerca ha incluso dati da decine di migliaia di rispondenti in organizzazioni di ogni dimensione e settore. Gli autori hanno utilizzato metodi statistici rigorosi, tra cui la structural equation modelling, per identificare relazioni causali piuttosto che correlazioni.

Questo distingue il libro dalla maggior parte della letteratura sull’engineering management. Le conclusioni non si basano su aneddoti o esperienze di consulenza. Si basano su dati, e i dati mostrano quali pratiche causano effettivamente una migliore performance di consegna del software.

Il libro classifica le organizzazioni in quattro cluster di performance: elite, alto, medio e basso. Le differenze tra i cluster non sono marginali. I performer elite effettuano deployment su richiesta, hanno lead time misurati in ore, ripristinano il servizio in meno di un’ora e hanno change failure rate inferiori al 15 percento. I performer bassi effettuano deployment mensilmente o meno, hanno lead time misurati in mesi, impiegano giorni per ripristinare il servizio e hanno change failure rate superiori al 46 percento.

Il divario tra performance elite e bassa non è spiegato principalmente dal budget, dalla dimensione del team o dallo stack tecnologico. È spiegato dalle pratiche.

Le Quattro Metriche Chiave per la Performance di Consegna del Software

Le quattro metriche chiave di Accelerate costituiscono la base di quello che ora viene chiamato framework DORA. Misurano due dimensioni della performance di consegna: velocità e stabilità.

Deployment frequency misura la frequenza con cui il team effettua deployment in produzione. Una frequenza più alta correla con batch size più piccole, feedback più rapidi e maggiore fiducia del team.

Lead time for changes misura il tempo da un commit di codice a quel codice in esecuzione in produzione. Cattura l’attrito totale nel sistema di consegna, dalla review alla CI al deployment.

Change failure rate misura la percentuale di deployment che causano un incidente in produzione. Riflette la sicurezza del processo di consegna e la qualità della copertura dei test.

Mean time to recovery misura quanto tempo ci vuole per ripristinare il servizio dopo un fallimento. Riflette la qualità dell’osservabilità, dei runbook e del processo di risposta agli incidenti.

Il risultato della ricerca che ha sorpreso molti professionisti è che velocità e stabilità non sono un trade-off. I team eccellenti hanno sia un’alta deployment frequency che un basso change failure rate. Le pratiche che rendono sicuro il deployment, test continui, sviluppo trunk-based, automazione del deployment, lo rendono anche veloce.

Cosa Dice la Ricerca Sulle Pratiche Tecniche

Accelerate identifica pratiche tecniche specifiche che sono predittive di un’alta performance di consegna del software.

La continuous integration riduce il costo dell’integrazione rendendola un’attività quotidiana piuttosto che una milestone di progetto.

Lo sviluppo trunk-based riduce la complessità del branching che crea rischio di integrazione.

L’automazione dei test è predittiva sia della deployment frequency che del change failure rate. I team con test automatizzati completi possono effettuare deployment più frequentemente perché possono verificare le modifiche rapidamente e con fiducia.

L’automazione del deployment riduce la variazione manuale nel processo di deployment.

Il monitoraggio e l’osservabilità consentono un ripristino rapido. I team che possono rilevare e diagnosticare rapidamente i fallimenti hanno un MTTR inferiore.

Molte di queste pratiche sono direttamente ostacolate dal debito tecnico. Un codebase legacy senza copertura dei test non può beneficiare della continuous integration. Un monolite strettamente accoppiato non può supportare lo sviluppo trunk-based senza un refactoring significativo.

La Cultura Organizzativa e il Suo Ruolo nella Performance di Consegna

Uno dei risultati meno citati di Accelerate è il ruolo centrale della cultura organizzativa. La ricerca si basa sulla tipologia di culture organizzative di Ron Westrum, che distingue tra organizzazioni patologiche, burocratiche e generative.

Le culture generative sono caratterizzate da alta fiducia, responsabilità condivisa e informazioni che fluiscono liberamente verso dove sono necessarie. Nel contesto della consegna del software, ciò significa che i team si sentono sicuri nel fare deployment senza paura di essere incolpati quando qualcosa va storto, le informazioni sullo stato del sistema sono visibili a tutti coloro che ne hanno bisogno, e i fallimenti sono trattati come opportunità di apprendimento.

La ricerca mostra che la cultura generativa non è un optional. È predittiva della performance di consegna del software. I team che operano in ambienti ad alta fiducia con proprietà chiara e sicurezza psicologica superano costantemente i team in ambienti burocratici o orientati alla colpa, anche quando le pratiche tecniche sono simili.

Cosa Dovrebbero Fare gli Engineering Leader con Questa Ricerca

L’errore più comune nell’applicare Accelerate è trattare le metriche come obiettivi. Quando la deployment frequency diventa un obiettivo, i team la manipolano dividendo artificialmente le modifiche. Quando il lead time diventa un obiettivo, i team abbreviano la review. La Legge di Goodhart si applica: quando una misura diventa un obiettivo, cessa di essere una buona misura.

L’applicazione corretta è usare le metriche in modo diagnostico. Misurarle onestamente, cercare le cause della sottoperformance e affrontarle attraverso le pratiche identificate dalla ricerca.

Un punto di partenza pratico per la maggior parte delle organizzazioni è stabilire le baseline per tutte e quattro le metriche, quindi identificare la singola fase più limitante del processo di consegna. Il lead time è lungo perché la review richiede giorni? Il change failure rate è alto perché la test suite è scarsa? La deployment frequency è bassa perché i deployment sono manuali e rischiosi?

Ogni collo di bottiglia ha una pratica corrispondente dalla ricerca Accelerate. Il compito dell’engineering leader è sequenziare correttamente gli interventi. Questo spesso include affrontare il debito tecnico che rende impraticabili certe pratiche.

Conclusione

Accelerate fornisce il framework più rigorosamente ricercato disponibile per comprendere e migliorare la performance di consegna del software. Le quattro metriche chiave danno agli engineering leader strumenti di misurazione concreti. Le pratiche tecniche forniscono una roadmap di miglioramento. I risultati culturali ricordano loro che le pratiche da sole non sono sufficienti.

La ricerca è chiara: la performance eccellente è raggiungibile e richiede sia investimenti tecnici che culturali.

Hai un codebase con questi problemi? Parliamo del tuo sistema