Agile o Waterfall: come scegliere per il tuo progetto software

Waterfall pianifica tutto il progetto all'inizio e lo realizza in fasi sequenziali. Agile pianifica in cicli brevi e si adatta man mano che impara. Scegli Waterfall quando portata, budget e punti di approvazione devono essere fissati prima di iniziare. Scegli Agile quando ti aspetti di imparare qualcosa strada facendo, che è la norma per un nuovo sito, un'app o una piattaforma. Molti team svizzeri finiscono per adottare un ibrido: cornice fissa, realizzazione iterativa.

Questa guida spiega che cosa comporta davvero ciascun metodo, li confronta sui punti che incidono su budget e tempi e ti dà un modo pratico per decidere.

In breve

• Waterfall completa le fasi una dopo l'altra (requisiti, design, sviluppo, test, rilascio) e definisce tutta la portata all'inizio. Agile consegna software funzionante in sprint brevi e ridefinisce le priorità tra uno e l'altro.
• Waterfall si adatta a una portata stabile e ben compresa e a punti di approvazione formali. Agile si adatta ai prodotti in cui utenti, mercato o requisiti hanno ancora qualcosa da insegnarti.
• Il fallimento più costoso di Waterfall è una scoperta tardiva: una modifica individuata durante i test può vanificare settimane di lavoro di progettazione.
• Gli ibridi sono diffusi in Svizzera: Waterfall per portata, budget e governance, Agile per la realizzazione vera e propria.
• Conta meno il metodo di chi lo guida. La continuità di persone esperte e una comunicazione onesta determinano gran parte dei risultati.

Che cosa sono davvero Waterfall e Agile

Waterfall è una sequenza lineare e strutturata di passi completati in ordine all'interno del ciclo di vita dello sviluppo software, come lo IBM describes it. Ogni fase si conclude prima che inizi la successiva. Una sintesi accademica svizzera del UNIL’s executive education team lo mette allo stesso modo: fasi sequenziali, ciascuna completata prima che inizi la seguente.

Una tipica descrizione del modello in ambito di ricerca, firmata da Wohlin and colleagues, passa per analisi dei requisiti, progettazione e sviluppo, test, rilascio e manutenzione. Tra una fase e l'altra i documenti devono superare un controllo di qualità, uno stage-gate. Al gate il team verifica che i requisiti siano compresi, condivisi e documentati e che i portatori d'interesse rilevanti siano stati individuati.

Agile è iterativo. Invece di redigere requisiti lunghissimi all'inizio, i team suddividono il prodotto in funzionalità e le affrontano in sprint a durata fissa, secondo IBM describes it. Alla fine di ogni sprint il team mostra il proprio lavoro ai portatori d'interesse e il loro riscontro può ridisegnare la roadmap.

Dove si colloca Scrum

Spesso Agile e Scrum vengono trattati come la stessa cosa. Non lo sono. La Scrum Alliance spiega che Agile è un termine ombrello per approcci che condividono valori e principi comuni, mentre Scrum è uno dei framework più usati per organizzare il lavoro. Scrum opera a livello di team di prodotto; Agile come mentalità riguarda tutta l'organizzazione. Quindi «Scrum contro Waterfall» è in realtà il confronto tra un framework agile e un metodo sequenziale. Anche Kanban e altri sono agili.

Le differenze nella pratica

Le differenze emergono in sei punti che toccano direttamente il tuo progetto.

Aspetto	Waterfall	Agile
Pianificazione	Completa, all'inizio	Roadmap di massima, il dettaglio emerge a ogni sprint
Portata	Definita per intero prima di iniziare	Backlog ridefinito per priorità a fine sprint
Consegna	Un solo rilascio alla fine	Software funzionante a ogni sprint
Test	Una fase dedicata dopo lo sviluppo	Continui, dentro ogni sprint
Modifiche	Controllate formalmente	Previste e assorbite
Coinvolgimento dei portatori d'interesse	Forte nella fase dei requisiti e in quella di collaudo	Revisione del software funzionante a ogni sprint

