Visto che in tempo di pandemia viaggiare è praticamente impossibile, l’unica cosa che ci rimane da fare è sognare ad occhi aperti e viaggiare con la mente. È quello che hanno fatto Paolo e Gianni, trovando un modo decisamente fuori dal comune per raccontare la vera storia del Manifesto Agile.
Prima di iniziare la lettura di questo articolo, è doveroso nei confronti del lettore fare tre premesse:
PREMESSA 1
Ogni riferimento a fatti realmente accaduti a Paolo e Gianni è puramente casuale
PREMESSA 2
Questo articolo è frutto della nostra fervida immaginazione, ma i fatti e le informazioni relative alla nascita ed ai valori dell’Agile Manifesto presenti in questo articolo sono REALI e tratti dal primo capitolo del libro Clean Agile di Robert C. Martin o dal sito https://agilemanifesto.org.
PREMESSA 3
Tutto quanto segue si svolge in un “universo parallelo”, privo di pandemia da Coronavirus e divieti da DPCM.
Ora che tutto è chiarito e non lascia adito a errate interpretazioni, iniziamo.
Dopo una proficua ed entusiasmante giornata di lavoro mi reco da Alberto che da anni si occupa della mia fluente chioma.
Entro annunciandomi con il classico “Ciao Alberto!” e saluto cordialmente i presenti. “Buonasera” dico, “Buonasera” mi rispondono altri, “Hi!” mi risponde un tizio canuto seduto sulla poltrona del barbiere.
Ma dai… sulle sedie, in attesa di essere “acconciato” c’è Paolo.
“Ciao Paolo! Sei venuto qui da Bologna per farti tagliare “i capelli?”
“Ma Gianni… non ho i capelli come te dal 2000! Sono venuto qui perché amici mi han detto che hanno visto Uncle Bob in Val Trompia in questi giorni. Ti risulta?”.
WAIT!!!!
“Paolo, scusa… ma quando sono entrato, qualcuno ha risposto HI?!?!?!?!!” :O
Pensandoci, il saluto americaneggiante ci lascia perplessi. Paolo abita a Bologna, e certamente di gente che parla “straniero” ne incontra parecchia, ma a Lumezzane, una ridente e soleggiata cittadina a pochi chilometri da Brescia, incontrare un americano dal mio barbiere è cosa alquanto strana.
Prendiamo la Gazzetta, ma contemporaneamente tendiamo l’orecchio per ascoltare la conversazione tra “l’americano” ed il barbiere Alberto…
“l’importanza dell’interazione tra persone”… “alla rigidità contrattuale è preferibile la collaborazione con il cliente”…
caspita, ma stanno parlando di Agile!
Ci guardiamo stupiti: Paolo chiede se è normale che a Lumezzane i barbieri conoscano il Manifesto Agile! Alzo le spalle e, senza proferire parola, ci avviciniamo, alla poltrona del barbiere e… ma certo! Alberto sta tagliando i capelli a Robert C. Martin !!!
Ci sosteniamo a vicenda… uno dei nostri idoli qui, davanti a noi! Non possiamo non cogliere l’occasione per attingere dalla sua profonda conoscenza! E quindi, timidamente, chiediamo il permesso di fare qualche domanda.
“Uncle Bob”, così è noto nel mondo informatico Robert, si mostra molto disponibile e dopo le presentazioni cerco di focalizzare l’argomento. Avremmo potuto chiedergli mille cose, da “i nomi delle variabili li preferisci in inglese o in italiano?” oppure “cosa ne pensi dei microservizi?” oppure “cosa ne pensi del fatto che JavaScript non è tipizzato?” (no beh, questa in effetti non serve, sappiamo perfettamente cosa pensa Uncle Bob di Js…), ma preferiamo focalizzarci su un tema su cui certamente potrà darci soddisfazioni: il Manifesto Agile!
Forse non tutti sanno che…
“Uncle Bob” è uno dei diciassette esponenti del mondo informatico che dall’11 al 13 Febbraio 2001 (sembra un’eternità, ma è solo del 2001) si ritrovarono a Snowbird, una località sciistica dello Utah, per discutere del futuro dello sviluppo software.
Ma perchè proprio a Snowbird, nello Utah?
“Hey ragazzi, ma chi se lo ricorda! Sono passati vent’anni!!! Immagino che qualcuno di noi avesse un coupon di GroupOn in scadenza e dovesse utilizzarlo. Non avete altro da chiedermi?!”
Eh effettivamente la prima domanda l’abbiamo proprio sbagliata, ma sapete… l’imbarazzo… l’agitazione… giocano brutti scherzi.
“Si, scusa Bob” rispondiamo all’unisono (e toccandoci il naso…) “forse è meglio se passiamo ad altro“.
Sigh!
Chi eravate?
“Eravamo in diciassette e rappresentavamo punti di vista differenti, inclusi i cinque processi lightweight.
“Io, Kent Beck, James Greening, Ward Cunningham e Ron Jeffries eravamo il gruppo più numeroso legato alla metodologia XP. Poi c’erano “quelli” di SCRUM, Ken Schwaber, Mike Beedle e Jeff Sutherland. Jon Kern esponente del FDD, il Feature Driven Development, mentre Aire van Bennekum rappresentava il DSDM, cioè il Dynamic System Development Method (hey, hai mai sentito parlare di AgilePM?! Se sei interessato, ascolta il nostro ultimo evento live qui!). Infine… come dimenticarlo… Alistar Cockburn ideatore dei processi della famiglia Crystal.”
“Altri partecipanti diciamo che non erano “schierati”: parlo di Dave Thomas ed Andy Hunt di Pragmatic Programmers, Brian Marick e Jim Highsmith erano consulenti rispettivamente in ambito testing e management e Steve Mellor rappresentava la filosofia Model-Driven.”
“Infine Martin Fowler che, seppur vicino al team XP, era scettico su qualsiasi tipo di processo.”
Perché avevate deciso di passare insieme due giorni?
Eh il problema era chiaro, dovevamo trovare una soluzione principalmente a due problemi:
- come fare modifiche con basso effort al nostro software;
- come portare a termine progetti definiti parzialmente ed in modo sommario.
Nel 1970 Winston Royce pubblicò un paper (“Managing the Development of Large Software System”) dove introdusse il metodo waterfall: l’articolo diventò virale e soprattutto questo diagramma (Robert estrae il suo smartphone e ci mostra questa figura)
Sicuramente aveva la sua razionalità, ma era un approccio… beh diciamolo, povero Royce… Sbagliato! Semplicemente perché si tratta di un approccio adatto a sistemi produttivi molto prevedibili fin dagli stadi iniziali, dove il costo del cambiamento “in corsa” è altissimo. Beh, lo sviluppo software, nella maggior parte dei casi, è l’esatto opposto no?
Eppure questo approccio ha dominato un’era, un periodo di tempo che va dagli anni ‘70 al 2000… dai ragazzi… chiamiamola pure la waterfall era. 30 anni!!!
30 anni di progettazione nel modo sbagliato!!!! Vi rendete conto?
Inoltre ragazzi, diciamolo chiaro…
(ed inizia a guardarsi attorno nella sala di Alberto).
I dispositivi programmabili sono ovunque: guardate questo rasoio… poco fa con Alberto abbiamo modificato il firmware ed ora è una bomba. Ogni minuto della nostra vita è dominato dal software, e per questo era, ed è, essenziale trovare un modo per lavorare al meglio. La nostra società è ormai dipendente dal software e noi softwaristi dominiamo il mondo! (muuahahahahah)!!!!
Caspita… che responsabilità!
Eh già… e quindi vi chiedo: ma voi il vostro software, come lo testate?!
Avete una suite di test che vi dica, con certezza che tutto stia funzionando a dovere?! Non so in quale ambito operiate, ma sappiate che il vostro software potrebbe uccidere delle persone! Oppure andare in loop infinito! (e Robert si fa una grassa risata).
Lo sviluppo software Agile è stato, ed è tuttora, lo step che consente di passare da programmare ad essere veri ed onorabili professionisti!
Per questo, in quanto sviluppatori Agili, dovrete porre la massima attenzione a Testing, Refactoring, Simple Design, Pairing ed ai feedback degli utenti!.
Se dovessi dare una definizione di Agile…
IMHO, lo sviluppo Agile è un “commitment” per aumentare la qualità del mio lavoro, per essere un professionista e promuovere un comportamento professionale nell’industria del software. Ahimè sbagliamo troppo, e troppe volte: rilasciamo molti bug e accettiamo più difetti del dovuto. Ogni giorno prendiamo terribili compromessi!.
Infatti… spesso una critica è che si “perde” troppo tempo a sviluppare, che si è lenti, che bisogna attendere mesi prima di vedere qualcosa…
Vi fermo subito! Nel mondo Agile non si rilascia il progetto, ma si rilasciano le iterazioni, gli incrementi come li chiamava Aire.
La regola è semplice: si rilascia ogni volta che il sistema è tecnicamente rilasciabile, alla fine di ogni iterazione. “Tecnicamente rilasciabile” significa, dal punto di vista dello sviluppatore, che il sistema è sufficientemente solido da essere rilasciato, il codice è pulito e tutti i test passano. Completare un’iterazione significa che tutte le attività di programmazione, testing, documentazione (si, ragazzi… documentazione!) e stabilizzazione delle storie che abbiamo preso in carico sono terminate.
Il deploy è invece una decisione del business: noi tecnici siamo pronti… ora la palla passa a voi! Quando il business ci dirà che la soluzione contiene tutto quanto si aspettava, potremo rilasciare.
Ma come facciamo a migliorare il software dopo averlo rilasciato?
Sapete perchè un software non migliora nel tempo? Per la paura di cambiare! Vi è mai capitato di vedere porzioni di codice e di dire che potremmo riscriverlo meglio?
Sicuramente, e perchè non lo fate? Per la paura di cambiare!
I clienti, gli utenti ed i vostri manager si aspettano una fearless competence. Essi si aspettano che se vedi qualcosa che non va o è sbagliato, tu possa fare pulizia e risolvere il problema, definitivamente!
I clienti si aspettano che quanto rilasciato sia stato abbondantemente testato ed i test manuali sono noiosi, lenti e dispendiosi.
Inoltre, più avanti nel tempo si scoprono i problemi, più costoso diventa risolverli; per questo sconsiglio l’approccio con test manuali fatti da team di Q/A e invece può venire fortemente in aiuto un’altra pratica chiamata Acceptance Testing: se scriviamo prima ciò che dobbiamo testare, otterremo una suite di test da utilizzare per la fase di Q/A e verificare in modo automatico il comportamento atteso.
Ma come facciamo ad essere sicuri che la modifica non introduca regressioni?
Semplice, con la pratica del TDD: praticando il TDD con disciplina e determinazione, avrete a disposizione un potenziale pulsante per fare refactoring senza timore. Ma scusate… non ve ne ha mai parlato Emanuele?!
Paolo a questo punto, incuriosito chiede
“Scusa Bob… maaaaaaa, Emanuele intendi EmaDb, cioè Emanuele DelBono?”.
“Certo ragazzi” risponde Robert estraendo nuovamente lo smartphone dalla tasca dei jeans, “guardatevi questo video e capirete subito l’importanza del TDD”.
Io e Paolo, ci guardano increduli ed esclamiamo: “Dobbiamo dirlo ad Ema!”
Una curiosità: perchè lo avete chiamato “Agile”?
Sarò sincero: nessuno era entusiasta di quel nome.
Se non ricordo male lo propose Mike Beedle per primo, ma sono certo che quel Lord inglese di Martin aveva espresso qualche preoccupazione sul fatto che noi americani non sapessimo bene come pronunciarlo… un po’ aveva ragione in effetti.
Comunque ci furono diverse proposte, ma alla fine ci rendemmo conto che “Agile” era il meno-peggio e perciò lo scegliemmo.
COME AVETE IDENTIFICATO I 4 VALORI? AVRETE DISCUSSO PER ORE…
Ma va là! Abbiamo fatto tutto in 15 minuti, durante la pausa caffè, mentre quelli che non sono presenti sulla famosa foto del manifesto erano a divertirsi sulle piste da sci.
Tutto partì attorno ad una lavagna, dove io scrissi la prima parte del primo valore “individuals and interactions” partendo da uno spunto di Martin Fowler. A questa frase venne replicato che anche i tools ed i processi erano però importanti… ed ecco che emerse il primo valore, così come lo leggete oggi:
We value individuals and interactions over processes and tools.
Allo stesso modo creammo gli altri, portando all’attenzione dei presenti le nostre personali esperienze.
Al termine della pausa caffè rileggemmo i 4 valori e ricordo perfettamente Ward Cunningham esclamare: “that’s awesome!”
Vi aspettavate che Agile prendesse piede a livello globale?
Ma assolutamente no! La verità è che ci aspettavamo che la cosa nascesse e morisse in quei due giorni. Avevamo la sensazione di aver fatto un buon lavoro facendo nascere il manifesto ed eravamo un po’ sorpresi di aver raggiunto un accordo tra tutti i punti di vista diversi che erano presenti.
Nessuno però si aspettava tutto il seguito ricevuto dopo la fine di quei due giorni a Snowbird…
Se tornassi indietro, lo rifaresti quel summit?
Decisamente sì. Senza alcun dubbio. Esserci ritrovati tutti assieme in diciassette persone, con le loro esperienze e competenze, ha generato un valore che è andato ben oltre la somme delle parti.
Inoltre, da una chiacchierata con Alistair è emerso che anche lui era in procinto di organizzare un summit dello stesso tipo. Questo per dire che i tempi erano più che maturi per cercare di pensare ad un modo diverso di approcciare lo sviluppo software. Se non ci fosse stato Snowbird, ci sarebbe stato qualcos’altro, ma l’esito finale sarebbe stato lo stesso.
Si, ma… dopo 20 anni, come ritrovi l’Agile?
Beh sai… l’Agile era nato da una piccola idea, per risolvere “piccoli” problemi di “piccoli” team di sviluppo che facevano cose “piccole”. Vent’anni dopo l’idea iniziale è stata distorta: sono nate diverse metodologie come SAFe, LeSS, … per carità non sono “brutte idee”, ma si discostano profondamente dal messaggio iniziale. Per questo potrebbe essere giunto il momento di un reboot dell’Agile e tornare a pensare al messaggio iniziale: un’idea piccola per cose piccole. Avete mai sentito parlare di “Software Craftsmanship”?
Ecco, l’idea è proprio quella di tornare ai principi base con cui nacque Agile, per alzare il livello dello sviluppo software professionale. E di questo magari ne parliamo un’altra volta…
I SALUTI 🙁
Bob: “Vabbè ragazzi, io sarei venuto qui per farmi fare barba e capelli ma voi mi state tempestando di domande e il povero Alberto non è riuscito a tagliare ancora nemmeno un ciuffo! Eppoi… se vi dico tutto… non comprerete il mio libro, non trovate?!”
Gianni: “Robert, scusa hai ragione, ma potrai ben capire che non capita proprio tutti i giorni di trovare a Lumezzane un personaggio come te”.
Bob: “Come no? Io sono qui tutti i secondi Giovedì del mese!”
Paolo & Gianni: “Davverooo??”
Bob: “Ma no! Ma secondo voi…mamma mia questi giovani d’oggi…”
Paolo: “Ci può mettere solo due autografi sui libri? Per piacere!”
Bob: “Va bene, datemi qui, poi fuori dai piedi che dopo devo andare anche a fare la spesa e passare in posta.”
Io e Paolo usciamo dal negozio con due sorrisi a trentadue denti, ammirando i nostri libri con autografo ancora fresco d’inchiostro.
Gianni: (trasognante, girandosi verso il negozio) “ma ma… siamo proprio sicuri che fosse Uncle Bob?”
Paolo: “Ma certo! Non hai sentito il chiaro accento di Chicago???”
Gianni: “Certo, perché tu vuoi farmi credere che conosci perfettamente l’accento di Chicago…”
Paolo: “Ti dico di sì! Ehm…Yes, indeed!”
Gianni: “Vabbè dai, lascia stare, andiamo… devo cospargere lo spiedo con il burro. Ho fatto partire il Ferraboli prima di uscire di casa… speriamo non si sia bruciato!”
Paolo: “Cospargere cosa??”
Gianni: “Lo spiedo… i mombolini!!! Guarda che nella vita non esistono solo tortellini e mortadella eh?”
Paolo: “Tu dici?”
Gianni: (Mettendo la mano sulla spalla a Paolo e incamminandosi) “Si, dico… dai andiamo.”
