Qual è il margine di errore accettabile quando si stima una durata del progetto?

La società in cui lavoro mira ad avere un margine di errore massimo del 10% e si aspettano che gli analisti non perdano la stima di più o di meno del 10%.

Non so cosa pensarci, dal momento che non ho nulla con cui confrontarlo.

Quale potrebbe essere una buona base da misurare se stiamo stimando troppo male, per più o meno? Quanto (in%) ritieni giusto perdere?

A meno che tu non stia stimando qualcosa di molto simile a quello che tu e i tuoi colleghi avete fatto prima, +/- 10% è ridicolmente ottimista. La tua direzione o non ha molta esperienza con il software o non è a conoscenza di grandi limiti alla stima del software . Quel documento ha del materiale di supporto di accompagnamento e si possono trovare molti punditry .

Esaminiamo un sistema molto più semplice di un tipico progetto software: il cubo di Rubik. Puoi risolvere qualsiasi posizione in 20 mosse , max. Ma poiché stai stimando, puoi guardare un cubo dato solo per pochi minuti prima di dare la soluzione. Puoi dare un buon preventivo? No, a volte la stima di un processo richiede più tempo rispetto al processo.

Un altro sistema semplice: Pinocchio. Un automa di legno, il suo naso cresce quando emette una bugia. Cosa succede quando Pinocchio è a riposo, e poi dice "Il mio naso sta crescendo"? Alcuni sistemi non sono suscettibili di previsione, sono indecidibili.

Questi due problemi sono integrati nella maggior parte dei sistemi software. Per questo motivo, non otterrai mai stime vicine al +/- 10%.

Il mio consiglio è di dare una stima pesantemente imbottita, lavorare come uno schiavo per portare a termine il progetto il più velocemente possibile, e quindi sembrare occupato fino a quando non si arriva al 10% o meno. A quel punto, annuncia un successo spettacolare.

Sarei molto titubante su qualsiasi tipo di "margine di errore target" perché dipende davvero dal progetto. Se stai cercando di stimare quanto tempo ci vorrà per installare, configurare e personalizzare un nuovo sistema CRM in cui nessuno è abbastanza sicuro di quali tipi di personalizzazioni saranno necessarie e che tipo di modifiche ai processi aziendali saranno necessarie e la società non ha precedenti di simili progetti di grandi dimensioni, il margine di errore dovrebbe essere piuttosto elevato (vale a dire che potresti immaginare che ci vorranno 18 mesi +/- 50% e un preventivo di 9-27 mesi). Man mano che il progetto procede, le specifiche diventano più chiare, le decisioni vengono prese sui processi aziendali, i tuoi sviluppatori diventano più a loro agio, ecc. Tali margini di errore dovrebbero essere più rigidi. Se stai cercando di stimare quanto tempo costruirà il 101 ° sito di e-commerce di base quando abbiamo una buona storia dai primi 100, ti aspetteresti di poter dare una stima molto più accurata. La maggior parte dei progetti, tuttavia, cadrà da qualche parte nel mezzo.

Ora, se stai citando un singolo numero anziché un intervallo, la risposta è probabilmente iniziare a quotare l'intervallo in modo che la persona che effettua la stima possa specificare quanto si aspettano che la stima sia accurata.

Una buona base sarebbe quella basata su dati reali che hai raccolto.

Il primo passo per farlo è la registrazione di tutte le stime . Il secondo passo è la registrazione dei risultati effettivi . Sii onesto, non essere tentato di "autoregolare" il reale. Raccogli abbastanza di queste informazioni e disponi di alcuni dati per basare le statistiche su quanto sono buone le tue stime. Nota, questo può / varierà selvaggiamente in base a chi ha fatto la stima e chi ha lavorato. Solo così si può ragionevolmente prevedere di dare un "margine di errore" che è qualsiasi altra spazzatura pura.

Non si ferma nemmeno qui; l'analisi di ciò che provoca la disattivazione delle stime può aiutare a migliorare l'accuratezza delle stime future. Nota: rimangono ancora stime e, come tali, sono solo stime .

Anche la stima non termina dopo la prima stima; questo è qualcosa che può essere adattato man mano che il progetto avanza man mano che si acquisiscono ulteriori conoscenze, riducendo così il possibile margine di errore nel corso del processo. Più sei aperto con la comunicazione, vengono discusse le sorprese precedenti, portando le persone a essere meno sorprese e concedendo più tempo per adeguare le aspettative del progetto o dei clienti.

In secondo luogo, forse un modo migliore di gestire il margine di errore è la " sicurezza interna " piuttosto che semplicemente% dei margini di errore. Non basarti sulla data di consegna stimata su un intervallo di confidenza, piuttosto che su una data singolare.

PERT è un esempio di un framework per gestire la stima basata su ragionamenti statistici. Per esempio:

"In base a ciò che so ora, abbiamo un livello di confidenza del 90% che possiamo offrire in 8 mesi. 95% di fiducia in 10 mesi, 99% di fiducia in 2 anni, ecc."

