Modello di sviluppo Waterfall: la sua storia e i suoi limiti
Chiunque abbia alle spalle lo studio dell’ingegneria del software o dell’informatica, conosce il modello a cascata, il famoso Waterfall. In questo articolo ne ripercorriamo la storia e, di conseguenza, i limiti.
Perché il Waterfall?
Quando lo sviluppo del software divenne un’attività industriale, venne applicato su questo terreno nuovo un modello di lavoro già rodato.
Il modello a cascata era quello utilizzato nella produzione manifatturiera: molto diffuso negli anni Settanta, è stato per decenni il metodo tradizionale per “raccontare” e portare avanti il ciclo di vita del software.
Le sue fasi
L’approccio Waterfall è scandito da alcuni step, o fasi, affrontati in modo lineare:
- Requirements: la prima fase di raccolta dei requisiti e di analisi per verificarne la fattibilità, i costi, i tempi, ecc.
- Design: il momento in cui si definisce l’architettura del software a partire dai documenti di analisi.
- Implementation: è la fase vera e propria della scrittura del codice.
- Verification: in questo step vengono effettuati i test di collaudo dei singoli moduli implementati e dei testi di integrazione, per verificare il corretto funzionamento dell’intero sistema.
- Maintenance: questa fase prevede il rilascio del prodotto al cliente e il continuo mantenimento per migliorare la funzionalità.
Come si può immaginare, si tratta di un processo consequenziale: l’output di uno step diventa l’input per il successivo. Inoltre, il rilascio del software avviene solo a processo ultimato, una volta che sono stati percorsi tutti gli “scalini” della cascata.
Limiti e difficoltà
Non ho mai visto un progetto sviluppato con questo modello che è andato a buon fine.
Nonostante all’Università io sia stato cresciuto a pane e Waterfall, nell’esperienza lavorativa mi sono scontrato da subito con i limiti e le difficoltà intrinseche di questo procedimento.
Innanzitutto l’interdipendenza tra le fasi rende essenziale un’analisi dettagliata del progetto, ben prima di iniziare a scrivere una sola riga di codice: finché tutti i requisiti non sono chiari è altamente sconsigliato iniziare la fase di implementazione.
E se a un certo punto il cliente cambia idea, magari in fase di verifica? Oppure se ci si accorge che quello che è stato implementato non rispecchia i requisiti?
Il mio suggerimento è di scappare a gambe levate, perché l’unica strada percorribile altrimenti è quella del cestino. Buttare via tutto e ricominciare da capo: fare l’analisi dei nuovi requisiti, redigere un nuovo preventivo, ricominciare a implementare e sperare, soprattutto, che questa volta funzioni tutto. E che le aspettative del cliente vengano soddisfatte.
I progetti sviluppati con il modello Waterfall che ho avuto tra le mani sono stati abbandonati incompleti o sottoposti a lunghe negoziazioni con il cliente, per stabilire i nuovi termini economici. Qualcuno perderà di sicuro qualcosa.
L’altro grande limite del processo a cascata è quello del rilascio alla conclusione delle fasi principali: arrivato il momento tanto atteso, magari, non è più possibile un cambio di programma e i nuovi requisiti, le nuove richieste, non possono essere integrate.
Ecco perché questo modello non trova più posto nel mondo attuale.
Il “nuovo mondo” del software
Come tutti sappiamo, oggi l’evoluzione delle esigenze che hanno i nostri clienti è rapida e repentina.
Gabriele Giaccari, il mio socio e CEO di 20tab, mi ricorda sempre che a cambiare rapidamente è proprio tutto il contesto in cui nasce il software: esigenze di mercato che si evolvono, utenti che ci danno feedback su come migliorare il nostro prodotto o semplicemente le tecnologie che avanzano.
Attendere l’intero ciclo per avere un feedback dai nostri clienti potrebbe generare un danno in termini economici o di soddisfazione generale che, nella migliore delle ipotesi, porta all’annullamento del guadagno preventivato, ma nella maggior parte dei casi può portare a gravi perdite.
Quali approcci adottare, allora?
La risposta possiamo trovarla nell’industria Toyota degli anni Ottanta, che introdusse uno dei principi di business fondamentali per il futuro: il miglioramento continuo, la filosofia Kaizen.
Il Signor Toyota non inventò nulla di nuovo, ma portò a evolversi il più datato ciclo di Deming, anche conosciuto come PDCA: Plan-Do-Check-Act.
A partire da qui si sviluppano una serie di metodologie legate all’idea di un processo iterativo: Lean, Agile, metodi che in 20tab utilizziamo sui nostri progetti e su quelli dei nostri clienti, aderendo così alla visione del Continuous Improvement.
La strategia vincente è quella del “rinnovamento a piccoli passi”, l’unica destinata a vincere in un’epoca come la nostra.
