Project Management: Differenza tra Approccio Waterfall e Metodologia Agile

Project Management

Il Project Management è una metodologia gestionale orientato ai risultati. Consiste nella “gestione sistemica di un’impresa complessa, unica e di durata determinata, rivolta al raggiungimento di un obiettivo chiaro e predefinito mediante un processo continuo di pianificazione e controllo di risorse differenziate e con vincoli interdipendenti di costi – tempi – qualità”.

Il Project Management come lo si intende oggi si è affermato circa cinquant’anni fa, quando le aziende iniziarono ad apprezzare i vantaggi del lavoro organizzato per progetti e a comprendere quanto fosse importante riuscire a far lavorare in modo coordinato tra di loro più reparti con diverse competenze e specializzazioni.
Fino alla metà degli anni ’60 del Novecento il modello di organizzazione del lavoro prevalente nell’industria meccanica era quello “tayloristico”, dal nome dell’ingegnere statunitense Frederick W. Taylor, che alla fine dell’Ottocento teorizza l’organizzazione scientifica del lavoro: al fine di ottenere un incremento della produttività, il suo metodo prevedeva la scomposizione delle mansioni, l’individuazione di compiti elementari ben definiti da affidare a ciascun esecutore, il calcolo della loro misura e la programmazione della produzione.

Un collaboratore di Taylor, Henry Gantt, studiò in dettaglio l’ordine delle operazioni nel lavoro, definendo quello che oggi è conosciuto come Diagramma di Gantt: uno strumento grafico per la rappresentazione sull’asse temporale delle attività che concorrono al completamento di un progetto, permettendo la programmazione e il controllo sull’avanzamento.

In genere i fattori propulsivi del Project management sono riconducibili a:

1. la presenza di un progetto importante o la compresenza di più piccoli progetti da gestire contemporaneamente;
2. le crescenti aspettative dei clienti.

A sua volta un progetto è uno sforzo articolato e caratterizzato da risultati specifici in termini di prodotti consegnati (deliverables), prodotti/servizi forniti (scope), tempi impiegati (time) e budget necessari a produrre i risultati attesi (cost). Scope, time & cost definiscono un insieme di vincoli che insieme con la qualità di progetto costituiscono il “perimetro” entro cui il progetto deve essere gestito.
Tipicamente un progetto si articola in una serie di fasi che costituiscono il suo ciclo di vita:

1. Definizione e Avvio;
2. Pianificazione;
3. Realizzazione;
4. Chiusura.

La gestione del ciclo di vita di un progetto può essere affrontata con approcci e modelli diversi di Project Management. Gli approcci utilizzati consistono in diversi approcci metodologici adottabili per la gestione delle attività di un progetto, che includono gli approcci agili, interattivi, incrementali e basati sulla successione di fasi predefinite. Indipendentemente dall’approccio utilizzato, una particolare attenzione va dedicata alla definizione chiara degli scopi/obiettivi del progetto e delle loro implicazioni; anche la definizione chiara dei ruoli e delle responsabilità di tutti gli attori coinvolti, inclusi i committenti, riveste un’importanza decisiva per il successo del progetto.

Approccio tradizionale: PMBOK

Il Project Management Body of Knowledge (PMBOK) descrive l’insieme delle prassi standard per la gestione di progetti così come definite dal Project Management Institute, che è il principale organismo internazionale di standardizzazione in materia di Project Management.

Il PMBOK prevede un approccio “waterfall” 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 modello a cascata (Waterfall Model), chiamato anche Classic Life Cycle, è un approccio sequenziale e lineare allo sviluppo software. Esso trova le sue origini negli anni ’50, quando l’attività di sviluppo di software iniziò ad affermarsi come una vera e propria attività di produzione industriale. A quel tempo, non essendo presente nessuna metodologia di realizzazione software, gli sviluppatori si ispirarono ai processi di produzione manifatturiera e alle industrie di costruzione, per ottenere una metodologia che potesse essere applicata allo sviluppo di codice in modo ordinato e meno caotico.

Il modello waterfall si basa fortemente sul concetto di Big Design Up Front ovvero su una “grande progettazione a monte”: se vengono rilevati difetti o imperfezioni nelle fasi iniziali di produzione del software, tali difetti saranno più facilmente eliminabili; sarà inoltre più economico in termini monetari e temporali correggere un difetto in fase di design piuttosto che in fase di implementazione, in quanto nelle ultime fasi si avrà ormai sprecato tempo e denaro nella realizzare una soluzione difettosa o poco performante.

Un altro aspetto caratterizzante il modello a cascata è il fatto che tale approccio considera di fondamentale importanza la documentazione generata dalle varie fasi, come affermato dallo stesso Royce.

L’idea che sta alla base di questa convinzione risulta essere che nelle situazioni in cui vi siano una povera progettazione e documentazione, la perdita di un componente del team di sviluppo corrisponde alla perdita di conoscenza riguardante il lavoro da svolgere, in quanto gran parte del sapere risiede nei componenti del team. Questo può comportare gravi difficoltà a riprendere il progetto o a inserire nuovi membri. Disponendo invece di una documentazione completa ed esaustiva, risulta relativamente semplice l’aggiunta di nuovo personale o addirittura assegnare il progetto ad un nuovo team di sviluppo.

