Waterfall

Waterfall (modello a cascata) è l'approccio più antico e ancora oggi più diffuso al project management strutturato: ogni fase del progetto si chiude prima di iniziare la successiva, in sequenza rigorosa.

Le origini, e un equivoco storico

Il modello viene attribuito a Winston W. Royce nel suo paper del 1970 Managing the Development of Large Software Systems. L'ironia è che Royce descrisse il modello a cascata per criticarlo: nel paper, dopo aver presentato la versione sequenziale pura, scriveva esplicitamente che era "rischiosa e foriera di fallimento" se applicata senza modifiche.

Il termine "Waterfall" non compare nemmeno nel paper originale — è stato coniato dopo, e il diagramma a cascata ha finito per essere identificato col modello stesso, perdendone le riserve originali.

Le fasi classiche

Requisiti — raccolta e documentazione completa di cosa va costruito
Design — progettazione di architettura e componenti
Sviluppo — implementazione vera e propria
Test — verifica della corrispondenza con i requisiti
Deploy — rilascio in produzione
Manutenzione — supporto, correzioni, evoluzioni

L'idea base: ogni fase ha un output stabile (un documento, un'architettura, un binario testato) che diventa input della successiva. Una volta firmata, una fase non si riapre — i cambiamenti richiedono change request formali.

Caratteristiche distintive

Scope fissato in anticipo durante la fase requisiti
Documentazione pesante ad ogni passaggio (specifiche, design doc, test plan)
Sign-off formali alla fine di ogni fase
Pianificazione lineare di tempo e costi
Cliente coinvolto soprattutto all'inizio (requisiti) e alla fine (accettazione)
Cambiamenti gestiti tramite processo formale di change management

Varianti

V-Model

Il V-Model rappresenta Waterfall a forma di "V": il braccio discendente sono le fasi di design (alto → basso livello), quello ascendente sono i test corrispondenti (unit → acceptance). Ogni livello di design ha il suo corrispondente livello di verifica. Diffuso in ingegneria del software safety-critical (avionica, medicale, automotive).

Sashimi (Modified Waterfall)

In Sashimi, le fasi si sovrappongono parzialmente: il design può iniziare prima che i requisiti siano finalizzati, lo sviluppo prima che il design sia completo. Riduce i tempi a costo di un po' di rework. Termine giapponese: come le fette di sashimi che si sovrappongono leggermente sul piatto.

Iterative Waterfall

Versione che ammette brevi loop di feedback tra fasi consecutive prima di chiudere ufficialmente la precedente. È quasi sempre come Waterfall viene effettivamente praticato nella realtà.

Vantaggi reali

Prevedibilità di tempi e costi (se i requisiti sono corretti)
Contrattualmente robusto: facile scrivere capitolato e SLA
Compliance-friendly: ogni fase produce documentazione tracciabile, requisito di settori regolati
Adatto a team distribuiti o con bassa autonomia: ognuno sa cosa fare e quando
Onboarding facile: chi entra a metà progetto trova documentazione completa
Audit-friendly: la sequenza è ricostruibile dai documenti

Limiti

Errore nei requisiti = costo esponenziale se scoperto tardi
Feedback degli utenti solo alla fine, quando cambiare è costoso
Bassa tolleranza all'incertezza: presuppone che cosa va fatto sia chiaro a inizio
Valore consegnato in blocco alla fine, non incrementalmente
Cambiamenti scoraggiati anche quando sarebbero opportuni
Test concentrati a fine progetto = picchi di rework

Quando Waterfall è la scelta giusta

Requisiti certi e stabili: ingegneria civile, hardware fisico
Vincoli contrattuali rigidi: appalti pubblici a corpo, gare europee
Costi di cambiamento altissimi: produzione di stampi, costruzioni
Settori regolati: medical device, avionica, farmaceutica, nucleare
Output fisico: ponti, edifici, impianti industriali
Team con bassa autonomia o multipli vendor coordinati gerarchicamente

In questi casi Agile è la scelta sbagliata: l'iterazione costa troppo, o non è proprio possibile.

Anti-pattern

✕ Negare l'incertezza — fingere che i requisiti siano stabili quando non lo sono. Il progetto fallisce in fase test
✕ Big Design Up Front senza validare — mesi di design senza mai mostrare nulla al cliente
✕ Cambio del PM a metà — il sapere è nella documentazione, ma il contesto si perde lo stesso
✕ Test schiacciati a fine — quando il tempo stringe, è la fase più sacrificata
✕ Change request come arma politica — bloccare modifiche legittime con scuse procedurali
✕ Waterfall di facciata su progetti agili — fingere prevedibilità che non c'è per rassicurare lo sponsor

Waterfall ≠ obsoleto

Una narrativa diffusa nell'industria del software dipinge Waterfall come superato e sempre inferiore ad Agile. È una semplificazione. Waterfall funziona — ed è la scelta corretta — in molti contesti reali: la costruzione del Burj Khalifa, una certificazione FDA, un farmaco in clinical trial, un appalto pubblico per un'autostrada non si gestiscono in sprint da due settimane.

La domanda giusta non è "Waterfall o Agile?", ma "che tipo di incertezza ho?". La risposta porta a uno dei due, o a un Hybrid.

Collegamenti

Metodologie — confronto Waterfall / Agile / Hybrid e Stacey matrix
Agile — l'alternativa iterativa
PRINCE2 — una metodologia strutturata compatibile con Waterfall
Gantt — lo strumento di pianificazione tipico
WBS — la scomposizione del lavoro precede il Gantt
Le 5 fasi del progetto — distinte dalle fasi di Waterfall