Keynote: back to basics
Oggigiorno parliamo tutti di agilità. Nel bene e nel male, quasi tutti lavoriamo in realtà che adottano Scrum e le annesse pratiche agili: abbiamo a che fare con P.O., Scrum Master, sprint planning… Insomma, ci sentiamo sul pezzo. Ma siamo davvero sicuri di conoscere la filosofia agile? Perché non fare un passo indietro e rivedere tutti insieme i principi che ne stanno alla base?
That’s why Charlie Poole is here!
Charlie Poole è uno sviluppatore ed agilista della prima ora, con esperienze di programmazione in Cobol, C, C++, C# (a proposito di C#, il framework di unit test NUnit è opera sua 😊).
Fu grazie al mondo agile che, in occasione della prima conferenza sull’Extreme Programming tenutasi ad Alghero parecchi anni fa, Charlie venne per la prima volta in Italia, innamorandosene. Da quella volta Mr. Poole ha visitato parecchie volte l’Italia, soggiornandoci anche per lunghi periodi; il nostro Bel Pese ha un posto speciale nel suo cuore, tanto da decidere di condurre il suo keynote in italiano! Ebbene sì, con nostro grande stupore, Charlie ha deciso di parlare tutti e 45 minuti a sua disposizione in italiano, non proprio una passeggiata se non siete abituati a parlare una lingua non vostra, per di più di fronte a qualche centinaio di persone. A lui il nostro plauso.
Ma torniamo al keynote. Qual è il cardine della filosofia agile quando lavoriamo ad un software?
Fornire valore al cliente
Secondo Charlie, il software di per sé non ha valore; noi sviluppatori non siamo artisti che produciamo qualcosa di tangibile, non dipingiamo quadri da esporre nei musei. Il software non è “bello”, non è qualcosa da ammirare: l’unico valore che produce è quello fornito al cliente, all’utilizzatore finale, per cui nel team (o “squadra”, come giustamente Charlie ha tradotto il termine) ogni membro deve essere consapevole del valore del prodotto sul quale sta lavorando, e anche come questo valore viene fornito dal software stesso. Charlie ci ha esposto quelli che secondo lui sono i punti da considerare per un ritorno alle basi delle pratiche agili.
Concentrarsi sul valore fornito al cliente
Come scritto prima, tutti noi sappiamo cosa vuol dire praticare Scrum, eXtreme Programming e le varie pratiche annesse. Ma la tendenza è quella di concentrarsi interamente sulle tecniche dimenticandosi dei valori. Ciò che è centrale sono i valori, non le tecniche. A tal proposito, Charlie ha creato un momento che ho ritenuto personalmente emozionante, facendoci ascoltare un piccolo estratto del brano La leva calcistica del ’68 di Francesco De Gregori: “Ma Nino non aver paura di sbagliare un calcio di rigore / Non è mica da questi particolari / Che si giudica un giocatore / Un giocatore lo vedi dal coraggio / Dall’altruismo e dalla fantasia”. Applausi da tutta l’aula magna 🙂
Per un giocatore, i valori sono la fantasia, l’altruismo, il coraggio. E per uno sviluppatore? Quali sono questi valori? Ne possiamo individuare molti, fra cui i classici 5 dell’eXtreme Programming: comunicazione, semplicità, feedback, coraggio e rispetto… Ma tutto sommato anche quelli proposti da De Gregori non sono così fuori luogo.
In particolare, Charlie si è concentrato su alcuni di essi, dei quali ogni membro del team dovrebbe avere la consapevolezza:
- Altruismo: ogni membro del team lavora per il team, il team lavora a sua volta per qualcun altro (cliente)
- Coraggio: conosciamo le capacità di ogni membro della squadra, per cui nessuna paura nel dover prendere decisioni
- Comunicazione: non soffochiamo la comunicazione, sia all’interno del team che soprattutto all’esterno; continuiamo a parlare con il cliente
- Estremismo: Kent Beck affermò che XP è un insieme di pratiche estreme; spesso si fa l’errore di adottare una versione moderata di pratiche agili. Sbagliato!
Riportare valori agili soprattutto quelli riguardanti il lavoro del team
Secondo Charlie è altrettanto importante la natura FRATTALE delle metodologie agili. L’agile è ripetitivo per sua definizione, con sprint planning e meeting giornalieri che si susseguonono con una certa frequenza; questa pianificazione iterativa è molto importante, permette di organizzare meglio il lavoro, e non cadere nella trappola di voler fare tutto e subito. E se in questi momenti di pianificazione considerassimo l’ipotesi di coinvolgere il cliente? Per Charlie è importante avere il cliente sul posto, magari farlo collaborare per la definizione dei test di accettazione del software. Questo aiuterebbe a mantenere viva la comunicazione e la pianificazione del lavoro, in maniera tale da rilasciare sempre qualcosa che sia allo stesso tempo il più semplice possibile ma che fornisca valore al cliente.
Lo sviluppo dovrebbe essere guidato dai test: Test Driven Development. Tutti sappiamo cosa voglia dire, ma non sempre lo applichiamo. Idem per il refactoring del codice: sappiamo cosa voglia dire, ma dobbiasmo ricordarci che non deve essere fatto solo per “abbellire” il codice: non stiamo realizzando un quadro da esporre nei musei.
Cosa ha voluto insegnarci Charlie in questo keynote? Che va bene, anzi benissimo, adottare l’agilità nel nostro progetto, ma dobbiamo farlo con consapevolezza e coraggio, non dimenticandoci MAI i principi e le sue fondamenta.
Posso solo dire “GRAZIE CHARLIE!”, è sempre importante ricordare chi siamo e da dove arriviamo 😊