Metriche Kanban per il miglioramento continuo

V parte: “Probabilistic forecasting” per prevedere il futurodi

Introduzione

Negli articoli di questa serie abbiamo parlato di svariate metriche che ci aiutano a guidare il nostro processo di miglioramento continuo e ad avere maggiore consapevolezza riguardo a ciò che può essere previsto in prospettiva.

In questo e nell’articolo del mese prossimo — che chiuderà la serie — mettiamo insieme tutto quanto imparato fin qui per prevedere la durata di gruppi di storie o di interi progetti. Mostrerò come nel team usiamo i dati e le metriche a nostra disposizione per migliorare il nostro processo di stima, facendo riferimento a una tecnica chiamata Probabilistic Forecasting.

Consiglio a chi non avesse ben presenti i temi degli articoli precedenti di fare una rilettura di alcune parti particolarmente importanti a cui farò spesso riferimento: “Work Item Type” [1], “Lead Time Distribution” [2], “Throughput” e “Il problema di Story Point e Velocity” [3].

 

“Quanto ci vuole? Mi fai una stima?”

Abbiamo tutti uno o più stakeholder che consideriamo essere i nostri “clienti”: potrebbe essere un altro team nella nostra stessa azienda, un cliente della nostra società di consulenza, un Product Owner per il prodotto che vendiamo, il CEO della nostra startup, e così via.

Solitamente la prima domanda che il cliente ci rivolge non appena spiegato il problema — o spesso anche prima… — è: “Quanto tempo ci vorrà? Quanto costa? Mi fai una stima?”.

L’approccio agile comune al processo di stima

Per rispondere a queste domande, l’approccio comune di un team Agile più o meno è:

  • analizza i requisiti con l’aiuto del cliente e/o del PO e li “spezza” in storie, creando un backlog;
  • stima ogni storia nel backlog, usando tecniche come Story Point, T-shirt size, ore ideali, o ore effettive, quest’ultima soprattutto in quei team non ancora molto agili;
  • usa la Velocity per convertire Story Point in giorni o sprint e per sapere quanto tempo ci vorrà per completare il lavoro; questa potrebbe essere una Velocity ideale se si tratta di un team nuovo, o la Velocity effettiva che si è misurata in passato se è un team già esistente;
  • prima di consegnare la stima al cliente, un Project Manager (o chi per lui) aggiunge un “buffer”, un “cuscinetto temporale” ulteriore, necessario per gestire eventuali emergenze o nel caso la stima sia sbagliata; a volte viene semplicemente aggiunto del tempo extra, a volte invece la stima viene proprio raddoppiata o addirittur triplicata;
  • dichiara la stima al cliente, in termini di costo e di data di consegna: un team agile idealmente consegna in modo incrementale, ma è ancora molto comune dichiarare la data in cui il progetto sarà “finito”;
  • durante il corso del progetto usa la Velocity per controllare se si è in linea e quando il backlog sarà completato, usando tool come burn-down e burn-up chart.

Problemi tipici con le stime

L’approccio appena visto rappresenta senza dubbio un enorme miglioramento dai tempi del waterfall e sono sicuro che siamo tutti in buona fede quando lo seguiamo. Tuttavia non possiamo ignorare alcuni problemi che tipicamente emergono con questo tipo di stime: vediamoli di seguito.

Falso senso di certezza

Il risultato è espresso come un singolo numero o una data precisa, con l’effetto di nascondere l’incertezza intrinseca in una stima. Per esempio: “Ci vogliono 60 giorni”; oppure “Lo consegniamo il 01 febbraio”.

Spesso è il cliente a chiedere una data esatta perché questo lo fa sentire più sicuro e può usare quella data come “committment”. Questa data finisce in qualche piano e diventa una deadline che ci spinge verso quei comportamenti molto poco agili: blocchiamo i cambiamenti, riduciamo la collaborazione, cerchiamo scorciatoie, e così via.

Molto inaccurata