Nota qui: più sono sicuri di volerti, più grande sarà la stima. A seconda della complessità (ovvero della precisione che potresti avere), potrebbe esserci una piccola differenza tra l'80% e il 90% o potrebbe essere enorme!

Infine, buona fortuna;) Se si risolve mai il "margine di errore massimo" nella stima del software in base al quale è possibile specificare qualcosa come "tutte le nostre stime saranno +/- 10%", assicurarsi di commissionare un film al botteghino per il resto di noi nel settore del software. Sto pensando a qualcosa di simile a un incrocio tra Office Space e The Matrix: D

In realtà dipende molto dalle dimensioni e dalla complessità del progetto.

Se la stima del tuo progetto è di 1 settimana, il 10% è ragionevole. Significa +/- 1/2 giorno.
Se è di 1 mese il 10% è traballante - dalla mia esperienza è impossibile prevedere cosa scoprirai in 1 mese.

Più di un mese: tutte le scommesse sono disattivate :).

Questi sono per sviluppatore, quindi per un team di 4 sviluppatori 1 settimana == 1 mese.

Per un team di sviluppatori 4, per lo più è utile elaborare un elenco di funzionalità che è possibile eseguire in 1 mese e rientrare nel 10% per tali funzionalità. Quindi, rivalutare per il mese successivo.

Ho fatto alcune ipotesi ingenue qui

1. Tutti gli sviluppatori possono lavorare in parallelo.
2. Non sono stati considerati tester - dovrebbero avere del tempo per testare
3. Tutti gli sviluppatori sono uguali: frontend, backend, designer ecc ...

Devi tener conto di quelli in ... ma questa è l'idea generale.

Ci sono molte variabili:

1. Quanto dura il progetto?

2. Come sarà gestito il progetto? Cascata? Agile? MISCHIA?

Presumo dalla domanda Waterfall. In tal caso, ci si aspetta che fallisca di una certa percentuale data la richiesta di un margine.

Se la risposta è una metodologia Agile, in particolare qualcosa come SCRUM. Non importa quale sia la percentuale di margine. Un margine di errore del 50% su uno Sprint di 2 settimane è di 1 settimana, su uno Sprint di 1 settimana è di 2,5 giorni, entrambi scenari estremamente peggiori. Questo perché la data di consegna viene rivalutata ad ogni Sprint e diventerà sempre più accurata nel tempo, anziché sempre meno.

Con Waterfall il 50% del margine di errore non è ancora sentito, ma su un progetto di 12 mesi che è di 6 mesi e non viene realmente scoperto / ammesso, è così grave fino a 10 mesi nei 12.

Ai tempi in cui guidavo i team di software, all'incirca attorno al confine cretaceo / terziario, in realtà ci siamo avvicinati al raggiungimento di +/- 10% sulla stima. Era circa il +/- 15% se la mia memoria molto complicata mi serve. Questo perché stavamo valutando le cose che avevamo già fatto : un firmware di comunicazione in tempo reale relativamente semplice che prendeva i byte da A e li spostava in B usando un linguaggio che conoscevamo, in un ambiente in tempo reale progettato da noi , parlando con hardware progettato internamente da ragazzi a pochi uffici di distanza. Molte lievi varianti sul tema sopra, per letteralmente anni .

Aspettarsi di ottenere questo tipo di tasso di errore nella normale stima del progetto software è francamente ridicolo . Quando lo vedi apparentemente raggiunto, è perché o le persone hanno sopravvalutato e imbottito (facendo cose extra e progetti di animali domestici per utilizzare il budget), o sottovalutato e hanno lavorato come cani di sera e nei fine settimana per recuperare il tempo.

Probabilmente hai sentito la cosa del 300%, giusto?

Lo uso davvero. Completamente basato su ciò che ho visto per anni. Quando sento un giorno o due, è una settimana o più da fare davvero . E testato. In tutti gli ambienti. Documentazione aggiornata. Test di usabilità. Prestazioni testate. Carico testato. Un paio d'ore è davvero più simile a un giorno.

Penso che siamo davvero pessimi nella stima a causa di:

• Aiutare gli altri
• Essere interrotto
• Formazione di nuove persone
• Altre cose in arrivo
• Malessere o malessere
• Coprendo le persone che se ne vanno
• Serve vacanza o tempo libero
• Distrarsi dagli altri
• Essere ostacolato da altri gruppi
• Essere troppo ottimisti oltre che realistici
• Non allocare tempo per lavorare su errori di test intermittenti
• Escludere facilmente i tempi per i test, in particolare la scrittura di test automatici

Quindi ai massimi livelli, con uomini d'affari che hanno bisogno di stime migliori del 300%, quello che finiamo per fare è mirare a stime ragionevolmente buone ma al prezzo di essere di livello superiore e più generale. "Avremo una funzione di modifica dell'utente" anche se la versione 1 significa solo per 1 gruppo di utenti per la modifica di 1 campo.

Quando si tratta di "Qual è il margine di errore accettabile quando si stima una durata del progetto?" Trovo che questo approccio, usato in molti ambienti Agile, aiuti a cambiare la domanda in quale sia la funzionalità minima per ottenere una versione alfa o beta in diretta e quindi iterarla.