Ciao, e benvenuto nella prima puntata della ventiduesima stagione di questo podcast. In tante stagioni abbiamo esplorato le tecnologie con cui si costruisce il software. Oggi cambiamo prospettiva e guardiamo a qualcosa di altrettanto importante ma spesso trascurato: non con cosa si costruisce il software, ma come si organizza il lavoro per costruirlo. Perché il modo in cui un gruppo di persone si mette d'accordo per realizzare un progetto è cruciale quanto gli strumenti che usa. Questa stagione è dedicata a un modo di lavorare che ha rivoluzionato lo sviluppo del software: la metodologia Agile. E oggi partiamo dal problema che l'ha fatta nascere.
Partiamo da come si costruiva il software prima, con un'immagine che chiarisce tutto: come si costruisce un ponte. Quando costruisci un ponte, procedi in modo ordinato e sequenziale: prima progetti tutto nei minimi dettagli, poi, quando il progetto è completo e approvato, cominci a costruire seguendolo alla lettera, fase dopo fase, fino alla fine. È un flusso a cascata: una fase si completa, e solo allora comincia la successiva, senza tornare indietro. Per anni, si è pensato di costruire il software allo stesso modo: progettare tutto in anticipo, in grande dettaglio, e poi eseguire il piano dall'inizio alla fine. Sembrava logico, ordinato, professionale.
Ma con il software, questo modo di procedere si è rivelato, molto spesso, un disastro, e capire perché è la chiave di tutta la stagione. Il problema è che il software non è un ponte. Un ponte, una volta progettato, non cambia: la fisica è quella, i bisogni sono chiari, tutto è prevedibile. Il software, invece, vive in un mondo che cambia di continuo, dove i bisogni non sono chiari all'inizio e si scoprono strada facendo. Fare un piano dettagliato e completo all'inizio, per il software, significa fare quel piano nel momento in cui ne sai meno, quando la tua ignoranza è massima. E poi eseguirlo rigidamente, mentre tutto cambia intorno a te. È lì che nascono i guai.
Vediamo concretamente quali guai, perché sono dolorosamente reali e chiunque abbia lavorato così li riconosce. Primo: i bisogni cambiano. Mentre costruisci per mesi seguendo il piano, il mondo va avanti, le esigenze del cliente si evolvono, i concorrenti si muovono, e il piano che avevi fatto all'inizio diventa via via superato. Secondo: si impara solo costruendo. Molte cose sul software le scopri solo mentre lo realizzi e lo provi, non prima; ma il piano rigido non lascia spazio per imparare e correggere. Terzo, il più doloroso: alla fine di mesi di lavoro sul piano, consegni qualcosa che, spesso, non è più ciò che serviva, perché nel frattempo tutto è cambiato o perché avevi frainteso i bisogni fin dall'inizio.
Voglio farti sentire quanto fosse frustrante questo modo di lavorare, perché la frustrazione è ciò che ha spinto al cambiamento. Immagina di lavorare per mesi, seguendo diligentemente un piano dettagliato, senza mai mostrare nulla al cliente finché non è tutto finito. E poi, dopo tutto quel lavoro, scoprire che il risultato non è ciò che il cliente voleva davvero, perché i suoi bisogni erano cambiati, o perché non li avevi capiti bene all'inizio, o perché solo vedendo il prodotto finito il cliente si è reso conto di cosa gli serviva veramente. Mesi di lavoro, un grande piano eseguito alla perfezione, e un risultato sbagliato. Questa esperienza, ripetuta mille volte, ha convinto molti che qualcosa, nel modo stesso di lavorare, andava profondamente ripensato.
Ed è da questa frustrazione diffusa che nasce l'idea rivoluzionaria che percorrerà tutta la stagione, e voglio piantarne il seme. Se il problema è che non puoi pianificare tutto in anticipo, perché i bisogni cambiano e si imparano strada facendo, allora smetti di provarci. Invece di un unico grande piano rigido eseguito fino alla fine, lavora a piccoli passi: costruisci un pezzetto, mostralo, impara dai riscontri, adatta, e ripeti. Invece di combattere il cambiamento cercando di ingabbiarlo in un piano, abbraccia il cambiamento, costruendo un modo di lavorare che si adatta man mano che impari. Questo capovolgimento, dal piano rigido all'adattamento continuo, è il cuore della metodologia Agile.
Voglio darti fin d'ora la lente di tutta la stagione, che ti guiderà. Il modo tradizionale trattava il cambiamento come un nemico, qualcosa da prevenire con la pianificazione e da respingere quando si presentava. L'Agile fa l'opposto: accetta che il cambiamento sia inevitabile, anzi utile, perché significa che stai imparando, e costruisce un modo di lavorare che lo accoglie invece di combatterlo. Abbracciare il cambiamento invece di combatterlo: tieni a mente questa frase, perché è l'anima di tutto ciò di cui parleremo. Non è caos né assenza di piano, ma un modo disciplinato di adattarsi alla realtà che cambia.
Per oggi ci fermiamo qui. Per anni si è costruito il software come si costruisce un ponte: progettare tutto in anticipo e poi eseguire il piano a cascata, fino alla fine. Ma il software non è un ponte: vive in un mondo che cambia, dove i bisogni si scoprono costruendo, e fare un piano rigido all'inizio significa deciderlo quando sai meno di tutto, per poi consegnare, mesi dopo, qualcosa che spesso non serve più. Da questa frustrazione nasce l'idea dell'Agile: invece del piano rigido, lavorare a piccoli passi, imparando e adattandosi, abbracciando il cambiamento invece di combatterlo. Nella prossima puntata vediamo il cuore dell'Agile: i valori prima delle regole. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.