È sufficiente che chi verrà assegnato ad un nuovo incarico, consulti i vari documenti per familiarizzare con il progetto.
L’approccio tradizionale a cascata prevede almeno le seguenti fasi:

1. raccolta dei requisiti;
2. analisi dei requisiti;
3. progettazione della soluzione;
4. codifica;
5. test e rilascio dell’applicazione.

Le fasi si concretizzano nelle seguenti attività:

1. raccogliere tutti i requisiti e le funzionalità desiderate dalle singole direzioni;
2. analizzare i requisiti per comprenderne la logica e la consistenza della soluzione;
3. progettare una soluzione e sottoporla all’accettazione dell’utente sulla carta;
4. realizzare la codifica dell’applicazione;
5. effettuare i collaudi con l’aiuto nuovamente dell’utente per l’accettazione;
6. implementare la soluzione e avviarle l’esercizio e la manutenzione.

Con il passare degli anni, gli stessi sostenitori del modello a cascata si resero presto conto di alcune importanti problematiche che nascevano dall’utilizzo di tale modello. Nell’articolo in cui presentò tale modello, lo stesso Royce descrisse che pur essendo un approccio molto semplice, nella sua esperienza il modello a cascata non risultò adatto alla realizzazione di grandi sistemi software e che i costi di produzione utilizzando tale metodo eccedettero di gran lunga le stime inizialmente previste.

Alcune delle maggiori cause di fallimento del modello waterfall si possono riconoscere in quelle che seguono:

1. il tempo necessario all’attività di analisi e pianificazione può ritardare l’implementazione;
2. i requisiti, una volta formalizzati, possono essere modificati solo attraverso specifiche procedure di escalation (ingrandimento);
3. il committente del progetto, anche a fronte di cambiamenti dello scenario del mercato, ha difficoltà ad influire su quanto richiesto, perché la fase di progettazione è tutta all’inizio e non è previsto un suo coinvolgimento;
4. il cliente prende visione dei deliverable(consegnabili) solo al momento del loro completamento;
5. possono emergere esigenze di nuove funzionalità in corso d’opera che necessitano di un approccio più flessibile ;
6. quello che appare come un processo lineare ed efficiente diventa spesso una serie di cicli turbolenti che si traducono in una perdita di tempo e soldi. Questo perché le fasi sono legate tra loro da artefatti che non sono definibili in modo rigoroso e questo scatena tutta una fase di cicli di revisione all’indietro che riducono drasticamente l’efficienza del metodo.

In un mercato sempre più volatile come quello attuale, basato su rapidi cambiamenti, bisogna essere agili, maggiormente produttivi, veloci e innovativi. Il cambiamento come regola mette in discussione i principi teorici base del management “tradizionale”, specialmente quelli legati alla stabilità dei requisiti o dei presupposti iniziali di progetto. Sempre più aziende prendono la decisione di passare da un approccio tradizionale di project management a un approccio iterativo che parte dal presupposto di ritornare più volte sulle varie fasi ridefinendo di volta in volta i vincoli di progetto finché non si raggiunge un sufficiente grado di maturità del prodotto.

Con un approccio allo sviluppo software più incline ad « abbracciare il cambiamento » piuttosto che a controllarlo, è possibile rispondere rapidamente alle opportunità di mercato e/o alle richieste dei committenti. In molti casi il time-to-market rimane il requisito fondamentale per il cliente, in quanto la perdita di una finestra di mercato, può rendere il software inutile.

Per questo motivo questi metodi si basano su processi iterativi che possano fornire piccoli rilasci di software in brevi cicli di sviluppo. Questo permette di ottenere un rapido feedback da parte del committente sin dalle prime settimane di lavoro.

Approccio Waterfall vs Metodologia Agile

MetodologiA a cascata (Waterfall):

1. Requisiti dettagliati definiti prima dell’avvio di Disegno e Sviluppo
2. Forte enfasi sulla pianificazione preventiva
3. Il controllo del contenuto è essenziale per controllare costi e tempi (schedulazione)
4. Enfasi sul controllo di costi e tempi

MetodologiA Agile (Scrum)

1. Definizione di alto livello del prodotto e requisiti di dettaglio definiti gradualmente in base all’avanzamento del disegno
2. Pianificazione a finestra mobile e rinvio delle decisioni finché possibile
3. Il contenuto può cambiare ed aumentare per soddisfare le esigenze del cliente
4. Enfasi sulla flessibilità e l‟adattabilità per soddisfare le esigenze di business

Infine, l’approccio a cascata cerca di acquisire ed analizzare tutti i requisiti del progetto prima di avviare il disegno dell’applicazione. L’approccio Agile, invece, pianifica per fasi successive (sprint) rinviando le decisioni quanto più possibile.

Infine, nella figura seguente si nota che l’approccio tradizionale a cascata prevede tempi e costi in anticipo controllando il contenuto per rispettarli mentre l’approccio agile è molto più flessibile, consente di modificare i requisiti per soddisfare tutte le esigenze di business.