Come imparare a fare stime migliori? [chiuso]

Non sono ancora bravo in questo, ma ho scoperto che il monitoraggio del tempo stimato per le attività e la durata effettiva del tuo intervento può essere di grande aiuto. In questo modo puoi avere una solida idea di quanto sei lontano di solito. Questo software di gestione dei problemi con il monitoraggio del tempo (Jira nel mio caso) o un foglio di calcolo può essere di grande aiuto.

Penso che più di ogni altra cosa sia un'esperienza.

Legge di Murphy sulla gestione del tempo: per capire quanto tempo prenderà , capire quanto tempo dovrebbe prendere e raddoppiarlo.

Quindi, passa all'unità di tempo immediatamente superiore. Pertanto, assegniamo due settimane per un progetto di un giorno.

Puoi imparare facendoli collettivamente .

Uso Pianificazione del poker . È una tecnica basata sul consenso per la stima.

La tua stima deve essere monitorata e confrontata con ciò che hai effettivamente fatto. Otterrai Velocity .

Ogni volta che valuti qualcosa, moltiplichi per la tua velocità recente per ottenere stima accurata .

La stima del software di Steve McConnell (MS Press) è una buona lettura.

La cosa principale con la stima del software è riepilogata dal seguente

Without historical information, your estimates are useless.

Questa è una delle ragioni per cui penso che i progetti iterativi abbiano molto più successo dei grandi progetti a cascata a fasi. Non stanno cercando di costruire un piano per un anno alla volta con poche informazioni diverse da un voodoo della scatola nera di ciò che pensano che dovrebbe essere. Ogni iterazione, stanno rivalutando / ripianificando e hanno le ultime iterazioni su cui basare le loro stime.

Alcuni altri punti da tenere a mente:

1. Otterrà solo più lento . Applicare la regola 80/20 significa che il lavoro più difficile verrà dopo, a meno che la gestione del tuo progetto sia molto disciplinata.
2. Stima! = Pianificazione. La stima è il processo per capire lo sforzo richiesto per ottenere qualcosa. Pianificazione è il processo di adattarlo in un programma.
3. Il 60% di efficienza è tutto ciò che puoi sperare. Il 70% è un'utopia. Se stai stimando in giorni, crea questo in. Se stai stimando in ore, non dimenticare di applicarlo in seguito.
4. Ricorda la coda lunga . Le stime sono un'ipotesi approssimativa di quanto a lungo "probabilmente" si adeguerà per un certo livello di rischio e incognite. La coda lunga entra in gioco perché la quantità effettiva di lavoro richiesta non sarà mai inferiore a 0. OTOH, la quantità massima di tempo che ci vorrà sarà limitata solo dal tempo che si è disposti a spendere prima di rinunciare. Come un mio ex capo ha detto "tutte le stime sono +/- x% e non è mai meno".

Sono sorpreso che nessuno abbia menzionato la tecnica di stima in stile PERT descritta in The Clean Coder . In questo metodo, stimerai quanto tempo ci vorrà per 3 scenari: ottimista ( O ), nominale ( N ) e pessimista ( P ). Quindi la durata prevista = (O+4N+P)/6 e ottieni una deviazione standard di (P-O)/6 .

Questo sembra funzionare piuttosto bene, e l'ho usato un po 'di volte quando la gestione si preoccupa veramente di quanto tempo ci vorrà probabilmente qualcosa.

Come altri hanno commentato, ho anche fatto delle stime esaminando i dati storici ("Quanto tempo ci è voluto per fare questa cosa simile?").

Ma il mio metodo preferito è di non fare stime temporali, e solo fare stime puntuali e ottenere una velocità su iterazioni. Se una squadra è abbastanza coerente nel dimensionamento e nel completamento del lavoro (storie degli utenti), risparmierai un sacco di tempo non chiedendo nemmeno per quanto tempo ogni cosa prenderà.

Le stime dell'ora sono diabolicamente difficili da correggere e richiedono molto lavoro per suddividere le cose in pezzi abbastanza piccoli da poter essere misurati in modo efficace. E anche allora raramente sono corretti perché ci sono troppe variabili e ci dimentichiamo di spiegare cose come malattie, ferie o anche distrazioni.

Se devo fare delle stime delle ore, cerco di farle solo per compiti piccoli all'interno di un'iterazione. Misuro tutto in stime di mezza giornata (4, 8, 12 ore) a meno che non sappia che potrebbe essere inferiore. Ma raramente stimolo qualcosa in meno di 1 ora.

Prima e più importante, devi definire un processo e attenerci ad esso. Includere la revisione del piano alla fine di ogni fase del processo. Puoi anche rivedere il processo, ma in modo ordinato.

In secondo luogo, fai un qualche tipo di design. Il design è il primo passo verso la pianificazione, non costruisci una casa senza disegni.

Terzo, durata della traccia (sforzo). Dovresti almeno differenziare:

