Metodologia Agile e PMBOK: waterfall e metodo iterativo

Uno degli errori che spesso si riscontrano nelle descrizioni della metodologia Agile per lo sviluppo di progetti consiste nel ritenere che uno sviluppo iterativo come quello proposto in Agile comporti l’abbandono delle aree di conoscenza e dei processi di project management così come descritti nello standard PMI-PMBOK®.

In realtà lo standard PMBOK® contiene ampiamente al suo interno le logiche per uno sviluppo iterativo che appunto viene visto come uno dei tool che può essere opportuno utilizzare sotto certe condizioni e su alcune tipologie di progetti.

Quindi non si tratta tanto di scegliere tra l’uno o l’altro quanto comprenderne le aree di utilizzo e le modalità di integrazione.

In tal senso occorre evidenziare che:

  • il PMBOK® prevede un approccio “waterfall” (a cascata) che individua uno sviluppo sequenziale di fasi che descrivono il ciclo di vita di un progetto e, parallelamente, il ciclo di vita del project management che ne governa lo sviluppo;
  • il PMBOK® prevede che all’interno di alcune di queste fasi (es. ingegnerizzazione) possa essere applicato un approccio iterativo come Agile o Scrum laddove questo sia compatibile con il rilascio dei corrispondenti deliverables e con gli obiettivi del progetto.

In generale l’approccio sequenziale “waterfall” privilegia la prevenzione dei cambiamenti nell’ambito e nei deliverables del progetto dovuti a scarsa analisi e pianificazione e vede la stima dei costi e dei tempi come una conseguenza delle specifiche dei deliverables.

Viceversa gli approcci iterativi si concentrano sui tempi e costi contrattualizzati e li gestiscono con una logica di tipo Timeboxing adattando di conseguenza l’ambito di progetto che rimane flessibile in funzione delle esigenze di rapidità di sviluppo e di massimo valore erogabile nei tempi e costi concordati.

Eventuali esigenze di modifica vengono raccolte e gestite all’interno di nuove release o versioni del prodotto.

Questo significa che i processi di definizione dell’ambito, di creazione della WBS  e di verifica dell’ambito vengono ripetuti iterativamente all’interno di approcci Agile. Ciò naturalmente deve essere compatibile con i prodotti da rilasciare e con quanto concordato con la committenza. In particolare si presta molto bene a gestire progetti ad esempio di sviluppo software oppure di ricerca o fasi di ingegnerizzazione.

In presenza di requisiti ben definiti e documentati un approccio integralmente “waterfall” è da preferire, mentre a fronte di esigenze e specifiche mutevoli è preferibile adottare approcci Agile ma all’interno di un sistema di governo complessivo del progetto strutturato secondo quanto previsto dal PMBOK®.

Waterfall

L’approccio “waterfall” descrive la struttura del ciclo di vita di un progetto come una sequenza di fasi appunto in cascata. Il ciclo di vita descrive le modalità di produzione dei deliverables previsti e non va confuso con i processi di project management che invece costituiscono l’infrastruttura di governo di un progetto.

La struttura del ciclo di vita è tipica di uno specifico progetto in uno specifico contesto organizzativo. Ad esempio può essere articolata in:

  • analisi dei requisiti;
  • disegno;
  • implementazione;
  • test;
  • installazione;
  • manutenzione.

Punti di forza dell’approccio “waterfall”:

  • i requisiti sono ben definiti, concordati e formalizzati;
  • molti potenziali difetti sono “intercettati” nelle fasi preliminari di analisi e pianificazione;
  • la documentazione è dettagliata;
  • può essere gestito con personale con skill non elevato in virtù del livello di dettaglio della documentazione;
  • i vincoli temporali di ciascuna fase ed il piano dei rilasci consentono un agevole monitoraggio e controllo.

Punti di debolezza dell’approccio “waterfall”:

  • il tempo necessario all’attività di analisi e pianificazione può ritardare l’implementazione;
  • i requisiti, una volta formalizzati, possono essere modificati solo attraverso specifiche procedure di escalation;
  • il cliente prende visione dei deliverable solo al momento del loro completamento;
  • possono emergere esigenze di nuove funzionalità in corso d’opera che necessitano di un approccio più flessibile.

Agile

La metodologia Agile si riferisce ad un approccio iterativo ed evolutivo nella gestione progetti in cui i requisiti e le soluzioni maturano in corso d’opera attraverso la collaborazione del team di sviluppo con la committenza. Il termine è stato coniato nel 2001 quando fu pubblicato l'”Agile Manifesto” e fa riferimento ad un insieme di approcci e strumenti (es. SCRUM, Extreme Programming, DSDM ecc.) che sono stati messi a punto con particolare riferimento alla gestione di progetti di sviluppo software.


La logica di fondo è quella di arrivare a produrre il più rapidamente possibile i deliverables e poi rifinirli attraverso cicli successivi di miglioramento.

Quindi l’applicazione della metodologia Agile comporta un delivery più rapido ed un costo più basso rispetto ad un approccio “waterfall”?
Non è detto: le modifiche sono incentivate e quindi può aumentare il rework con conseguente aumento dei tempi e dei costi.

Per questo è bene che le modalità complessive di governo di un progetto rimangano strutturate secondo la logica “waterfall” e solo alcune fasi siano gestite con modalità di sviluppo iterativo o per prototipi.

Punti di forza della metodologia Agile:

  • l’avvio dell’implementazione è rapido e lo sviluppo è incrementale;
  • i requisiti possono evolvere in corso d’opera;
  • la risposta ad esigenze di cambiamento è rapida;
  • frequenti momenti di test e di revisione dei requisiti;
  • collaborazione attiva nello sviluppo tra fornitore e committente.

Punti di debolezza della metodologia Agile:

  • in assenza di pianificazione e documentazione del lavoro da svolgere, questo può essere frainteso o procedere in modo indisciplinato con conseguente rework;
  • richiede personale del cliente molto qualificato;
  • il tempo richiesto al cliente per il suo coinvolgimento è elevato;
  • l’orizzonte è concentrato sul breve termine è c’è quindi il rischio che si perda la prospettiva di lungo periodo;
  • la documentazione prodotta è poco dettagliata e questo può creare problemi di utilizzo da parte dell’utente o di governo del progetto da parte del Project Manager

Confronto dei costi

Come detto, i due approcci si prestano ad un impiego in situazioni diverse. In alcuni casi (es. sviluppo software) è consigliabile un’integrazione tra le due modalità in quanto Agile consente una gestione snella delle versioni e delle release software mentre l’approccio waterfall (es. PMBOK®) consente di meglio governare i costi ed i rischi complessivi.

In tal senso, è possibile confrontare i due approcci attraverso i costi riferibili alla pianificazione complessiva di progetto ed alla gestione delle modifiche di progetto.

Nel caso della pianificazione di progetto, i costi dell’approccio tradizionale sono inizialmente consistenti e poi tendono a diminuire man mano che si acquisisce certezza organizzativa e che il progetto avanza, mentre nell’approccio agile rimangono sostenuti fino alla fine in quanto il succedersi di versioni e release obbliga ad una continua revisione degli obiettivi iniziali.

Nel caso della gestione della configurazione e delle modifiche, l’introduzione di cambiamenti alle specifiche di progetto nel caso di un project management tradizionale ha un costo crescente in particolare in fase di realizzazione mentre tende a stabilizzarsi nell’approccio Agile.