Stima dei progetti software: scegli il metodo in base all'incertezza

Il modo giusto di presentare una stima software è un intervallo con livelli di confidenza, non una cifra sola: un caso base P50, un caso atteso P70 e un tetto P90 per tutto ciò che viene venduto a perimetro fisso. Scegli il metodo in base a quello che non sai. Se il perimetro è definito e la tecnologia è familiare, basta una scomposizione bottom-up. Se l'incertezza è alta, servono la stima a tre punti (PERT) e, per il reporting di rischio a livello di portafoglio, la simulazione Monte Carlo. Calibra ogni numero sui tuoi progetti passati prima che esca dallo studio.

---

In breve:

• Un intervallo con livelli di confidenza (P50, P70, P90) rappresenta l'incertezza meglio di una stima fissa, soprattutto sui moduli rischiosi come le integrazioni con servizi di terze parti.

• Calibrare le stime sullo storico del team migliora la precisione, perché corregge la tendenza sistematica a sottostimare o sovrastimare.

• Applicare la stima a tre punti (PERT) ai moduli più incerti ed eseguire simulazioni Monte Carlo dà una visione probabilistica di tempi e costi del progetto.

• Scomporre il perimetro in attività dettagliate e segnalare le aree più rischiose rende le stime tracciabili e realistiche, riducendo il rischio di scostamenti importanti.

• Rifare la previsione più volte durante il progetto, aggiornando perimetro e tappe intermedie, riduce l'incertezza e mantiene la fiducia degli stakeholder.

---

Che cos'è la stima di un progetto software e perché una cifra sola non basta

Stimare un progetto software significa prevedere impegno, durata, costo e rischio di uno sviluppo prima che il lavoro cominci, e affinare quella previsione man mano che si sa di più. L'errore che fa quasi tutti i team è trattarla come un esercizio di previsione che produce un numero. È molto più simile a una modellazione del rischio che produce una distribuzione.

Una stima puntuale, per esempio «12 settimane», comunica una precisione che non esiste. Non dice allo stakeholder se quelle 12 settimane sono un testa o croce o una quasi certezza. Un intervallo con livelli di confidenza dichiarati fa l'opposto: dice al cliente esattamente quanto margine sta comprando e perché. È tutto qui il senso di tecniche come PERT e Monte Carlo. Non ti rendono più bravo a prevedere il futuro: rendono visibile la tua incertezza invece di nasconderla, ed è questo che permette al cliente di negoziare il rischio reale e non solo il numero.

Il termine tecnico usato nei paper accademici o nelle linee guida del Software Engineering Institute è software effort estimation oppure software cost estimation. Entrambi coprono lo stesso terreno della «stima di progetto software», con un accento leggermente diverso sull'asse impegno/tempo rispetto a quello dei costi. In questo articolo li trovi usati come sinonimi.

Il percorso: come costruire una stima che regge alla prova dei fatti

La maggior parte delle stime sbagliate non nasce da errori di calcolo, ma da errori di processo: qualcuno ha scelto una tecnica sola, l'ha applicata una volta e ha presentato un numero senza contesto.

1. Fai prima un controllo top-down di buon senso. Prima che qualcuno apra un foglio di calcolo, confronta il progetto con due o tre lavori simili già fatti. Se una piattaforma di e-commerce paragonabile ha richiesto quattro mesi l'anno scorso, un progetto di perimetro simile quest'anno non può risultare di sei settimane o di quattordici mesi. Questo esercizio, che richiede al massimo una giornata, intercetta le ipotesi completamente sballate prima che finiscano dentro una stima di dettaglio.

2. Scomponi il perimetro confermato in una struttura di scomposizione del lavoro (WBS). Per tutto ciò che andrai davvero a quotare, scomponi il progetto in attività abbastanza piccole da poter essere stimate in giorni di sviluppo o in story point. Questa è la tua stima bottom-up ed è l'unico metodo che ti dà tracciabilità voce per voce quando un cliente chiede perché il flusso di checkout costa più del catalogo prodotti.