La tabella segue il confronto della Rework’s methodology guide. Due punti meritano più dettaglio.

Pianificazione e documentazione

Con Waterfall documenti i requisiti dall'inizio alla fine prima che lo sviluppo parta. Con Agile documenti soprattutto ciò che serve ai primi sprint. Deloitte Switzerland traccia esattamente questo contrasto nel contesto della trasformazione IT del core banking.

Un mito diffuso vuole che Agile significhi niente documentazione. PMI Switzerland ha riferito da un evento fra professionisti che nella maggior parte dei casi nessun documento usato in Waterfall manca in Agile, e a volte i progetti agili ne producono di più. Agile aggiunge i propri artefatti, come il product backlog, lo sprint backlog e il burndown chart. Ciò che cambia è il momento in cui i documenti vengono scritti e quanto si decide all'inizio.

Gestire il cambiamento

Qui sta la vera linea di demarcazione. TechTarget descrive Waterfall come un metodo a cancelli: i team non possono passare alla fase successiva finché quella in corso non è completata secondo criteri definiti. In Agile il riscontro del cliente può cambiare gli sprint futuri in base a quanto hanno mostrato quelli precedenti.

La Scrum Alliance segnala la conseguenza per Waterfall: il valore arriva agli utenti finali solo alla fine del progetto. Nel frattempo possono essere passati mesi o anni e i requisiti potrebbero non essere mai stati rivisti. Modifiche importanti possono imporre di ricominciare da capo o addirittura far naufragare il progetto, sprecando tempo e denaro. La sintesi dell'UNIL indica lo stesso svantaggio: un aggiustamento importante scoperto durante i test può vanificare settimane di progettazione, il che rende care le modifiche tardive.

Un esempio di Waterfall, passo per passo

Waterfall non è un residuo del passato. È una forma sensata per lavori in cui la destinazione è nota. Il fornitore svizzero di software Polynorm descrive una classic Waterfall software introduction in sei fasi:

1. Concetto di massima
2. Concetto di dettaglio
3. Adattamenti del software secondo il concetto
4. Migrazione dei dati
5. Formazione
6. Messa in esercizio

Il progetto viene pianificato nel dettaglio e poi eseguito secondo quel piano, con un carico di lavoro per il cliente particolarmente pesante all'inizio e alla fine. Questo schema si adatta bene a situazioni come l'introduzione di un modulo ERP consolidato in un'azienda con processi già definiti.

Nota che cosa richiede a te: devi conoscere i tuoi requisiti fin dall'inizio. Se li conosci, Waterfall ti dà un percorso chiaro e poche sorprese. Se non li conosci, il piano è un'ipotesi scritta con tono sicuro.

Un esempio di Agile

Immagina un fondatore che costruisce una piattaforma di prenotazione per un mercato di nicchia. La prima versione ha bisogno di account, un calendario e i pagamenti. Tutto il resto è ipotesi: i clienti vogliono promemoria, prenotazioni di gruppo, fatture?

In un'impostazione agile, il primo sprint consegna un flusso di prenotazione cliccabile. Il fondatore lo mostra a cinque potenziali clienti. Il riscontro sposta le prenotazioni di gruppo più in alto nel backlog e i promemoria più in basso. Il secondo sprint realizza i pagamenti. Dopo qualche sprint c'è un prodotto utilizzabile e i soldi sono finiti su funzionalità sostenute da riscontri reali. Un piano Waterfall avrebbe specificato tutte le funzionalità all'inizio e mostrato il risultato mesi dopo.

Il compromesso è che Agile chiede di più a te. Qualcuno dalla tua parte deve decidere in fretta, partecipare alle revisioni e farsi carico delle priorità. Una portata che si muove ha bisogno di una cornice di budget che si muova con intenzione, non per caso.

Quando usare Agile e quando Waterfall è più adatto

Usa questa come guida alla decisione, non come regola.

Agile è adatto quando:

• I requisiti sono incerti o cambieranno con il riscontro degli utenti.
• Stai costruendo un nuovo prodotto, un MVP o una piattaforma in cui imparare è il punto centrale.
• Vuoi una versione funzionante in poche settimane, non alla fine di un piano lungo.
• I portatori d'interesse possono essere disponibili per revisioni regolari.
• Il mercato o la concorrenza si muovono in fretta.

