Introduzione
Nel precedente articolo abbiamo sfatato alcuni miti sull’Agile, specialmente riguardo ai costi e al ruolo del middle management nel processo. Abbiamo discusso come, contrariamente all’opinione diffusa, il framework agile non sia una scusa per evitare la pianificazione o per non avere controllo sui costi. Abbiamo anche visto come la trasparenza e la gestione oculata degli obiettivi siano parte integrante del lavoro del Product Owner (PO). In questa seconda parte ci concentreremo su alcuni aspetti pratici per aiutare i middle manager a orientarsi nella gestione della roadmap, nella valutazione delle spese e nella comunicazione con gli stakeholder. Proporremo delle azioni concrete da compiere e, cosa altrettanto importante, dei comportamenti da evitare.
La pianificazione in Agile: non è una favola
Uno dei miti più diffusi è che “in agile non si pianifica”. La realtà è ben diversa: il PO ha il compito di creare una roadmap che comprenda milestone e rilasci chiave, proiettando lo sviluppo delle funzionalità sul calendario. Questa pianificazione avviene sincronizzando le milestone del backlog con il calendario, usando come parametri la velocity del team e l’effort stimato per le varie epiche o story.
Story Mapping
Fra i molti, uno strumento utile per visualizzare la roadmap in maniera chiara è lo Story Mapping, che aiuta a comprendere la sequenza delle funzionalità e a definire le priorità, facilitando la comprensione del lavoro da svolgere nel tempo.
Qualora si desideri una rappresentazione più “tradizionale” della roadmap, si potrebbe creare uno schema in forma di lista o tabella in stile Excel, dove si elencano gli elementi del backlog, raggruppandoli in blocchi (chunk) corrispondenti a vari gruppi di elementi. Questo tipo di rappresentazione consente di avere una lista organizzata che raggruppa ogni tot punti — o ore, se si stima in ore — un gruppo di elementi del backlog, creando così una rappresentazione modulare.
Spostando elementi da un punto all’altro del backlog, è possibile riorganizzare i pezzi (chunk) e quindi aggiornare la roadmap in maniera dinamica.
Product burndown chart
Uno strumento fondamentale per visualizzare l’avanzamento e capire se si riuscirà a completare il lavoro entro la scadenza prefissata è il product burndown, che mostra graficamente la progressione del lavoro rimanente rispetto al tempo.
Per fare un esempio concreto, immaginiamo un backlog composto da 10 epiche, ciascuna delle quali rappresenta una parte significativa del prodotto da sviluppare. Ogni epica è stata suddivisa in user story e sono stati assegnati dei punti di stima. Supponiamo che il backlog contenga un totale di 500 punti, distribuiti tra le 10 epiche. La velocity media del team è di 50 punti per sprint.
Con queste informazioni, il PO può iniziare a fare delle previsioni sulla roadmap. Se il team mantiene una velocity di 50 punti per sprint, possiamo stimare che ci vorranno 10 sprint per completare tutte le epiche del backlog (500 punti totali / 50 punti per sprint = 10 sprint).
Tuttavia, il PO potrebbe voler fissare delle milestone intermedie. Ad esempio, si potrebbe prevedere di completare le prime 5 epiche, per un totale di 250 punti, entro i primi 5 sprint. Questo tipo di pianificazione aiuta a definire le aspettative con gli stakeholder e a mantenere una visione chiara del progresso del progetto.
Naturalmente, il piano è soggetto a cambiamenti: la velocity può variare, le epiche possono essere riformulate o suddivise, e possono emergere nuove priorità. Tuttavia, avere una roadmap di riferimento permette al team e agli stakeholder di avere una visione chiara di dove si sta andando e di quali sono le tappe principali.
Cose fatte e risorse spese: due mondi diversi
Spesso — forse a causa del retaggio del Project Management tradizionale dove Earned Value parte da una prospettiva differente — si fa confusione tra la misurazione delle ore di lavorazione e l’effettivo avanzamento di un progetto.
È importante ripetere fino alla noia che se i punti storia accumulati a fine sprint servono a capire quanto si è avanzato nello sviluppo del prodotto, le ore di lavorazione rappresentano il tempo impiegato, e di conseguenza il costo sostenuto.
Se durante i primi sprint, stima dei tempi e stima dei costi possono essere collegate, con l’avanzare del progetto queste due misure possono diversificarsi anche in maniera sostanziale: l’avanzamento rispetto al backlog non è legato al consuntivo delle spese.
Per comprendere in modo estremamente intuitivo questo concetto, basta un semplice esempio: se passassi tutta una giornata a spingere un muro, a sera sarei stanco (effort) ma il muro presumibilmente — o almeno così si spera nell’ottica della solidità dell’edificio — non si sarebbe spostato (avanzamento di progetto). Trasportando questo esempio volutamente elementare nel Project Management, se il progetto non avanza perché per esempio il team sta incontrando un problema importante, le ore passate a cercare di risolvere il problema rappresentano comunque un costo — di base potremmo dire che le persone dovranno comunque essere pagate — anche se il progetto non è progredito.
Non è un caso che in Agile si fissano tempi e costi e si stima lo scope.
Una piccola divagazione: la gestione dei bug
Discorso analogo si potrebbe fare con la gestione dei bug. Un bug non lo si stima e non lo si mette nel backlog: si risolve. Nel tempo che impiega per farlo, il team non dedica tutte le energie sulle cose nuove del backlog, quindi il progetto va più piano. Guardando le cose con la prospettiva del rilascio di valore per l’utente finale, questo approccio torna: fino a che stiamo lavorando ai bug, non stiamo producendo qualcosa di nuovo nel prodotto (rilascio valore), ma stiamo sistemando le cose che non vanno. Il progetto è fermo.
Se però volessimo comunque stimare i bug per capire l’effort che ci aspetta e capire quanto spazio prendono i bug nello sprint, allora è bene ricordarsi di aggiungere tale effort alla somma dei punti del backlog: aumenta il totale delle cose da fare, il backlog si ingrandisce, il burndown si rialza e, conseguentemente, anche in questo caso le tempistiche rallentano.
Lo stato di avanzamento lavori non è un consuntivo di spesa
È importante ricordare ancora una volta un concetto fondamentale: il SAL (Stato Avanzamento Lavori) non è un consuntivo di spesa. Anche se i due aspetti sono correlati, il PO deve mantenere il controllo su entrambi separatamente, per poter fornire agli stakeholder un quadro realistico della situazione: dove siamo in termini di backlog, quanto tempo manca, quanto budget è stato speso e quanto ne servirà ancora.
La visione binoculare: percentuale di avanzamento e soldi
D’altro canto, sebbene l’avanzamento e i costi siano due cose separate, entrambi devono essere tenuti sotto controllo. Ad esempio, come mostrato dai grafici in figura 5, possiamo vedere che stiamo spendendo più o meno quanto previsto, sebbene il burndown ci dica che siamo in ritardo rispetto alla linea di avanzamento prevista: le cause possono essere molteplici, anche se in definitiva possiamo dire che ci sono ancora troppi elementi da completare.
La previsione dei costi e del tempo
Per avere un previsionale temporale sul completamento lavori, possiamo osservare il backlog rimanente e ricavare la fine lavori tramite la velocity del team, come descritto sopra. Per esempio, immaginiamo che il backlog rimanente abbia 200 punti e la velocity media del team sia di 40 punti per sprint. In questo caso, possiamo stimare che serviranno circa 5 sprint per completare il lavoro (200 punti / 40 punti per sprint = 5 sprint). Se lo sprint fosse di 2 settimane (10 giornate lavorative), avremmo ancora 50 gornate di lavoro, circa un mese e mezzo.
Ma, oltre a saper calcolare il tempo mancante, spesso il team — o più precisamente il PO — è chiamato a dare una valutazione (stima) del previsionale di spesa, cosa che può essere fatta incrociando il costo unitario — p.e., del team in una giornata, o il costo dello sprint, o un punto del backlog — con la durata rimanente stimata.
Un esempio concreto
A titolo di esempio, nel progetto a cui sto lavorando in questo momento, al fine di avere una semantica comune al reparto finanziario, abbiamo proposto due modi:
- Grana grossa: Se il costo del team per sprint è di 20.000 euro, e si stima che servano 5 sprint per completare il lavoro, il costo totale previsto sarà di 100.000 euro (20.000 euro * 5 sprint).
- Grana fine: Supponiamo che il costo per punto sia di 500 euro, ottenuto dividendo il costo medio del team per sprint per la velocity (20.000 euro / 40 punti). Se restano 200 punti da completare, il costo previsto sarà di 100.000 euro (500 euro * 200 punti).
Entrambi i metodi offrono una stima. In nessuno dei due casi è ragionevole aspettarsi risultati con una precisione assoluta, ma piuttosto strumenti per avere un’idea indicativa. Sono stime attendibili, ma non si tratta di una scienza esatta.
Il primo metodo è più semplice da utilizzare se il team è definito e stabile. Il secondo forse più adatto se abbiamo molta variabilità sulla composizione del team: ragionare sulle unità di lavoro dà in alcuni casi l’illusione di poter controllare meglio la complessità. Purtroppo spesso questa è, appunto, solo un’illusione.
L’illusione del piano di lavorazione dettagliato
Oltre al team Scrum che sviluppa il progetto, nelle aziende di una certa dimensione ci sono altri uffici che operano intorno — amministrazione, approvvigionamento, vendite, etc. — che si aspettano dal team di sviluppo informazioni e output per fare il loro lavoro di contabilità, piani di lavoro, gestione delle ferie, gestione dei contratti e altro ancora.
Per esempio, spesso si chiede al team, o più spesso al PO, di indicare quali persone faranno cosa e per quanto tempo. Questo tranquillizza i Project Manager, o gli account, poiché si ritiene che in questo modo si potranno evitare sorprese sgradite alla fine del progetto. Sebbene questa richiesta sia comprensibile, di fatto porta spesso a una forma di micromanagement non molto efficace…
Noi agilisti diremmo subito che si tratta di uno spreco puro, sia per l’inattendibilità del piano già dopo poche settimane, sia per il sovraccarico di lavoro per il team, sia per l’effetto limitante delle scelte sull’operatività.
Una strategia, potrebbe consistere nel far comprendere agli stakeholder l’inutilità delle previsioni dettagliate in un contesto reale: è proprio la complessità — nel senso di teoria della complessità — del sistema in cui si opera a rendere inutili le previsioni e le pianificazioni di dettaglio. Ma serve una risposta circostanziata, fatta di prove e magari alternative. Non basta dire: “Questo è micromanagement, è spreco… In Agile noi non lo facciamo”.
Ribaltare la prospettiva
L’approccio Agile, Scrum in particolare, offre un radicale cambio di prospettiva: al termine di ogni sprint è possibile fornire un consuntivo preciso di quanto speso in termini economici e temporali, offrendo così una maggiore trasparenza su quanto manca per completare il progetto. È un cambio di prospettiva significativo, che richiede al dipartimento finance di accettare questo nuovo approccio in cambio di una maggiore fiducia e trasparenza.
Spesso, per “rassicurare” chi è abituato a ricevere un certo tipo di piani, rapporti, previsionali, non basta dire: “Ti fornirò dati più dettagliati a consuntivo ogni 2 settimane, invece di fare un piano previsionale a 6 mesi, che non è detto che torni”.
Quello che stiamo facendo in questo momento è stimolare questo cambio di prospettiva fornendo una doppia contabilità a chi la chiede: “Ti faccio anche un piano previsionale a 6 mesi, ma ti propongo un report a consuntivo con gli stati di avanzamento a ogni fine sprint, che ti fornisce informazioni più attendibili”.
Il vero cambio che sta creando molto “stupore” è che, grazie ai check frequenti e ai consuntivi ravvicinati, il PO pretenda poi di ripresentare il previsionale modificato in base alle nuove informazioni che emergono dal campo. Nonostante in questo modo il previsionale diventi più attendibile, almeno all’inizio questo modo di fare viene vista coma una mancanza di professionalità.
Conclusioni
In sintesi, la gestione agile richiede un cambio di prospettiva sia per il middle management che per gli stakeholder. Pianificazione e controllo ci sono, ma non si manifestano con la rigidità di un piano dettagliato che assegna compiti specifici per mesi. Occorre imparare a distinguere tra costi e avanzamento, tra ore lavorate e valore prodotto. Solo così possiamo avere una visione chiara, realistica e condivisa del progresso di un progetto agile.
Nel prossimo articolo parleremo di un argomento fondamentale per chi gestisce progetti e risorse: l’Earned Value Analysis (EVA). Questo metodo ci aiuterà a comprendere meglio come misurare il progresso del progetto in termini di valore creato rispetto al budget e ai tempi previsti. Scopriremo come EVA può essere utilizzato in un contesto agile per dare ancora più trasparenza agli stakeholder e per prendere decisioni basate su dati concreti. Solo così possiamo avere una visione chiara, realistica e condivisa del progresso di un progetto agile.
Giovanni Puliti ha lavorato per oltre 20 anni come consulente nel settore dell’IT e attualmente svolge la professione di Agile Coach. Nel 1996, insieme ad altri collaboratori, crea MokaByte, la prima rivista italiana web dedicata a Java. Autore di numerosi articoli pubblicate sia su MokaByte.it che su riviste del settore, ha partecipato a diversi progetti editoriali e prende parte regolarmente a conference in qualità di speaker. Dopo aver a lungo lavorato all’interno di progetti di web enterprise, come esperto di tecnologie e architetture, è passato a erogare consulenze in ambito di project management. Da diversi anni ha abbracciato le metodologie agili offrendo ad aziende e organizzazioni il suo supporto sia come coach agile che come business coach. È cofondatore di AgileReloaded, l’azienda italiana per il coaching agile.