3. Segnala da uno a tre moduli più rischiosi. Ogni progetto ha una manciata di componenti su cui nessuno è sicuro: un'API di terze parti con documentazione scarna, una migrazione di dati di qualità ignota, una funzionalità che nessuno nel team ha mai costruito. Applica la stima a tre punti (PERT) solo a quei moduli, non a tutto il progetto.

4. Calibra sul tuo storico. Recupera i dati di consuntivo rispetto a stima di tre-cinque progetti paragonabili e calcola un fattore di calibrazione. Se il tuo team ha storicamente sottostimato il lavoro di integrazione backend del 20%, applica quel fattore adesso, non a cose fatte.

5. Usa Monte Carlo se il destinatario ha bisogno di una curva di probabilità. Per il reporting di rischio a livello di consiglio di amministrazione o per un portafoglio di progetti, dai in pasto le distribuzioni delle singole attività a una Monte Carlo simulation per ottenere una curva di probabilità completa invece di tre punti statici.

6. Presenta intervallo, ipotesi e budget consigliato. Non consegnare mai un numero da solo. Il risultato dovrebbe sempre includere:

• L'intervallo P50/P70/P90 in tempo e costo

• Le ipotesi specifiche da cui dipende l'intervallo (perimetro, composizione del team, dipendenze da terze parti)

• Un prezzo contrattuale consigliato, fissato al P90 se l'incarico è a perimetro fisso

Questa sequenza richiede più tempo che tirare a indovinare, ma raramente supera uno o due giorni di lavoro complessivo anche su un progetto di media grandezza, ed è la differenza tra una stima che puoi difendere in una trattativa sul perimetro e una per cui ti tocca scusarti al terzo mese.

Come funzionano davvero le tecniche di stima

Ognuna delle tecniche qui sotto risolve un problema diverso. Confonderle, usare PERT quando serve un controllo rapido di buon senso oppure fidarsi di un modello parametrico senza dati di calibrazione, è l'origine reale della maggior parte delle stime fallite.

Stima bottom-up (WBS e story point)

La stima bottom-up scompone il progetto in singole attività o user story, stima ciascuna e somma i risultati. Per un preventivo a perimetro fisso è la spina dorsale: è l'unico metodo che ti permette di ricondurre il totale a specifici deliverable quando il cliente mette in discussione il numero.

Il procedimento: spezza il lavoro in attività abbastanza piccole perché una singola persona possa plausibilmente completarne una in un tempo che va da un giorno a una settimana. Stima ognuna direttamente in giorni di sviluppo oppure in story point, poi converti i punti in tempo usando la velocity effettiva del team, cioè la media di story point completati per sprint su una finestra mobile di tre-sei sprint.

Quando il lavoro assomiglia a qualcosa che il team ha già costruito, le stime bottom-up si collocano di solito entro circa il 15% dei consuntivi. Quando non è così, quella precisione crolla in fretta, ed è esattamente per questo che conta il passaggio di segnalazione dei moduli rischiosi descritto sopra. La stima bottom-up è precisa su ciò che conosce, ma non cattura l'incertezza dove manca la familiarità.

Stima top-down e per analogia

La stima per analogia confronta il nuovo progetto con uno o più progetti simili già conclusi e scala la stima di conseguenza. È rapida, di solito poche ore, e il suo unico vero compito è intercettare gli errori di ordine di grandezza prima che contagino una stima di dettaglio.

Qui scegliere buoni progetti di riferimento conta più di qualsiasi formula. Un progetto di riferimento deve coincidere per tipo di perimetro, stack tecnologico e composizione del team, non solo perché «anche quella era un'applicazione web». Due e-commerce con lo stesso numero di pagine possono differire di mesi se uno richiede una sincronizzazione di magazzino su misura e l'altro no.

Stima a tre punti (PERT)

PERT chiede tre numeri per ogni attività: ottimistico (O), più probabile (M) e pessimistico (P). Il expected value is calculated as (O + 4M + P) / 6, dando molto peso al caso più probabile ma tenendo comunque conto delle code. La deviazione standard è (P − O) / 6 e ti dice quanto è davvero ampia l'incertezza su quella specifica attività.

