Storia del metodo Waterfall
Il modello Waterfall è un modello logico da seguire: pianifica, costruisci, testa e rilascia in sequenza. La storia del metodo Waterfall ha origine dall'articolo del 1970 di Winston W. Royce in Proceedings of IEEE WESCON, "Managing the Development of Large Software Systems". L'articolo di Royce è stata probabilmente la prima discussione sul metodo Waterfall nello sviluppo software, sebbene la parola "waterfall" (cascata) non appaia nell'articolo. Il termine formale è stato introdotto nella relazione di Thomas E. Bell's e T.A. Thayer del 1976 pubblicata in Proceedings of the 2nd International Conference on Software Engineering, "Software requirements: Are they really a problem?". Come notato da molti, tuttavia, la relazione di Royce non ha esaltato il metodo. Anzi, lo descrive in termini poco lusinghieri, definendolo difettoso e propenso al fallimento sotto molti aspetti. È andato avanti parlando di un approccio più iterativo, forse il fondamento di ciò che sarebbe diventato un approccio Agile.
La relazione di Bell e Thayer parla di un cambiamento nell'approccio, dal basso verso l'alto all'alto verso il basso, nello sviluppo dei requisiti software, in riferimento all'adozione di questo approccio in MIL STD 490/483 (MILD 490), in cui si parla pratiche sulle specifiche, e MILD 483, in cui si parla delle pratiche di gestione delle configurazioni per sistemi. La relazione è interessata principalmente dall'esame degli approcci in modo empirico per determinare quale funziona meglio. In definitiva, il documento dichiara che "negli ultimi dieci anni, sono state adottate maggiori struttura e disciplina e i professionisti hanno concluso che un approccio dall'alto verso il basso è migliore rispetto all'approccio inverso del passato". Il termine "waterfall" (cascata) è utilizzato in riferimento diretto alla relazione di Winston Royce.
Nonostante i difetti descritti da Royce, il metodo Waterfall è diventato un metodo preferenziale nel 1985, quando il Dipartimento della Difesa ha pubblicato lo standard DOD-STD-2167A, Defense Systems Software Development. Lo standard descrive il ciclo di sviluppo software come riportato di seguito:
- Analisi dei requisiti software
- Progettazione preliminare
- Progettazione dettagliata
- Codifica e test dell'unità
- Integrazione e test dei CSC (Computer Software Component)
- Test CSCI
Andando avanti, si afferma che "questo standard è destinato ad essere dinamico e reattivo nel campo della tecnologia software in rapida evoluzione. Pertanto, deve essere applicato selettivamente e personalizzato per adattarlo alle caratteristiche uniche di ogni programma di acquisizione software." Tuttavia, il requisito è stato messo nero su bianco e seguito scrupolosamente.
Il metodo Waterfall ha iniziato a perdere popolarità quando i leader del settore hanno accusato una certa frustrazione in termini di flessibilità del metodo e hanno e sviluppato il Manifesto Agile. Da allora, sempre più aziende hanno adottato Agile, ma molte aziende sfruttano ancora il metodo Waterfall, e per un buon motivo. Il metodo, pur con i suoi difetti, offre dei vantaggi e, nell'ambiente giusto, può essere la best practice da seguire.
Guida alla gestione dei progetti
Il tuo punto di riferimento per la gestione di tutti i progetti
Vuoi ottenere di più dai tuoi sforzi di gestione dei progetti? Consulta la nostra guida completa alla gestione dei progetti per suggerimenti, best practice e risorse gratuite per gestire il tuo lavoro in modo più efficace.
Vantaggi della gestione dei progetti Waterfall
A fronte di le critiche mosse al metodo Waterfall, occorre ricordare alcuni vantaggi reali offerti dalla sua implementazione:
- È un approccio semplice e diretto.
- È facile sviluppare un piano per la gestione di un progetto Waterfall, poiché ogni fase ha un inizio e una fine, e si sa prima di codificare cosa occorre sviluppare, entro quando, quando iniziare i test, ecc.
- La pianificazione iniziale fornisce una buona base per la progettazione di componenti che si integrano con sistemi esterni.
- È facile pianificare le risorse per il metodo Waterfall perché, ripetiamo, si sa quando ogni cosa inizia e finisce.
- I clienti che desiderano date di inizio e fine definitive possono trovarlo un metodo rassicurante. Ai clienti può essere detta la data in cui avranno a disposizione il prodotto e, se il progetto è giusto per un approccio Waterfall, viene consegnato in quella data.
- Il costo dello sviluppo può essere determinato in anticipo.
- Procedure dettagliate possono essere utilizzate per regolare ogni parte del processo.
- L'approccio del metodo Waterfall, caratterizzato da una progettazione intensa, costringe ad adottare un approccio disciplinato allo sviluppo e rende chiare le aspettative.
- I membri del team possono partecipare ad altri progetti prima dell'inizio della loro fase o dopo la sua fine, tornando al progetto secondo le necessità.
- L'affidamento alla documentazione sulla progettazione riduce lo stress dall'avvicendamento degli sviluppatori.
- L'approccio di progettazione intensa implica che è possibile individuare gli errori nella fase di progettazione. Questo comporta insidie ovvie, e chiunque abbia lavorato con il metodo Waterfall sa che gli errori di progettazione si verificano, ma ci si avvale di un team di esperti e si mette insieme un piano, ottenendo spesso un design valido che può essere eseguito secondo il piano.
Aspetti negativi della gestione dei progetti Waterfall
Ecco alcuni dei principali problemi e critiche del metodo Waterfall:
- Il tempo per il rilascio è estremamente lungo per i progetti di grandi dimensioni. La relazione su Waterfall elaborata da Royce era benevola quando si parlava di progetti piccoli e interni, ma il metodo era considerato abbastanza difettoso per progetti più grandi e complessi. In effetti, questo è probabilmente il motivo principale per cui Agile è diventato così popolare. Con il metodo Waterfall, i progetti troppo grandi venivano annullati prima di poter raggiungerne il completamento.
- La seconda critica principale al metodo Waterfall è che il cambiamento non è cosa gradita. Una volta iniziato il test, è estremamente costoso tornare allo sviluppo o a riprogettare. Il design deve essere scritto accuratamente e correttamente prima di andare troppo avanti.
- Il software funzionante appare in ritardo nel progetto.
- I bug scritti all'inizio del progetto possono essere grandi grattacapi per la codifica successiva, ma nessuno di questi diventa evidente fino all'inizio dei test, il che rende la correzione del codice costosa in termini di denaro e di tempo.
- Non è un approccio orientato all'oggetto. I progetti Waterfall sono altamente integrati. Si tratta di un altro aspetto di questo metodo che ne riduce la flessibilità.
- Non è un buon metodo per la manutenzione e altri tipi di progetti a lungo termine.
- Parallelamente alle critiche precedenti, c'è il fatto che i clienti spesso non sanno cosa vogliono prima dell'inizio del progetto.
- Se il team non ha esperienza o naviga in acque sconosciute, si presentano ostacoli che creano rischi per il progetto.
- I test possono essere brevemente modificati al fine di rimanere nei tempi previsti, il che lascia bug che scoprirà il cliente dopo la consegna del prodotto.
- Gli eventi possono portare allo smantellamento dell'intero progetto. Ad esempio, i cambiamenti nel settore che si verificano durante la fase di sviluppo potrebbero rendere l'intero progetto obsoleto. Un altro evento può essere la scoperta di un difetto di progettazione così grave da dover riprogettare da capo, operazione che può essere così costosa che il cliente potrebbe annullare il progetto.
Confronto tra Waterfall e Agile
Il modello Waterfall si concentra sulla fase di progettazione di un progetto, mentre Agile prevede per questa fase un tempo minimo. Entrambe le opzioni di gestione dei progetti hanno l'obiettivo di fornire un software funzionante, ma i progetti Waterdall vengono consegnati solitamente una o due volte l'anno (o anche meno frequentemente) mentre il metodo Agile consente di consegnare un software funzionante con una frequenza anche di una settimana. Le consegne con il metodo Waterfall possono essere grandi e richiedono un periodo di test lungo, con molte aziende che utilizzano anche i clienti per fornire test Beta. Agile testa il del software mentre viene costruito, con lo sviluppatore che esegue spesso i test.
Una differenza significativa tra i metodi Waterfall e Agile è che il primo è una metodologia, mentre il secondo è un "movimento" che include una serie di metodi derivati che applicano i principi e i valori di Agile. Scrum, eXtreme Programming (XP), Kanban, Scrumban e molti altri metodi offrono al team di sviluppo diverse opzioni, quindi la scelta migliore potrebbe essere uno di questi.
Una metodologia Agile è una scelta superiore quando il cliente è incerto sui requisiti o vuole essere strettamente coinvolto nel processo di sviluppo e se le tempistiche sono brevi e vuole una consegna rapida. Il modello Waterfall è superiore se ci sono dipendenze complesse, ma Agile è preferibile quando le dipendenze sono minime. Agile è anche il migliore se la velocità è più importante della qualità.
Alcuni svantaggi di Agile sono i seguenti:
- Richiede il coinvolgimento dei clienti
- I costi e le tempistiche sono incerti
- La pianificazione è difficile
- Mancanza di chiarezza sul risultato finale
- Documentazione minima
- I membri del team devono essere interfunzionali: qualcuno che non abbia esperienza in ruoli non familiari
- Gli sviluppatori sono dedicati a un singolo progetto
- Lo scope creep è un rischio: se un progetto è ben disposto al cambiamento può crescere in modo incontrollato e proseguire oltre la sua data di scadenza
L'idea che Agile sia radicalmente diverso dal metodo Waterfall non è completamente vera. L'approccio Agile è in realtà più di un approccio Waterfall adattato, un tentativo di risolvere alcuni degli svantaggi del metodo Waterfall in termini di resistenza ai cambiamenti e alle date di consegna a lungo termine. La mancanza di flessibilità e un alto tasso di progetti annullati ha determinato il passaggio da Waterfall ad Agile da parte di molti team. Tuttavia, è importante capire che Agile adotta comunque un approccio sequenziale: semplicemente, utilizza una sequenza più breve. Agile include ancora alcune analisi dei requisiti e la progettazione all'inizio, ma la codifica non inizia finché i requisiti e la progettazione vengono completati e non è possibile testare il codice che non è stato scritto o consegnato un codice che non sia stato testato e integrato. Pertanto, Agile può essere pensato come una forma più flessibile e rapida di gestione dei progetti Waterfall.
Suggerimenti e best practice per il tuo prossimo progetto utilizzando la metodologia Agile.
Scopri tutto quello che c'è da sapere sulla gestione dei progetti Agile e i suggerimenti per iniziare a implementare le best practice Agile per il PM.
Ottieni l'e-book gratuito per implementare le mie best practice Agile
Quando utilizzare il metodo Waterfall per la gestione dei progetti
Decidere tra Waterfall e Agile significa esaminare le caratteristiche del progetto e le esigenze del cliente. In particolare, presta attenzione ai requisiti, allo scopo e all'obiettivo del progetto. Il modello Waterfall è spesso una scelta migliore quando:
- I requisiti sono ben compresi e probabilmente non cambiano.
- Il cliente non è incline a cambiamenti impegnativi.
- Il cliente preferisce non essere coinvolto nello sviluppo, ma vuole essere consultato all'inizio e ricevere un pacchetto di lavoro alla fine del progetto. Agile funziona meglio quando il cliente è coinvolto in tutte le fasi (rivedendo il prodotto a ogni iterazione), ma i clienti Waterfall hanno bisogno di ricevere un solo rilascio e di installarlo. (Nota: si tratta di una semplificazione. I clienti devono anche essere formati all'utilizzo del sistema, che può essere una fase lunga e importante. Questo vale indipendentemente dal metodo utilizzato e può darsi che la formazione degli utenti una o due volte l'anno sulle nuove funzioni di una versione più ampia sia meno intrusiva rispetto a una formazione mensile o anche settimanale su una serie di funzioni più piccole. Inoltre, tieni presente che i clienti che vogliono essere coinvolti possono essere clienti di un progetto Waterfall. Coinvolgere il cliente in revisioni frequenti può distrarre e portare a richieste di cambiamenti indesiderate, ma può anche mantenere il progetto incentrato sulle esigenze dei clienti.)
- Il progetto è piccolo.
- La velocità di consegna non è importante.
- La consegna deve essere applicata a un sistema precedente non incline al cambiamento.
- Avrai progetti simili in futuro, e potrai riutilizzare il piano del progetto e trarre lezioni dalla documentazione consistente del progetto precedente.
Un breve sguardo alle migliori metodologie di gestione dei progetti
Waterfall è solo una delle molte metodologie concorrenti. Nel decidere di implementarne una, avere un'idea di cosa sono può essere d'aiuto. Di seguito è riportata una breve descrizione delle principali metodologie di gestione dei progetti attualmente in uso.
Waterfall
La metodologia Waterfall è generalmente considerata un approccio tradizionale alla gestione dei progetti. Questo modello si basa sul principio di eseguire le operazioni in sequenza, terminando una fase del progetto prima di iniziarne un'altra. Ciò ha creato molte dipendenze e ha comportato alcune situazioni abbastanza disastrose per lo sviluppo di software. I progetti sono spesso rimasti indietro e hanno sforato il budget, e in alcuni casi sono stati annullati completamente quando la tecnologia è cambiata troppo rapidamente.
Metodo del percorso critico (CPM)
Il metodo CPM è un altro metodo sequenziale che presume il completamento di ogni fase per poter passare a quella successiva. La fase di pianificazione di un progetto CPM consiste nell'identificare le parti più intense di risorse del progetto per allocare le risorse ed evitare colli di bottiglia. L'applicazione del metodo avviene nei seguenti passaggi:
- Identificare le attività richieste e definire la sequenza per completarle.
- Definire le dipendenze per le attività necessarie.
- Determinare le relazioni che sono e non sono critiche tra le attività.
- Pianifica la sequenza temporale prevista per ogni attività.
- Sviluppa un piano B per percorsi critici.
Gestione dei progetti a catena critica (CCPM)
Waterall si concentra sulla progettazione e il CPM sulle attività, mentre il CCPM si concentra sulle risorse e sulla loro allocazione. La CCPM si concentra sui fattori che possono influenzare le tempistiche, i costi, le prestazioni e il rischio di mancare la consegna. L'approccio della CCPM è quello di definire la catena critica, applicare le risorse che possono fare il meglio e infine introdurre i buffer di tempo nelle attività critiche per garantire una consegna tempestiva se si verificano problemi.
PMI PMBOK® Guide
Il metodo PMI PMBOK® Guide per la gestione dei progetti applica i cinque gruppi di processo PMI del testo A Guide to Project Management Body of Knowledge. Ecco una panoramica di alto livello di questi gruppi:
- Avvio-Definisci la visione. Si tratta anche del gruppo di processi in cui il project manager viene selezionato.
- Pianificazione-Definisci l'ambito. Il PMBOK descrive 24 processi nella fase di Pianificazione.
- Esecuzione-Metti in azione il piano.
- Monitoraggio e controllo-Si verifica durante l'intero progetto e non è una fase sequenziale che aspetta la fine di un'altra fase.
- Chiusura-Si verifica quando il cliente accetta il progetto.
Metodologie Agile
Agile è definito come un movimento, non come una metodologia, ma come una famiglia di metodologie Agile sviluppate in accordo con i valori e i principi Agile.
Scrum
Il metodo Scrum ha un piccolo team Agile diretto da uno Scrum master. Il ruolo dello Scrum master è facilitare il lavoro del team. La pianificazione è minima e viene creata una lista delle attività da lavorare. Le attività vengono lavorate in "sprint", che durano solitamente da due a quattro settimane. I brevi meeting quotidiani (detti Daily Scrum) vengono tenuti per trattare le attività quotidiane e identificare gli ostacoli. I membri del team svolgono tutte le attività tradizionali di un progetto, progettando man mano che procedono e testano man mano che completano un'attività. L'obiettivo di Scrum è di consegnare il software funzionante. Quando uno sprint termina, inizia quello successivo, con il team che delinea una serie di attività dal backlog di progetto. Quando gli obiettivi generali del progetto sono stati raggiunti e non ci sono più attività, il progetto è completato.
Kanban
È il metodo più adatto per i progetti di manutenzione. Il fulcro del metodo Kanban è la bacheca Kanban, un elenco di tutte le attività (chiamate anche cartellini Kanban) da eseguire che vengono continuamente aggiornate e sono facilmente visibili a tutti i membri del team. Quando una risorsa (membro del team) diventa disponibile, assume un'attività dalla bacheca e la lavora. Le attività vengono aggiunte alla bacheca e lavorate continuamente. Non esiste un inizio o una fine definiti per il progetto.
Extreme Programming (XP)
Gli sprint durano solitamente una settimana con molte iterazioni. In XP, il cambiamento è la chiave e i programmatori XP lavorano a stretto contatto con le parti interessate. XP è ideale per gli ambienti in cui i requisiti cambiano costantemente. Le attività possono essere sostituite a metà sprint.
Adaptive Project Framework (APF)
Il presupposto dell'APF è che i progetti IT variano così ampiamente che nessun approccio prefissato ha senso. I progetti IT sono diversi in termini di rischi, costi, durata e complessità e spesso comportano incertezza nel mercato, nel valore aziendale, nel coinvolgimento dei clienti e negli obiettivi. Un progetto APF inizia quindi con l'analisi dei requisiti per definire gli obiettivi strategici. Il progetto viene eseguito iterativamente e le iterazioni vengono analizzate dopo la sua chiusura per migliorare il processo. L'analisi è solitamente continuativa, in modo che l'intero progetto possa essere ridefinito o adattato man mano che procede in risposta alle questioni di incertezza per mantenere o aumentare il valore aziendale.
Lean
Il metodo Lean è destinato a ridurre gli sprechi e massimizzare il valore. I valori fondamentali del metodo Lean sono il miglioramento incrementale continuo e il rispetto delle persone. Lean si concentra sulla consegna del valore più alto al cliente, mantenendo il flusso, assegnando il lavoro in modo uniforme e, soprattutto, eliminando gli sprechi.
Six Sigma
Il metodo Six Sigma si basa sull'eliminazione dei difetti nello sviluppo attraverso processi efficienti e un miglioramento continuo dei processi. Una valutazione Six Sigma significa che il prodotto è al 99,99966% privo di difetti. Quando si dispone di un processo con una valutazione Six Sigma, significa che ogni prodotto consegnato tramite questi prodotti darà lo stesso risultato prevedibile.
Lean Six Sigma
Lean Six Sigma tenta di combinare gli approcci Lean e Six Sigma, eliminando gli sprechi per rendere i processi più efficienti e fornire alto valore e bassi difetti al cliente.
Gestione dei progetti basata sui processi
Nella gestione dei progetti basata sui processi, l'attenzione è dedicata all'allineamento di ogni progetto alla mission e ai valori aziendali. I progetti sono incorporati nella strategia aziendale. Di conseguenza, tali aspetti tradizionali dell'analisi del progetto, come i parametri, vengono utilizzati per determinare quanto accuratamente si soddisfa l'obiettivo.
PRINCE2
Il metodo PRINCE2 si basa sul metodo PRINCE di minor successo. Il metodo PRINCE non è stato ampiamente adottato perché era troppo ingombrante e fu rivisto nel 1996 diventando PRINCE2 da un comitato composto da 150 organizzazioni europee. Sebbene PRINCE fosse destinato a ridurre gli sforamenti di costi e tempo in ambito IT, fu sviluppato anche come metodologia di gestione dei progetti per qualsiasi tipo di progetto. PRINCE2 è stata una revisione importante del 2009 che ha reso il metodo più semplice e ha introdotto sette principi di base per il successo del progetto.
Metodo sostenibile di integrazione dei progetti (PRiSM)
PRiSM si concentra su una gestione dei progetti socialmente responsabile. Il suo intento è gestire i progetti riducendo gli impatti negativi sull'ambiente e promuovendo progetti socialmente utili.
Benefits Realization
Il metodo Benefits Realization è tutto incentrato sul cliente. Dall'inizio alla fine, il metodo cerca di garantire che il cliente ottenga il massimo vantaggio dai risultati, al di sopra e al di là dei costi e del calendario.
Molti metodi di gestione dei progetti sono uguali per molte opportunità
Esistono molti metodi nel mondo della gestione dei progetti. La maggior parte è cresciuta attorno a nuovi approcci e a diverse esigenze che sono emerse quando il settore software è diventato più complesso (varietà di metodi e lingue) e anche più semplice (maggiore facilità di scrittura del codice). I vecchi metodi di gestione dei progetti, tuttavia, mantengono il loro valore negli ambienti giusti, come evidenziato dalle aziende che sviluppano progetti ancora con il metodo Waterfall. Molti clienti vogliono comunque sapere quanto costerà e quando sarà realizzato prima di accettare lo sviluppo, nonché sapere cosa includerà. Senza queste informazioni vitali, come saprebbero se il risultato ha un valore aziendale?
Perché Smartsheet è uno strumento potente per la gestione di progetti Waterfall
Dalla semplice gestione delle attività e pianificazione dei progetti, alla complessa gestione delle risorse e del portfolio, Smartsheet ti aiuta a migliorare la collaborazione e ad aumentare la velocità del lavoro, consentendoti di ottenere di più. La piattaforma Smartsheet semplifica la pianificazione, l'acquisizione, la gestione e la creazione di report sul lavoro da qualsiasi luogo, aiutando il tuo team a essere più efficace e ottenere di più. Crea report sulle metriche chiave e ottieni visibilità in tempo reale sul lavoro mentre accade con report di riepilogo, pannelli di controllo e flussi di lavoro automatizzati creati per mantenere il tuo team connesso e informato. Quando i team hanno chiarezza sul lavoro da svolgere, possono ottenere maggiori risultati in meno tempo. Prova Smartsheet gratuitamente, oggi.