• Analisi
• design
• Codice
• Test delle unità (include la correzione dei difetti)
• Test di integrazione (include correzione dei difetti)

• Test di accettazione, con l'utente (includi i difetti di correzione)

  Sarebbe fantastico se misurassi i difetti di fissaggio per ogni tipo di test, ma aggiungesse complessità, quindi puoi farlo in seguito.

In quarto luogo, identifica gli elementi di base della chiave per la stima. Ad esempio:

• Numero di processi da automatizzare (Analisi)
• Numero di entità del modello di dominio (Design)
• Numero di moduli e rapporti (Codice)

Quinto, correlare gli elementi di base e lo sforzo. Ad esempio:

• Sforzo di analisi = X ore uomo / processo da automatizzare
• Sforzo di progettazione = entità uomo-ore / modello dominio
• Sforzo codice = Z uomo-ore / modulo (o rapporto); numero di moduli = A * entità modello di dominio
• Sforzo di test unitario = M% * Sforzo del codice
• Sforzo test di integrazione = N% * Sforzo codice
• Sfida test di accettazione = P% * Sforzo codice

Sesto, tieni traccia delle prestazioni e della deviazione dalle stime per ciascun progetto. Quindi puoi mettere a punto i tuoi fattori di correlazione.

Settimo, ripeti e migliora. Otterrai molte informazioni alla fine del primo progetto, al terzo ti sentirai a tuo agio nella pianificazione e nella stima.

Dai un'occhiata al link , funziona davvero.

Ogni volta che incontri un problema di stima, prova a dividerli in parti più piccole. Poi vedi se hai già fatto cose simili ai pezzi. Se lo hai, dovresti già avere una buona idea di quanto tempo ogni pezzo prende. Se non lo fai, dovresti iniziare a tenere traccia del tempo impiegato per vari tipi di attività. Questo ti aiuterà nelle stime future.

Il tempo totale necessario sarà più della somma dei singoli pezzi, poiché è necessario un po 'di tempo per l'integrazione e il test.

Se non hai fatto qualcosa di simile, puoi probabilmente contare sull'esperienza di altre persone e ottenere una stima da loro. Non prendere questo al valore nominale però. Niente ti insegna come l'esperienza.

È come sparare a un bersaglio. Gli scatti precedenti alla stima dovrebbero dirti quanto sei lontano, in modo da poterlo correggere.

Trovo più facile eseguire il processo di divisione per i compiti minimi come menzionato sopra, elaborare ciascuno di essi e quindi raddoppiare tale stima. Poi li aggiungo insieme e aggiungo il cinquanta percento. Questo mi dà un tempo approssimativo di progetto in condizioni ideali. Se il lavoro sta per accadere praticamente in parallelo con altri, avrà bisogno di più tempo. Se devi aspettare altre persone, aspettati che durino il doppio del tempo che pensi. L'attesa di contenuti o feedback o altre informazioni spesso richiede molto più tempo di quanto sembra possibile.

Dove lavoro elaboriamo il caso migliore / il caso previsto / la stima del caso peggiore per ogni fase del processo, che è utile come guida e anche per valutare come le tue stime hanno funzionato.

La tecnica non è mai così importante se non che devi essere in grado di combattere la tentazione del programmatore di sottovalutare i compiti, ma ciò che è importante è essere prudenti quando puoi consegnare qualcosa. Se ti occorrono sette settimane per costruire qualcosa e hai promesso otto settimane, puoi entrare un po 'in anticipo e cercare un test extra e assicurarti affidabilità. Se hai promesso sei settimane puoi sembrare brutto anche se non è assolutamente colpa tua. In caso di dubbio, indovina prudentemente.

Potresti provare a creare una traccia di ciò che era la stima e quale era l'effettivo per i vari compiti di creare un numero sufficiente di record per poi sapere quale moltiplicatore avere per cose specifiche che vengono ripetute nella tua lista. Concesso che questo è un esercizio di prova ed errore, ma è sembrato funzionare bene per me. C'è anche qualcosa da dire per molte prove prima che il modello emerga probabilmente. Questo è probabilmente simile a molte altre risposte che direbbero che si potrebbe ridurre a "Basta farlo!" in quanto è così che la maggior parte di noi ha sviluppato l'abilità. È un grande dolore vedere quanto può essere sbagliato fare stime? Sì, ma se le stime miglioreranno, alla fine tutti saranno felici.

Se riesci a scomporre il progetto in compiti più piccoli e fai delle stime per quelle, sarai più preciso nel complesso. Qualsiasi compito più grande di un paio di giorni dovrebbe essere ulteriormente suddiviso. Se non riesci a scomporlo ulteriormente, probabilmente hai un gap di requisiti. Se devi fare una stima del back-of-the-napkin per un requisito di una sola riga, beh ... niente può davvero aiutarti molto. Purtroppo molti negozi funzionano in questo modo la maggior parte del tempo.