Come spiegato nel terzo articolo della serie [3], la correlazione tra Story Point e Lead Time è molto bassa. Inoltre la Velocity è una delle metriche più facili da imbrogliare, soprattutto quando siamo sotto pressione: senza rendercene conto, finiamo per raddoppiare i punti di ogni storia per sentirci più veloci o per rispettare le aspettative di qualche manager.

Il risultato è che la traduzione da stime a giorni/data diventa altamente inaccurata, pur sembrando precisa. È la ricetta per un disastro...

Stime inaffidabili quando siamo troppo occupati

La teoria delle code, da cui Kanban prende enorme ispirazione, ci insegna che più il livello di utilizzo del sistema va verso il 100% più il Lead Time schizza in alto. In breve: quando siamo troppo occupati, le attività impiegano molto tempo, come ben illustrato in un celebre libro di Don Reinertsen [4] o in un articolo del 2015 di Pawel Brodzinski [5].

Figura 1 – Percentuale di utilizzo del sistema vs. Lead Time.

Figura 1 – Percentuale di utilizzo del sistema vs. Lead Time.

 

Un alto utilizzo è tipico in team che non hanno un limite al Work In Progress (WIP): quando una attività è bloccata, ne iniziano un’altra perché vogliono essere sempre occupati, e finiscono con avere 10 cose lasciate a metà e niente di completato.

In questi casi, stime basate sulla dimensione di una attività perdono senso perché anche qualcosa di molto semplice impiega moltissimo. L’analogia di Troy Magennis [6] descrive bene il problema: in una strada intasata, la bici, la Ferrari e il camion si muovono tutti alla stessa velocità, vale a dire molto lentamente.

Figura 2 - In una strada intasata, la bici, la Ferrari e il camion si muovono tutti alla stessa velocità: molto lentamente.

Figura 2 - In una strada intasata, la bici, la Ferrari e il camion si muovono tutti alla stessa velocità: molto lentamente.

Diamo il risultato che il cliente vuole sentirsi dire

Spesso abbiamo già un’idea di cosa il cliente vuole sentirsi dire. Finiamo così per influenzare le nostre decisioni per cercare di dare il risultato che crediamo sarà accettato dal cliente, a discapito di quello che derivava dalla nostra stima. Se il cliente non accetta, marchiamo le nostre stime come “sbagliate” e le rivediamo. Diventa un processo di negoziazione da cui una delle due parti uscirà perdente… e troppo spesso il perdente è proprio il team di sviluppo.

Questo è uno scenario particolarmente tipico per società di consulenza che devono vincere contratti.

Fixed-scope: ci fissiamo troppo presto su una particolare soluzione

Invece di presentargli un problema da risolvere, molto spesso viene chiesto al team di sviluppo di stimare una particolare soluzione.

Il team si concentra quindi a stimare quella soluzione, crea un backlog con tutte le storie da implementare, e il progetto non è considerato concluso finché tutte le storie non sono complete. Diventa un progetto con fixed-scope. Se il progetto va lungo abbiamo paura di fermarlo perché ci abbiamo già investito troppo: è la cosiddetta Sunk Cost Fallacy [7].

Non ci rendiamo conto che ogni problema ha infinite soluzioni e potremmo invece partire con la più economica per consegnare immediatamente del valore: magari è una soluzione che richiede qualche step manuale e qualche hack qua e là, ma per lo meno risolve il problema subito. Successivamente possiamo sempre iterare e implementare soluzioni più complesse, se il cliente lo ritiene necessario.

 

“Probabilistic forecasting”: quanto impiegheranno le prossime N storie?

Probabilistic forecasting [8] è una tecnica usata in diverse industrie per prevedere il verificarsi di eventi incerti. Il risultato della previsione è espresso come una lista di possibili risultati accompagnati dalla probabilità che quel particolare risultato divenga realtà.

Un classico esempio sono le previsioni meteo. Magari in gran parte dei notiziari TV si limitano a dire “domani piove”, ma quello che il meteorologo ha previsto è piuttosto una cosa del genere: “dopo aver utilizzato diversi modelli matematici per simulare la situazione meteorologica di domani, l’80% dei risultati dà esito di pioggia, il 15% dà nuvoloso senza pioggia, il 5% dà poco nuvoloso”.

