Nei tradizionali approcci di project management si presuppone che i requisiti siano chiari al cliente già all’avvio del progetto e che egli possa attenderne la fine per effettuare l’acceptance test . Ma è veramente sempre così? Esploriamo insieme le ragioni per cui diventa sempre più necessario abbracciare una metodologia alternativa.
Ogni progetto è caratterizzato in maniera univoca dai suoi vincoli. Secondo il concetto di triple constraint la natura sistemica dei progetti può essere rappresentata da un triangolo ai cui vertici vi sono:
Obiettivo del business è di ottenere il miglior risultato, nel minor tempo e con il minor costo possibile.
Il legame esistente tra questi vincoli non consente però l’applicazione di un approccio lineare, poiché i cambiamenti riguardanti uno si ripercuotono inevitabilmente sugli altri. Aggiungere nuove features al prodotto costringe a riconsiderare la schedulazione e il carico del risorse, così come la decisione di anticipare i tempi di rilascio comporta un aumento del budget o un ridimensionamento dell’ambito di progetto.
Per gestire tale complessità le imprese si affidano a un sistema di pratiche, tecniche e procedure che prende il nome di Project Management. Secondo l’approccio tradizionale, il project team è chiamato a una pianificazione dettagliata dell’ambito che, una volta concordato con gli stakeholders, costituisce la base da cui derivare a cascata [waterfall] gli altri documenti della baseline, nonché le successive fasi: esecuzione, monitoraggio e chiusura.
Risalire il corso del progetto è possibile, ma non senza un notevole dispendio di costi e tempo. La definizione iniziale dei requisiti riveste infatti un ruolo fondamentale.
Nella misura in cui vengono individuati come rischi tutti quegli eventi che possono portare al mancato rispetto della baseline, lo scope rappresenta un elemento fisso, da preservare da eventuali change requests o fintanto che queste non saranno state accolte in una nuova baseline; il che avviene soltanto a fronte di formali e severi processi di approvazione.
“Il cliente“ recita le legge Humphrey, “non sa mai cosa vuole finché non vede il prodotto funzionante”; ciò è tanto più vero negli ambienti di R&D e sviluppo software, la cui incertezza non consentire una pianificazione dettagliata. Quando il progetto inizia non se ne possono prevedere gli esiti, né l’utente riesce a razionalizzare i requisiti poiché ancora non immagina come sarà la propria interazione con il prodotto. Se si seguisse un approccio tradizionale si correrebbe il rischio di dover rifare gran parte del lavoro quando ormai è troppo tardi.
In risposta a tale criticità, l’agile predilige rapidi e frequenti cicli di esecuzione-monitoraggio-adattamento (sprints) attraverso cui garantire al cliente porzioni di lavoro funzionanti (quelli che in gergo vengono chiamati chunks). Soltanto così egli potrà comprendere se quanto desiderato corrisponde alla realtà. Sulla base delle informazioni acquisite, il team di sviluppo sviluppo pianifica la nuova iterazione, ridefinendo gli assunti sottostanti alle alle previsioni iniziali.
Per chi lavora in agile i cambiamenti dell’ambito costituiscono la norma. Lungi dall’essere percepiti come un rischio da evitare, vengono accolti e incentivati come opportunità per generare valore. Al contrario, i vincoli considerati fissi sono costi e tempi. Dal “quanto tempo costa e quanto tempo serve per realizzare questo prodotto?” si passa al “con questo tempo e questo budget quanto possiamo realizzare?”.
L’agile è una metodologia empirica ed estremamente concreta. Basando ogni processo di pianificazione sull’esperienza, gestisce l’ambito di progetto come una variabile sempre negoziabile per far fronte alle turbolenze interne ed esterne, quali per esempio:
Ne consegue una demistificazione della baseline. Affinché ricalchino la dinamicità del contesto in cui si trovano, piani e procedure devono essere sufficientemente snelli da poter recepire il cambiamento dei requisiti, anche quello tardivo. Lo stesso discorso vale per la documentazione: consapevoli del suo carattere mediato, gli agilisti ne promuovono un uso limitato, senza confondere lo strumento di osservazione con la realtà osservata e dimenticarne la convenzionalità originaria. A loro giudizio bisogna privilegiare il working software; unica metrica realmente oggettiva dell’avanzamento di un progetto, nonché artefatto indispensabile per comprendere le reali esigenze del business.
Difficilmente si lavora puramente in agile, senza l’ausilio dei tradizionali strumenti di project management (Gantt, WBS, Critical Path Method, etc.). Spesso la strategia vincente consiste proprio nel saper attivare metodologie diverse a seconda delle fasi o del contesto applicativo, consci del fatto che ciò che si perde in struttura e stabilità lo si guadagna in prontezza e flessibilità.