Applica PERT in modo selettivo. Usarlo su ogni singola attività del progetto aggiunge solo rumore, perché gli errori sulle attività ben comprese sono già piccoli e il valore vero di PERT emerge sulla manciata di moduli su cui nessuno è sicuro. Usalo sugli elementi rischiosi che hai segnalato al passo tre del percorso, poi somma quelle distribuzioni in un totale per quella parte del progetto.

Consiglio pratico: Chiedi ai tuoi tre stimatori O, M e P in modo indipendente, prima della discussione di gruppo. In una stanza l'ancoraggio scatta in fretta e, nel momento in cui uno sviluppatore senior pronuncia un numero ad alta voce, la stima «indipendente» di tutti gli altri scivola silenziosamente in quella direzione.

Planning poker e Wideband Delphi

Il planning poker fa stimare una story a un team interfunzionale contemporaneamente, usando carte (spesso su scala di Fibonacci: 1, 2, 3, 5, 8, 13), con rivelazione simultanea e poi discussione dei casi estremi finché non emerge un consenso. Wideband Delphi è l'antenato più vecchio e più formale: più round di stima anonima con discussione guidata da un facilitatore tra un round e l'altro.

Nessuna delle due tecniche riguarda davvero la matematica. Entrambe esistono per far emergere ipotesi nascoste. Quando uno sviluppatore backend stima una story a 3 punti e uno frontend stima la stessa story a 13, la discussione che segue rivela quasi sempre un disaccordo sul perimetro che nessuno aveva notato, non un errore di stima. È quello il risultato che vale la pena mettere per iscritto.

Modelli parametrici: COCOMO II, Function Point Analysis, COSMIC

I modelli parametrici ricavano una stima per via matematica a partire da input di dimensione e complessità. COCOMO II calcola i mesi/persona da righe di codice o function point, cost driver e fattori di scala; Function Point Analysis e COSMIC dimensionano il progetto contando input, output e strutture dati invece del volume di codice.

Questi modelli, per valere qualcosa, vanno calibrati sui tuoi progetti passati. Un coefficiente COCOMO II tarato sul reparto Java aziendale di qualcun altro dice pochissimo sul tuo team che costruisce un'app React Native, e il Software Engineering Institute is explicit that a cost model is only as good as the data used to calibrate it. I modelli parametrici si ripagano su lavori ripetibili di tipo enterprise, dove hai cinque o più progetti passati su cui calibrare. Sono poco adatti a un prodotto nuovo senza uno storico interno a cui attingere.

Simulazione Monte Carlo

Monte Carlo prende le distribuzioni che hai costruito con PERT (o i dati storici di varianza) ed esegue migliaia di scenari simulati, campionando dall'intervallo di probabilità di ogni attività e sommando ogni volta i risultati. Il risultato è una curva di probabilità completa: la percentuale di probabilità di chiudere entro un certo budget o una certa data, invece di tre punti di controllo statici.

Per uno strumento interno da quattro settimane è sproporzionato. Si giustifica quando un portafoglio di progetti richiede un reporting di rischio a livello di consiglio di amministrazione, oppure quando una singola offerta a prezzo fisso ad alto rischio ha bisogno di un'affermazione probabilistica difendibile, che vada oltre il «pensiamo che il P90 sia 20 settimane».

Un esempio concreto

Mettiamo che il rifacimento di un checkout abbia 40 attività WBS ben comprese e un elemento rischioso: l'integrazione di una nuova API antifrode con documentazione scarna. La stima bottom-up colloca le 40 attività note a 60 giorni di sviluppo. Lo storico di due integrazioni paragonabili dà un fattore di calibrazione di 1,15, che porta il totale a 69 giorni. Per l'API antifrode il team raccoglie O = 5, M = 10, P = 25 giorni. PERT dà un valore atteso di (5 + 40 + 25) / 6 ≈ 11,7 giorni e una deviazione standard di (25 − 5) / 6 ≈ 3,3 giorni. Il P50 totale si colloca intorno agli 81 giorni; il P90, tenendo conto dell'ampia dispersione di quel modulo, si avvicina agli 88-90 giorni. È questo il numero che finisce in un preventivo a prezzo fisso.

