Differenze tra la metodologia Waterfall e Scrum

Come Scrum si differenzia da Waterfall

In questo articolo andremo a mettere a confronto le due metodologie sotto diversi aspetti: le metodologie prese in esame sono Waterfall e Agile, in particolare Scrum.
Scrum si differenzia da Waterfall principalmente per:

1. Differenti caratteristiche;
2. Differenti ruoli;
3. Differenti eventi;
4. Differente documentazione.

Confronto tra Waterfall e Scrum

La metodologia Waterfall è caratterizzata da fasi sequenziali che seguono un flusso lineare. Ogni fase di sviluppo procede una dopo l’altra senza la possibilità di overlapping e non è possibile avanzare alla fase successiva se prima non si è conclusa la fase precedente. Tutte le funzionalità vengono pianificate, progettate, implementate e testate in maniera simultanea durante le rispettive fasi e le attività di ciascuna fase devono essere completate entro un certo periodo di tempo. La produzione della documentazione e la realizzazione dei test avvengono alla fine di ogni fase e questo aiuta a mantenere la qualità del progetto. Inoltre, i difetti di progettazione sono identificati molto tardi e se i requisiti non sono chiari è difficile completare il progetto.

Invece, Scrum è un framework Agile di tipo “Lightweight” ed è caratterizzato per uno sviluppo del progetto di tipo iterativo, attraverso gli Sprint. È definito “leggero” perché se comparato con le tradizionali metodologie di project management la produzione di documentazione è inferiore e perché abbraccia i cambiamenti durante il progetto. Inoltre, è gestibile attraverso una serie di eventi ripetuti, milestone e riunioni che hanno obiettivi specifici.

Waterfall si concentra sull’esecuzione di una pianificazione dettagliata definita all’inizio del progetto con un’attenzione particolare al triangolo dei vincoli di progetto e alla sua gestione. Sebbene sicuramente anche le metodologie tradizionali di project management possano produrre prodotti e software di ottima qualità, talvolta, a causa della loro elevata rigidità, può accadere che il progetto si concluda con successo ma il cliente non sia soddisfatto del prodotto e che quindi i benefici attesi non siano realizzati. Scrum, invece, presta maggiore attenzione alla consegna di prodotti che per prima cosa soddisfino i requisiti dei clienti in piccoli ma utilizzabili incrementi iterativi. Infatti, secondo tale framework non è efficiente pianificare anticipatamente ogni cosa in un settore in cui tutto può cambiare rapidamente. Il vantaggio dello sviluppo iterativo è che permette eventuali correzioni in corso d’opera, in quanto il team di lavoro, apprendendo in modo iterativo, ha una migliore comprensione di ciò che deve essere prodotto. Questi vantaggi si potrebbero tradurre in una riduzione del tempo per concludere il progetto e in un aumento della redditività e del ROI.

Ora parleremo invece delle differenti modalità di consegna del valore in progetti che adottano l’approccio Waterfall o quello Scrum. Nello specifico è possibile notare come per le metodologie tradizionali la consegna del valore inizi soltanto nel momento del rilascio del prodotto finale. Infatti, l’intero prodotto viene rilasciato in maniera simultanea e solo al termine delle fasi di analisi, progettazione, implementazione e test. La consegna di valore nei progetti gestiti con Scrum e, più in generale con le metodologie Agile, avviene poco per volta ad ogni Sprint e la curva del valore da consegnare assume una forma a “scalini”. Come discusso nel Capitolo 1, creazione di valore e Benefit realization sono concetti strettamente correlati e quindi anche le curve di Benefit Realization assumono questi andamenti per entrambi gli approcci. Tuttavia, è possibile che i benefici di progetti gestiti con Waterfall non si realizzino come desiderato.

L’approccio iterativo permette di avere sempre disponibile almeno un rilascio del prodotto che possiede le Minimum Marketable Features (MMF) e anche se il progetto viene interrotto prematuramente sono comunque stati generati del valore e dei benefici.

Anche l’implementazione e la realizzazione della qualità è differente nelle due metodologie.
Nei progetti Waterfall, gli utenti chiariscono le proprie aspettative e il project manager le traduce in termini misurabili. Successivamente, a seguito di una pianificazione dettagliata e anticipata di lungo periodo, il gruppo di lavoro sviluppa il software richiesto in un periodo di tempo determinato. Eventuali modifiche dei criteri di qualità concordati possono essere gestite solo in modo formale, attraverso un processo di gestione del cambiamento che implica la stima degli impatti su quanto già lavorato e che richiede l’approvazione di tutti gli stakeholder del progetto.

Nei progetti gestiti con Scrum i criteri di accettazione delle User Story sono definiti dal Product Owner che rappresenta direttamente la Voce del Cliente nel corso del progetto. Inoltre, il Product Owner, per stare al passo con i bisogni dei clienti, può decidere di apportare dei cambiamenti ai requisiti. Lo Scrum Team li prenderà in carico e valuterà se interrompere lo Sprint in corso o se incorporare le modifiche richieste nello Sprint successivo.

Bisogna dire anche che le due metodologie Waterfall e Scrum hanno due paradigmi opposti. Il primo è di tipo plan-driven e mantiene fissi i requisiti mentre tempo e risorse sono solo stimate e possono subire variazioni. Il secondo è value-driven e mantiene fisse risorse e tempo, mentre a essere stimate sono le funzionalità.
Agile opera in situazioni in cui c’è molta incertezza e poca necessità di rigore, mentre Waterfall opera in condizioni di alta necessità di rigore ma poca incertezza sul processo.

Infine, sono elencate in modo schematico, nella tabella seguente, molte delle principali differenze tra i due approcci.