Uno dei miei obiettivi con questa serie di articoli a tema agile (aggettivo) è sicuramente cercare di diffondere in modo semplice i concetti fondamentali, per far si che si diradi un pò di nebbia attorno a questa metodologia che purtroppo è stata un pò strumentalizzata negli ultimi decenni.
Molto spesso, anzi troppo, le persone che sento deluse e preoccupate dal nome “Agile” (nome proprio, in questo caso) hanno maturato questo sentimento tramite cattive esperienze, dettate da contesti abituati al Waterfall che non riescono, o non vogliono, vedere il valore che un reale cambiamento porterebbe per la loro azienda; mascherano quindi il processo esistente introducendo pratiche random dal mondo agile usate a sproposito – l’esempio classico di questa situazione è la gestione del lavoro e dei requisiti, che non diventa davvero iterativa ed incrementale, ma al contrario si prende la roadmap dei 12 mesi successivi e la si divide in modo rozzo in “sprint”; oppure lo stand-up, che invece di permettere al team di organizzare la giornata serve solo a fare da SAL giornaliero per il PM di turno.
Non basta metterci l’etichetta sopra: tutto questo non è realmente “Agile” – e come la storia dello sviluppo software ci ha insegnato, semplicemente non funziona proprio come non funzionava prima di mettergli l’etichetta.
Sono fermamente convinto che raccontando le modalità e le motivazioni per cui sono nate determinate metodologie e pratiche, chiarendo quali problemi volessero risolvere e in che modo possano rappresentare una soluzione efficace, si possano gettare le basi per permettere a tutti di avere chiaro perchè l’agile sia importante – ed anche riconoscere abbastanza facilmente se le esperienze passate o future meritino l’etichetta o meno.
Articolo consigliato: Manifesto Agile, quanto è rilevante nel 2024?
Un circolo vizioso positivo
Credo che parlare solo di Agile in senso stretto nel 2024 risulti un pò limitativo, perchè gli stessi problemi si sono presentati più volte nella storia dello sviluppo software e i tentativi di trovare soluzioni che fossero efficaci si sono ripetuti nel tempo; mettendo insieme quelle che hanno funzionato e che continuano a funzionare ancora oggi, possiamo scoprire quanto abbiano in comune tra loro – e questo non fa che dare forza a queste metodologie, creando una sorta di circolo vizioso positivo che si autoalimenta.
Oggi parleremo di questo circolo vizioso composto da Agile, eXtreme Programming (XP), Lean e DevOps – nomi formali di metodologie che hanno tantissimo da condividere, pur mantenendo ognuna di esse qualche sfumatura specifica, e che quindi meritano di essere rappresentate come entità che hanno una relazione forte tra loro.
Prima di entrare nel vivo del discorso, ecco una doverosa, seppur breve e semplificata, introduzione alle 4 metodologie.
Lean
Per primo arriva il Lean, il modello di “produzione snella” che nasce in Toyota negli anni 40 che porterà l’azienda ad essere al top del settore in un paio di decenni; si fonda su principi come il “Just in Time” (i componenti arrivano esattamente quando servono e nella quantità necessaria), lo Jidoka (sistemi automatici per prevenire imprevisti nel sistema), lavoratori adibiti a più mansioni e Kanban. Questo modello è stato adattato al mondo software nel 2003 nel libro “Lean Software Development: An Agile Toolkit” (hai letto bene, Agile!), che descrive alcuni principi fondamentali come eliminare gli sprechi ed ottimizzare il sistema, portando esempi di come implementare questi principi.
eXtreme Programming (XP)
Nel ’99, due anni prima della stesura del Manifesto Agile, Kent Beck era già un bel pezzo avanti nei suoi pensieri riguardo alle caratteristiche di uno sviluppo software di qualità, efficace e sostenibile: nel libro “Extreme Programming: Explained” formalizza questi pensieri sotto forma di valori, principi e pratiche, esponendo le fondamenta su cui poi si sono evolute, tra le altre, il Test-Driven Development (che Kent Beck stesso racconta nel suo libro del 2000) e tante altre pratiche agile nei decenni successivi. Con valori e principi, Beck vuole assicurarsi che le motivazioni e gli obiettivi per cui nasce XP siano chiari, per poi fornire anche alcuni esempi di pratiche da lui utilizzate.
Agile
Come abbiamo già visto il mese scorso, le idee fondanti per l’Agile vengono formalizzate nel Manifesto del 2003, frutto del lavoro comune di un gruppo di eccellenze del nostro lavoro (tra cui, guarda caso, lo stesso Kent Beck che aveva pubblicato libri a tema XP e TDD nei due anni precedenti). L’idea era raccogliere tutte quelle caratteristiche che si erano rivelate vincenti nelle loro esperienze, come dichiarato nel manifesto stesso: “Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a fare lo stesso. Grazie a questa attività siamo arrivati a considerare importanti…” – il resto è storia.
DevOps
Gia negli anni ’80/’90 si sono diffuse le prime idee che suggerivano che sviluppo (Dev) e operations (Ops, semplificando si intende la parte di rilascio e supporto) dovrebbero essere responsabilità condivise dalle stesse persone e dallo stesso team, e non da due team separati che si passano la mano come si era soliti fare storicamente, una modalità che si è rivelata totalmente disfunzionale nella storia del software. Nel 2007/2008 queste idee sono tornate con forza e il nome DevOps ha iniziato a circolare per definire in generale l’idea che il team di sviluppo dovrebbe essere owner (il che implica, tra le altre cose, autonomia e responsabilità) dell’intero ciclo di vita dell’applicazione, dall’esplorazione al rilascio e monitoring/supporto passando ovviamente per lo sviluppo.
Valori condivisi con declinazioni particolari
Già da queste brevi descrizioni penso che sia facile riconoscere che ci sia una radice comune molto forte tra queste metodologie, ed andando più in profondità risulta sempre più evidente, e possiamo facilmente fare qualche esempio.
Mentre l’Agile Manifesto ci dice di considerare “individui ed interazioni” più importanti di “processi e strumenti”, l’XP allo stesso tempo di parla di valori come “comunicazione” e “rispetto”, quest’ultimo valore condiviso esplicitamente anche da Lean.
Il DevOps, con tutte le sue declinazioni, tende a far convergere (shift left) tutte le responsabilità del software sul team del progetto/prodotto – non solo sviluppo e operations, ma anche sicurezza ed architettura ad esempio – richiedendo quindi una multitudine di skill che vanno a combinarsi perfettamente con l’idea di team cross funzionale che pone le basi sia in XP (“Whole team”) che in Lean(“Eliminate waste” nello specifico evitiamo il waste derivante dal passaggio di consegne di un lavoro) e Agile (self-organizing teams).
Si potrebbero fare tanti altri esempi ma chiudo con il terzo, a mio avviso uno dei più evidenti: pratiche come retrospettive e root-cause analysis. Questo tipi di pratiche derivano da un principio di miglioramento continuo presente in tutte e 4 le formalizzazioni di queste metodologie in modo piuttosto evidente: DevOps parla di “Continuous Improvement” in modo diretto, XP ci suggerisce il principio di “Improvement”, Agile indica al team di “riflettere su come diventare più efficace ad intervalli regolari”, e Lean si concentra molto sull’idea di amplificare l’apprendimento continuo del team (“Amplify learning”).
Quello che voglio evidenziare è come risulti abbastanza evidente quanto si sia partiti da problematiche comuni, cercando soluzioni che funzionassero al meglio, e nonostante questi processi siano stati separati (pur con dei punti in comune, vedi Beck padre di XP che è tra i firmatari del Manifesto – mentre DevOps arrivando dopo ha preso a piene mani dalle altre tre in modo più derivativo) i risultati ottenuti hanno tantissimi punti in comune, ognuno con le proprie declinazioni chiaramente.
Per quanto oggi, ormai, quando parlo di pratiche e metodologie agile non mi riferisco solo specificatamente al Manifesto, ma a tutto quello che deriva da queste 4 famiglie con antenati comuni – in fondo, parlare di Continuous Integration solo come una pratica XP sarebbe ridicolo, considerando che rilasciare tante volte al giorno risulta fondamentale per “Consegnare più velocemente possibile” come vuole il Lean, rispondere ai cambiamenti come indicato dal Manifesto e raggiungere l’ideale di automazione completa del DevOps.
Ancora una volta risulta evidente che parlare di uno facendo finta che l’altro non esiste significa perdersi qualche sfumatura.
Riflessioni finali
Tutto questo discorso ha un duplice scopo: il primo è sicuramente quello di evidenziare che la storia dello sviluppo Software ha cercato, in vari momenti e luoghi, di risolvere determinati problemi – e le soluzioni che sono durate nel tempo, cercando di essere formalizzate perchè quelle che si sono rivelate più efficaci, si possono ricondurre alla stessa matrice e questo non può che dare forza ad essa.
Anche senza scomodare le metriche DORA, se facendo TDD e CI stiamo “rispettando” tutte e 4 queste metodologie qualcosa vorrà pur dire, no?
In secondo luogo, la riflessione finale riguarda un altro elemento in comune che a volte viene usato come punto debole dell’agile ma che ritengo invece il punto fondamentale: nessuna di queste metodologie offre pacchetti di soluzioni pronte all’uso.
Certo, XP e Lean suggeriscono delle pratiche, ma nessuna di queste viene descritta come “pratica fondamentale ed irrinunciabile”, e sopratutto nessuna di queste viene indicata come dogma. Tutte e 4 queste metodologie, anzi, si concentrano in primis sui loro valori e principi, che sono l’elemento fondamentale da comprendere per poter poi far si che riusciamo ad utilizzare queste metodologie nel nostro lavoro giornaliero.
Citando per l’ennesima volta Kent Beck oggi: “purchè rispetti i valori e principi, se sentite il bisogno di inventare una pratica o modificarne un altra per adattarsi al vostro contesto, fatelo!”.
Se questo articolo ti è piaciuto, sappi che è parte di una serie mensile a tema Agile, il che significa che puoi recuperare i precedenti e che ne arriveranno altri nei prossimi mesi! In più, se ti piace il mio stile, dai un occhiata a Learn Agile Practices, il mio ecosistema di contenuti online nei quali parlo di pratiche e metodologie Agile come TDD, CI, CD e molto altro a tema programmazione:
- Learn Agile Practices – una newsletter settimanale (in inglese) – iscriviti qui ➡️ https://learnagilepractices.substack.com/about
- Video Podcast, principalmente in italiano – scopri tutti i link per le varie piattaforme di podcast ➡️ qui e iscriviti al canale Youtube ➡️ qui
