Stima del progetto software: guida pratica per i PM
Stima del progetto software: guida pratica per i PM Combina il dimensionamento relativo (planning poker o taglie di maglietta) per la pianificazione iniziale con una stima bottom-up calibrata per l'ambito impegnato.
Stima del progetto software: guida pratica per i PM
Combina il dimensionamento relativo (planning poker o taglie di maglietta) per la pianificazione iniziale con una stima bottom-up calibrata per l'ambito impegnato. Questa combinazione ti offre il miglior compromesso tra velocità e difendibilità in ogni fase del ciclo di vita del progetto. Prima di presentare alle parti interessate, produci questi cinque output: un intervallo di sforzo 50/90, un totale in mesi-persona, la tua tariffa oraria media presunta, una percentuale di contingenza e un registro delle assunzioni scritto.
Quando usare quale approccio:
- Dimensionamento relativo ora: fase di concept, pre-proposta, grooming del backlog o qualsiasi momento in cui i requisiti sono ancora in evoluzione
- Stima bottom-up: ambito impegnato con criteri di accettazione definiti, offerte a prezzo fisso o appalti regolatori/governativi
- Entrambi in parallelo: programmi di grandi dimensioni, modernizzazione di sistemi legacy o qualsiasi impegno in cui la banda di errore di un singolo metodo è troppo ampia per essere difesa
Punti chiave
Una stima affidabile del progetto software richiede di abbinare il dimensionamento relativo per la pianificazione iniziale con un controllo bottom-up calibrato per l'ambito impegnato, sempre riportato come intervallo 50/90 con assunzioni esplicite.
| Punto | Dettagli |
|---|---|
| Abbina il metodo alla fase del ciclo di vita | Usa il dimensionamento relativo (taglie di maglietta, story point) all'inizio; passa alla WBS bottom-up per l'ambito impegnato e le offerte a prezzo fisso. |
| Riporta sempre un intervallo | Presenta il 50° percentile per la pianificazione e il 90° percentile per il finanziamento; le stime a punto singolo creano una falsa precisione. |
| Il registro delle assunzioni è non negoziabile | Documenta i confini dell'ambito, la composizione del team e la volatilità prima di dimensionare qualsiasi cosa; questo registro è la tua traccia di audit. |
| Calibra prima di impegnarti | La velocità, il costo per punto e gli analoghi storici sono gli input che separano una stima difendibile da una congettura. |
| Ridiculous Engineering | Gli impegni di scoping di Ridiculous Engineering producono un registro delle assunzioni condiviso e un intervallo 50/90 prima che venga concordato qualsiasi lavoro a prezzo fisso. |
Sommario
- Perché stime software accurate contano per le decisioni aziendali
- Quando dovresti eseguire stime lungo il ciclo di vita del progetto?
- Quali sono i metodi di stima software più comuni?
- Come si esegue un processo di stima passo dopo passo?
- Come si modella l'incertezza in una stima software?
- Quali errori e pregiudizi di stima dovresti tenere d'occhio?
- Quali strumenti e metriche ti aiutano a stimare in modo più affidabile?
- Quando dovresti stimare internamente vs. portare una consulenza?
- Esempio pratico: stima di una release a tre epic end-to-end
- Ridiculous Engineering ti aiuta a costruire stime che puoi difendere
- Fonti
- FAQ
Perché stime software accurate contano per le decisioni aziendali
Una stima non è un'ipotesi travestita da foglio di calcolo. È l'input primario per tre decisioni che determinano il successo di un progetto: prioritizzazione dell'ambito, approvazione del budget e piani di assegnazione delle risorse. Sbagliarla in entrambe le direzioni ha conseguenze concrete: i progetti sottofinanziati vengono ridimensionati a metà consegna, quelli sovrafinanziati sprecano capitale che avrebbe potuto essere destinato altrove, e gli stakeholder disallineati perdono fiducia nel team molto prima che il codice venga rilasciato.
Il SEI della Carnegie Mellon inquadra la stima dei costi software come uno strumento per decidere l'accessibilità economica e prioritizzare l'ambito, con metriche di dimensione e fattori di costo che lavorano insieme per spiegare la variazione. Questa impostazione è importante perché posiziona la stima come una disciplina di supporto alle decisioni, non come un esercizio di pianificazione. Quando i team la trattano in questo modo, le stime diventano artefatti viventi che informano le conversazioni di compromesso, piuttosto che impegni fissi che perseguitano le retrospettive.
Le stime scadenti si accumulano anche. Per i product owner, ciò significa elementi della roadmap rimandati. Per i project manager, significa conversazioni difficili che sarebbero state evitate con un processo migliore a monte.
Quando dovresti eseguire stime lungo il ciclo di vita del progetto?
La stima non è un evento una tantum. La fedeltà che puoi ragionevolmente ottenere cambia man mano che i requisiti maturano, e il metodo che usi dovrebbe cambiare con essa. La guida del PMI sulla stima dei progetti Agile descrive questo come pianificazione a ondate: inizia con stime top-down di livello generale, poi elabora progressivamente man mano che impari di più.
-
Concetto / fattibilità (banda di errore: ±50–100%). Gli input sono una dichiarazione del problema e un elenco approssimativo di funzionalità. Usa la stima analogica o il dimensionamento a taglie di maglietta. L'output è un intervallo di ordine di grandezza approssimativo per decidere se finanziare la scoperta.
-
Proposta / budget (banda di errore: ±25–50%). Gli input sono un documento di ambito ad alto livello e eventuali analoghi disponibili. Usa modelli parametrici o raggruppamento per affinità. L'output è un intervallo di budget con assunzioni esplicite per la richiesta di finanziamento.
-
Pianificazione del rilascio (banda di errore: ±10–25%). Gli input sono un backlog prioritizzato con criteri di accettazione. Usa story point con calibrazione della velocità o una WBS bottom-up. L'output è una previsione di rilascio con un intervallo 50/90.
-
Pianificazione dello sprint / iterazione (banda di errore: ±5–15%). Gli input sono user story perfezionate con criteri di accettazione chiari. Usa stime orarie a livello di attività o story point rispetto alla velocità nota. L'output è un impegno di sprint.
-
Trigger di ristima. Ristima quando: le modifiche all'ambito superano il 15–20% della baseline originale; uno spike tecnico rivela un'architettura fondamentalmente diversa; una dipendenza chiave si sposta; o la velocità effettiva si discosta dalla previsione per più di due sprint consecutivi.
Le bande di errore sopra sono intervalli pratici, non garanzie. Riflettono la realtà che l'incertezza si riduce man mano che i requisiti si stabilizzano, non con l'avanzare del calendario.
Quali sono i metodi di stima software più comuni?
Nessuna tecnica singola funziona per ogni progetto. La ricerca che esamina gli approcci di stima rileva costantemente che combinare più metodi e confrontare i risultati produce migliori intuizioni che affidarsi a uno solo. La tabella seguente mappa ogni metodo ai suoi input, accuratezza attesa e contesto più adatto.
| Metodo | Input richiesti | Accuratezza attesa | Tipi di progetto più adatti | Requisiti di dati |
|---|---|---|---|---|
| Top-down / analogico | Dati storici di progetto, ambito ad alto livello | ±25–50% | Fase iniziale, fattibilità, pre-proposta | Registri di progetti passati |
| Bottom-up (basato su WBS) | Attività scomposte, criteri di accettazione | ±5–15% | Ambito impegnato, offerte a prezzo fisso | Requisiti dettagliati |
| Parametrico (COCOMO II) | Dimensioni in KSLOC o function point, fattori di costo | ±10–25% (calibrato) | Programmi di grandi dimensioni, appalti governativi | Dati di calibrazione organizzativa |
| Giudizio esperto / Wideband Delphi | Esperti di dominio, processo di consenso strutturato | ±20–40% | Tecnologia innovativa, nessun dato storico | Disponibilità di esperti |
| Planning poker / story points | Elementi di riferimento relativi, consenso del team | Solo relativo | Team agili, dimensionamento del backlog | Cronologia della velocità per le previsioni |
| Function point | Requisiti funzionali, flussi di dati | ±10–25% | Lavoro incentrato sui requisiti, contrattuale | Specifica funzionale |
| Righe di codice (LOC) | Codebase esistente o norme specifiche del linguaggio | ±25–50% | Solo dopo la revisione dell'architettura | Benchmark di codice o linguaggio |
Alcune note sui metodi più spesso usati in modo errato:
Story points misurano sforzo, complessità e rischio, non tempo. La guida alla stima di Atlassian è diretta su questo: convertire i punti in ore di solito segnala una decomposizione insufficiente o una pressione organizzativa che distorcerà la stima. Usa i punti per dimensionamento relativo e previsioni basate sulla velocità; converti in date solo dopo aver considerato capacità e dipendenze.
LOC è una metrica debole nelle fasi iniziali perché può essere osservata solo dopo che il codice è scritto. La panoramica di GeeksforGeeks sulle tecniche di stima delle dimensioni nota che LOC, function point, use-case point e conteggi di entità/processi hanno ciascuno diverse finestre di applicabilità. LOC è più utile per la calibrazione post-architettura, non per la pianificazione pre-sviluppo.
COCOMO II produce sforzo in mesi-persona usando dimensioni (KSLOC o function point), fattori di scala e moltiplicatori di sforzo nei modelli Early Design e Post-Architecture. Il manuale COCOMO II è esplicito: il modello richiede calibrazione sui dati organizzativi per produrre risultati accurati. Una esecuzione COCOMO II non calibrata è un punto di partenza, non un risultato finale.
Per programmi ad alto rischio, esegui almeno due metodi complementari, come un modello parametrico insieme a una WBS bottom-up, e tratta divergenze significative come segnali per indagare su ambito, assunzioni o qualità dei dati.
Come si esegue un processo di stima passo-passo?
La sequenza è: Scomponi → Dimensiona → Calibra → Aggrega → Quantifica l'incertezza → Convalida. Ogni passaggio produce un artefatto. Salta un passaggio e perdi la traccia di audit che rende una stima difendibile.
-
Definisci ambito e presupposti. Scrivi un registro dei presupposti prima di dimensionare qualsiasi cosa. Documenta cosa è in ambito, cosa è esplicitamente fuori, quali interfacce si presume esistano e quale composizione del team stai assumendo. Questo registro è l'artefatto più importante dell'intero processo.
-
Scegli la metrica di dimensionamento. Story point per il dimensionamento relativo Agile; function point o KSLOC per modelli parametrici; ore attività per la WBS bottom-up. Abbina la metrica al metodo e alla fase del ciclo di vita.
-
Scomponi il lavoro. Costruisci una work breakdown structure (WBS) o una gerarchia feature/epic/storia. Per i team Agile, questo è il backlog. Per lavoro waterfall o a prezzo fisso, è una WBS formale. La guida Agile di PMI descrive questo come elaborazione progressiva: prima epic di alto livello, poi storie, poi attività man mano che i requisiti maturano.
-
Dimensiona ogni elemento. Usa il planning poker per gli story point, o stime a livello di attività per il lavoro bottom-up. La guida alla stima Agile di Wrike consiglia di ancorare le stime a elementi di riferimento consegnati, il che impedisce al team di dimensionare nel vuoto. Se il team dibatte i dettagli di implementazione per più di qualche minuto su un singolo elemento, quell'elemento necessita di uno spike o di un'ulteriore scomposizione, non di un dibattito più lungo.
-
Applica fattori di costo e calibrazione. Regola le stime di dimensione grezze per esperienza del team, novità tecnologica, volatilità dei requisiti e complessità di integrazione. Per i modelli parametrici, questi sono moltiplicatori di sforzo formali. Per le stime bottom-up, applica un fattore di calibrazione derivato dalla tua velocità storica o dai dati effettivi di progetti passati.
-
Aggrega e converti in costo. Somma lo sforzo attraverso la WBS o il backlog. Converti le ore-persona in dollari usando la tua tariffa oraria mista (completamente caricata, inclusi benefit e overhead). Aggiungi contingenza (tipicamente 15–25% per ambito ben definito, 25–40% per lavoro ad alta incertezza).
-
Quantifica l'incertezza e convalida. Applica la stima a tre punti o una simulazione Monte Carlo per produrre un intervallo. Controlla incrociato con eventuali analoghi storici. Se la stima diverge significativamente dagli analoghi, indaga prima di presentare.
Suggerimento Pro: Conduci workshop di stima in un unico timebox di 60–90 minuti. Assegna un facilitatore il cui compito è mantenere il team a dimensionare, non a dibattere l'architettura. Usa tre elementi di riferimento all'inizio (uno piccolo, uno medio, uno grande) per calibrare la scala del team prima di toccare il backlog. I team che saltano questo passaggio di calibrazione producono regolarmente dimensioni incoerenti tra le sessioni.
Come modelli l'incertezza in una stima software?
Riporta sempre un intervallo e un percentile di confidenza, non un singolo numero. Una stima a punto singolo comunica falsa precisione e prepara il team a una conversazione sul perché il progetto è "in ritardo" quando atterra ovunque al di fuori di quel numero.
La stima a tre punti (PERT) è il punto di partenza pratico. Per ogni attività o elemento di lavoro, cattura tre stime: ottimistica (O), più probabile (M) e pessimistica (P). Il valore atteso PERT è calcolato come (O + 4M + P) / 6. La deviazione standard è (P - O) / 6. Aggrega queste attraverso la WBS per ottenere una distribuzione per la stima totale.
Il framework dei percentili 50/90 è il modo più utile per comunicare quella distribuzione agli stakeholder. Il 50° percentile (mediana) è l'esito che ti aspetti circa la metà delle volte sotto le assunzioni correnti. Il 90° percentile è il budget o la pianificazione di cui hai bisogno per essere fiducioso di non sforare. Usa il 50° percentile per la pianificazione interna e il 90° percentile per richieste di finanziamento e contratti a prezzo fisso.
Simulazione Monte Carlo porta questo oltre eseguendo migliaia di iterazioni attraverso la distribuzione completa delle stime delle attività e producendo una curva di probabilità per il totale. Puoi eseguire una Monte Carlo di base in un foglio di calcolo usando campionamento casuale da distribuzioni triangolari (O, M, P) per ogni attività. L'output ti dice non solo la mediana e il 90° percentile, ma la forma del rischio: una lunga coda a destra significa che poche attività portano la maggior parte del rischio di pianificazione.
Richiamo statistico: Il framework di stima dei costi software del SEI richiede esplicitamente analisi di incertezza e rischio man mano che i requisiti maturano, perché le stime in fase iniziale portano un'incertezza irriducibile che nessuna quantità di pianificazione può eliminare.
Suggerimento Pro: Usa il 90° percentile per qualsiasi impegno preso con finanza, dirigenti o clienti. Usa il 50° percentile per la pianificazione interna di sprint e release. Presentare entrambi nella stessa diapositiva, con un'etichetta chiara su ciascuno, è il modo più veloce per costruire fiducia degli stakeholder nel tuo processo di stima.
Quali errori di stima e bias dovresti osservare?
Il più grande anti-pattern nella stima di progetti software è trattare una stima come una promessa. Nel momento in cui un numero diventa un impegno, il team smette di aggiornarlo man mano che impara di più, e il divario tra stima e realtà si allarga silenziosamente fino a diventare una crisi. La soluzione è strutturale: presenta sempre stime come intervalli con presupposti espliciti e stabilisci una cadenza di ristima dall'inizio.
Oltre a quel fallimento strutturale, questi sono i bias e gli errori che appaiono più prevedibilmente:
- Ancoraggio. Il primo numero menzionato in una sessione di stima diventa il centro gravitazionale per tutte le stime successive. Mitigazione: usa la stima cieca (tutti scrivono il loro numero simultaneamente, come nel planning poker) prima che qualsiasi numero sia pronunciato ad alta voce.
- Bias di ottimismo. I team sottostimano costantemente la durata e sovrastimano la propria produttività. Mitigazione: applica la previsione a classe di riferimento confrontando il progetto corrente con gli esiti effettivi di progetti simili passati, non con le stime originali di quei progetti.
- Mescolare story point con ore.I punti della storia sono uno strumento di dimensionamento relativo. La guida alla stima Agile di Wrike è chiara: la stima è dimensionamento, non pianificazione. Convertire i punti in ore per qualsiasi cosa oltre ai controlli di capacità a breve termine introduce una falsa precisione e erode la fiducia del team nel processo.
- Stima per procura.Lasciare che una persona stimi per conto dell'intero team, o accettare la stima di un fornitore senza revisione indipendente, rimuove la conoscenza distribuita che rende accurate le stime. Richiedi che le persone che fanno il lavoro dimensionino il lavoro.
- Scope creep senza ristima.Aggiungere funzionalità senza adeguare la stima è il modo in cui i progetti raddoppiano di dimensioni mentre il budget rimane fisso. Stabilisci una soglia (tipicamente variazione dello scope del 15–20%) che attiva una ristima formale.
Per offerte di fornitori e contratti a prezzo fisso, una breve checklist di mitigazione: richiedi al fornitore di documentare tutte le assunzioni per iscritto; chiedi dati di calibrazione storici o progetti di riferimento; e commissiona una stima indipendente per qualsiasi impegno superiore alla soglia di materialità della tua organizzazione.I progetti di modernizzazione legacy sono particolarmente inclini a complessità nascosta che emerge solo dopo l'inizio del lavoro, rendendo la revisione indipendente particolarmente preziosa.
Quali strumenti e metriche ti aiutano a stimare in modo più affidabile?
Per i team Agile, standardizza prima su due metriche: velocità (punti della storia consegnati per sprint) e costo per punto (costo totale dello sprint diviso per i punti consegnati). Tutto il resto si basa su questi due numeri. Per programmi di grandi dimensioni che utilizzano modelli parametrici, la priorità è un modello COCOMO II calibrato con almeno tre-cinque progetti passati nel set di dati di calibrazione.
Gli intervalli di benchmark sopra sono punti di riferimento, non obiettivi. Calibra rispetto alla storia del tuo team prima di utilizzare qualsiasi benchmark esterno.
Modelli che vale la pena mantenere:
- Registro delle assunzioni: un documento vivo aggiornato a ogni evento di ristima
- Foglio di calibrazione storica: sforzo effettivo vs. stimato per progetti passati, organizzato per tipo di progetto e composizione del team
- Foglio di calcolo PERT/Monte Carlo: input a tre punti per ogni elemento WBS, aggregati in una distribuzione totale
- Tracker della velocità: velocità sprint per sprint con note su anomalie (cambi di team, ferie, picchi di scope)
COCOMO II vale la pena adottarlo quando la tua organizzazione gestisce più programmi di grandi dimensioni (tipicamente oltre 50.000 righe di codice o equivalenti punti funzione) e ha i dati storici per calibrarlo. Lo sforzo di calibrazione è reale: aspettati da due a quattro settimane di raccolta dati e adattamento del modello per una calibrazione iniziale, con aggiornamenti continui man mano che nuovi progetti vengono completati. Per team più piccoli o lavoro in fase iniziale, un tracker di velocità ben mantenuto e un foglio di calibrazione ti serviranno meglio di un modello parametrico non calibrato. Il framework Agile Advantage spiega perché il dimensionamento relativo e le previsioni basate sulla velocità tendono a superare le stime parametriche puntuali per la consegna iterativa.
Quando dovresti stimare internamente vs. portare una consulenza?
Per scope sotto i tre sprint con un backlog stabile e un team che ha consegnato lavoro simile in precedenza, la stima interna è la scelta giusta. Per lavoro di grandi dimensioni, cross-team, ad alto rischio o di modernizzazione legacy, una consulenza esterna aggiunge valore portando dati di calibrazione, revisione indipendente e metodi di stima che il team interno potrebbe non aver usato prima.
Prima di coinvolgere un fornitore o richiedere un preventivo a prezzo fisso, raccogli questo pacchetto di evidenze:
- Criteri di accettazione scritti per ogni funzionalità in scope
- Specifiche di interfaccia per tutti i sistemi esterni a cui il software deve connettersi
- Almeno due analoghi storici (progetti passati di tipo e dimensioni simili) con dati di sforzo effettivi
- Un registro dei rischi che copra rischi tecnici, organizzativi e di dipendenza
- Risultati di eventuali spike tecnici eseguiti per risolvere incognite architetturali
- Un'ipotesi di composizione del team (ruoli, seniority, full-time vs. part-time)
- Una valutazione della volatilità dei requisiti (quanto è probabile che lo scope cambi e in quali aree)
Flusso decisionale:
- Hai velocità storica e un backlog stabile: esegui una stima bottom-up basata sulla velocità internamente.
- Hai molte incognite o tecnologia innovativa: esegui prima uno spike, poi ristima utilizzando i risultati dello spike come input.
- Stai preparando un contratto a prezzo fisso o una gara d'appalto governativa: utilizza almeno due metodi complementari e considera una revisione indipendente.
- Stai modernizzando sistemi legacy o integrando su più piattaforme: il rischio di complessità nascosta è abbastanza alto che il supporto di consulenza sulla stima stessa spesso vale il costo.
Consiglio da professionista: Quando negozi un impegno a prezzo fisso, condividi il tuo registro delle assunzioni con il fornitore e chiedi di confermare o correggere ogni assunzione per iscritto. Le divergenze tra le tue assunzioni e le loro sono il predittore più affidabile delle variazioni d'ordine. Risolverle prima della firma è più economico che risolverle durante la consegna.
Ridiculous Engineering consulenza software e supporto alla consegna gli impegni iniziano tipicamente con una sessione di scoping che produce un registro delle assunzioni condiviso e un intervallo 50/90 prima che venga concordato qualsiasi lavoro a prezzo fisso. Questo processo protegge entrambe le parti.
Esempio pratico: stima di un rilascio con tre epic end-to-end
Questo esempio fornisce un intervallo di sforzo 50/90, un totale in mesi-persona e una conversione in dollari per un rilascio di applicazione web di medie dimensioni. Tutti i numeri sono illustrativi; calibra sui dati del tuo team.
Input e assunzioni:
- Tre epic: autenticazione utente (Epic A, per lo più pattern riutilizzati), dashboard di reporting (Epic B, nuova build) e integrazione API di terze parti (Epic C, incognite moderate)
- Team: due ingegneri senior, un ingegnere mid-level, un ingegnere QA
- Velocità: 32 story point per sprint di due settimane (media mobile di tre sprint)
- Tariffa oraria combinata: $150/ora (completamente caricata)
- Capacità sprint: 80 ore-persona per ingegnere per sprint
- Volatilità dei requisiti: moderata (moltiplicatore del 25% applicato alle stime pessimistiche)
Dimensionamento e input PERT:
Valore atteso PERT per epic = (O + 4M + P) / 6. Valore atteso PERT totale: 105 story point.
Conversione in sprint e mesi-persona:
A 32 punti per sprint, 105 punti richiedono circa 3,3 sprint (50° percentile). Il totale pessimistico di 168 punti richiede circa 5,3 sprint (90° percentile, prima dell'aggiustamento per volatilità).
Con un team di quattro persone a 80 ore a persona per sprint di due settimane, ogni sprint rappresenta 320 ore-persona, o circa 1,9 mesi-persona (a 168 ore per mese-persona). Intervallo di sforzo totale: un intervallo di mesi-persona dal 50° al 90° percentile con volatilità applicata.
Conversione in dollari:
A una tariffa oraria combinata, il costo stimato in dollari varia da una stima media a una stima più alta con contingenza applicata.
Il moltiplicatore di volatilità quasi raddoppia il limite superiore, ed è questo il punto. Presentare solo la stima più probabile avrebbe fissato un budget che il risultato al 90° percentile supererebbe senza preavviso.
Ridiculous Engineering ti aiuta a costruire stime che puoi difendere
Ridiculous Engineering lavora con team di prodotto e leader aziendali per produrre impegni definiti basati su assunzioni esplicite, intervalli di sforzo calibrati e una valutazione onesta del rischio, non numeri ottimistici a punto singolo progettati per vincere una gara.
Il nostro team porta la stessa disciplina ingegneristica alla stima che portiamo alla consegna: documentiamo le assunzioni, eseguiamo metodi complementari e presentiamo intervalli 50/90 così sai a cosa ti stai impegnando. Se ti stai preparando per una selezione di fornitori, una richiesta di finanziamento al consiglio o un contratto a prezzo fisso, inizia con una conversazione di scoping e porta il registro delle assunzioni che hai costruito usando questa guida.
Fonti
Questi sono i riferimenti di maggior valore per approfondire metodi specifici:
- Stima agile: planning poker, story point e dimensionamento – Atlassian
- Spiegazione della stima dei costi software – SEI (CMU)
- Manuale COCOMO II
- Tecniche di stima dei progetti agili – PMI
- Guida definitiva alle tecniche di stima Agile 2026 | Wrike
FAQ
Come si stima un progetto di sviluppo software?
Scomporre l'ambito in una struttura di suddivisione del lavoro o backlog, dimensionare ogni elemento con un metodo adatto alla fase del ciclo di vita (story point per Agile, ore attività per ambito impegnativo), applicare fattori di costo e calibrazione, quindi aggregare e convertire in un intervallo di sforzo 50/90 e importo in dollari utilizzando la tariffa oraria mista.
Quali sono i quattro tipi principali di stima del software?
Le quattro categorie principali sono giudizio esperto (Wideband Delphi, planning poker), stima analogica (confronto con progetti passati), stima parametrica (COCOMO II e modelli simili) e stima bottom-up (decomposizione delle attività basata su WBS). Le stime più affidabili combinano almeno due di queste.
Come si stima il costo di un progetto software?
Convertire la stima dello sforzo (in ore-persona o mesi-persona) in dollari utilizzando una tariffa oraria mista completamente caricata che include stipendi, benefit e spese generali.
Cos'è la tecnica di stima 50/90?
La tecnica 50/90 riporta due risultati percentile da una distribuzione di probabilità dello sforzo o della durata. Il 50° percentile (mediana) è il risultato atteso circa la metà delle volte; il 90° percentile è il budget o la pianificazione necessaria per evitare il superamento con alta confidenza. Utilizzare il 50° per la pianificazione interna e il 90° per richieste di finanziamento e contratti a prezzo fisso.
Quando dovrebbero essere convertiti gli story point in ore?
Gli story point dovrebbero essere convertiti in ore solo per controlli di capacità a breve termine, come confermare che uno sprint rientri nelle ore disponibili del team. Utilizzare la conversione punti-ore per previsioni multi-sprint o a livello di release introduce falsa precisione e mina il modello di dimensionamento relativo che rende utili gli story point in primo luogo.