Gabriele Lana

Il burn down chart è decisamente uno dei miei grafici preferiti in quanto si adatta perfettamente alla filosofia Agile

E’ estremamente semplice da disegnare e da tenere aggiornato, potrebbe sembrare una sciocchezza, ma non lo è: la complessità di disegno del grafico ci potrebbe portare ad utilizzare uno o più programmi specifici per il plotting, il che ci porterebbe a dover inserire manualmente i dati relativi, il che probabilmente ci porterebbe a considerare la possibilità di utilizzare uno o più software per memorizzare i nostri dati di processo in modo da poter automatizzare la generazione del grafico. Ne vale la pena? A mio parere questo è un’antipattern abbastanza comune che dovrebbe essere accuratamente evitato, per questo consiglio tutti i miei team di disegnare i loro grafici di processo a mano e di fare il traking dopo o durante lo stand-up meeting.

E’ estremamente intuitivo: sull’asse verticale sono rappresentati i punti storia, ovvero una misura della complessità (cumulativa) delle funzionalità che dovremmo implementare, sull’asse orizzontale sono rappresentati i giorni che abbiamo a disposizione per completare il nostro lavoro. L’ho definito “intuitivo” sia perchè è semplice identificare l’obiettivo (consumare i punti storia entro la data prevista), sia perchè basta un colpo d’occhio per capire se siamo in ritardo o se siamo in anticipo sulle nostre previsioni: se siamo sopra l’andamento ideale, siamo in ritardo, altrimenti siamo in anticipo

Un’altra caratteristica “Agile” di questo tipo di grafico è la possibilità di identificare molto rapidamente dei trend, possiamo avere feedback immediato su quello che è lo stato del progetto oggi e sullo stato in cui sarà il progetto domani se non modificheremo il nostro processo produttivo.

Ultimamente ad uno dei miei team è stato affidato un progetto che dovrà essere sviluppato contemporaneamente al loro progetto principale. Ovviamente c’è stato dato un budget di tempo (e quindi di costo) all’interno del quale abbiamo negoziato le funzionalità che dovranno essere implementate. Durante una retrospettiva ho consigliato di tener traccia dell’andamento di questo progetto (che ha uno scope ben definito a dispetto del loro progetto principale) attraverso un burn down chart. In quel momento mi sono accorto che per questo tipo di progetti il burn down chart nel suo formato originale può portare a dei problemi.

Il progetto in questione è limitato nello scope e nel tempo, ma deve anche essere limitato nell’effort che il team può spendere per la sua realizzazione. Avendo come unica metrica il burn down chart tradizionale correremmo il rischio di dedicare troppe energie (leggi persone/ore) per mantenere ideale l’avanzamento di questo progetto secondario a discapito del progetto principale

Quando ci si trova di fronte ad una situazione di questo genere una soluzione potrebbe essere quella di tener traccia, all’interno dello stesso grafico, anche dell’effort. Supponiamo che il nostro budget preveda 5 mesi uomo, calcolando 10 pomodori/giorno/uomo (un pomodoro è un’unita di tempo di 25 minuti), per 20 giorni/mese/uomo, fanno un totale di 1000 pomodori che possiamo spendere come team su questo progetto. In questo modo abbiamo un grafico che non solo ci comunica l’andamento del progetto, ma lo mette in relazione con l’effort spesa. Per esempio nell’immagine qui di fianco possiamo vedere come l’andamento del progetto sia praticamente perfetto, a discapito però di un’utilizzo eccessivo di risorse