CSMA 2010: le basi culturali dei metodi agili

Raccolgo qui alcune considerazioni personali sui metodi agili e sulla cultura che li ha resi possibili.

Al CSMA 2010, Jacopo ha introdotto i metodi agili con il classico paragone fra la costruzione di ponti e la costruzione di software. Nel primo caso, i costi di esecuzione dell’opera dominano i costi di progettazione. Nel secondo, il rapporto si è ormai ribaltato.

Le metodologie riflettono i tempi in cui sono state sviluppate.

Waterfall ha visto la sua prima descrizione formale nel 1970, come esempio di metodo negativo e non funzionante, in un articolo di Winston W. Royce. Agli albori, l’informatica era appannaggio di grandi matematici e scienziati. L’invenzione del transistor aprì la strada all’informatica commerciale nel decennio 1955-1965. Il nascente settore  — terra vergine — adottò i metodi di altri già affermati, della manifattura industriale e dell’edilizia, campi altamente strutturati in cui il costo del cambiamento era proibitivo.

Il costo delle macchine dominava ancora su quello del personale, le loro potenzialità erano ancora molto limitate. Valeva la pena pagare uno specialista perché verificasse la correttezza dei programmi a mano prima di sprecare prezioso tempo macchina.

Non sono solo limitazioni di carattere tecnico a impedire l’avvento di una nuova metodologia. Lo zeitgeist, la sensibilità del tempo, e le conoscenze limitate nel campo della teoria dell’informazione non permettevano proprio di pensare un metodo differente.

Nel campo psicologico, si combattevano scuole neo-istintiviste (Lorenz) — in cui l’uomo era dominato dai propri istinti — e scuole ambientaliste e comportamentiste (F. Skinner) — in cui l’uomo è dominato da forze esterne. In entrambi i casi, mancava la centralità dell’individualità e dell’esperienza soggettiva, necessarie per concepire un metodo che ponga le persone e le esperienze sopra i processi ed i documenti.

I metodi a cascata portano a prendere le decisioni nelle condizioni peggiori possibili, quando i pochi elementi a disposizione rendono il rischio massimo, e assumono che il mondo sia un luogo ideale in cui tutti sanno ciò che vogliono e sono in gradi di comunicarlo, un posto ove ci sono ben pochi imprevisti.

Per assaporare l’infondatezza di questi assunti, bisogna attendere che nasca la cibernetica, che la filosofia della mente evolva e che i suoi risultati si diffondano. Bisogna aspettare la rivalutazione della psicologia della Gestalt e i suoi risultati nel campo della percezione. Non a caso è una scuola d’impostazione olistica: come ha ben sottolineano Jacopo, è necessario un approccio olistico più che deterministico, descrittivo più che esplicativo, dal sapore più orientale che occidentale, per avere un approccio sistemico, analogamente ai metodi agili.

Il risultato di questo mutamento culturale sono metodi iterativi che cominciano ad incorporare cicli di feedback e coinvolgono i principali stakeholders nelle fasi di analisi. Nel tempo queste metodologie si sono raffinate, diventando sempre più elaborate.

Sono processi in gradi di gestire requisiti che mutano nel tempo, ma si basano ancora su un’idea deterministica del mondo e sull’assunto che esista una realtà oggettiva e questa sia comunicabile. Ne consegue che il processo di sviluppo software è un processo controllabile in senso classico e che eventuali errori nei requisiti sono dovuti a vizi nella comunicazione. La risposta all’aumentare degli errori, dovuta anche all’accelerazione del progresso tecnologico così ben teorizzata da Raymond Kurzweil, è perciò processi più pesanti, per evitare errori d’esecuzione, e documenti più estesi, per evitare errori di comunicazione.

Entrambe sono risposte sbagliate: peggiorano il problema invece che alleviarlo.

Bisogna comprendere le implicazioni della matematica del caos e della teoria della complessità — ironia della sorte, entrambe figlie dell’informatica — per capire il primo errore. Gli odierni progetti software corrono sulla sottile linea che separa il caos dall’ordine, l’ambito deterministico da quello caotico. Cercare di gestire un progetto con gli strumenti classici è come cercare di scrivere un algoritmo per determinare quando terminerà una classe di programmi, un problema irrisolvibile nel caso generale. Invece di gestire il progetto bisogna occuparsi di governare il processo, con tecniche statistiche.

Sul secondo fronte, bisogna scomodare la psicologia e la filosofia contemporanee. Bisogna apprezzare il problema della coscienza per capire che l’esperienza soggettiva non è riducibile a dati oggettivamente comunicabili.

Negare la possibilità di una realtà oggettiva è un passo che in realtà la nostra cultura deve ancora collettivamente affrontare, le implicazioni sono amplissime e vanno ben al di là delle basi culturali dei metodi agili. È un processo epocale, che trova radice nel nichilismo nicciano, espressione degenere nel solipsismo e che si compirà completamente solo quando lasceremo l’episteme giudaico-cristiana e le conseguente spinta trascendente, con il suo corollario di Vero e Falso, Giusto e Sbagliato e tutti gli altri assoluti. Ma questa è un’altra storia ☺

L’impossibilità di comunicare il dato soggettivo ha una conseguenza immediata ed importante per il tema di questo post: l’esperienza vale necessariamente più che la sua sintesi in un documento, le persone — i soggetti — sono necessariamente più importanti dei processi.

La società post-disciplinare mette al centro l’individuo e l’affermazione di sé, permettendogli di scardinare il primato del processo e del suo rapporto simbiotico con la gerarchia.

Su questi fondamenti culturali fioriscono nuove idee di management negli anni ‘90: dalla six sigma alla qualità totale, dal lean thinking alla teoria dei vincoli. Queste sono le basi teoriche da cui nascono i metodi agili, la cui filosofia è ben riassunta nel loro manifesto:

Manifesto per lo Sviluppo Agile di Software

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:

Gli individui e le interazioni più che i processi e gli strumenti
Il software funzionante più che la documentazione esaustiva
La collaborazione col cliente più che la negoziazione dei contratti
Rispondere al cambiamento più che seguire un piano

Ovvero, fermo restando il valore delle voci a destra,
consideriamo più importanti le voci a sinistra.

Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler

James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick

Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas