Metodo a Cascata: Definizione, Processo ed Esempi

Di cosa tratta la metodologia di gestione progetti Waterfall?

La cascata rappresenta il concetto di gestire i progetti di sviluppo suddividendoli in fasi distinte, affrontandole una dopo l’altra in modo sequenziale.

Anche se suddividere grandi attività in parti più piccole è un concetto usato dall’uomo sin dall’alba dei tempi, la "nascita" formale della metodologia a cascata è avvenuta molto più tardi — nel 1970, quando il celebre informatico Dr. Winston W. Royce la descrisse nel suo libro “Managing the Development of Large Software Systems”.

Da allora, è diventato il principale metodo per la gestione dei progetti software fino a quando, all’inizio degli anni 2000, il mondo non si è orientato verso Agile.

Com’è il ciclo di vita di sviluppo software (SDLC) con la metodologia Waterfall

A differenza della struttura iterativa e incrementale di Agile, il SDLC per la cascata ha sia un inizio che una fine ben definiti. L’intero processo di sviluppo viene suddiviso in cinque fasi o traguardi, e il lavoro su una fase non inizia finché la precedente non è completata. Visivamente, appare così:

Il lavoro fluisce da una fase all'altra, fino a raggiungere il fondo e il progetto si considera "completo"—per questo appare visivamente simile a una cascata (da qui il nome).

Vediamo ora ogni fase di questo approccio lineare e scopriamo cosa comportano.

Fase #1: Raccolta dei requisiti

Tutto inizia con la raccolta dei requisiti del progetto da tutti gli stakeholder. Durante la fase dei requisiti, i project manager preparano un documento completo e molto dettagliato che copre ogni aspetto del progetto, dai requisiti funzionali al budget e il piano di gestione dei rischi.

Unlock the Product Vault

We’ve collected the goods — AI prompts, exclusive deals, and a library of resources for product leaders. Unlock your account for access.

Sign up with:

LinkedInGoogleMicrosoft

Or sign up with email:

URL

This field is for validation purposes and should be left unchanged.

Name*

First name Last name

Business email*

This field is hidden when viewing the form

Free Account Module

Bottom BarLanding PageFooterInlinePop UpSidebarSSO

LinkedIn profile

Seniority*

Select an optionExecutive / C-suiteVPDirectorManagerIndividual ContributorOther

Company's AI adoption maturity*

Select an optionExploring opportunitiesRunning pilotsScaling adoptionEmbedded in the business model

Fase #2: Progettazione della soluzione

Sulla base dei requisiti definiti nella fase precedente, il team di progetto comincia a formulare la soluzione e a progettarla. Il termine "progettazione" in questo contesto si riferisce sia alla struttura tecnica del prodotto (progettazione di sistema), sia al design visivo e all’interazione dell’utente (UI/UX Design), sia alla progettazione fisica (se si tratta di un prodotto fisico).

Fase #3: Implementazione

Qui è dove avviene realmente la programmazione. I membri del tuo team di sviluppo inizieranno a costruire il prodotto sulla base dei deliverable creati durante la fase di design.

A differenza di Agile, dove puoi modificare costantemente gli ambiti e il design del progetto, la cascata presuppone che si seguirà il documento di progettazione senza “evolvere” il prodotto durante la fase di implementazione.

Fase #4: Testing

Appena il team di ingegneri del software ha finito di realizzare il prodotto, possiamo passare alla fase successiva del nostro piano di progetto: il test. Il team inizierà a verificare il prodotto per individuare eventuali bug, vulnerabilità di sicurezza o problemi di esperienza utente.

Durante la fase di testing, si controlla anche che le funzionalità e il design del prodotto finale corrispondano ai requisiti riportati nei documenti delle prime due fasi.

Fase #5: Deploy e supporto post-rilascio

Supponendo che il tuo team abbia individuato e risolto tutti i problemi rilevanti sul prodotto, è arrivato il momento di rilasciare la soluzione e consegnarla ai clienti e agli utenti finali. 

I programmatori passeranno ora alla fase di manutenzione, raccogliendo costantemente feedback dagli utenti, apportando correzioni necessarie e pubblicando nuove patch e aggiornamenti del prodotto.

Questo è tutto, il tuo progetto è completato e puoi passare al prossimo!

Dunque, dovresti usare il metodo a cascata?

Se tu, PM con mente Agile (almeno è quello che presumo tu sia), pensi che questa metodologia sia ormai sorpassata e da non prendere mai in considerazione, (rispettosamente) non sono d’accordo e sostengo che l’approccio a cascata sia in realtà la scelta migliore per alcuni tipi specifici di progetti.

Vorrei illustrarti alcuni esempi per dimostrare ciò che sostengo.

Casi di Studio: Il Metodo Waterfall in Azione

Come per qualsiasi concetto complesso, alcuni esempi concreti possono essere utili per comprendere come la metodologia funzioni nella realtà. Ecco quindi alcuni esempi basati su progetti reali (ai quali potrei aver lavorato o meno) per aiutarti a capire come l’approccio a cascata funzioni in pratica.

Caso n.1: Una Piattaforma di Sdoganamento per il Governo dell’Egitto

Immagina di far parte di un’azienda che si è aggiudicata l’appalto per modernizzare i sistemi di commercio internazionale e sdoganamento di un paese relativamente grande, ad esempio l’Egitto.

