Agile vs waterfall è la scelta tra pianificare tutto prima e poi realizzarlo in un solo passaggio (waterfall), o costruire in cicli brevi correggendo il piano man mano che si impara (agile). Per la maggior parte dei progetti di app e siti web la risposta onesta sta nel mezzo: una fase fissa di analisi e design, poi cicli di sviluppo brevi con un budget chiaro. Questa guida spiega i due metodi in parole semplici, li confronta fianco a fianco, mostra quale si adatta a siti web, app e brand e chiude con i contratti adatti a ciascuno e una checklist per scegliere.
Che cosa sono agile e waterfall, in parole semplici?
Prima di confrontarli, conviene togliere a entrambe le parole il loro gergo. Nessuno dei due è una religione. Ognuno è un modo di decidere quando ti impegni su ciò che costruisci, e quanto costa cambiare idea dopo.
Waterfall: prima decidere, poi costruire
Il waterfall gestisce un progetto come una sequenza di fasi. Si raccolgono e si approvano i requisiti, poi il design, poi lo sviluppo, poi i test, poi il lancio. Ogni fase parte quando la precedente è finita, e tornare indietro costa tempo e denaro.
Il suo punto di forza è la prevedibilità. Conosci perimetro, prezzo e data prima che venga scritta la prima riga di codice. Il suo punto debole è che presume tu sappia tutto fin dall’inizio. Quando un utente reale incontra il prodotto per la prima volta, verso la fine, è tardi per scoprire che una schermata chiave non funziona per lui.
Agile: costruire, imparare, correggere
L’agile divide il lavoro in cicli brevi, di solito di una o due settimane, spesso chiamati sprint. Ogni ciclo si chiude con qualcosa di funzionante che puoi vedere e provare. L’elenco di ciò che va costruito dopo (il backlog) viene riordinato a ogni ciclo, in base a ciò che si è imparato.
Il suo punto di forza è l’adattabilità. Gli errori emergono presto, quando costano poco, e puoi fermarti in qualsiasi momento con qualcosa di utilizzabile. Il suo punto debole è che perimetro e costo finali non sono fissati all’inizio, il che innervosisce alcuni committenti e rende un rischio reale un referente debole dalla parte del cliente: l’agile richiede qualcuno dalla tua parte che prenda decisioni ogni settimana.
Agile vs waterfall a confronto
La tabella riporta le differenze pratiche che un committente percepisce, non la teoria.
| Waterfall | Agile | |
|---|---|---|
| Perimetro | Fissato all’inizio | Evolve ciclo dopo ciclo |
| Budget | Prezzo fisso per un perimetro fisso | Fisso per ciclo; il totale segue il perimetro |
| Quando vedi qualcosa di funzionante | Verso la fine | Ogni una o due settimane |
| Costo di una modifica | Alto, tramite richieste di modifica | Basso, assorbito nel ciclo successivo |
| Il tuo tempo richiesto | Intenso all’inizio e all’approvazione | Costante, ogni settimana |
| Documentazione | Dettagliata, scritta in anticipo | Più leggera, aggiornata strada facendo |
| Ideale quando | I requisiti sono chiari e stabili | I requisiti cambieranno man mano che impari |
| Rischio principale | Costruire bene la cosa sbagliata | Perimetro e budget che sfuggono |
Nota che nessuna delle due colonne è “migliore”. Il waterfall scambia flessibilità con certezza; l’agile scambia certezza con flessibilità. La scelta giusta dipende da quanto sai già.
Quale metodo per siti web, app e lavoro sul brand?
Il tipo di progetto decide il metodo più di qualsiasi preferenza dell’agenzia. Ecco come si collocano di solito i tre su cui lavoriamo più spesso.
Siti web
Un sito aziendale o di marketing ha di solito una forma ben nota: una serie di pagine, un CMS, moduli, visibilità nella ricerca. Gran parte si può pianificare in anticipo, il che si adatta a una struttura simile al waterfall per analisi, sitemap e design.
È nello sviluppo che l’agilità aiuta. I contenuti arrivano tardi, una pagina ha bisogno di una nuova sezione, il cliente vede la home page nel browser e vuole che l’apertura funzioni in un altro modo. Costruire in cicli brevi su un sito di staging permette di accogliere queste modifiche senza una richiesta formale per ognuna. Se stai definendo il budget, la nostra guida su quanto costa un sito web mostra dove vanno i soldi in ogni fase della realizzazione siti web.
App
Le app, che siano app mobile o applicazioni web con account, dati e logica di business, sono il terreno in cui il waterfall puro fallisce più spesso. Gli utenti si comportano in modi che nessuna specifica prevede, le piattaforme cambiano le regole e la funzione più preziosa è spesso una che nessuno aveva scritto all’inizio.
Per un’app l’agile è quasi la norma. Una prima versione utilizzabile (il minimum viable product) arriva agli utenti reali il prima possibile, e i cicli successivi si orientano su ciò che fanno. Il waterfall conserva un ruolo per le parti fisse: il modello dei dati, i requisiti di sicurezza, le integrazioni con i sistemi esistenti e tutto ciò che leggerà un’autorità di controllo.
Brand
La brand identity è un’altra cosa. Passa per strategia, concept e cura del dettaglio, e ogni passaggio dipende dalla decisione precedente. Non ha senso fare uno “sprint” su un logo: un’identità si sceglie nel suo insieme, tra poche strade ponderate.
Per questo il lavoro sul brand segue di solito una sequenza per fasi, simile al waterfall, con momenti di revisione ma con la possibilità di tornare indietro di un passo quando un concept non regge. Quando abbiamo creato l’identità di Nothing To Eat, il marchio e la sua costruzione sono stati definiti per primi, e il sito e le sue schermate sono venuti dopo, costruiti su decisioni già prese. Se ti chiedi dove finisce l’identità e inizia la percezione, il nostro articolo su brand image e brand identity va più a fondo.
Approcci ibridi che funzionano
La maggior parte dei progetti reali è ibrida, che qualcuno lo dica o no. La domanda utile è quali parti sono fisse e quali flessibili. Tre schemi si ripresentano di continuo.
Analisi fissa, poi sprint
È lo schema che consigliamo più spesso. La prima fase è un’analisi a perimetro e prezzo fissi: obiettivi, utenti, contenuti, scelte tecniche, una sitemap o una mappa delle funzioni, e le schermate chiave progettate. Sai esattamente quanto costa e cosa ottieni.
Poi lo sviluppo procede in sprint su un backlog ordinato per priorità, con un budget per sprint e una stima complessiva. Mantieni la certezza dove conta (la direzione e il design) e la flessibilità dove ripaga (lo sviluppo e i dettagli).
Waterfall con l’agile dentro
Alcune organizzazioni hanno bisogno di un contratto fisso e di una data di lancio fissa: un ente pubblico, un lancio legato a un evento, un prodotto regolamentato. Qui il guscio esterno è waterfall, con un perimetro firmato e delle milestone, ma ogni milestone si costruisce in brevi cicli interni con demo. Il cliente vede qualcosa di funzionante ogni due settimane circa senza che il contratto cambi forma.
Agile con un nucleo fisso
Per un’app uno schema diffuso è fissare le parti costose da cambiare (architettura, modello dei dati, sicurezza, design system) e mantenere agile tutto ciò che sta sopra. Le funzioni salgono e scendono liberamente nel backlog, perché le fondamenta non si muovono con loro.
Quali contratti per ciascun metodo?
Il metodo scelto deve corrispondere al contratto firmato. Un disallineamento, come un processo agile dentro un contratto a prezzo fisso rigido, è la causa di controversie più comune che vediamo.
Prezzo fisso
Il prezzo fisso si adatta al waterfall e alle fasi a perimetro fisso come l’analisi o la brand identity. L’agenzia si assume il rischio della stima, quindi il perimetro va scritto con precisione: pagine, funzioni, giri di revisione, cosa è incluso e cosa no.
Tutto ciò che esce da quel perimetro scritto diventa una richiesta di modifica: un breve documento che descrive la modifica, il suo costo e il suo effetto sulla data, firmato prima di iniziare il lavoro. Le richieste di modifica non sono un trucco. Sono ciò che mantiene un prezzo fisso equo per entrambe le parti.
Time and materials
Il time and materials si adatta all’agile. Paghi il tempo effettivamente impiegato, di solito a sprint o a mese, secondo una tariffa concordata. Il perimetro può muoversi liberamente, perché il prezzo segue il lavoro.
La tua tutela è la visibilità, non un totale fisso: un backlog che puoi leggere, una demo alla fine di ogni ciclo, un totale aggiornato rispetto alla stima e il diritto di fermarti dopo qualsiasi sprint con tutto ciò che è stato costruito fino a lì. Un tetto mensile o per fase è una richiesta ragionevole.
Prezzo fisso per sprint
Una via di mezzo è un prezzo fisso per ogni sprint, con un team e una durata fissi e un elenco flessibile di ciò che vi entra. Sai quanto costa ogni quindicina; l’agenzia sa a cosa si impegna; il contenuto di ogni sprint si concorda al suo inizio.
Se stai valutando a chi affidare il lavoro oltre a come contrattualizzarlo, il nostro confronto tra agenzia nuova o agenzia affermata spiega cosa chiedere a entrambe.
Come cambia l’AI il compromesso?
Parte del vecchio argomento a favore del waterfall era il costo: cambiare direzione significava rifare il lavoro a mano. Oggi è meno vero. In Odduel l’AI si occupa di gran parte della produzione ripetitiva (componenti del design system, codice front-end, prime bozze, casi di test, prime bozze delle traduzioni), così un ciclo produce più lavoro funzionante e un cambio di direzione costa meno da assorbire.
Ciò che non diventa più economico è il giudizio. Strategia, concept, direzione artistica, la voce del brand e la revisione finale restano lavoro umano, ed è lì che va il budget. Nella nostra esperienza questo sposta più progetti verso i cicli brevi: quando costruire è rapido, conviene vedere presto schermate reali piuttosto che perfezionare una specifica che nessun utente ha provato. È così che gestiamo i progetti di sviluppo app e di UX/UI design da Barcelona e São Paulo.
Come scegliere? Una checklist
Rispondi con onestà a queste domande. Più risposte cadono a sinistra, più ti si adatta il waterfall; più cadono a destra, più ti si adatta l’agile.
- Requisiti. Puoi scrivere oggi tutto ciò che il prodotto deve fare (waterfall), o ne imparerai la maggior parte dagli utenti (agile)?
- Budget. Ti serve un’unica cifra fissa firmata prima di iniziare (waterfall), o puoi lavorare con un budget mensile e un totale aggiornato (agile)?
- Scadenza. La data è fissata da qualcosa fuori dal tuo controllo (guscio waterfall), o è un obiettivo da bilanciare con il perimetro (agile)?
- Il tuo tempo. Qualcuno dalla tua parte può rivedere il lavoro e prendere decisioni ogni settimana (agile), o solo a poche milestone (waterfall)?
- Utenti. Puoi mettere una prima versione davanti a utenti reali (agile), o non esce nulla finché tutto non è finito (waterfall)?
- Conformità. Un’autorità di controllo, una regola sugli acquisti o un consiglio di amministrazione richiedono una specifica completa in anticipo (waterfall, almeno per il guscio esterno)?
- Tipo di lavoro. Si tratta di brand identity (per fasi), di un sito di marketing (ibrido) o di un’app (agile con un nucleo fisso)?
Se le risposte sono miste, è normale. Scegli un ibrido e decidi, parte per parte, cosa è fisso e cosa è libero.
Le domande più comuni
L’agile costa sempre più del waterfall?
No. L’agile può sembrare più caro perché il totale non è fissato all’inizio, ma i progetti waterfall finiscono spesso per pagare richieste di modifica e rifacimenti dopo il lancio. L’agile spende il budget su ciò di cui gli utenti hanno davvero bisogno, e puoi fermarti quando il prodotto è abbastanza buono. La vera differenza di costo dipende da quanto bene è gestito ciascuno.
Un contratto a prezzo fisso può essere agile?
In parte. Un prezzo fisso per fase o per sprint funziona bene con l’agile, purché il perimetro di ciascuno si concordi al suo inizio. Ciò che fallisce è un unico prezzo fisso per un elenco fisso di funzioni unito a una promessa di flessibilità: una delle due cede, di solito in una controversia.
Quale metodo è meglio per il restyling di un sito web?
Di solito un ibrido. Analisi, sitemap e design delle pagine chiave traggono vantaggio dall’essere fissati e approvati; sviluppo, inserimento dei contenuti e rifiniture traggono vantaggio dai cicli brevi su un sito di staging. Il sito esistente ti dà molte informazioni in anticipo, il che rende più facile definire la parte fissa.
Quanto dura uno sprint in un progetto di app?
La maggior parte dei team usa una o due settimane. Una settimana tiene stretto il feedback ma lascia poco spazio alle funzioni più grandi; due settimane sono l’equilibrio più comune. Più della durata conta che ogni sprint si chiuda con qualcosa di funzionante che puoi vedere e provare.
Cosa devo mettere a disposizione in un progetto agile?
Un product owner dalla tua parte: una persona che conosce l’azienda, sa fissare le priorità ed è disponibile ogni settimana per rivedere il lavoro e rispondere alle domande. Senza questa persona l’agile rallenta, perché il team aspetta decisioni che nessuno ha l’autorità di prendere.
Se hai in mente un’app o un sito e non sai come strutturarlo, parti da una breve analisi a prezzo fisso: ti dà un prezzo per lo sviluppo, un design su cui reagire e le informazioni per scegliere il metodo con sicurezza. Scopri come affrontiamo lo sviluppo app, oppure parlaci del tuo progetto.
