Come parte della nostra serie di stime software, abbiamo esplorato l’importanza di gestire le aspettative come parte di qualsiasi progetto software. Questo articolo si concentrerà sul cono di incertezza, un potente strumento per mitigare i rischi coinvolti nel processo di scoping e stima. Al suo interno, è una rappresentazione dell’incertezza sul tempo necessario per completare un progetto, basata sulla quantità di conoscenza (o mancanza di ciò) all’inizio di un progetto. Alla fine rappresenta il rischio che il progetto si estingua a causa di incognite e il fatto che più nel futuro si tenta di stimare, più è probabile che si sbagli. È un paradosso interessante in cui vogliamo prevedere il futuro con precisione, tuttavia non possiamo essere veramente precisi perché è solo una stima.

Nel caso in cui non l’hai già fatto, ti consiglio di familiarizzare con un precedente esperimento che abbiamo condotto qui a Codebots per scoprire come potremmo gestire al meglio i rischi nel software. La motivazione per questo esercizio è stato il frequente iperottimismo da parte dei nostri team di software quando si trattava di condurre stime.

Avendo fornito la procedura migliore per proporre un esperimento, abbiamo identificato un problema nelle nostre stime di ambito fisso. Ogni preventivo conteneva una variazione minima dell ‘ 80% rispetto al lavoro svolto, indipendentemente dalla lunghezza del progetto. Poiché non abbiamo applicato un cono di incertezza, la nostra capacità di fornire ai nostri clienti stime realistiche e gestire le loro aspettative è stata notevolmente ostacolata.

Punto 1: Comprendere il problema

Come accennato in precedenza, abbiamo riscontrato un problema nelle nostre stime, che si verificano quando forniamo un prezzo di ambito fisso nella fase di citazione. (Ambito fisso che significa fornire i requisiti esatti forniti, ma per un periodo di tempo flessibile). Non importa la lunghezza del progetto, siamo sempre andati oltre a causa di avere una grande quantità di variazione.

La causa principale – non abbiamo avuto un cono di incertezza. Non abbiamo tenuto conto del fatto che più nel futuro si tenta di prevedere, maggiore è l’aumento della varianza temporale. Ciò è dovuto alla presenza di una serie di rischi specifici, di cui i più gravi sono stime imprecise, variazioni dell’ambito e coinvolgimento degli utenti finali. Poiché tutto era stato stimato all’inizio, non vi era alcuna possibilità di modificare la stima per tenere conto di questi rischi scoperti. Invece, l’impatto di questi rischi sono aggravati nel corso della vita del progetto, il che significa più a lungo il progetto, più si tenta di prevedere, quindi più è probabile che si è sbagliato.

Punto 2: Sviluppare un’ipotesi

Dopo aver digerito il problema, abbiamo lavorato allo sviluppo di un’ipotesi per testare come un cono di incertezza potesse essere applicato con precisione alle nostre stime di ambito fisso.

Da ciò, è stato ipotizzato che una formula potesse essere utilizzata per calcolare la dimensione del Cono di Incertezza, data la lunghezza di un progetto.

Fase 3: Pianificare l’esperimento

Equipaggiato con la nostra ipotesi, abbiamo proceduto a pianificare un esperimento per testare la nostra proposizione del Cono di Incertezza. Per fare ciò, abbiamo generato una funzione quadratica per simulare il nostro cono, con un parametro che rappresenta il numero di settimane di sviluppo previste. Potremmo quindi applicare questo moltiplicatore alle nostre stime per tenere conto della varianza temporale, in base a quanto lontano nel futuro stavamo cercando di prevedere.

Se applichiamo questo ai dati di stima dei progetti precedenti, potremmo quindi determinare se un prezzo di ambito fisso con la variazione sarebbe stato più accurato.

Punto 4: Raccogliere i dati

Abbiamo raccolto i dati da una varietà di progetti, comprese le informazioni sul tempo assegnato e preso, storie completate, tempo fino al completamento, comprese le note aggiuntive sul progetto e rischi incontrati.

Prendendo le stime, abbiamo calcolato un ipotetico valore di ambito fisso per ogni progetto, utilizzando il cono di incertezza. Utilizzando queste informazioni, siamo stati in grado di esaminare se il tempo che abbiamo effettivamente impiegato per sviluppare, terminando sia il lavoro iniziale che le variazioni aggiuntive, fosse paragonabile ai nuovi valori di stima generati utilizzando il cono di incertezza. Risulta, la stima migliorata e il tempo effettivamente impiegato erano molto simili!

Punto 5: Prendere una decisione

Alla fine, i dati hanno dimostrato che se applicassimo il Cono di incertezza a un ambito fisso, usando una formula che tiene conto della lunghezza di un progetto, finiremmo con una stima che terrebbe conto della varianza che si verifica sullo sviluppo del progetto.

In definitiva, si consiglia che piuttosto che cercare di stimare l’intero progetto, un team di sviluppo si concentra solo su e stima una piccola quantità di lavoro. Ciò contribuirà a ridurre l’impatto delle incognite e quindi la dimensione del cono di incertezza. Ciò significa anche che mentre il team lavora sul progetto ne impara di più e quando si tratta di stimare il prossimo pezzo di lavoro, possono ridurre l’incertezza e fare stime più accurate.