velocità di stima del software e precisione

Question

Diciamo che hai un progetto che coinvolgerà due applicazioni web (che condivideranno DAL / DAO / assiemi Bo e alcune librerie OSS):

• un'applicazione di gestione complessa semi che utilizza Windows Live ID per l'autenticazione ed è anche in grado di comunicare con vari servizi notifier (e-mail, sms, Twitter, ecc), i notificanti mirati essendo circa il 10% delle funzionalità
• un basso a semi applicazione utente complesso con meno funzionalità ma più robustezza che utilizza anche Windows Live ID per l'autenticazione

Ci sono due di noi con funzionalità di stima media e non saranno in grado di farlo in due giorni, anche se volevamo / necessario. Almeno sarebbe un lontano stima.

Domande

1. Quanto tempo / non normalmente vi porterà a fare una stima attendibile / valore?
2. Cosa suggeriresti per accelerare la stima senza sacrificare la precisione?
3. Come allentamento (in termini di costo / ora) molto vorresti aggiungere a seconda della velocità di stima (quando si potrebbe dire: ho potuto stimare un po 'di più, perché penso che sia ancora abbastanza off )

Answer 1

Domanda interessante. Temo che la risposta è "dipende davvero!" So che non è terribilmente utile (anche se è vero), quindi ecco alcuni fattori:

1) Qualità e completezza dei requisiti e delle specifiche. Questo è, per me, il più delle volte il progetto e preventivo assassino. Se non si dispone di requisiti di qualità, avete alcuna base ragionevole per una stima. Usiamo uno stile "RUP-lite" di sviluppo del prodotto qui, così come il direttore di ingegneria non voglio dare nulla, ma la stima grossolana-grano finché non avremo completato il nostro fase di "elaborazione" e ottenuto sign-off dalla gestione del prodotto che il nucleo 80% delle caratteristiche del prodotto sono infatti accuratamente coperto.

2) La portata e la natura del prodotto. Più grande / più costose / più complicata = sostanzialmente più lunga per stimare. Ho passato anni a lavorare nella terra di telco-carrier fornitura di soluzioni che hanno le normali esigenze di supporto robusto ( "5 9 di" di uptime richiesto da SLA significa che bisogna davvero fare un buon lavoro di progettazione della soluzione e di recupero fallimento!). In questo tipo di ambiente con tutte le parti in movimento attraverso le aree funzionali del business, la stima del lavoro sta andando a cerniera su come ottenere l'intero quadro ... in particolare, le dipendenze cross-funzionali e dipendenze esterne possono essere un killer reale qui. Detto questo, ho anche costruito un sacco di plastica retraibile e software per le imprese, anche. In tali ambienti è molto più semplice poiché la portata è tipicamente sostanzialmente più piccolo, in modo quindi più facile da stimare.

3) Come "nuovo" è questo progetto? Come "nuovo" è la squadra a questo prodotto o la tecnologia set? Il più recente prodotto o di squadra, il più lungo e più tampone è necessario allocare.

4) Come specifico abbiamo bisogno di essere? Se questo è un "occhio e croce" poi mi appoggio sul mio engineering porta a fornire una stima conservativa, allora io pad. Se abbiamo bisogno di una stima "reale" (ad esempio, uno che viene utilizzato dal mio capo, e che sarò responsabile per colpire), avrei bisogno del contributo di una serie di diversi manager e membri del team, che avrà bisogno di tempo per analizzare i requisiti e conferire tra loro.

Che può richiedere un minimo di un paio di giorni, o weeks..it tutto dipende dalle dimensioni. "Due o tre giorni" è, francamente, non abbastanza a lungo per il dimensionamento nulla, ma il più banale dei progetti.

La cosa migliore che puoi fare per migliorare la qualità delle stime per migliorare la qualità delle vostre esigenze, ed essere spietato per identificare le dipendenze nascoste.

Una finale cosa:. FWIW, ho fatto presente dal '81 e considero con precisione la stima di un progetto di durata / costo come il singolo più difficile / irto di pericoli parte di Ingegneria Gestionale

Answer 2

Dal momento che usiamo metodi agili (Scrum, in particolare) ci vuole circa un'ora in più di quello necessario agli utenti di dare la priorità.

Più tempo non porta a una maggiore precisione.

La parte più difficile, quindi, è sempre agli utenti di priorità. Sentiamo questa discussione tutto il tempo "se il tutto non è stato completato in tempo, è tutto inutile." "Fatta eccezione per la componente XYZZY, che ha un certo valore." Questo argomento può andare avanti per ore fino a quando è deliberato che XYZZY dovrebbe essere il primo.

In generale, cerchiamo di creare 4 settimane sprint. I primi sono complicate, perché c'è sempre qualcosa di nuovo. Dopo i primi due (o tre) ci sembra di impostare un ritmo costante.

Ogni caso d'uso ha una relativamente semplice, la valutazione personale di come lo sforzo ci vorrà per finirlo. Nulla più di uno sprint pieno di durata deve essere decomposto. La maggior parte delle volte un paio di casi d'uso sono raggruppati in un unico sprint.

