Terza e ultima parte del nostro percorso nel mondo della pianificazione Agile con l'aiuto di Mike Cohn e del suo bellissimo libro Agile Estimating and Planning.
Introduzione
Nella seconda parte di questa serie di articoli abbiamo visto perchè la pianificazione nei progetti spesso fallisce.
In quest'ultima parte vedremo come pianificare accettando di convivere, anzi, incoraggiando i cambiamenti che avvengono nel corso del progetto.
Cambiare un piano non significa necessariamente cambiare le date. Forse servirà ma invece magari
scopriamo che alcune funzionalità che dovevamo realizzare non servono più oppure
potremmo introdurre più persone nel team.
Questo è un primo pensiero di base. Ma ci sono altre tecniche che possiamo utilizzare per modificare la nostra iniziale stima.
Replanning
Un piano di progetto per essere utile deve essere accurato, ma dobbiamo accettare che
piani fatti nelle prime fasi del progetto portino in sé incertezza.
Se vogliamo poter accogliere nuovo requisiti e avere il massimo feedback possibile dal
committente ad ogni iterazione allora è necessario che il nostro piano sia flessibile, che
tutti i partecipanti accettino questa flessibilità e che soprattutto il nostro budget si adegui di
conseguenza sebbene seguendo determinati parametri.
Allo stesso tempo è possibile che i task non corrispondano esattamente alla stima che avevamo
ipotizzato.
Diciamo, per fare un esempio, che il nostro progetto è stimato in story points ed è composto da tre task.
Nel corso della prima iterazione pianifichiamo di realizzare i primi due task ma al termine ci
accorgiamo di non esserci riusciti.
Il task 1 infatti ha occupato tutta l’iterazione.
Che fare?
Convochiamo il team e nel retrospective meeting decidiamo la strategia da seguire.
Per gestire la situazione dobbiamo necessariamente fare replanning ma di cosa? Di quali
storie?
Un modo è identificare le relazioni tra le storie. Se ad esempio la storia 1, quella che era stata sotto-
stimata, ha relazione con la 2 e la 3 , allora meglio rifare la stima di entrambe.
In questo modo possiamo procedere nella prossima iterazione con dati aggiornati e basati
sull’esperienza.
E’ chiaro che ciò che stiamo facendo è spostare la data di fine del progetto,
ma nel contempo stiamo lavorando su dati reali, su stime sempre più accurate e stiamo
anche accogliendo i feedback del committente perché, come ogni progetto Agile che si
rispetti, ad ogni iterazione accogliamo tutte le osservazioni.
Buffering
Anche questa è una tecnica usata ovvero tenersi del tempo di buffer nella stima delle attività.
E’ una tecnica usata anche in progetti con una gestione più lineare come il waterfall. Fatto
100 il mio impegno per realizzare una attività, la stimo 120 al fine di tenermi un buffer per
gestire le incertezze.
C’è però una grossa differenza. In waterfall arrivo troppo tardi ad accorgermi di
cambiamenti necessari e richiesti dall’utente. Gestirli potrebbe ritardare ulteriormente e
nessun buffer ci può salvare.
Così come le stime possono essere sbagliate o poco precise, anche il cliente cambia idea,
e non è poco frequente.
Non sempre il cliente chiede cambiamenti che implicano un allungamento dei tempi, a volte rinuncia a
features rendendosi conto che non servono o che era poco attuabili.
Lo può fare se nel corso del progetto ha dei propotipi con cui “giocare”.
Da qui, togliendo feature, emerge la possibilità di recuperare del tempo o di inserire altre
funzionalità, ecco quindi che cambiare non vuol dire necessariamente...peggiorare.
Riassumendo quindi pianificare tutto e con troppo anticipo non ci consente di accogliere l'incertezza che è sempre presente in ogni progetto. Come è già stato delineato in "Un Cono al gusto di incertezza" e in "Se vuoi una garanzia comprati un tostapane" la certezza è una chimera che non fa parte della progettazione. Forzare i progetti entro schemi rigidi vuol dire non renderli antifragili e quindi potenzialmente fragili, delicati come dei bicchieri di cristallo.
Apriamo quindi la mente progettuale ad accettarli al fine di evolvere assieme al progetto accogliendo ogni richiesta di modifica in termini, appunto, evolutivi.