Da qualche anno la comunità Kanban ha introdotto l’uso di questa tecnica nello sviluppo software.

Monte Carlo Simulation

Il meteo, come lo sviluppo software, è un sistema complesso [9] dove le relazioni di causa-effetto non sono prevedibili e sono visibili solo a posteriori. Non possiamo prevedere in modo deterministico cosa succederà. Quello che possiamo fare è usare i dati storici a nostra disposizione per simulare cosa potrebbe accadere in futuro.

Per fare Probabilistic Forecasting utilizziamo una tecnica presa dalla statistica chiamata Monte Carlo Method, anche se nella comunità Kanban tutti la chiamano Monte Carlo Simulation. È una tecnica particolarmente utile quando abbiamo a che fare con variabili incerte, o quando queste variabili sono generate a partire da una distribuzione. Consiste nell’estrarre valori random per queste variabili per ogni simulazione, ripetendo la simulazione per migliaia di volte così da generare sufficiente variazione nei valori e trovare statisticamente l’occorrenza di ogni possibile risultato.

 

Probabilistic Forecasting passo per passo

Vediamo passo passo con un esempio come usare Probabilistic Forecasting per rispondere alla fatidica domanda “quanto impiegheranno le prossime N storie?”. Come nota importante, stiamo dando per scontato che tutte le N storie siano dello stesso work item type.

Passo 1: suddividere in storie

Se non lo abbiamo già fatto, analizziamo i requisiti e li spezziamo in storie, usando i nostri soliti criteri. Per ogni storia identifichiamo il suo work item type. Il risultato sono storie con cui ci sentiremmo a nostro agio a lavorare.

Passo 2: dati di input

Abbiamo bisogno di due dati in input: il numero di storie da completare, e il throughput che il team ha avuto in passato. Per esempio, vogliamo completare 20 storie e abbiamo avuto il throughput rappresentato in figura 3.

Figura 3 – Esempio dei dati che ci servono in input.

Figura 3 – Esempio dei dati che ci servono in input.

Passo 3: prima simulazione

Iniziamo la prima simulazione. Estraiamo a random un campione dal throughput che abbiamo avuto in passato, per far finta che nella prima iterazione completeremo quel numero di storie. Nell’esempio ho estratto 3: stiamo quindi simulando che nella prima iterazione completeremo 3 storie.

Figura 4 – Nella prima simulazione, completeremo 3 storie nella prima iterazione.

Figura 4 – Nella prima simulazione, completeremo 3 storie nella prima iterazione.

Passo 4: seconda iterazione della prima simulazione

Ripetiamo per eseguire la seconda iterazione della prima simulazione: quante storie completeremo nella seconda iterazione? Estraiamo un nuove campione a random. Nell’esempio ho estratto 5. Dopo due iterazioni, avremo completato 8 storie in totale

Figura 5 – Iterazione 2 della prima simulazione: 8 storie completate finora.

Figura 5 – Iterazione 2 della prima simulazione: 8 storie completate finora.

Passo 5: completiamo la prima simulazione

Ripetiamo finché il numero di storie completate in totale arriva o supera 20. Nell’esempio ci sono volute 5 iterazioni prima di completare 20 storie. La prima simulazione è completata.

Figura 6 – Nella prima simulazione avremo completato le 20 storie dopo 5 iterazioni.

Figura 6 – Nella prima simulazione avremo completato le 20 storie dopo 5 iterazioni.

Passo 6: ripetere la simulazione per migliaia di volte

Ripetiamo la simulazione per qualche migliaio di volte, ovviamente in modo automatico, con uno spreadsheet [11] o uno script. Ogni volta continuiamo a estrarre numeri a random dal nostro throughput passato. Ripetendo la simulazione così tante volte, stiamo generando ogni possibile variazione nel risultato, così da osservare statisticamente quante volte avviene quel particolare risultato.