Waterfall è adatto quando:

• La portata è stabile e ben compresa, per esempio la sostituzione di un sistema noto.
• Un contratto, un ente di vigilanza o una procedura d'appalto richiedono risultati fissi e approvazioni formali a ogni tappa.
• Le fasi dipendono l'una dall'altra in modo concreto, come hardware, migrazioni di dati o calendari di formazione.
• La tua organizzazione ha bisogno di un prezzo fisso unico e di una sola data di collaudo.

Poniti tre domande:

1. Quanto siamo sicuri di ciò che ci serve? Meno sei sicuro, più Agile.
2. Quanto ci costa una modifica tardiva? Se costa poco, Agile è sicuro. Se è rovinosa, pianifica di più all'inizio.
3. Chi decide dalla nostra parte? Agile ha bisogno di un product owner con autorità reale. Senza, gli sprint si impantanano.

Per la maggior parte delle startup e delle aziende in crescita che costruiscono siti, app o piattaforme, la prima domanda fa pendere la risposta verso Agile. La sfumatura onesta è che un «Agile» fatto male, senza obiettivi e senza una cornice di budget, può andare alla deriva. È un problema di disciplina, non di metodo.

L'approccio ibrido e perché i team svizzeri lo usano

Nella pratica si vedono raramente le forme pure. La gestione ibrida dei progetti unisce una pianificazione iniziale di portata e budget in stile Waterfall a un'esecuzione iterativa, con consegne in fasi successive invece che tutte in una volta. La UNIL’s executive education team afferma che si adatta ai casi in cui la direzione ha bisogno di un calendario, di tappe e di un budget controllato, mentre i team si aspettano che i dettagli evolvano.

I dati svizzeri vanno nella stessa direzione:

• Uno study presented at ICIS 2015 ha esaminato un approccio «Water-Scrum-Fall» in una grande banca svizzera per oltre un anno, su quattro team e con 17 interviste. Waterfall definiva il lavoro iniziale (funzionalità, budget, organizzazione), Scrum realizzava il software e Waterfall tornava per i passi finali come la consegna.
• La testata specializzata svizzera inside-it.ch reported on the same pattern: i grandi progetti usano Waterfall per il coordinamento, mentre i singoli team continuano a lavorare in modo agile.
• Il settore pubblico ha un metodo proprio. HERMES è uno standard aperto eCH usato nell'Amministrazione federale svizzera e in numerosi Cantoni e Città, perciò i team che lavorano per enti pubblici devono spesso far rientrare una realizzazione iterativa in una struttura di governance definita.

Un ibrido applicabile a un progetto piccolo

Non ti serve la governance di una banca per trarne vantaggio. Una versione pratica per una startup o una PMI:

1. Cornice (stile Waterfall): concordate l'obiettivo, il tetto di budget, le tappe principali e che cosa significa «finito» per il primo rilascio.
2. Realizzazione (Agile): lavorate in cicli brevi con un backlog visibile e una dimostrazione a ogni ciclo.
3. Rilascio e consegna (stile Waterfall): un collaudo definito, la documentazione e un passaggio di consegne chiaro, così da non restare poi dipendenti da chi ha costruito.

Così la direzione e le finanze hanno un confine e il team ha spazio per imparare.

Errori frequenti con entrambi i metodi

• Scegliere un metodo per moda. Nessuno dei due è automaticamente migliore. L'idea che Waterfall sia cattivo e Agile buono è una semplificazione molto diffusa e porta i team ad adottare i riti senza la sostanza.
• Portata fissa, prezzo fisso e «Agile» insieme. Se tutti e tre sono bloccati, non resta spazio per adattarsi. Decidi quale dei tre è flessibile.
• Saltare la fase di analisi iniziale. Anche i progetti agili hanno bisogno di una breve fase iniziale: obiettivi, utenti, vincoli, rischi tecnici.
• Cambiare il team a progetto in corso. Entrambi i metodi dipendono da persone che conoscono il contesto. Consegnare un sistema a metà a nuovi sviluppatori è l'inizio delle riscritture.
• Nessun piano di consegna. Qualunque sia il metodo, alla fine devi avere codice, documentazione e accessi sotto il tuo controllo.