Piuttosto che scrivere un libro su di esso, ti offrirò un piccolo consiglio su come utilizzare il metodo di "abbattere" della stima:

• Rompere il compito in compiti di componenti più piccoli. Valuta ogni attività nel miglior modo possibile.

• Aggiungi un'attività per la pianificazione e la progettazione (che include ciò che stai facendo ora.) Stimalo.

• Se non ne hai già uno, aggiungi un'attività per "riunire i compiti". All'inizio questo compito potrebbe non sembrare utile. Tuttavia, quando si utilizza questo metodo di "abbattere" della stima, ci sono sempre cose che richiedono tempo per fare ciò che "cade tra le attività" e che "tira insieme i compiti". Questo può essere difficile da stimare. Fai del tuo meglio.

• Aggiungi un'attività per test e documentazione. Il tuo compito potrebbe non richiedere molti test e documentazione, ma dovresti almeno dedicare un po 'di tempo a pensarci.

• Sommare le stime delle attività per ottenere una stima complessiva.

• Vai avanti e moltiplica la stima totale di due ††. Questo ti darà il tempo di riempimento per:

  1. Completa le cose che hai trascurato nell'elenco delle attività originali
  2. Finisci cose che non avresti potuto conoscere fino a quando non sono in corso
  3. incorporare il feedback di altre persone e apportare modifiche
  4. Sii interrotto da altre cose che ti circondano, come le riunioni
  5. Termina il preventivo più spesso che dietro

E ultimo, ma non meno importante, non abbiate paura di delineare le stime per te stesso che sono probabilmente totalmente sbagliate. A volte solo delineare tutto, non importa quanto potenzialmente selvaggiamente inaccurato, può aiutarti a iniziare il percorso per avere un senso migliore per ciò che è coinvolto.

†† Man mano che ottieni sempre più esperienza, questo "fattore fondente" può essere regolato in base al tuo stile personale e al tuo ambiente di lavoro.

La formula che funziona quando lavori per me stesso:

1. fai una suddivisione di todo da 1 a 4 ore di granularità. Trovo che di solito sono accurato con questi

2. il "fattore sconosciuto": moltiplicare per un fattore 2 elevato al numero di incognite. Cioè se devi sviluppare un'applicazione per couchdb, ma ora sai qualcosa su javascript e http ... aggiungi 2 ^ 2 come fattore mult.

3. fattore di cambio di contesto: multiplo di 1,5 se lavorerai in un ambiente perfetto (a casa nell'angolo dello studio, ecc.), o 2.5 se lavorerai in un ambiente imprevedibile (ufficio / posto affollato ecc.)

Trovo che sia compreso tra +/- 20% del tempo effettivo !!

Impara il tuo pregiudizio. Se la tua ultima stima è stata troppo bassa per il fattore due, la volta successiva, raddoppia la stima iniziale. (Naturalmente, la legge di Hofstadter rende difficile farlo correttamente ...)

È anche sempre una buona idea ricordare quanto lavoro è stato necessario dopo il rilascio iniziale del lavoro precedente e aggiungerlo alla stima successiva. Per esempio. il tuo ultimo compito ha richiesto 2 mesi per essere completato, ma dopo l'attivazione, il supporto, gli hotfix e le modifiche aggiuntive ti sono costati un altro mese, quindi, la stima della prossima stima di 3 mesi per un'attività simile.

Per gli opener, leggi "Software Engineering Economics" di Barry Boehm e "Controlling Software Projects" di Tom DeMarco. Dopo aver letto e digerito questi due, leggi "Stima dei costi del software con COCOMO 2", di Barry Boehm.

Per quello che ho da dire in seguito, ti aiuterà molto a prendere una classe di probabilità e statistica, anche di base per un libro di cucina.

Nessuna stima è perfetta. C'è una certa probabilità di arrivare presto e alcune probabilità di arrivare in ritardo. Il modello COCOMO dettagliato originale di Boehm ha fornito previsioni che si sono rivelate entro il 30% del risultato effettivo, meglio del 60% delle volte. È stato molto meglio di quello che era comune quando ha scritto e pubblicato il libro.

Quando fai la tua ipotesi migliore (e questa è tutta una stima), stai includendo quelle probabilità. Se aumenti la stima, aumenti la probabilità che arrivi in ritardo. Se aumenti la stima, aumenti la probabilità che arrivi presto o termini in tempo. Quanto lo tiri dentro o lo fai fuori controlla come cambia la probabilità, e deve necessariamente dipendere dalle penalità per essere in anticipo o in ritardo. (Inserisci storie dell'orrore qui - e ce ne sono state MOLTE nel corso degli anni!)

DeMarco affronta questo in una certa misura. Sottolinea inoltre che esiste una "regione di impossibilità": alcuni orari sono troppo stretti per essere realizzati, indipendentemente dal tipo di eroismo che si tenta.