Stima vs previsione: i vantaggi del Probabilistic Forecasting

Nella scorsa puntata ci eravamo occupati di capire i meccanismi del Probabilistic Forecasting e in questa vedremo di vedere tale approccio all’opera. Ovviamente, il Probabilistic Forecasting non è la bacchetta magica in grado di risolvere ogni problema con le stime, ma, dalle esperienze vissute, possiamo dire che se non altro ci aiuta a mitigare molte situazioni difficili e ci rende la vita un po’ più tranquilla.

C’è anzitutto un concetto molto importante da capire e lo introduciamo subito: mentre l’approccio “classico” genera una stima (in inglese “estimate”), con il Probabilistic Forecasting generiamo una previsione (“forecasting”). Non è solo questione di parole: le differenze tra i due termini sono molto importanti.

Che cosa è una previsione

Vediamo di capire quali sono le caratteristiche di una previsione.

• Comunica la naturale incertezza nel futuro. Mentre una stima è espressa come un numero singolo, una previsione è espressa come un range di possibili eventi con la loro probabilità.
• È più accurata perché si basa su dati e misurazioni invece che sull’intuito delle persone. L’inaccuratezza nel convertire Story Point in tempo è sparita.
• Tiene automaticamente conto di code e dei problemi avuti in passato. Siccome usiamo dati storici, stiamo tenendo conto delle code nel nostro processo, di quanto siamo impegnati di solito, dei blocchi, etc. Quando invece cerchiamo di stimare, tendiamo a pensare solo al caso ideale, che raramente diventa realtà.
• Riduce l’errore dovuto alle opinioni personali. Basandoci su dati reali, riduciamo l’importanza di opinioni personali, dei nostri “pregiudizi” — nel senso di giudizi dati in anticipo senza conoscere a fondo la questione — e siamo più inclini a restare oggettivi invece di dare la risposta che il cliente vuole sentirsi dire.
• Richiede meno investimento. Come per una stima, dobbiamo ancora investire tempo per analizzare i requisiti e spezzarli in storie. Tuttavia, per una previsione non occorre niente altro, mentre per una stima dovremmo scorrere ogni singola storia e stimarla individualmente
• Riduce l’importanza di una particolare soluzione. La previsione ci dice che “ci vuole X tempo a completare N storie” ma quali esattamente sono quelle storie è meno importante. Siamo meno legati a una particolare implementazione

Quanto impiegherà questo progetto?

Abbiamo visto come prevedere la durata di un gruppo di storie. Ma come affrontiamo un intero progetto? Vi dico cosa facciamo nel mio team.

Se i requisiti del progetto sono sufficientemente piccoli, li spezziamo direttamente in storie e poi usiamo il processo descritto sopra.

Quando invece il progetto è più grosso, seguiamo questo processo.

Da requisiti a epiche di alto livello

Anzitutto, suddividiamo i requisiti in epiche di alto livello,

Da epiche a storie

A questo punto, scegliamo 5 epiche (a caso, oppure le prime 5 su cui lavoreremmo) e le spezziamo in storie.

Vogliamo evitare di impiegare troppo tempo spezzando ogni singola epica in storie. La cosiddetta “regola del 5” [1] ci dice che con 5 campioni sappiamo che la mediana della popolazione sarà compresa tra questi 5.

Calcoliamo quindi la mediana del numero di storie per epica trovate finora, e da quella deduciamo quante storie avremo in totale.

• Mediana(5, 2, 3, 4, 9) = 4 storie per epica
• Mediana x N. Epiche = 4 x 15 = 60 storie

Da epiche a storie: altre tecniche

In alternativa, a quelle appena dette, altre tecniche che abbiamo usato per trovare il numero di storie a partire dalle epiche sono:

• usare una Monte Carlo Simulation per trovare il numero di storie, usando come input le 5 epiche già spezzate;
• assegnare una T-shirt size ad ogni epica e decidere quante storie ci aspettiamo per ogni taglia.

Aggiungere un margine di compensazione

Nella nostra previsione per farci un’idea del tempo che un progetto impiegherà per essere terminato, teniamo conto di bug, storie che scopriremo e scope creep per aumentare il numero di storie di conseguenza

• 1 bug ogni 6 storie = 60 storie / 6 = 10 bug
• 1 nuova storia ogni 5 storie = 60 / 5 = 5 nuove storie che scopriremo
• totale storie = 60 + 10 + 5 = 75 storie

Monte Carlo!

Dopo tutta questa preparazione, ora abbiamo il numero di storie e possiamo applicare la nostra Monte Carlo Simulation così come visto nell’articolo precedente.

S-curve