Ci saranno simulazioni particolarmente fortunate dove magari impieghiamo solo un paio di iterazioni, e altre particolarmente sfortunate dove impieghiamo 7-8 iterazioni. Ma con così tante ripetizioni questi casi anomali diventano una minoranza rispetto ai casi più probabili.

Figura 7 – Ripetiamo la simulazione migliaia di volte per generare un campione statistico.

Figura 7 – Ripetiamo la simulazione migliaia di volte per generare un campione statistico.

Passo 7: individuare la probabilità dei risultati

Contiamo la frequenza di ogni risultato per trovarne la probabilità.

Figura 8 – I risultati della nostra previsione.

Figura 8 – I risultati della nostra previsione.

 

L’esempio di figura 8 mostra che abbiamo il 17% di probabilità di impiegare 3 iterazioni, il 38% di probabilità di impiegare 4 iterazioni, e così via. La colonna più a destra è la somma cumulativa delle singole probabilità: ci dice che abbiamo il 56% di sicurezza che completeremo le 20 storie entro al massimo 4 iterazioni, e l’84% di sicurezza che le completeremo entro al massimo 5 iterazioni.

 

Passo 8: comunicare il risultato al cliente

Idealmente esprimiamo il risultato al cliente in questo modo: “Abbiamo circa il 50% di possibilità di completare il lavoro in 4 iterazioni, ma potrebbero volercene 5. È improbabile che ne servano più di 5, ma nel peggiore dei casi potremmo arrivare a 6”.

Questo stile ci aiuta a concentrarci sulla gestione del rischio: se dovesse verificarsi il peggiore dei casi e dovessimo impiegare 6 iterazioni, quale sarebbe l’impatto? Cosa possiamo fare per diminuire quel rischio?

Se invece il cliente insiste per un singolo numero o una data precisa, sta a noi decidere quanto livello di rischio vogliamo assumerci. Se vogliamo essere sicuri dovremmo dichiarare 5 iterazioni. Altrimenti potremmo anche rischiare e dire 4 iterazioni; ma in questo secondo caso abbiamo quasi il 50% di probabilità di sbagliarci e sforare le stime.

Passo 9: tener traccia dell’avanzamento

Una volta che iniziamo a lavorare sulle 20 storie, usiamo esattamente la stessa tecnica per tenere traccia dell’avanzamento del lavoro. Al termine di ogni iterazione torniamo al passo 1 e aggiorniamo i dati in input: aggiungiamo un valore al throughput, e il numero di storie da completare viene diminuito. Ripetiamo quindi gli altri step per prevedere quando completeremo il resto delle storie.

Ribadiamo la nota: la dimensione delle storie non conta… ma il loro tipo sì!

Lo abbiamo già spiegato negli articoli precedenti [2] ma preferisco ripeterlo: la dimensione delle storie non conta, a patto che siano storie dello stesso tipo (Work Item Type). Storie dello stesso tipo seguono la stessa distribuzione di Lead Time, e quindi avremo molte storie veloci, alcune storie un po’ più lente e, di tanto in tanto, qualche storia più grossa.

Ma per le storie di tipo diverso? Vediamo di seguito quello che si può fare.

 

Previsioni per storie di tipo diverso

Gli step descritti qui sopra fanno riferimento al throughput per una tipologia singola di Work Item Type. Supponiamo invece di dover fare previsioni per storie di diverso tipo, per esempio: 20 storie di tipo 1 e 8 storie di tipo 2. Seguiamo lo stesso processo ma lo ripetiamo per i due tipi:

  • Iniziamo con il tipo 1: diamo in input “20 storie” e il throughput che abbiamo avuto in passato per il tipo 1. Il risultato è 4-5 iterazioni.
  • Ripetiamo per il tipo 2: diamo in input “8 storie” e il throughput che abbiamo avuto in passato per il tipo 2. Il risultato è 2-3 iterazioni.
  • Il risultato è quindi 4-5 iterazioni: le storie di tipo 2 saranno complete dopo 3 iterazioni, ma ci vorranno un altro paio di iterazioni prima di finire anche le storie di tipo 1.

Altri fattori da considerare

