LA ROTTAMAZIONE DELL’AGILE
Basta scrivere rottamazione oggi (2017) e in Italia si diventa subito impopolari. Esattamente l’opposto di ciò che accadeva qualche anno fa, in epoca “renziana”, quando rottamare era lo spot del “nuovo” che incalzava il “vecchio”. Questo è il potere delle buzz-word. Per riscoprire il vero significato di un termine bisogna prima svestirlo da mode e slogan, ricercandone la neutralità delle radici. Agile è una buzz-word. L’industria del software, al pari della nostra politica, è chiaramente immatura. Basta osservare in che misura nuovi metodi di sviluppo sembrano apportare innovazione e miglioramento a colpi di slogan, senza però risolvere davvero i problemi fondamentali che ci sono alla base. Agile è di moda, quindi è ancora un utile strumento di marketing. Sotto il vestito, tuttavia, il più delle volte non c’è niente. Non c’è cultura.
Ha ragione Dave Thomas, uno dei firmatari del movimento agile, a sostenere che è ora di ritirare il termine Agile (Time to kill agile). Adriano Comai in un post nel suo blog evidenziava questo passo dell’articolo originale già qualche anno fa. Condivido questa posizione che ritengo ancora attuale.
L’adozione di qualche pratica agile non rende agile un’organizzazione. L’agilità passa attraverso i suoi processi e i processi sono la testimonianza del livello di maturità dell’organizzazione. Essere agili significa ben più di adottare uno strumento o una tecnica agile, come se fossero gli strumenti o le tecniche ad essere agili. Questo è spesso un fraintendimento comune: è soltanto il modo in cui utilizziamo strumenti e tecniche, all’interno di un processo maturo, che apporta agilità.
Prendiamo la modellazione del software come esempio. UML agile non può essere sinonimo di raccogliere qualche schizzo grafico durante un brainstorming tecnico, archiviandolo in un repository di immagini che non consulteremo mai. Tanto meno non può significare costruire montagne di diagrammi sincronizzati con il codice attraverso la generazione automatica (round-trip engineering). UML è un linguaggio, ha una sua semantica, deve servire per comunicare meglio, non per fare disegnini colorati fine a se stessi o per produrre tomi di specifiche post-mortem. Se non usiamo il linguaggio grafico in modo corretto, falliremo nell’intento di far arrivare un messaggio chiaro, senza ambiguità, e con poco sforzo. Falliremo cioè lo scopo principale dell’adozione di un linguaggio di modellazione. UML va capito sia nella semantica, sia nella sua sintassi di base. UML agile non può significare essere approssimativi. Questo almeno per tutti coloro che i diagrammi li costruiscono.
Un altro uso frequente del concetto di UML agile abbraccia sempre la creazione rapida di schizzi, snellita dalla liturgia di processi model-based come Unified Process, per poi vedere questi schizzi “cristallizzati” o, peggio, cestinati dopo il loro primo uso. Un modello è una specifica in movimento. Usare UML nelle prime fasi di analisi e poi procedere senza mantenere e far evolvere il modello non vuol dire essere agili. Vuol solo dire procedere senza specifica, senza visione. Se decidiamo di accostare a UML il termine agile, lo facciamo per altri motivi. Lo facciamo ad esempio perché abbiamo in mente i principi e le pratiche di modellazione agile. I processi aziendali devono essere in armonia col vestito di modellazione agile, altrimenti usiamo dei termini per il solo effetto di marketing. Non significano nulla.
Attorno all’agilità si muove tutta l’organizzazione. Continuare a svolgere l’analisi, il design, l’implementazione con dinamiche tipiche del modello a cascata non può conciliarsi con i valori agili. Adottare prima gli strumenti, costruendo poi i processi attorno ad essi non può conciliarsi con i valori agili. Creare una frattura tra l’analisi e lo sviluppo, mettendo in competizione i rispettivi team non può conciliarsi con i valori agili. L’agilità nella modellazione si ottiene piuttosto segregando un sottoinsieme della notazione e usandolo, anche informalmente (ma non per questo senza precisione), per codificare un modello concettuale che, al pari di un linguaggio ubiquo, viene usato come nucleo di conoscenze per trasformare il problema nella soluzione, tenendo le due viste indipendenti ma correlate. Essere agile significa sapere quali diagrammi fare, quando farli, per chi e con quale livello di dettaglio farli. Essere agili vuol dire ancora saper usare il principio di scala per individuare il livello più strategico in cui dedicare il maggior sforzo di modellazione. Essere agili significa infine usare il principio di elisione in ogni diagramma, così da lasciare solo i concetti essenziali, senza nasconderli in mezzo a dettagli implementativi.
Per fare tutto questo serve un team forte che metta insieme analisti, progettisti, sviluppatori, project manager, product manager e li faccia lavorare insieme. Per fare questo non servono strumenti esosi, serve prima di tutto cultura. E attraverso la cultura si costruisce un team migliore. Un software migliore, dopotutto, passa necessariamente per un team migliore. Essere agili passa per la maturità di tutti i processi aziendali e non solo di quelli relativi allo sviluppo del software. Essere agili è una cultura. Essere agili è tutto questo. Essere agili non è per tutti.