C’è un ultimo importante aspetto da considerare. Se si tratta di un progetto completamente nuovo — creare una nuova applicazione, o usare una nuova tecnologia — teniamo conto della cosiddetta S-curve [2]: all’inizio e alla fine del progetto siamo più lenti che nel mezzo e quindi la curva di andamento del progetto assume una tipica forma a “S”.

Rolling Wave Forecasting: quando saranno consegnate le prossime storie?

Rolling Wave Forecasting è un modo per visualizzare quando ci aspettiamo che le prossime storie saranno concluse. L’idea di “Rolling Wave Planning”[3] non è nuova ma Vasco Duarte nel suo libro #NoEstimates la adatta per usare previsioni invece di stime.

Usiamo le nostre previsioni per evidenziare in tempo reale nel backlog le storie che saranno sicuramente completate nelle prossime due settimane, quelle che saranno probabilmente completate, e quelle che è improbabile che completeremo.

Stime e previsioni: non sempre sono la migliore soluzione

Quando ci viene chiesta una stima, la prima domanda che dovremmo farci è sempre “Perché vuoi una stima? Come la userai?”. Possono esserci diverse ragioni dietro la richiesta di una stima. In base al motivo, la risposta migliore potrebbe essere una previsione, oppure una risposta completamente diversa! Quindi, vediamo quando è meglio non fare stime e previsioni e invece quando può essere vantaggioso.

Quando è meglio non stimare/prevedere?

Non sempre stime e/o previsioni sono la soluzione migliore. Ci sono casi in cui è decisamente meglio usare altri strumenti. In particolare, vediamo di seguito alcune situazioni in cui stime e previsioni non sono la risposta giusta alle necessità.

Stabilire il budget

Per quanto possa “dare fastidio” a un management di impostazione tradizionale, stime e previsioni non sono lo strumento più adatto per decidere il budget. Le domande tipiche sono: “Quanti soldi mi servono?”, “Qual è il ROI?”. La risposta migliore in questo caso, invece di stimare, è essere agili.

Chiediamoci “Quanto siamo disposti a spendere?” e lavoriamo in iterazioni brevi per implementare la miglior soluzione possibile che sta nel budget. Alla fine possiamo decidere se vale la pena continuare e iniettare altro budget o se il valore consegnato finora è sufficiente a risolvere il problema.

Questo approccio cade spesso sotto il cappello di Agile Contracts e se volete approfondire consiglio una presentazione di Jacopo Romei [5].

Individuare le priorità di lavoro

Le stime / previsioni non sono lo strumento adatto per decidere la priorità del lavoro, ad esempio “Quale storia fare come prossima?”, “Quale progetto cominciamo?”. Usare una stima per queste decisioni significa prioritizzare in base al costo, ma ci sono aspetti molto più importanti del costo che invece dovremmo usare. È molto meglio prioritizzare in base al valore del lavoro, o in base al rischio, o in base al cost of delay [6].

Comprendere entità e tipologia del personale

Non usate le stime e le previsioni per decidere se abbiamo abbastanza staff: “Devo assumere nuove persone?”, “Devo creare un nuovo team?”. I team più efficaci sono quelli che restano stabili nel tempo. Se aggiungiamo persone o creiamo nuovi team per un progetto, dobbiamo tenere conto che per un lungo periodo quel team sarà meno efficiente, rendendo imprecisa ogni stima. Dove possibile è meglio tenere i team stabili a discapito della quantità di lavoro.

Cause di forza maggiore

Quando il lavoro va fatto comunque, ad esempio per rispettare qualche legge o perché altrimenti il software smetterà di funzionare, è inutile stare a fare previsioni. Se non c’è scelta, non ha senso perdere tempo a stimare: meglio iniziare subito il lavoro|

Sistemi complessi

Stimare e fare previsioni è poco utile quando il problema è decisamente complesso e non sappiamo quale soluzione applicare: il tipico esempio è quello del prodotto del tutto nuovo. In questo caso è meglio lavorare in modalità Lean Startup: formuliamo un’ipotesi e implementiamo il minimo indispensabile per validarla. Continuiamo finché non siamo soddisfatti.

Quando è utile usare una previsione?

Accanto ai casi in cui stime e previsioni sarebbero una risposta inadeguata, esistono situazioni per le quali invece una previsione è molto utile.

Pianificare il lavoro

Le previsioni vanno bene per pianificare il lavoro, rispondendo a domande quali “Quando possiamo iniziare?”, “Per quanto tempo saremo impegnati?”, “Quante/quali feature saranno in questa release?”. Per rispondere a queste domande, usiamo le nostre previsioni e Rolling Wave Forecasting.

Controllare l’andamento del progetto

