Agile vs Waterfall: come scegliere il metodo per la tua commessa
Agile e Waterfall a confronto: requisiti, consegne, feedback e responsabilità. Una matrice pratica per scegliere come organizzare la tua commessa.

Waterfall e Agile sono due modi diversi di organizzare una commessa. Waterfall (detto anche "a cascata") procede per fasi in sequenza: prima si definiscono tutti i requisiti, poi si progetta, si realizza, si collauda e si consegna. Agile lavora per cicli brevi: si consegna una parte utile, si raccoglie il feedback del cliente e si decide cosa fare nel ciclo successivo. Nessuno dei due è migliore in assoluto. Quello giusto dipende da quanto sono stabili le richieste del cliente, da quanto spesso puoi coinvolgerlo e da come è stata venduta la commessa. In questa guida trovi un confronto pratico, un caso ipotetico, una matrice per scegliere e una checklist da usare al prossimo avvio progetto.
In breve
- Waterfall fissa l'ambito del lavoro all'inizio: funziona bene quando i requisiti sono chiari e difficilmente cambieranno.
- Agile fissa tempi e risorse di ogni ciclo e lascia flessibile l'ambito: è adatto quando le richieste evolvono strada facendo.
- Le differenze concrete si vedono su consegne, feedback, approvazioni, gestione delle modifiche e responsabilità.
- La scelta del metodo inizia già in fase di vendita: preventivo, accordi sulle modifiche e passaggio di consegne al team di progetto.
- Molte aziende lavorano in modo ibrido: pianificazione a fasi per il quadro generale, cicli brevi per il lavoro operativo.
Indice
- Cosa cambia davvero tra i due approcci
- Il confronto su cinque punti operativi
- Un caso ipotetico: due commesse, due metodi
- Matrice per scegliere il prossimo modo di lavorare
- L'approccio ibrido: quando conviene combinare
- Dalla vendita al progetto: dove si decide il metodo
- Checklist di avvio progetto
- Domande frequenti
- Prova il tuo flusso di commessa in Flusia
- Raccomandati
Cosa cambia davvero tra i due approcci
La differenza più utile da capire non riguarda i rituali o gli strumenti, ma quale variabile resta fissa. Ogni commessa ha tre leve: ambito (cosa consegni), tempo e costo.
Secondo le risorse di project management del Department of Technology della California, l'approccio Waterfall tende a fissare l'ambito e ad accettare variazioni su tempo e costo, mentre Agile fissa tempo e risorse e rende l'ambito la parte flessibile. Le due impostazioni sono i due estremi di uno spettro, non due scatole chiuse.
In pratica:
- Con Waterfall dici al cliente: "Ti consegniamo esattamente questo elenco di cose". Se durante il lavoro emergono nuove richieste, serve una variante: più tempo, più budget o entrambi.
- Con Agile dici al cliente: "In ogni ciclo di due o quattro settimane lavoriamo sulle priorità più importanti". Se le priorità cambiano, cambia cosa entra nel ciclo successivo, non la durata del ciclo.
Il Service Manual del governo scozzese riassume bene il criterio di partenza: la scelta dipende dai requisiti del progetto e da quanta flessibilità ti serve.
Due termini che incontrerai spesso:
- Iterazione: un ciclo in cui si sviluppa e verifica una parte del lavoro. In Scrum il ciclo si chiama sprint e ha durata fissa; altri approcci Agile possono organizzare diversamente il flusso.
- Backlog: l'elenco ordinato per priorità delle cose da fare. In Agile è un documento vivo, che si aggiorna a ogni ciclo.
Il confronto su cinque punti operativi
Per un responsabile che deve organizzare una commessa, le differenze teoriche contano meno di quelle che si vedono nel lavoro quotidiano. Ecco i cinque punti su cui i due metodi si separano.
| Aspetto | Waterfall | Agile |
|---|---|---|
| Consegne | Una consegna principale alla fine, con eventuali milestone intermedie | Consegne parziali e frequenti, una per ciclo |
| Feedback del cliente | Concentrato all'inizio (requisiti) e alla fine (collaudo) | Raccolto a ogni ciclo, sulle parti già realizzate |
| Approvazioni | Formali, a chiusura di ogni fase: chi approva firma e la fase si chiude | Frequenti e più leggere: il cliente valuta l'incremento e riordina le priorità |
| Gestione delle modifiche | Ogni modifica è una variante da stimare, approvare e pianificare | Le modifiche entrano nel backlog e competono con le altre priorità |
| Responsabilità | Il project manager governa il piano e il perimetro concordato | Il team si organizza sul lavoro del ciclo; una figura lato cliente o interna decide le priorità |
Una precisazione sulle responsabilità. Nel framework Scrum, uno dei modi più diffusi di applicare Agile, la Scrum Guide assegna a un Product Owner il compito di ordinare il lavoro per valore. Se il tuo cliente non ha tempo o autorità per svolgere questo ruolo, un approccio Agile "puro" diventa difficile da sostenere: le priorità resterebbero senza un responsabile.
Un caso ipotetico: due commesse, due metodi
Per rendere concreto il confronto, prendiamo due commesse ipotetiche che la stessa azienda acquisisce nello stesso mese. I nomi e i dettagli sono inventati a scopo illustrativo.
Commessa A: sito istituzionale con requisiti definiti
Un cliente del settore industriale chiede un sito istituzionale di otto pagine. Ha già il logo, i testi approvati dalla direzione, la mappa delle pagine e una data di lancio legata a una fiera.
Come si sviluppa con un'impostazione a fasi:
- Raccolta requisiti: il commerciale passa al team il documento con pagine, contenuti e funzioni richieste.
- Progettazione: il team prepara il layout e lo sottopone al cliente per un'approvazione formale.
- Realizzazione: sviluppo delle pagine secondo il layout approvato.
- Collaudo: il cliente verifica il sito su un ambiente di prova e segnala le correzioni.
- Consegna: messa online e chiusura della commessa.
Qui Waterfall ha senso: il perimetro è chiaro, il cliente sa cosa vuole e la data è fissa. Ogni richiesta fuori perimetro (per esempio una sezione blog aggiunta a metà lavoro) viene gestita come variante, con una stima separata.
Commessa B: progetto con richieste che cambiano
Un secondo cliente vuole un'area riservata per i propri rivenditori. Sa quale problema vuole risolvere (i rivenditori chiedono troppe informazioni via email), ma non sa ancora quali funzioni serviranno davvero. Vuole provare qualcosa presto con un gruppo ristretto di rivenditori.
Come si sviluppa a cicli:
- Obiettivo e backlog iniziale: si concordano l'obiettivo e un primo elenco di funzioni, ordinate per priorità.
- Primo ciclo: il team realizza la funzione più richiesta, per esempio la consultazione dei documenti.
- Revisione con il cliente: il cliente prova la funzione con alcuni rivenditori e porta i loro commenti.
- Riordino delle priorità: dai commenti emerge che serve prima uno storico ordini; il backlog si aggiorna.
- Cicli successivi: si procede finché il budget o il tempo concordato lo permettono, consegnando ogni volta la parte con più valore.
Qui un piano dettagliato a inizio lavoro diventerebbe vecchio in poche settimane. Un approccio iterativo consente di rivedere le priorità secondo gli accordi scritti, a patto che il cliente partecipi alle revisioni. Variazioni di budget o di perimetro contrattuale vanno comunque concordate.
Cosa insegna il confronto
La differenza tra le due commesse non sta nel settore o nella dimensione, ma nel livello di incertezza. Lo stesso team può lavorare a fasi sulla commessa A e a cicli sulla commessa B. Quello che deve cambiare è il modo in cui la commessa viene venduta, preventivata e passata al team.
Matrice per scegliere il prossimo modo di lavorare
Usa questa matrice prima di avviare la prossima commessa. Per ogni riga, segna la colonna che descrive meglio la tua situazione. Se la maggior parte delle risposte cade a sinistra, parti da un'impostazione a fasi; se cade a destra, valuta i cicli brevi; se le risposte sono miste, considera un approccio ibrido.
| Domanda | Orienta verso Waterfall | Orienta verso Agile |
|---|---|---|
| I requisiti sono scritti e approvati? | Sì, in un documento condiviso | No, o solo l'obiettivo generale |
| Le richieste cambieranno durante il lavoro? | Poco probabile | Molto probabile |
| Il cliente può partecipare a revisioni frequenti? | No, solo a inizio e fine | Sì, con una persona di riferimento |
| Chi decide le priorità lato cliente? | Referente per chiarimenti e approvazioni di fase | Una persona con tempo e autorità |
| Il preventivo è a corpo o a tempo? | A corpo, su un perimetro fisso | A tempo o a budget per ciclo |
| La data di consegna è vincolata a un evento esterno? | Sì, e il perimetro deve esserci tutto | Sì, ma il perimetro può ridursi |
| Ci sono approvazioni formali obbligatorie tra le fasi? | Sì | No, o sono leggere |
| Il team ha già lavorato a cicli brevi? | No | Sì |
La matrice non dà un punteggio: serve a rendere esplicite le condizioni. Se scopri che il cliente non ha una persona di riferimento disponibile, per esempio, è un dato da chiarire prima di firmare, non dopo.
L'approccio ibrido: quando conviene combinare
Nella realtà molte commesse non sono né tutte stabili né tutte incerte. Le linee guida del governo britannico sui contratti Agile mettono a confronto il modello Agile con la consegna tradizionale e indicano in quali contesti il primo è più adatto, il che implica che non vale ovunque.
Un esempio ipotetico di impostazione ibrida:
- A fasi: analisi iniziale, budget complessivo, data di lancio, approvazioni contrattuali.
- A cicli: sviluppo delle funzioni, con revisioni ogni due settimane e priorità riviste a ogni revisione.
- A fasi di nuovo: collaudo finale, formazione degli utenti, chiusura amministrativa.
Il rischio da evitare è l'ibrido "per inerzia": riunioni Agile sovrapposte a un piano rigido che nessuno può cambiare. In quel caso il team ha il carico di entrambi i metodi e i benefici di nessuno.
Dalla vendita al progetto: dove si decide il metodo
Il metodo di lavoro non si sceglie il giorno del kick-off. Si decide, spesso senza accorgersene, quando il commerciale scrive il preventivo e promette cosa sarà consegnato. Se il preventivo descrive un perimetro chiuso a prezzo fisso, stai già vendendo una commessa a fasi. Se descrive un obiettivo e un budget per cicli, stai vendendo un lavoro iterativo.
Per questo il passaggio dalla vendita al progetto è il punto più delicato. Ecco una sequenza applicabile:
- Qualifica l'incertezza durante la trattativa. Quando un'opportunità avanza nella pipeline di vendita, annota nelle note dell'opportunità quanto sono definiti i requisiti e chi decide lato cliente.
- Scrivi il preventivo coerente con il metodo. A corpo per un perimetro fisso; a cicli o a budget per un progetto evolutivo. Indica sempre come verranno gestite le modifiche. Se stai valutando come impostarlo, trovi criteri utili nella guida sul software per preventivi.
- Passa al team tutto il contesto. Requisiti, accordi sulle modifiche, referenti e scadenze devono arrivare al responsabile di progetto insieme alla commessa, non in una email separata.
- Imposta il progetto nella vista giusta. Un diagramma di Gantt (la rappresentazione delle attività su una linea temporale, con dipendenze tra fasi) aiuta a governare una commessa a fasi; una bacheca Kanban (colonne che mostrano lo stato di ogni attività) aiuta a seguire il lavoro a cicli. Le differenze sono spiegate nella guida a Gantt, Kanban e task.
- Definisci chi approva cosa. Assegna ruoli chiari nel team e, dove serve, limita chi può modificare scadenze o perimetro. Per impostare l'accesso trovi indicazioni su ruoli e permessi nel CRM.
- Collega avanzamento e fatturazione. Con Waterfall si fattura tipicamente a milestone; con Agile spesso a ciclo o a consuntivo. In entrambi i casi chi amministra deve sapere cosa è stato consegnato e approvato.
Come ti aiuta Flusia in questo passaggio
Flusia è un CRM italiano pensato per tenere insieme clienti, opportunità e lavoro del team. Nella stessa piattaforma gestisci lead e opportunità, prepari preventivi con il supporto dell'AI, organizzi progetti e task con viste Gantt e Kanban, colleghi la fatturazione e imposti utenti e ruoli. Il metodo resta una scelta tua e del tuo team: Flusia non lo applica al posto tuo, ma ti aiuta a non perdere informazioni tra la firma del contratto e l'avvio del lavoro. Le funzioni disponibili dipendono dal piano: per piani, fasce di utenti e add-on consulta la pagina prezzi aggiornata.
Checklist di avvio progetto
Usa questa checklist al kick-off di ogni commessa, qualunque metodo tu abbia scelto.
Prima del kick-off
- Il preventivo firmato descrive perimetro, modalità di consegna e gestione delle modifiche.
- Hai deciso il metodo (a fasi, a cicli o ibrido) e lo hai comunicato al cliente.
- C'è un referente lato cliente con tempo e autorità per approvare o dare priorità.
- Il team di progetto ha ricevuto le note della trattativa, non solo il preventivo.
Al kick-off
- Condividi con il cliente il calendario delle consegne o delle revisioni.
- Concorda chi approva cosa e in che forma (firma, email, commento sul task).
- Spiega come verrà gestita una richiesta nuova: variante o voce nel backlog.
- Assegna un responsabile per ogni attività o per ogni ciclo.
Nelle prime settimane
- Controlla che le attività siano aggiornate nella vista scelta (Gantt o Kanban).
- Registra ogni modifica richiesta con data, richiedente ed effetto su tempi o costi.
- Verifica con il cliente, alla prima consegna o revisione, che il metodo funzioni per entrambi.
Domande frequenti
Scrum è Agile o Waterfall?
Scrum è un framework Agile. La Scrum Guide lo definisce un framework leggero per generare valore attraverso soluzioni adattive a problemi complessi, organizzato in sprint di durata fissa. Agile è l'insieme di valori e principi; Scrum è uno dei modi per metterli in pratica.
Un software di gestione progetti è Agile o Waterfall?
Nessuno strumento è Agile o Waterfall di per sé. Gli strumenti offrono viste e modelli, come il Gantt per le fasi o il Kanban per i cicli, che supportano il metodo scelto dal team. Prima decidi come vuoi lavorare, poi configura lo strumento di conseguenza.
Agile è ancora attuale nel 2026?
È un riferimento per i progetti in cui il confronto frequente con il cliente e la revisione delle priorità sono utili. La scelta va fatta sul progetto concreto. I principi del Manifesto Agile, come la consegna di valore fin da subito e in modo continuo, restano un riferimento per i progetti con richieste che cambiano.
Si può passare da Waterfall ad Agile a commessa avviata?
Si può, ma va concordato con il cliente, perché cambiano il modo di approvare, di gestire le modifiche e spesso di fatturare. Il momento più semplice è a chiusura di una fase, quando hai un risultato da mostrare. Aggiorna anche il preventivo o gli accordi scritti, in modo che riflettano il nuovo modo di lavorare.
Prova il tuo flusso di commessa in Flusia
Ogni azienda vende e consegna in modo diverso: c'è chi chiude commesse a perimetro fisso, chi lavora a cicli, chi combina le due cose. Se vuoi vedere come collegare opportunità, preventivo, progetto e fatturazione nel tuo caso specifico, richiedi una demo di Flusia e portaci il flusso di una tua commessa reale: lo analizziamo insieme.
Raccomandati
Le procedure e le tabelle della guida sono modelli da adattare al proprio processo. Prima di attivare un automatismo, verifica con il team quali passaggi sono disponibili nel piano e quali richiedono configurazioni o integrazioni.
Condividi questo articolo
Scritto da
Flusia
Risorse e guide sul CRM
Articoli correlati

Kanban o Gantt: come scegliere per commesse, responsabilità e scadenze
Kanban o Gantt per le commesse? Criteri di scelta, esempi ipotetici e checklist per collegare attività, responsabilità e scadenze al cliente.

Software gestione commesse: cosa deve fare
Come scegliere un software di gestione commesse: le funzioni che servono davvero, come provarle prima di comprare e le domande da fare durante la demo.

Come organizzare gli interventi di assistenza
Come organizzare gli interventi di assistenza: raccogliere la richiesta, pianificare l'uscita, preparare il tecnico, chiudere il lavoro e fatturare gli extra.