Ci sono un paio di fattori importanti da considerare quando diamo in input il numero di storie:

  • Quanti bug abbiamo di solito? Dovremmo tenerne conto e aumentare il numero di storie di conseguenza. Per esempio: come abbiamo spiegato nell’articolo precedente, se abbiamo 1 bug ogni 6 storie, invece di 20 storie dovremmo dare in input 23 o 24 per tenere conto dei bug che troveremo.
  • Ci sarà scope creep? Vale a dire, scoprirò altre storie a cui non avevo pensato? È molto comune che questo accada; quindi, in base a quanto ci sentiamo sicuri, potremmo voler aggiungere altre storie per tenerne conto. Idealmente, è bene guardare agli scorsi progetti: quante storie erano nel backlog all’inizio, e quante storie si sono avute alla fine?

“Effort” vs “Elapsed”

È importante notare che il risultato della nostra previsione è quello che un project manager chiamerebbe Effort. Risponde alla domanda: “Quanto impiegheremo? Quanto costa?”.

Se invece vogliamo sapere “Quando il lavoro sarà concluso o consegnato?”, ossia i giorni di calendario, allora dobbiamo pensare alla misura di tipo Elapsed e dobbiamo stare attenti: dipende da come lavoreremo sulle storie. Se il team è libero di concentrarsi e lavorare a tempo pieno sulle storie, allora Effort ed Elapsed coincidono. Se invece il lavoro è mischiato con altro, dobbiamo allora tenere conto di quanto tempo trascorreremo su questo progetto per ogni iterazione.

 

Conclusione

In questo articolo abbiamo cominciato a vedere come utilizzare i dati a nostra disposizione per prevedere la durata di interi progetti e migliorare il nostro processo di stima, grazie al Probabilistic Forecasting e alla tecnica statistica Monte Carlo Simulation. Nel prossimo articolo concluderemo il discorso con una serie di considerazioni su stime e previsioni.

Mi farebbe molto piacere sentire la vostra opinione e rispondere ad eventuali domande! Potete trovarmi per email, o su Twitter e Linkedin.

 

Riferimenti

[1] Mattia Battiston, Metriche Kanban per il miglioramento continuo – I parte: Uno sguardo alle metriche per il flow, MokaByte 214, febbraio 2016

http://www.mokabyte.it/2016/02/kanbanmetrics-1/

 

[2] Mattia Battiston, Metriche Kanban per il miglioramento continuo – II parte: Metriche per il Delivery Time, MokaByte 215, marzo 2016

http://www.mokabyte.it/2016/03/kanbanmetrics-2/

 

[3] Mattia Battiston, Metriche Kanban per il miglioramento continuo – III parte: Metriche per la prevedibilità, MokaByte 216, aprile 2016

http://www.mokabyte.it/2016/04/kanbanmetrics-3/

 

[4] Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development, Celeritas Publishing, 2009

 

[5] Pawel Brodzinski, Economic Value of Slack Time

http://brodzinski.com/2015/01/slack-time-value.html

 

[6] Troy Magennis, Agile 2015 – Risk – The Final Agile Enterprise Frontier

https://goo.gl/GFIov3

 

[7] David McRaney, The Sunk Cost Fallacy

https://goo.gl/u4ikTv

 

[8] La voce “Probabilistic forecasting” su Wikipedia

https://en.wikipedia.org/wiki/Probabilistic_forecasting

 

[9] Il modello Cynefin

https://lizkeogh.com/cynefin-for-developers/

 

[10] La voce “Monte Carlo method” su Wikipedia

https://en.wikipedia.org/wiki/Monte_Carlo_method

 

[11] Un foglio di calcolo per realizzare la simulazione Monte Carlo

https://goo.gl/wKHybt

 

Condividi

Pubblicato nel numero
218 giugno 2016
Mattia Battiston è un software developer con una grande passione per il miglioramento continuo. Attualmente lavora a Londra per Sky e utilizza Kanban, Lean e Agile per aiutare diversi team a migliorare.
Articoli nella stessa serie
Ti potrebbe interessare anche