Quando conviene davvero produrre una stima

La stima non è un evento unico al lancio del progetto. È un'attività ricorrente che diventa più precisa man mano che l'incertezza si scioglie, e presentare una stima vecchia come se fosse attuale è uno dei modi più rapidi per perdere la fiducia degli stakeholder.

1. Al primo contatto, produci una stima di massima (rough order of magnitude, ROM). Una stima top-down per analogia, fatta in poche ore, dà a un potenziale cliente abbastanza elementi per decidere se passare alla fase di discovery. Questo non è in alcun modo un preventivo.

2. Dopo la discovery, produci una stima bottom-up di dettaglio. Una volta documentati perimetro, integrazioni e vincoli tecnici, una stima basata sulla WBS con PERT sui moduli rischiosi ti dà l'intervallo su cui negozierai davvero.

3. Prima di un'offerta a prezzo fisso, quota al P90. Tutto ciò che viene proposto a compenso fisso va messo a budget sul novantesimo percentile della tua distribuzione, non sul valore centrale. Il P50 resta interno come aspettativa di lavoro; il cliente vede il numero che protegge la consegna.

4. Da lì in avanti, rivedi la previsione a cadenza fissa. Rifai la previsione dopo l'approvazione del design, a ogni tappa importante e ogni volta che le variazioni di perimetro superano una soglia prestabilita, spesso il 10-15% della stima iniziale.

Il cono dell'incertezza di Barry Boehm è il modo classico per spiegare questa progressione a uno stakeholder infastidito dal fatto che un numero iniziale si sia spostato. La precisione delle stime si restringe in modo prevedibile con l'avanzare del progetto: una stima iniziale può sbagliare di un fattore quattro in entrambe le direzioni, mentre una stima fatta dopo il design di dettaglio rientra tipicamente entro il 20% circa. Fissare questa aspettativa all'inizio, per iscritto, prima ancora che venga quotato il primo numero, trasforma il «la vostra stima è cambiata» da problema di credibilità a parte prevista del processo.

Perché le stime sbagliano: gli errori che nessuno mette a budget

Quasi mai una stima sbagliata nasce da conti sbagliati. Nasce da errori psicologici e organizzativi prevedibili, che si presentano a prescindere da quanto è bravo il team.

La fallacia della pianificazione colpisce tutti, ingegneri senior compresi. Le persone stimano il proprio lavoro futuro in modo ottimistico anche quando sanno, razionalmente, che lavori simili in passato sono andati lunghi. La fallacia della pianificazione resiste a ogni livello di esperienza, ed è esattamente per questo che esiste la previsione per classi di riferimento, cioè ancorare la stima ai risultati reali di progetti passati paragonabili. L'intuizione da sola non corregge questo bias. I dati esterni sì.

L'intuizione del team sulla difficoltà di un progetto è uno degli input meno affidabili a disposizione, proprio perché tutti sono immersi nello stesso ottimismo nello stesso momento.

L'ancoraggio sotto pressione degli stakeholder riplasma il numero senza che te ne accorga. Quando uno sponsor dice «speravamo in otto settimane» prima che il team abbia stimato alcunché, quella cifra ancora ogni discussione successiva anche se non ha alcun fondamento nel perimetro reale. La soluzione è procedurale: raccogli stime indipendenti prima che in sala venga pronunciato un qualsiasi numero obiettivo.

L'impegno per integrazione e verifica viene quasi sempre sottostimato. I team stimano con cura il lavoro sulle funzionalità e poi dimenticano che collegare tre sistemi, scrivere i test e sistemare ciò che si rompe quando vengono messi insieme costa spesso quanto costruire le funzionalità stesse.

Gli story point vengono trattati come se avessero un significato universale. Uno story point non è un'unità di tempo, è un'unità di dimensione relativa specifica della velocity di un singolo team. Confrontare stime in story point tra team diversi, o dare per scontato che «un 5 vale sempre circa due giorni», è un uso improprio molto diffuso che corrompe silenziosamente le previsioni. È il cuore del dibattito tra story point e ore: i punti sono utili a un team stabile che monitora la propria velocity, ma non si traducono direttamente in un impegno di tempo verso il cliente senza la calibrazione specifica di quel team.