Le previsioni ci aiutano a controllare l’andamento del progetto: “Siamo in linea con i nostri piani?”, “Dobbiamo rivedere scope/budget?”. La previsione è continuamente aggiornata per evidenziare ogni rischio il prima possibile.

Analizzare problemi con una comprensione collaborativa

Le previsioni servono anche per analizzare un problema e creare shared understanding nel team, per esempio, “Quale problema stiamo risolvendo?”, “Quale soluzione possiamo offrire?”. Analizzare il problema come team è importantissimo per far sì che tutti abbiano lo stesso livello di comprensione e trovare la soluzione migliore.

Domande frequenti

Ci avviamo a conclusione con una serie di domande frequenti a riguardo del Probabilistic Forecasting: sono alcuni semplici consigli che possono aiutare a intraprendere questo approccio.

• Come faccio a iniziare con Probabilistic Forecasting? Consiglio inizialmente di continuare con il vostro attuale processo di stima e, allo stesso tempo, usare Probabilistic Forecasting in parallelo. Dopo un po’ potrete confrontare i risultati e decidere cosa fare.
• Quanti dati mi servono per iniziare? Tra 5 e 11 campioni sono abbastanza per partire. Con 11 campioni abbiamo già il 90% di sicurezza di essere nel range di valori giusto. Poi, ovviamente, più dati abbiamo, più la precisione aumenta
• Quali tool posso usare? I comuni tool di gestione (per esempio Jira) non fanno ancora niente di quanto descritto. Esistono tool professionali per effettuare Monte Carlo Simulation, ma secondo me il modo più semplice è usare un foglio di calcolo, che si tratti di Google Spreadsheet [7] o fi Microsoft Excel [8]. Ultimamente è uscito Guesstimate [9]: è un tool ancora giovane ma che promette bene, come potete vedere da un mio esempio [10].
• Cosa faccio se non ho dati storici (team nuovo, nuovo tipo di lavoro)? Farei comunque una simulazione, usando un throughput ideale che si può ragionevolmente ipotizzare. Non appena iniziate il lavoro, si sostituiscono i dati ideali con quelli reali e si aumenta l’accuratezza della previsione.
• Questo è #NoEstimates? Ehm… forse. Molta gente ama litigare in rete e c’è chi sostiene che una previsione è comunque una stima, e quindi non fa parte di #NoEstimates. Non ho interesse a dibattere sulla semantica dei due termini, ma trovo utile usare due parole diverse per spiegarne le differenze. #NoEstimates è soprattutto una discussione su come possiamo migliorare il nostro processo di stima. Probabilistic Forecasting serve esattamente a questo.
• Ma non posso semplicemente usare la media invece di tutta questa matematica? Per cosa userete il risultato della vostra previsione? Una media è sbagliata nel 50% dei casi e può nascondere enormi variazioni nel range dei valori. Se vi interessa solo farvi un’idea di alto livello dell’ordine di grandezza del lavoro, probabilmente la media è abbastanza. Ma se dovete dichiarare questi risultati e prendervi un impegno… io preferirei essere più preciso.

Conclusione

In questo articolo abbiamo visto la differenza tra stima e previsione e abbiamo cercato di vedere come è possibile mettere in campo le tecniche di Probabilistic Forecasting.

Questo numero conclude la serie sulle metriche Kanban. Mi auguro che abbia suscitato il vostro interesse e generato qualche idea da provare. Magari non sono cose che potete applicare da subito, ma spero che questi spunti vi incoraggino a proseguire nel vostro processo di miglioramento continuo.

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

Riferimenti

[1] Jay Jacobs, Simulating the Rule of Five

http://www.r-bloggers.com/simulating-the-rule-of-five/

[2] David Anderson, Project Management with Kanban (part 3)

http://www.djaa.com/project-management-kanban-part-3-forecasting

[3] Rolling Wave Planning

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

[4] Vasco Duarte, No estimates: how to measure project progress without estimating

http://noestimatesbook.com/

[5] Agile@Work 2015 – Jacopo Romei – Extreme Contracts

https://www.youtube.com/watch?v=FAv_O5oVUoc

[6] Cost of delay

http://blackswanfarming.com/cost-of-delay/

[7] Il foglio di calcolo per realizzare Monte Carlo Simulation

https://drive.google.com/open?id=0B2p8TYBgYF-MdmVrbnk3aDB2dE0

[8] Alcuni fogli di calcolo per realizzare Monte Carlo Simulation

https://github.com/FocusedObjective/FocusedObjective.Resources

[9] Guesstimate

https://www.getguesstimate.com/

[10] Un esempio su Guesstimate

https://www.getguesstimate.com/models/5488