Quello che il governo egiziano desidera è un sistema dell’autorità portuale che gestisca tutti i manifesti delle navi (un documento doganale che contiene tutte le informazioni sul carico e sui passeggeri presenti a bordo di quella nave) che entrano nei vari porti dell’Egitto.

Inoltre, vogliono che questo sistema sia integrato direttamente con un altro prodotto che ti chiedono di realizzare, il quale dovrà gestire tutte le dichiarazioni doganali (ovvero i cosiddetti SAD o documenti amministrativi unici) all’interno del paese. Il modulo è piuttosto complicato da compilare per le persone comuni, quindi vogliono che tu lo automatizzi per loro.

L’Egitto ha un sistema complesso di tassazione e dazi doganali che modifica le tariffe in base al tipo di merce importata, alla quantità ed altri fattori. Visto che i cittadini comuni non hanno idea di quali siano queste tariffe, il governo egiziano desidera che la tua applicazione calcoli automaticamente tutto sulla base delle loro dichiarazioni e permetta il pagamento online con carta di credito.

Sembra un compito mastodontico, vero? Quando si arriverà a definire i dettagli dell’implementazione, la leadership (e forse anche il governo egiziano) verranno da te, il project manager, e ti chiederanno come vuoi organizzare la realizzazione di questo progetto.

Perché e come dovresti usare il metodo Waterfall in questo scenario:

Qualsiasi cosa tu costruisca per un governo nazionale sarà probabilmente basata su una legge o una decisione ratificata dal parlamento. Queste decisioni comprenderanno tutto, dai termini generali del progetto (ad esempio costi e tempistiche) fino ai dettagli minuziosi di come tutto dovrà funzionare.

Sembra e appare proprio come un documento dei requisiti della prima fase del ciclo Waterfall, giusto? In effetti lo è, e significa anche che non puoi davvero cambiare al volo dettagli d’implementazione, design e requisiti come avviene nello sviluppo Agile.

Un tempo guidavo proprio un prodotto di questo tipo. Un giorno, ci siamo accorti che potevamo migliorare notevolmente l’esperienza utente apportando alcune piccole modifiche alla logica di business. Abbiamo condiviso subito la nostra idea con il rappresentante dell’autorità doganale che lavorava con noi.

Beh, lui ci disse di no. Potresti pensare che fosse sbagliato bocciare una tale proposta, ma aveva una buona ragione per cui non potevano farlo.

Le nostre piccole modifiche avrebbero implicato un cambiamento nella formula utilizzata dal governo per il calcolo delle tasse su un determinato prodotto. La formula era fissata per legge, quindi cambiarla avrebbe significato riunire tutto il parlamento nazionale e deliberare con una votazione.

Caso n.2: Il Sistema di Controllo di Volo dell’Elicottero Ingenuity

Ingenuity è il nome che la NASA ha dato all’elicottero tecnologicamente avanzato che hanno costruito e inviato su Marte nel 2021. Ecco come appare questo piccolo gioiello.

Bene, immagina di essere quel fortunato project manager responsabile dello sviluppo del software di questo straordinario gioiello tecnologico. In particolare, il tuo team doveva scrivere il codice che avrebbe controllato il volo dell’elicottero.

Creare un sistema di controllo di volo per un aeromobile (specialmente un elicottero) è molto complicato. Dovrai considerare tutte le leggi della fisica che interagiscono con il velivolo durante il volo e calcolare la velocità necessaria delle pale, l’angolo delle stesse e mille altri dettagli.

Ma il tuo compito è ancora più complesso. Il tuo elicottero dovrà volare sopra la superficie di un altro pianeta con un’atmosfera 100 volte meno densa di quella terrestre.

Perché e come dovresti usare il metodo Waterfall in questo scenario:

A mio avviso, lo sviluppo in modalità Waterfall qui è l’unica opzione possibile. Al contrario del project management Agile, in cui costruisci qualcosa di piccolo (il tuo MVP), lo rilasci, lo utilizzi nella realtà, raccogli feedback e migliori gradualmente la soluzione sulla base di questi riscontri, in un progetto di questo calibro la posta in gioco è troppo alta.

Puoi davvero rischiare di creare un MVP difettoso di Ingenuity e farlo volare per 140 milioni di miglia fino a Marte? Semplicemente nessuno accetterebbe mai una cosa del genere.

Quindi, dovrai costruire la versione finale e poi testare rigorosamente tutti i suoi sistemi prima di avere la necessaria fiducia per collocarla in un razzo diretto verso il pianeta rosso.

Il modello a cascata è vivo e vegeto!

In realtà, è molto più diffuso di quanto potresti aspettarti, con la metà di tutti i progetti nel mondo che ancora utilizzano questa metodologia di sviluppo.

Nonostante l’avvento dell’Agile abbia reso il mondo un posto migliore per molti project manager, permettendo loro di lanciare prodotti molto prima e di costruire sulle basi dei feedback degli utenti, il modello a cascata resta una metodologia di grande valore che puoi adottare per progetti dalla flessibilità limitata e dalla bassa tolleranza agli errori.

Spero che ti sia piaciuta la nostra panoramica sulla metodologia waterfall. Se vuoi approfondire anche l’Agile, ecco cosa ti consiglio:

• La nostra guida su Agile Product Management.
• La raccolta delle migliori pratiche per Agile Portfolio Management.
• La nostra lista selezionata dei migliori strumenti per Agile Product Management.

Questi sono solo tre delle tante guide e articoli che abbiamo su product e project management. Per saperne di più, iscriviti alla nostra newsletter.