• Fallacia della pianificazione e ancoraggio distorcono sia il giudizio di chi stima sia la trattativa che ne segue.

• Integrazione, test e rilavorazione sono le categorie più spesso sottostimate in una WBS.

• I coefficienti parametrici presi dal set di calibrazione di qualcun altro producono stime che sembrano precise e sono silenziosamente sbagliate.

• Confondere «stima» e «impegno» elimina lo spazio di trattativa che un intervallo dovrebbe garantire.

Il rimedio strutturale più efficace per tutti e quattro i casi è separare per iscritto la stima dall'impegno, esplicitare ogni ipotesi da cui dipende l'intervallo e non lasciare mai che la data sperata da uno sponsor prenda il posto di una data calcolata.

Come rendere le stime più precise

La precisione non dipende dal trovare una formula migliore. Dipende dal dare dati migliori alla formula che già usi, e dal farlo con abbastanza costanza perché quei dati si accumulino nel tempo.

1. Costruisci un set di dati per classi di riferimento. Raccogli consuntivi rispetto a stime dei tuoi progetti passati, etichettati per tipo di perimetro, tecnologia e maturità del team. Un set utilizzabile richiede almeno tre-cinque progetti conclusi paragonabili prima che il fattore di calibrazione che produce sia degno di fiducia.

2. Calcola e conserva un fattore di calibrazione per ogni categoria di progetto. Se lo sviluppo di app mobili ha storicamente superato del 25% la stima bottom-up mentre i gestionali interni sono andati perfettamente in linea, quel fattore va applicato in automatico la volta successiva che arriva un progetto simile.

3. Combina i metodi in modo consapevole invece di sceglierne uno. Comparative reviews of estimation techniques consistently find that hybrid approaches, mixing algorithmic and expert-based methods, outperform any single technique used alone. Usa il top-down come controllo di buon senso, il bottom-up per la tracciabilità, PERT sugli elementi rischiosi e Monte Carlo quando al destinatario serve una curva di probabilità.

4. Presenta sempre P50/P70/P90, mai una cifra sola, con le ipotesi esplicitate. Presentare un intervallo calibrato con ipotesi esplicite rende l'errore visibile e delimitato, invece che nascosto e cumulativo una volta che il progetto è partito. Quota le offerte a prezzo fisso al P90; usa la formula a consumo con controlli regolari quando il cliente può accettare più flessibilità in cambio di un tetto più basso.

5. Monitora stima e consuntivo su ogni progetto e riporta il dato nella calibrazione. Una retrospettiva che non viene registrata da nessuna parte non insegna nulla all'organizzazione. Un registro condiviso ed etichettato dei dati stima/consuntivo è ciò che trasforma il «ci sembra di stare migliorando» in un numero che puoi davvero mostrare a un cliente.

Consiglio pratico: Etichetta ogni progetto concluso per tipo di perimetro il giorno stesso della chiusura, non sei mesi dopo quando a qualcuno servono i dati per una nuova offerta. La memoria delle stime si deteriora in fretta e i dettagli che contano, quale modulo è andato lungo e perché, diventano sfocati nel giro di poche settimane.

La comparative literature on effort estimation models conferma lo stesso schema da un'altra angolazione: i modelli algoritmici sono forti sul lavoro ripetibile e ben documentato, il giudizio esperto è forte sul lavoro nuovo o ambiguo, e nessuno dei due vince su tutti i tipi di progetto. Gli approcci ibridi e calibrati danno risultati costantemente migliori di un singolo metodo usato da solo.

Quali dati e strumenti servono davvero per stimare meglio

Le tecniche viste sopra valgono quanto i dati che le alimentano, e quasi tutti i team investono troppo poco proprio su questo. Non serve un software aziendale per rimediare. Serve l'abitudine di registrare i numeri giusti con costanza.

I dati essenziali da raccogliere su ogni progetto:

• Durata e costo a consuntivo rispetto alla stima, distinti per modulo o pacchetto di lavoro