Come lavoriamo in Ampersand

Siamo un piccolo studio di Zurigo e non vendiamo un metodo: lo adattiamo al progetto. Il nostro posizionamento è semplice: ingegneri senior guidano ogni progetto dalla prima conversazione fino alla consegna, un'impostazione pensata per evitare requisiti riscritti, cambi di personale a progetto in corso e trappole di dipendenza. È proprio questa continuità a far funzionare un approccio iterativo, perché chi ha capito la tua attività nel primo sprint c'è ancora al decimo.

Se stai progettando un sito, un'app, una piattaforma o una consulenza, la pagina dei prezzi elenca i formati che offriamo, tra cui piani di consulenza come Guidance a 799 CHF al mese e supporto continuativo come Run & monitor a 750 CHF al mese. Se non sai se il tuo progetto ha bisogno di una cornice fissa, di una realizzazione iterativa o di un mix, parti da una conversazione tramite il nostro sito e ti aiutiamo a dargli forma.

Lista di controllo rapida per decidere

Rispondi sì o no:

• Riesci a mettere per iscritto tutti i requisiti oggi e resteranno invariati?
• Un ente di vigilanza o un contratto richiedono un'approvazione per ogni fase?
• Il budget è fisso e non negoziabile?

Tre sì indicano Waterfall. Ora l'altro lato:

• Gli utenti reali cambieranno ciò che costruisci?
• C'è qualcuno nel tuo team che può rivedere il lavoro ogni una o due settimane?
• Un rilascio precoce e parziale ti insegnerebbe qualcosa di utile?

Tre sì indicano Agile. Risposte miste indicano un ibrido: fissa la cornice e itera al suo interno.

Domande frequenti

Agile è ancora attuale oggi?

Sì. Agile è il modo di lavorare predefinito di molti team software e continua a evolversi attraverso framework come Scrum e Kanban. La sua idea di fondo, imparare dal software funzionante e correggere la rotta, conta ancora di più quando i mercati si muovono in fretta. L'abilità sta nell'applicarlo con disciplina invece che come un rito.

Agile è una metodologia di gestione dei progetti?

A rigore, Agile è un insieme di valori e principi, e framework come Scrum li mettono in pratica. Secondo la Scrum Alliance, è un termine ombrello più che un metodo unico. I team lo usano per gestire progetti, ma è più ampio di qualsiasi singolo processo.

In che cosa Scrum è diverso da Waterfall?

Scrum lavora in sprint a durata fissa, con un backlog riordinato per priorità e una revisione del software funzionante alla fine di ciascuno. Waterfall completa fasi sequenziali rispetto a una portata definita all'inizio. Scrum si aspetta il cambiamento; Waterfall lo controlla in modo formale.

Posso combinare Agile e Waterfall?

Sì, e molte organizzazioni lo fanno. Uno schema comune è pianificare portata e budget all'inizio, costruire in modo iterativo e chiudere con un rilascio e un passaggio di consegne formali. Funziona meglio quando tutti sono d'accordo su quali parti sono fisse e quali possono cambiare.

Quale costa meno?

Nessuno dei due costa meno per natura. Waterfall può essere efficiente quando la portata è davvero stabile, mentre le modifiche tardive costano care. Agile distribuisce il costo lungo la realizzazione e ti permette di fermarti o cambiare direzione quando il riscontro lo suggerisce. L'approccio più economico è quello che corrisponde a quanto sei certo dei tuoi requisiti.

Fonti

• IBM describes it
• UNIL’s executive education team
• Wohlin and colleagues
• Scrum Alliance
• Rework’s methodology guide
• Deloitte Switzerland
• PMI Switzerland
• TechTarget
• classic Waterfall software introduction
• study presented at ICIS 2015
• reported on the same pattern
• HERMES