Quando cerchiamo di modellare i nostri progetti di sviluppo software su una metafora proveniente dall’ingegneria civile dimentichiamo che l’ingegneria civile esiste da migliaia di anni
Nel 2009 mi sono rivolto a un imprenditore edile per costruire una casa. Insieme a un architetto abbiamo delineato le caratteristiche: oltre a prevedere un seminterrato, abbiamo scelto con cura i materiali, la posizione delle finestre, la disposizione delle stanze e del sottotetto, cioè tutto ciò che occorreva all’impresario per stabilire un prezzo e una data di consegna. La casa è stata completata in circa un anno e mezzo. Se si esamina da una lunga distanza un progetto come questo, sembra trattarsi proprio di un normale progetto di costruzione: sono stati specificati i requisiti, l’impresario ha fornito un prezzo e una data, e tutto è stato consegnato circa un anno e mezzo dopo. Si potrebbe suggerire che questo modello per i progetti di costruzione sia abbastanza adatto anche per i progetti di sviluppo software: si specificano i requisiti, si impostano prezzo e data di consegna, e si parte. In effetti, molti project manager suggeriscono questo modello per i progetti di sviluppo software, supportati dal fatto che questo modello è stato usato fin dagli anni Settanta, da quando veniva spesso definito “a cascata” o “lineare”.
Purtroppo, il modello a cascata o lineare, nel quale si identificano tutti i requisiti e si mettono in concreto prima di iniziare la costruzione vera e propria, non funziona proprio bene. Sono molti gli imprenditori che non riescono a soddisfare i budget o le scadenze, oppure realizzano solo una piccolissima parte dei requisiti concordati. Recenti pubblicazioni su grandi progetti governativi in Olanda documentano di numerosi risultati negativi e di progetti falliti. I clienti danno la colpa agli appaltatori, e questi a loro volta ce l’hanno con i clienti perché impongono di eseguire i progetti seguendo il modello lineare. Molti progetti finiscono in tribunale e la nostra amata disciplina di sviluppo software gode di un’immagine pubblica negativa.
Ma quindi dove sta l’errore? Permettetemi di cercare di spiegare.
Lo sviluppo software è una disciplina molto giovane
Quando cerchiamo di modellare i nostri progetti di sviluppo software su una metafora proveniente dall’ingegneria civile dimentichiamo che l’ingegneria civile esiste da migliaia di anni. C’è tutto un mondo di esperienze e conoscenze nel settore dell’edilizia che fa capo a Babilonesi, Greci, Egiziani, al Medioevo, al Rinascimento e alle rivoluzioni industriali. Duemila anni fa, gli antichi Romani utilizzavano già il calcestruzzo. Tutta questa esperienza contribuisce al modo in cui i progetti di costruzione vengono eseguiti oggi. Ma lo sviluppo del software è una disciplina piuttosto giovane: se la matematica e il calcestruzzo sono con noi da moltissimo tempo, i linguaggi di programmazione hanno solo circa sessant’anni. È forse per questo che l’applicazione di un modello di progetto derivato da una disciplina che ha migliaia di anni potrebbe non adattarsi benissimo: non abbiamo tutta questa esperienza, o almeno non ancora.
Anche i progetti di costruzione falliscono
Tuttavia, anche con migliaia di anni di esperienza e di sviluppo tecnologico, i progetti di costruzione che utilizzano questo modello “single-pass”, cioè in un solo passaggio, possono fallire. Subito dopo che la mia nuova casa è stata consegnata dall’impresario, abbiamo iniziato a notare un odore terribile dai bagni. Dopo due settimane la situazione è peggiorata. Non potevamo più nemmeno usare lo sciacquone, perché il sistema era completamente intasato. Per farla breve, l’impresario si era completamente dimenticato di collegare la casa alla rete fognaria centrale della città. La riparazione di questo “bug” ha fatto sì che il mio giardino appena finito sia stato rovinato.
Così il modello single-pass in realtà non va bene nemmeno per le costruzioni. E la costruzione di una sola casa non è un grosso progetto. Quando si esaminano progetti di costruzione molto più grandi, i progetti che hanno effettivamente rispettato i requisiti concordati in termini di tempo e di budget costituiscono le eccezioni e non la regola. Quindi, se i progetti di costruzione non funzionano su un modello lineare, come potrebbero farlo i progetti di sviluppo software?
Nello sviluppo software i requisiti possono cambiare
E c’è di più. Quando ho costruito la mia casa, ho dovuto prendere molte decisioni iniziali. Per esempio, anche se non ho dovuto decidere l’altezza delle prese sulle pareti, non è complicato da capire che è molto più difficile aggiungere uno scantinato dopo che una casa è completamente costruita. E lo stesso vale per la rete fognaria. Si potrebbe ben dire che la maggior parte dell’architettura e del design devono essere realizzati all’inizio. Tuttavia, lo sviluppo del software è davvero molto diverso. Il software può sempre cambiare. Anche in un progetto in ritardo si è sempre in grado di cambiare requisiti, interfaccia utente e anche architettura. Pertanto, non abbiamo bisogno di un grande progetto iniziale. Il fatto che (anche) molti progetti si basino ancora su un grande “disegno” iniziale è perché stiamo applicando il modello sbagliato. L’applicazione di un grande progetto iniziale nello sviluppo software ha un effetto negativo sul risultato di questi progetti, perché non consente il cambiamento. E il cambiamento è benefico. Essere in grado di cambiare nel corso di un progetto, anche in ritardo, migliora semplicemente la qualità, e migliora la capacità di massimizzare i vantaggi del software che realizziamo per i nostri clienti.
Il fatto che possiamo cambiare i requisiti, il design e anche l’architettura rende i progetti di sviluppo software molto diversi da altre opere di costruzione. Il software è fluido, non lineare, e dovremmo trarre beneficio da questo.
I progetti non sono la metafora giusta
Ma questo, a mio parere, non è tutto. Come abbiamo visto prima, dopo che abbiamo elaborato le caratteristiche della mia nuova casa, l’impresario ci ha comunicato prezzo e data di consegna: cioè, abbiamo fissato le caratteristiche, il prezzo e la data di consegna. In sostanza, gli stessi tre fattori che vengono utilizzati per monitorare il successo dei progetti di sviluppo software. Spesso chiedo ai project manager di descrivere quando considerano che i loro progetti sono riusciti, e la risposta che spesso ricevo è che se tutti i requisiti vengono consegnati in tempo e all’interno del budget, il progetto è un successo.
Ma è davvero così? Prendiamo in considerazione Word: un prodotto con migliaia di caratteristiche di cui molti ne utilizzano solo un numero molto limitato. Sarebbe stato un prodotto di successo anche se fosse stato consegnato solo con la limitata serie di funzioni perlopiù usate e per una frazione del budget che ci è voluto per realizzarlo? La mia ipotesi è che lo sarebbe stato: ho da tempo sostituito Word con un editor di testo semplice e diretto. Che cosa succede se invece di utilizzare il modello di progetto si decide di realizzare il nostro software funzione per funzione? E se realizziamo solo la versione minima appena sufficiente di tali caratteristiche? Potremmo chiedere continuamente al cliente come intende utilizzare le successive parti di tempo e denaro che ha a disposizione: dobbiamo realizzare una versione più sofisticata delle funzionalità esistenti o la versione minima delle funzionalità successive in lista? Ogni prodotto costruito in questo modo avrebbe l’insieme minimo di funzionalità, realizzato per un budget minimo in una quantità minima di tempo. Consegnato prima di quanto sarebbe stato utilizzando un modello di progetto, lineare o agile che sia, e consegnato a minori costi che non con l’utilizzo di un modello di progetto. E solo con quelle caratteristiche di cui abbiamo veramente bisogno. Costruito così, Word sarebbe stato un editor striminzito ed essenziale, senza tutte le caratteristiche abbondanti che ha oggi.
Ecco perché a mio parere, il software non dovrebbe essere costruito utilizzando un modello di progetto. Mai. Il software dovrebbe invece essere realizzato caratteristica per caratteristica, offrendo un prodotto minimo valido. E nel caso in cui ve lo stiate chiedendo, la mia casa non è stata consegnata in tempo e i limiti di budget non sono stati rispettati. Quindi è proprio il caso di smettere di fare progetti!
Sander Hoogendoorn
Mentore, allenatore, software architect, sviluppatore, speaker e scrittore, apprezzato come grande innovatore nello sviluppo software. Autore del best-seller “This Is Agile”, ha scritto libri anche su UML e pubblicato più di 250 articoli su riviste specializzate. Oltre a essere keynote speaker in molte conferenze internazionali, presenta seminari e corsi di formazione in tutto il mondo su diversi argomenti quali, tra gli altri: Agile, Scrum, Kanban, continuous delivery, architettura software, Microservices, modeling e UML.
Sander Hoogendoorn presenterà a Roma per Technology Transfer i seminari “Introduzione a Agile, Scrum, XP, Kanban e Continuos Delivery in pratica” il 27 aprile 2017 e “Progettare, sviluppare e implementare una Microservices Architecture” il 28 aprile 2017.