• Velocity sprint per sprint per i team agili, monitorata su una finestra mobile e non su un singolo sprint

• Tassi di difetti e di rilavorazione, perché la rilavorazione è una delle voci di costo più regolarmente sottostimate

• Numero di interfacce e integrazioni, che ha una forte correlazione con il rischio sui tempi nei progetti multi-sistema

Modelli leggeri coprono quasi tutto ciò che serve a un team di media grandezza: un semplice foglio di dimensionamento in stile FPA per la definizione iniziale del perimetro, una tabella di calibrazione dei giorni di sviluppo per story point aggiornata ogni trimestre, un foglio standard di input PERT con le colonne O/M/P per ogni attività rischiosa e un impianto Monte Carlo di base costruito in un foglio di calcolo con un componente aggiuntivo per la generazione di numeri casuali.

Quasi tutti i team possono gestire l'intero processo in un foglio di calcolo, più un componente aggiuntivo di scripting per il campionamento Monte Carlo, ben oltre il punto in cui ti aspetteresti di aver bisogno di un software dedicato. Passa a uno strumento più pesante di stima o di previsione di portafoglio solo quando esegui simulazioni su più progetti in parallelo e ti servono dati condivisi e verificabili, invece di un foglio di calcolo che gira per e-mail.

La qualità dei dati migliora grazie a tre abitudini più che a qualsiasi scelta di strumento: etichetta ogni progetto per tipo e tecnologia alla chiusura, registra le ipotesi dietro ogni stima nel momento in cui la fai invece di ricostruirle dopo, e conserva le metriche anonimizzate abbastanza a lungo da costruire la classe di riferimento di tre-cinque progetti che la calibrazione richiede davvero.

Come Ampersand Labs trasforma la discovery in un intervallo difendibile

Il coinvolgimento di persone senior fin dalla prima conversazione è ciò che mantiene onesta una stima. Quando chi definisce il perimetro del progetto è la stessa persona che ne risponderà in consegna, e resta coinvolta fino al passaggio di consegne, lo scarto tra ciò che è stato quotato e ciò che è stato costruito rimane piccolo. Quella continuità è anche ciò che accorcia la discovery stessa, perché un ingegnere senior individua il modulo rischioso già nella prima sessione di lavoro e non tre sprint dopo.

Un tipico percorso di stima per la realizzazione di un MVP si svolge così:

• Prima la discovery. Conversazioni strutturate e revisione tecnica per definire perimetro, integrazioni e vincoli prima che venga messo per iscritto un qualsiasi numero.

• Poi il bottom-up calibrato. Una stima basata sulla WBS, corretta sullo storico di Ampersand relativo a MVP e progetti web e mobile paragonabili.

• PERT sui moduli che portano rischio davvero. Integrazioni con terze parti, migrazioni di dati o qualsiasi cosa realmente nuova ricevono un trattamento a tre punti invece di una stima a occhio.

• Un intervallo, non un numero. I clienti ricevono P50/P70/P90 con le ipotesi specifiche da cui dipende l'intervallo, così una variazione di perimetro più avanti ha un costo chiaro e tracciabile.

Il lavoro svolto per realtà come UBS e la Città di Lugano riflette l'ampiezza dei perimetri che Ampersand Labs stima, dalle integrazioni enterprise fortemente regolamentate agli MVP di startup che si muovono in fretta. I casi studio sui progetti consegnati, tra cui una piattaforma che gestisce oltre 600 siti web per un partito politico svizzero e un sistema di gestione del portafoglio immobiliare realizzato per Repa Immobiliare, mostrano come questo percorso dalla discovery alla consegna funzioni su incarichi reali.

Lo scostamento viene monitorato anche dietro le quinte: il tempo di consegna effettivo rispetto all'intervallo quotato all'inizio alimenta il fattore di calibrazione applicato al progetto paragonabile successivo. È il set di dati per classi di riferimento descritto prima, costruito sullo storico dei progetti di Ampersand Labs e non su un parametro di settore generico, e applicato ogni volta che si prepara un nuovo preventivo.

Chiedi una stima calibrata prima di impegnarti su una scadenza

