Recentemente ho avuto modo di pianificare un progetto con il metodo Kanban e di apprezzare una volta di più la rapidità con cui le pratiche Kanban permettono di elaborare una previsione affidabile dei tempi e costi di progetto. Ho già introdotto in un precedente articolo i concetti fondamentali relativi al KPPM – Project, Programme e Portfolio Management. Qui racconto un breve esempio applicativo che fa uso di alcune tra le pratiche suggerite.
Il progetto
Il progetto informatico da pianificare è consistito nel refactoring e sostituzione di una soluzione software per la gestione di un workflow aziendale che era diventata obsoleta e inadeguata. Il flusso di lavoro in questione ha una lunga storia ed è stato via via nel tempo ottimizzato. Non ci si aspettava nel progetto particolari sorprese da un flusso sostanzialmente consolidato.
Il team di progetto ha visto il coinvolgimento della responsabile dell’area di business interessata, oltre che della project manager (la responsabile IT), della sua assistente, il sottoscritto come Kanban coach e due team di sviluppatori appartenenti a due aziende fornitrici diverse, ben conosciuti e con entrambi i quali esiste da anni un solido rapporto di collaborazione. I due team di sviluppatori hanno caratteristiche e performance differenti e la responsabile IT ha effettuato nel tempo delle misurazioni che ci hanno permesso di conoscere con una certa accuratezza il tipo di distribuzione di probabilità dei loro Lead Time. Per il tipo di sviluppo da effettuare potevamo in questo caso considerare i Lead Time di entrambi i team di tipo gaussiano (Thin-Tailed), quindi abbiamo potuto utilizzare nelle previsioni il Lead Time medio e applicare la Legge di Little.
Preliminarmente abbiamo effettuato un’analisi del lavoro da svolgere e creato un backlog di progetto composto da circa 40 requisiti di alto livello in forma di User Story.
La pianificazione
Non entrerò nei dettagli tecnici dei concetti probabilistici e matematici sottostanti, mi limiterò a una panoramica del metodo applicato. Per pianificare il progetto con il metodo Kanban abbiamo proceduto come segue.
Modello probabilistico per calcolare il numero di User Story di dettaglio
Innanzitutto ci siamo creati un modello per fare delle ipotesi probabilistiche su quale avrebbe potuto essere il numero di User Story di dettaglio a partire da quelli che erano i requisiti di alto livello. Il modello probabilistico ci ha suggerito che un numero di circa 10 User Story di dettaglio per ciascun requisito era una misura ragionevole, per cui abbiamo previsto circa 400 User Story di dettaglio da sviluppare.
Fattore di correzione per tenere conto della ‘dark matter’
Abbiamo successivamente corretto il numero di User Story previste in funzione di quella che in Kanban chiamiamo ‘dark matter’, ovvero tutta quella parte di requisito che emerge man mano che il progetto procede. Non si tratta di nuovi requisiti, chiedendo al committente del progetto risponderà che quei requisiti non sono nuovi, sono sempre stati lì anche se non erano emersi in modo chiaro. Per questo è meglio introdurre un fattore di correzione opportuno per tenerne conto. Nel nostro caso, data la natura del progetto di refactoring del software, con poche sorprese, abbiamo ritenuto che un fattore di correzione del 40% fosse adeguato per tenere conto in modo corretto della ‘dark matter’. In totale la previsione è diventata quindi di 560 User Story.
Calcolo del throghput e del WIP a partire dalla deadline di progetto
Considerando che tipicamente, in un progetto che fa uso di un flusso di lavoro Kanban, è solo la parte temporalmente centrale quella in cui è possibile considerare il flusso di lavoro stabile e costante, abbiamo applicato la Legge di Little al 90% circa del lavoro da realizzare, pari a circa 500 User Story, da svolgersi nel 60% circa del tempo totale di progetto.
Ripartendo le User Story sui due team di sviluppo e conoscendo la deadline di progetto richiesta dalla responsabile dell’area di business, abbiamo calcolato il throghput richiesto, ovvero il numero di User Story che i team devono sviluppare per unità di tempo. Applicando la Legge di Little a ciascun team, in funzione del Lead Time medio su base storica e del throghput richiesto abbiamo quindi calcolato il WIP (Work in Progress) medio per entrambi i team.
Correzione del bias cognitivo sul concetto di media
Il modello prevede poi un ulteriore fattore di correzione del 10% per tenere conto del fatto che i valori medi usati per il calcolo sono un’approssimazione della mediana (ossia il cinquantesimo percentile statistico), che sarebbe il valore corretto da considerare. Noi esseri umani siamo soggetti a un bias cognitivo che ci fa considerare ‘valore medio’ quello che in realtà è il valore mediano. Quando diciamo che “mediamente facciamo una certa attività in un certo tempo” intendiamo che una volta su due ci mettiamo di più e una volta su due ci mettiamo di meno, ma questo appunto è il concetto statistico di mediana, non di media.
Definizione dei tempi e costi di progetto
Abbiamo infine richiesto ai fornitori di mettere a disposizione un numero di sviluppatori adeguato al WIP di lavoro calcolato. In base al calcolo effettuato i fornitori hanno organizzato ciascuno il proprio team e ci hanno fornito un preventivo dei costi per la realizzazione del progetto nei tempi previsti.
Al netto dei tempi necessari per l’elaborazione dell’offerta da parte dei fornitori, la previsione dei tempi e costi di progetto ha richiesto in tutto solo qualche ora.
Il monitoraggio
La previsione così definita ha permesso anche alcuni monitoraggi in corso di progetto molto semplici ma efficaci:
- il fattore utilizzato per calcolare il numero di User Story per ciascun requisito ha consentito un controllo rapido e costante della stabilità del backlog. Quando un team registrava un valore significativamente diverso da quello previsto, faceva immediatamente escalation al project manager;
- ci si aspettava che il Lead Time medio di ciascun team fosse sostanzialmente stabile. Quando si discostava significativamente dai valori di riferimento, partiva immediatamente un escalation al project manager;
- infine ci si aspettava che il throghput di ciascun team restasse attestato al valore medio previsto. Anche in questo caso, quando si discostava significativamente dai valori di riferimento, partiva immediatamente un escalation al project manager.
Conclusione
E’ chiaro, come nell’esempio applicativo qui descritto, che per pianificare e monitorare un progetto con Kanban sia necessaria la presenza di un flusso di lavoro stabile del quale si conoscano i Lead Time medi. C’è del lavoro da fare a monte del progetto, sempre con Kanban, per misurare e, nel caso, rendere stabile e prevedibile il flusso di lavoro dei team.