Uno dei miei obiettivi con questa serie di articoli a tema agile (aggettivo) \u00e8 sicuramente cercare di diffondere in modo semplice i concetti fondamentali, per far si che si diradi un p\u00f2 di nebbia attorno a questa metodologia che purtroppo \u00e8 stata un p\u00f2 strumentalizzata negli ultimi decenni. <\/p>\n\n\n\n
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<\/strong>; mascherano quindi il processo esistente introducendo pratiche random dal mondo agile usate a sproposito – l’esempio classico di questa situazione \u00e8 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.<\/p>\n\n\n\n Non basta metterci l’etichetta sopra: tutto questo non \u00e8 realmente “Agile” – e come la storia dello sviluppo software ci ha insegnato, semplicemente non funziona proprio come non funzionava prima di mettergli l’etichetta.<\/p>\n\n\n\n Sono fermamente convinto che raccontando le modalit\u00e0 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\u00e8 l’agile sia importante – ed anche riconoscere abbastanza facilmente se le esperienze passate o future meritino l’etichetta o meno.<\/p>\n\n\n\n Articolo consigliato: Manifesto Agile, quanto \u00e8 rilevante nel 2024?<\/em><\/a><\/p>\n\n\n\n Credo che parlare solo di Agile in senso stretto nel 2024 risulti un p\u00f2 limitativo, perch\u00e8 gli stessi problemi si sono presentati pi\u00f9 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.<\/p>\n\n\n\n Oggi parleremo di questo circolo vizioso composto da Agile, eXtreme Programming (XP), Lean e DevOps<\/strong> – 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\u00e0 che hanno una relazione forte tra loro.<\/p>\n\n\n\n Prima di entrare nel vivo del discorso, ecco una doverosa, seppur breve e semplificata, introduzione alle 4 metodologie.<\/p>\n\n\n\n Per primo arriva il Lean, il modello di “produzione snella” che nasce in Toyota negli anni 40 <\/strong>che porter\u00e0 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\u00e0 necessaria), lo Jidoka (sistemi automatici per prevenire imprevisti nel sistema), lavoratori adibiti a pi\u00f9 mansioni e Kanban<\/strong>. Questo modello \u00e8 stato adattato al mondo software nel 2003 nel libro “Lean Software Development: An Agile Toolkit<\/a>” (hai letto bene, Agile!), che descrive alcuni principi fondamentali come eliminare gli sprechi ed ottimizzare il sistema, portando esempi di come implementare questi principi.<\/p>\n\n\n\n Nel ’99, due anni prima della stesura del Manifesto Agile, Kent Beck era gi\u00e0 un bel pezzo avanti nei suoi pensieri riguardo alle caratteristiche di uno sviluppo software di qualit\u00e0, efficace e sostenibile: nel libro “Extreme Programming: Explained<\/strong>” 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.<\/p>\n\n\n\n Come abbiamo gi\u00e0 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\u00e0 siamo arrivati a considerare importanti…” – il resto \u00e8 storia.<\/p>\n\n\n\n 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\u00e0 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\u00e0 che si \u00e8 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\u00e0) dell’intero ciclo di vita dell’applicazione, dall’esplorazione al rilascio e monitoring\/supporto passando ovviamente per lo sviluppo.<\/p>\n\n\n\n Gi\u00e0 da queste brevi descrizioni penso che sia facile riconoscere che ci sia una radice comune molto forte tra queste metodologie, ed andando pi\u00f9 in profondit\u00e0 risulta sempre pi\u00f9 evidente, e possiamo facilmente fare qualche esempio.<\/p>\n\n\n\n Mentre l’Agile Manifesto ci dice di considerare “individui ed interazioni<\/strong>” pi\u00f9 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.<\/p>\n\n\n\n Il DevOps, con tutte le sue declinazioni, tende a far convergere (shift left) tutte le responsabilit\u00e0 del software sul team del progetto\/prodotto<\/strong> – 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). <\/p>\n\n\n\n Si potrebbero fare tanti altri esempi ma chiudo con il terzo, a mio avviso uno dei pi\u00f9 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\u00f9 efficace ad intervalli regolari”, e Lean si concentra molto sull’idea di amplificare l’apprendimento continuo del team (“Amplify learning”).<\/p>\n\n\n\n Quello che voglio evidenziare \u00e8 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 \u00e8 tra i firmatari del Manifesto – mentre DevOps arrivando dopo ha preso a piene mani dalle altre tre in modo pi\u00f9 derivativo) i risultati ottenuti hanno tantissimi punti in comune, ognuno con le proprie declinazioni chiaramente. <\/p>\n\n\n\n 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\u00f9 velocemente possibile” come vuole il Lean, rispondere ai cambiamenti come indicato dal Manifesto e raggiungere l’ideale di automazione completa del DevOps.<\/p>\n\n\n\n Ancora una volta risulta evidente che parlare di uno facendo finta che l’altro non esiste significa perdersi qualche sfumatura.<\/p>\n\n\n\n Tutto questo discorso ha un duplice scopo: il primo \u00e8 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\u00e8 quelle che si sono rivelate pi\u00f9 efficaci, si possono ricondurre alla stessa matrice e questo non pu\u00f2 che dare forza ad essa.<\/p>\n\n\n\n Anche senza scomodare le metriche DORA, se facendo TDD e CI stiamo “rispettando” tutte e 4 queste metodologie qualcosa vorr\u00e0 pur dire, no?<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Certo, XP e Lean suggeriscono delle pratiche, ma nessuna di queste viene descritta come “pratica fondamentale ed irrinunciabile”, <\/strong>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. <\/p>\n\n\n\n Citando per l’ennesima volta Kent Beck oggi: “purch\u00e8 rispetti i valori e principi, se sentite il bisogno di inventare una pratica o modificarne un altra per adattarsi al vostro contesto, fatelo!”.<\/p>\n\n\n\n Se questo articolo ti \u00e8 piaciuto, sappi che \u00e8 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\u00f9, 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:<\/p>\n\n\n\n
\n\n\n\n
\n\n\n\nUn circolo vizioso positivo<\/h2>\n\n\n\n
Lean<\/strong><\/h3>\n\n\n\n
eXtreme Programming (XP)<\/strong><\/h3>\n\n\n\n
Agile<\/strong><\/h3>\n\n\n\n
DevOps<\/strong><\/h3>\n\n\n\n
Valori condivisi con declinazioni particolari<\/h2>\n\n\n\n
Riflessioni finali<\/h2>\n\n\n\n
\n\n\n\n\n