Ampersand Labs è l'alternativa al preventivo della classica agenzia per i team che hanno bisogno di un numero difendibile davanti a un consiglio di amministrazione o a un investitore, non di una cifra approssimativa che si dilata silenziosamente dopo tre mesi. Poiché sono gli ingegneri senior a condurre la discovery in prima persona, invece di affidare la definizione del perimetro a uno stimatore junior, l'intervallo che ricevi riflette un giudizio tecnico sulle tue integrazioni specifiche e sui tuoi moduli rischiosi, non un modello moltiplicato per il numero di persone.

Se stai valutando un MVP o lo sviluppo di un'app web e mobile, il passo successivo è una conversazione di discovery, non un preventivo al buio. Ampersand Labs può esaminare il tuo perimetro, segnalare i due o tre moduli che portano incertezza reale e consegnarti un intervallo P50/P70/P90 con le ipotesi messe nero su bianco. Se stai ancora confrontando modelli di collaborazione, la pagina dei prezzi spiega come sono strutturati il lavoro a perimetro fisso e quello di consulenza, ancora prima di una telefonata.

Fonti

• Software Engineering Institute is explicit that a cost model is only as good as the data used to calibrate it

• comparative literature on effort estimation models

• Comparative reviews of estimation techniques consistently find that hybrid approaches, mixing algorithmic and expert-based methods, outperform any single technique used alone

• velocity

Domande frequenti

Quali strumenti si usano per stimare un progetto software?

Quasi tutti i team partono da fogli di calcolo costruiti attorno a una struttura di scomposizione del lavoro, con colonne di input PERT e un componente aggiuntivo per la simulazione Monte Carlo, perché così coprono le tecniche di stima fondamentali senza costi di gestione aggiuntivi. Le organizzazioni più grandi che usano calibrazioni COCOMO II o Function Point Analysis adottano talvolta software parametrici dedicati, una volta che hanno abbastanza dati storici da giustificarli. Lo strumento conta molto meno dei dati di calibrazione che ci stanno dietro.

Come si stima il costo di un progetto software?

Parti da un controllo top-down per analogia con progetti simili già conclusi, per intercettare gli errori di ordine di grandezza, poi costruisci una stima bottom-up di dettaglio a partire da una struttura di scomposizione del lavoro per il perimetro confermato. Applica la stima a tre punti (PERT) ai moduli più rischiosi, da uno a tre, calibra il totale sui dati storici di stima e consuntivo del tuo team e presenta il risultato come intervallo P50/P70/P90 invece che come cifra secca.

Come si stimano i tempi di un progetto software?

Scomponi il progetto in attività abbastanza piccole da poter essere stimate singolarmente, poi stima direttamente in giorni di sviluppo oppure usa gli story point convertiti attraverso la velocity effettiva del tuo team, cioè la media dei punti completati per sprint su una finestra mobile. Per le attività più rischiose raccogli una stima ottimistica, una più probabile e una pessimistica e passale nella formula PERT, invece di tirare a indovinare un numero solo.

Che cosa sono le stime software?

Una stima software è una previsione dell'impegno, del tempo, del costo e del rischio necessari per costruire un software, espressa come intervallo con livello di confidenza invece che come numero fisso. Viene affinata in diversi momenti della vita di un progetto: si parte da una stima di massima al primo contatto e si arriva a un intervallo di dettaglio e calibrato una volta completati discovery e design.

Meglio stimare in story point o in ore?

Gli story point funzionano bene per un team stabile che monitora la propria velocity sprint dopo sprint, perché misurano la dimensione relativa e non il tempo assoluto e si adattano da soli quando cambia il ritmo del team. Le ore o i giorni di sviluppo vanno meglio quando ti serve un impegno verso il cliente o quando confronti stime tra team diversi, perché il significato di uno story point non è standardizzato fuori dal team che lo ha assegnato.

Da leggere

• Servizi di ingegneria del software, studio di Zurigo

• CTO ad interim a Zurigo, responsabile tecnico frazionale e part-time

• Manutenzione software a Zurigo, assistenza mensile

• Sviluppo di MVP, app web e mobile a Zurigo