Caratteristiche e differenze tra Waterfall e Agile Project Management

Teoria Waterfall Project Management

Il modello a cascata è un modello prescrittivo in base al quale la realizzazione di un prodotto software consiste in una sequenza di fasi ben definita.
Sono indicati come prescrittivi perché prescrivono una serie di elementi del processo: attività strutturali, azioni di ingegneria del software, compiti, risultati, valutazione della qualità, meccanismi di controllo delle modifiche per ciascun progetto, anche stabilendo il modo in cui sono correlati gli uni agli altri.

Il modello a cascata è stato adottato dagli scienziati informatici nei primi anni ’70 come primo metodo di lavoro con l’obiettivo di ridurre i costi di sviluppo, rispetto alle pratiche precedenti, e di iniziare a lavorare utilizzando un modello di lavoro ben definito e iterabile.
Il modello a cascata è, probabilmente, il processo di sviluppo software più diffuso al mondo perché richiama la catena di montaggio tipica della produzione industriale.

Suggerisce un approccio sistematico e strettamente sequenziale dello sviluppo del software in cui ogni fase produce un output preciso (deliverable) che viene utilizzato come input per la fase successiva (da cui deriva la metafora della cascata).
Tuttavia, questa metodologia richiede una grande quantità di documentazione, necessaria per informare le persone che lavoreranno al prossimo passo e che non hanno familiarità con i requisiti del progetto.
Le caratteristiche principali di questo modello sono la rigida sequenzialità tra le fasi, che comporta la completa assenza di sovrapposizioni tra di esse, l’assenza di riciclaggio, cioè l’incapacità di tornare a uno degli stadi precedenti per cambiare qualcosa.
Tra le tematiche da tenere in considerazione sono, ad esempio, la disciplina (lavorare seguendo regole precise), la pianificazione (la necessità di dettare i tempi e rispettarli), la conoscenza degli obiettivi prima dell’implementazione del prodotto e, infine, la divisione in fasi del lavoro.

L’adozione di questi principi può sembrare estremamente produttiva ma, la loro applicazione, spesso, porta a difficoltà di coordinamento tra le diverse attività (fasi). Supponendo che i requisiti possano essere definiti alla fine della fase di raccolta requisiti, dopo ogni attività deve essere realizzata una corposa documentazione per rendere il lavoro da svolgere nella fase successiva il più chiara possibile. Definire cosa fare non è sempre facile, questa difficoltà, è una delle principali cause dell’aumento del numero di errori commessi.
Problema di coordinamento evidenziato anche dall’assenza di qualsiasi forma di feedback, sia tra le attività e le persone che svolgono il lavoro, sia con il cliente, con il quale vi è un contatto solo all’inizio del progetto (fase di specifica) e alla fine quando si consegna il prodotto.
Un’ulteriore difficoltà di questo modello è la rigidità della sua applicazione: è necessario completare una fase prima di poter iniziarne la successiva.

L’inflessibile divisione del progetto in fasi distinte rende difficile soddisfare le richieste del cliente in merito a modifiche dei requisiti. Eventuali difficoltà o modifiche ai requisiti comportano ritardi nelle fasi e all’intero progetto, tradotto in maggiori costi di sviluppo e un rinvio del “time to market”, uno dei principali problemi in questa metodologia. Il “time to market” è definito come il tempo che può passare dalla commissione di progetto alla consegna di quest’ultimo al cliente.
Nel Waterfall il time to market potrebbe anche durare anni, causando problemi, soprattutto nel settore tecnologico, dove l’obsolescenza rende inadeguato un prodotto anche a breve distanza dalla richiesta di produzione.

Un ulteriore effetto collaterale è l’incapacità di stimare con precisione le risorse e i costi fintanto che non venga eseguita almeno la prima fase di analisi.

Teoria Agile Project Management

