Forecasting Monte Carlo per la pianificazione della delivery in Azure DevOps

Come funziona realmente la simulazione Monte Carlo

Si tratta di un bootstrap resampling della cronologia del proprio team, non di un adattamento statistico a una curva. Per ciascuna delle 10.000 iterazioni, la simulazione avanza nella finestra di forecast e, a ogni passo, estrae a caso (con reinserimento) uno degli sprint conclusi del team, poi aggiunge il numero di elementi completati in quello sprint al totale corrente. Ripetendo l'operazione 10.000 volte, la distribuzione dei risultati diventa il forecast. Il calcolo utilizza la cronologia di Azure DevOps che l'estensione legge già, senza esportare i dati su un'altra piattaforma, senza configurare un personal access token e senza un backend di analytics gestito dal publisher nel mezzo. La simulazione è inoltre deterministica: le estrazioni casuali sono generate a partire dalla cronologia degli sprint, dalla finestra di forecast e dal numero di iterazioni, quindi eseguirla due volte con gli stessi input restituisce lo stesso intervallo P50/P70/P85/P95 entrambe le volte. L'intervallo cambia solo quando cambia il throughput sottostante. Se il tratto finale della finestra di forecast non coincide con un confine netto di sprint, quel periodo parziale finale viene riproporzionato invece di essere contato come uno sprint completo, così il modello non sovrastima ai margini.

Come leggere i forecast per percentile, e perché un intervallo batte una singola data

Ogni forecast restituisce quattro livelli di confidenza calcolati sulle stesse 10.000 simulazioni, ciascuno con il significato "almeno questo numero di elementi, con almeno questa frequenza":

• P95, Molto probabile: il numero che ha il 95% di probabilità di raggiungere o superare. Di solito è l'impegno più piccolo e più sicuro dell'intervallo.
• P85, Probabile: il livello che la maggior parte dei team usa per una data da presentare a uno stakeholder.
• P70, Plausibile: una via di mezzo praticabile, corretta più spesso che no, ma non una promessa sicura.
• P50, Testa o croce: il numero che metà delle simulazioni ha raggiunto e metà no. Utile come obiettivo ambizioso, rischioso come impegno.

Quanti elementi entro una data, rispetto a quando saranno completati N elementi

Sono due domande diverse, e la simulazione esegue una modalità separata per ciascuna. "Quanti?" prende una data obiettivo (30 giorni di distanza per impostazione predefinita) e restituisce quanti elementi del backlog è probabile completare entro quella data, per ciascun livello di confidenza; la usi quando la data è fissa e la domanda aperta è lo scope, ad esempio una data di rilascio o una milestone contrattuale. "Quando sarà completato?" prende una dimensione di backlog, come gli elementi rimanenti di un epic, e restituisce un intervallo di date invece di una data unica; la usi quando lo scope è fisso e la domanda aperta è la data. Poiché la direzione della domanda si inverte, si inverte anche il percentile: per "quando sarà completato?", P50 è la data più precoce e più ottimistica, e P95 è quella più tardiva e più prudente. Quando un backlog è grande al punto che alcune delle 10.000 simulazioni non raggiungono il numero obiettivo entro l'orizzonte di forecast, lo strumento indica la percentuale che non ha finito, invece di dare per scontato che ogni simulazione sia arrivata a termine, così un intervallo di date ampio non viene mascherato da un numero falsamente rassicurante.

Cosa serve al forecast prima che i numeri abbiano un senso

Un forecast Monte Carlo è affidabile solo quanto la cronologia degli sprint conclusi da cui viene ricampionato. Quando apre il forecast per un team, il selettore degli sprint elenca i dieci sprint conclusi più recenti e seleziona per impostazione predefinita i sei più recenti per eseguire il primo forecast; può scegliere manualmente un insieme diverso, il che è utile se uno di quegli sprint è stato un'eccezione vera e propria, una settimana di festività o una riorganizzazione, che vuole escludere dal ricampionamento. Lo sprint attualmente in corso viene escluso automaticamente da quella selezione predefinita: ricampionare da uno sprint parziale e ancora aperto abbasserebbe l'intero forecast con un numero di throughput che non ha ancora finito di essere conteggiato. Se uno sprint selezionato non riesce a caricarsi, la vista lo segnala ("solo X sprint su Y richiesti sono stati caricati") invece di calcolare silenziosamente il forecast su un campione più piccolo e presentarlo come completo. Un team con solo uno o due sprint conclusi otterrà comunque un forecast, ma l'intervallo resterà ampio finché non si accumula altra cronologia; la simulazione non può creare una certezza che il team non si è ancora guadagnato.