L'sono modi formali di segnare ogni caso d'uso per gestire meglio i problemi di costo e di pianificazione. Non usiamo perché lo sforzo supplementare non aiuta.

Dopo i primi due sprint,

1. C'è funzionalità di nuovo e diverso,

2. Le priorità sono tutti cambiati,

3. I dettagli di ciascun caso d'uso sono stati drasticamente rivisti.

Che cosa significa "precisione" dire quando la cosa si sta cercando di stimare i cambiamenti alla fine di ogni sprint?

---

Una lezione appresa. Parti della mia società spendono un molto tempo completamente definizione esattamente quello che sarà consegnato, e poi di misura che si stanno consegnando esattamente ciò che vogliono.

I clienti notare questo, e uno ha detto che "spendiamo un sacco di tempo fornire ciò che dice il contratto, ma non è quello che ci serviva".

Il problema con la ditta stime up-front è che essi assumono una vita propria. Quanto più si "investe" nella stima, tanto più le stime sembrano essere un risultato finale utile. Essi non sono utili perché sono in genere totalmente sbagliato. Sono basate su ipotesi up-front che sono totalmente sbagliato.

E 'una cattiva politica di investire più di tempo nella stima. Le risposte "precise" non sono più accurate, ma sono più apprezzati da ogni strato della gestione. Come voi e il cliente impara, si invalidare numerose ipotesi e si deve assolutamente ri-stima costantemente.

Non farlo in anticipo. Se il contratto richiede di farlo in anticipo, quindi assicuratevi di avere una disposizione di controllo delle modifiche e dire al cliente che è assolutamente farà modifiche, come si va avanti. Come sia voi e il cliente imparare, si sia deve apportare modifiche.

Answer 3

Per effettuare una stima attendibile si ha realmente avrebbe bisogno di creare un elenco di attività da fare. Scomposizione in storie / compiti (anche se non si usa agile) e valutarli. Questo può richiedere molto tempo già - in particolare la quantità di ricerca (per cercare librerie di fare questa roba notificante per ridurre i costi). Vorrei prendere almeno 3 giorni - tuttavia 1-2 settimana (s) suona più ragionevole per me. Questo non sembra essere un piccolo progetto.

Non avrei il coraggio di accelerare il processo di stima se si wan't per avere risultati alquanto ragionevoli. Le stime non sono mai precise e si sarà solo peggiorare le cose.

Una possibilità sarebbe quella di fare una congettura del tutto approssimativa nel giro di poche ore e poi iniziare a lavorare su di esso già (per una settimana o giù di lì). Alla fine della settimana si potrebbe essere in grado di dare un migliore preventivo, sulla base di progressi in corso. Tuttavia è importante creare un buon prototipo (che assomiglia schifo ma ha un po 'di codice in tutte le regioni).

Answer 4

Bene, una citazione comune è "Il prezzo sarà compreso tra il 50% e il 400% delle nostre stime iniziali". La ragione per cui questa citazione è cresciuto di grandi dimensioni è che è vero. Stima accuratezza dipende in gran parte il dominio conoscenza. Se questo è il momento 100 ° che hai venduto un determinato tipo di blog-motore di quello che sei abbastanza sicuro circa le stime. Tuttavia, il più delle volte, non si ha che la conoscenza approfondita del dominio (se l'applicazione esiste già, perché creare una nuova?).

sviluppo Agile è diventato popolare perché la gente in gran parte riconoscono che il tipo tradizionale "cascata" di pensare semplicemente non funziona per la maggior parte dei progetti del mondo reale. Si dovrebbe applicare lo stesso modo di pensare per le stime. Ovviamente, è necessario un qualche tipo di punto vendita, ma essere sicuri di dire ai tuoi clienti che questa informazione è molto vago (e che non importa quello che dirà a qualsiasi concorrente loro, le loro stime sono vaghi pure).

Hai bisogno di vendere iterazioni, e quindi anche stimare iterazioni. Sono sicuro che alcuni di marketing-guy in qualsiasi azienda saprà come gestire il lavoro di ufficio e la roba legale per questo, quindi non dovrebbe essere un grosso problema.

Si consideri un progetto di 5 iterazioni:

• Iniziate mettendo su pietre miliari. Questi sono soggetti a modifiche, ma forniranno i tuoi vargue prime stime per il prodotto finale.
• Piano di iterazione # 1.
• Stima iterazione # 1, regolare le stime totali di conseguenza.
• Fare iterazione 1 #
• Sciacquare / ripetizione fino iterazione # 5
• Il gioco è fatto:)
• Rifletti sul tuo progetto. Come hanno fatto le stime si evolvono? Motivi? Imparare facendo:)

La maggior parte dei clienti preferisce avere parziali stime e part-liberazioni di qualche obiettivo non realistico che alcune vestito li ha venduti:)

Answer 5

Randagi leggermente dalla tua domanda originale, ma è anche importante imparare dalle stime che si è prodotta in passato, mantenendo le informazioni su quanto tempo in realtà ha portato a fare le cose che si stimato.

Abbiamo stimato 5 giorni per la produzione di queste pagine, in realtà sono voluti 10 giorni, ed ecc.

Nel informazioni lungo termine come questo sarà (si spera!) Consentono di produrre stime più accurate.