Per questi motivi, l’ingegneria del software ha progressivamente abbandonato l’approccio più tradizionale (Waterfall) a favore dello sviluppo Agile.
Le metodologie agili sono una serie di pratiche di sviluppo software che stanno emergendo a partire dagli anni 2000. L’idea di base non è quella di essere predittivi, non si cerca di prevedere come evolverà il sistema, ma adattivi, cioè proporre valori e pratiche per adattarsi meglio all’evoluzione costante delle esigenze degli utenti.

Nei progetti software, le esigenze dei clienti cambiano continuamente: sebbene disporre in anticipo di tutti i requisiti degli utenti sia un aspetto desiderabile, spesso non è fattibile…
“Tutto cambia nel software. I requisiti cambiano. Cambiamento di design. Il business cambia. La tecnologia cambia. La squadra cambia. I membri del team cambiano. Il problema non è il cambiamento, di per sé, perché il cambiamento sta per accadere; il problema, piuttosto, è l’incapacità di far fronte al cambiamento quando arriva “.

Di fronte a situazioni turbolente, in cui il mercato o la tecnologia cambiano rapidamente e sono difficili da prevedere, è necessario adottare un approccio completamente diverso per la gestione dei progetti.
In quest’ottica, quindi, molto importanti sono i concetti di iterazione e feedback continuo che ben si adattano alle dinamiche moderne. Ogni iterazione ha una durata limitata, generalmente da una a quattro settimane. In gergo si dice che ogni iterazione è “timeboxed” e può essere immaginata come un piccolo progetto da realizzare, in cui sono presenti le normali fasi del processo di sviluppo del software, con la differenza, rispetto la vecchia metodologia, che c’è una risposta immediata da parte del cliente, soprattutto data la stretta collaborazione tra il team di sviluppo e gli esperti del business (uno dei principi fondanti definiti da Beck nel Manifesto Agile).

La sintesi delle principali tecniche utilizzate da questo approccio sono:

1. Pianificazione: la pianificazione non viene calcolata sulla base di una ripartizione dettagliata di tutte le attività pianificate che vanno dall’inizio alla fine dell’intero progetto ma, al contrario, una pianificazione dettagliata viene sviluppata per un futuro prossimo a breve termine (4 settimane). Inoltre, la pianificazione viene aggiornata a intervalli regolari (1/2 settimane) che prendono il nome di sprint.
2. Pianificazione flessibile: le attività sono classificate in base alla loro incertezza e creatività.
3. Gestione del tempo: con la gestione dei tradizionali progetti a cascata, il project manager doveva garantire che i risultati fossero raggiunti gestendo un certo tempo target già impostato ex-ante. Con il metodo agile viene eseguito l’approccio opposto, il progetto viene suddiviso in intervalli regolari (sprint) e si identificano i risultati attesi alla fine di ciascuno. Nessun ritardo è consentito durante l’esecuzione e ogni team di progetto deve segnalare i risultati raggiunti (revisione sprint).
4. Specifiche: le specifiche evolvono nel tempo con un numero elevato di iterazioni al rilascio di ciascuna nuova soluzione, ciascuna delle quali consente, a ciascun membro del team, di avere una comprensione più profonda del problema e delle specifiche.

Per avere una visione ancora più chiara ed esplicita, è interessante analizzare le differenze sostanziali tra questo metodo innovativo e quello più tradizionale, a cascata, prendendo in considerazione lo strumento più significativo di gestione del progetto, il cosiddetto triangolo ferroso. È bene notare come l’importanza attribuita a ciascuno dei cambiamenti dei vincoli chiave, si avvalga di questi due diversi approcci.

Nella cascata tradizionale le caratteristiche, o requisiti, sono mantenute fisse, chiare e ben definite, procedendo con lo sviluppo del progetto solo dopo aver effettuato la stima del costo e del tempo. Dall’altra parte, nella metodologia agile, si può osservare un cambiamento “brusco” e meccanicistico inerente lo scopo e le funzionalità, mentre il costo e le fasce orarie da seguire sono mantenute stabili.
Se nel modello a cascata è la pianificazione che guida l’intero progetto, nel modello agile lo scopo principale è quello di mantenere una buona qualità attraverso l’iterazione fissa in time box, modificando anche i requisiti.