Come imparare a fare stime migliori? [chiuso]

Faccio schifo alle stime. Quando qualcuno mi chiede quanto tempo ci vorrà, non oso nemmeno fare un'ipotesi poiché sarò completamente fuori dal comune. Di solito sono troppo ottimista e probabilmente dovrei moltiplicare la mia ipotesi con un grande fattore X ...

Come posso imparare a fare stime migliori? Non è insegnato alla mia università, e anche se abbiamo delle scadenze per tutte le lavorazioni, non penso mai a quanto tempo impiegherà effettivamente qualcosa. Quale dovrei. Per il bene di tutti (specialmente il mio).

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

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

Murphy's Law of Time Management: per capire quanto tempo impiegherà qualcosa , capire quanto tempo dovrebbe impiegare e raddoppiarlo.

Quindi, passa all'unità di tempo successiva più alta. Pertanto, assegniamo due settimane per un progetto di un giorno.

Puoi imparare facendoli collettivamente .

Uso Planning Poker . È una tecnica basata sul consenso per la stima.

La tua stima deve essere tracciata e confrontata con ciò che hai effettivamente fatto. Otterrai la velocità .

Ogni volta che si stima qualcosa, moltiplicare per la velocità recente per ottenere una stima accurata .

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

La cosa principale con la stima del software è riassunta da quanto segue

Senza informazioni storiche, le tue stime sono inutili.

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

Alcuni altri punti da tenere a mente:

1. Sarà solo più lento . Applicare la regola 80/20 significa che il lavoro più duro arriverà più tardi, a meno che la gestione del progetto non sia molto disciplinata.
2. Stima! = Pianificazione. La stima è il processo per capire lo sforzo necessario per ottenere qualcosa. La pianificazione è il processo di adattamento a un programma.
3. Il 60% di efficienza è tutto ciò che puoi sperare. Il 70% è utopia. Se esegui una stima in giorni, compila questo. Se esegui una stima in ore, non dimenticare di applicarlo in seguito.
4. Ricorda la coda lunga . Le stime sono una stima approssimativa di quanto tempo "probabilmente" richiederà aggiustato 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, il tempo massimo che ci vorrà è limitato solo da quanto tempo sei disposto a spendere prima di arrenderti. Come ha affermato un mio ex capo "tutte le stime sono +/- x% e non sono mai meno".

Sono sorpreso che nessuno abbia menzionato la tecnica di stima in stile PERT descritta in The Clean Coder di Robert Martin . In questo metodo, si stima il tempo necessario per 3 scenari: optimistic ( O), nominal ( N) e pessimistic ( P). Quindi la durata prevista = (O+4N+P)/6e si ottiene una deviazione standard di (P-O)/6.

Questo sembra funzionare abbastanza bene, e l'ho usato un paio di volte in cui il management si preoccupa davvero di quanto tempo richiederà 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 è non fare affatto stime del tempo, e fare solo stime puntuali e ottenere una velocità sulle iterazioni. Se una squadra è abbastanza coerente nel dimensionare e completare il lavoro (storie degli utenti), allora risparmi un sacco di tempo senza nemmeno chiedere quanto tempo impiegherà ogni cosa.

Le stime delle ore sono diabolicamente difficili da ottenere, e richiedono molto lavoro per scomporre le cose in blocchi abbastanza piccoli da misurare efficacemente. E anche allora raramente sono corretti perché ci sono troppe variabili e ci dimentichiamo di tenere conto di cose come la malattia, le vacanze o persino le distrazioni.

Se devo fare delle stime delle ore, provo a eseguirle solo per compiti di piccole dimensioni all'interno di un'iterazione. Misuro tutto nelle stime di mezza giornata (4, 8, 12 ore) a meno che non sappia che potrebbe essere inferiore. Ma raramente stimo qualcosa a meno di 1 ora.

Prima di tutto, è necessario definire un processo e attenersi ad esso. Includi la revisione del piano alla fine di ogni fase del processo. Puoi anche rivedere il processo, ma in modo ordinato.

In secondo luogo, fai una sorta di design. Il design è il primo passo per la pianificazione, non si costruisce una casa senza disegni.

In terzo luogo, tenere traccia del tempo (sforzo). Dovresti almeno differenziare:

• Analisi
• Design
• Codice
• Test unitari (include la correzione di difetti)
• Test di integrazione (include correzione dei difetti)

• Test di accettazione, con l'utente (include correzione dei difetti)

  Sarebbe bello se misurassi lo sforzo di correzione dei difetti per ogni tipo di test, ma aggiunge complessità, quindi puoi farlo in seguito.

In quarto luogo, identificare gli elementi di base chiave per la stima. Per esempio:

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

In quinto luogo, correlare gli elementi di base e lo sforzo. Per esempio:

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

In sesto luogo, tenere traccia delle prestazioni e della deviazione dalle stime per ciascun progetto. Quindi puoi mettere a punto i tuoi fattori di correlazione.

Settimo, ripetere e migliorare. Otterrai molte informazioni solo alla fine del primo progetto, dal terzo ti sentirai a tuo agio nella pianificazione e nella stima.

Dai un'occhiata a http://en.wikipedia.org/wiki/Personal_Software_Process , funziona davvero.

Ogni volta che incontri un problema di stima, prova a dividerlo in pezzi più piccoli. Quindi vedi se hai già fatto cose simili ai pezzi. Se sì, dovresti già avere una buona idea di quanto tempo impiega ogni pezzo. In caso contrario, dovresti iniziare a tenere attivamente traccia del tempo impiegato per vari tipi di attività. Questo ti aiuterà nelle stime future.

Il tempo totale necessario sarà superiore alla somma dei singoli pezzi, poiché è necessario del tempo per l'integrazione e i test.

Se non hai fatto qualcosa di simile, probabilmente puoi fare affidamento sull'esperienza di altre persone e ottenere una stima da loro. Non prenderlo al valore nominale però. Nulla ti insegna come esperienza.

È un po 'come sparare a un bersaglio. Gli scatti precedenti alla stima dovrebbero dirti quanto sei fuori dal segno, in modo da poterlo correggere.

Trovo più semplice eseguire il processo di divisione per i compiti minimi, come indicato sopra, elaborare ciascuno di essi e quindi raddoppiare tale stima. Quindi li aggiungo insieme e aggiungo il cinquanta percento. Questo mi dà un tempo di progetto approssimativo in condizioni ideali. Se il lavoro praticamente si svolgerà in parallelo con gli altri, avrà bisogno di più tempo. Se dovrai aspettare altre persone, aspettati che impieghino il doppio del tempo che pensi. Attendere contenuti, feedback o altre informazioni spesso richiede molto più tempo di quanto sembri possibile.

Dove lavoro elaboriamo una stima del caso migliore / caso previsto / caso peggiore per ogni fase del processo, che è utile come guida e anche per valutare come le stime sono state elaborate.

La tecnica non è mai così importante, tranne per il fatto che devi essere in grado di combattere la tentazione del programmatore di sottovalutare i compiti, ma l'importante è essere prudenti quando puoi consegnare qualcosa. Se ti occorrono sette settimane per costruire qualcosa e hai promesso otto settimane, puoi arrivare un po 'in anticipo e avere un bell'aspetto o fare qualche test extra ed essere certo dell'affidabilità. Se hai promesso sei settimane puoi sembrare brutto anche se non è assolutamente colpa tua. In caso di dubbi, indovina in modo conservativo.

Potresti provare a creare un track record di ciò che era il preventivo e quale era l'effettivo per varie attività per creare un record sufficiente per poi sapere quale moltiplicatore avere per cose specifiche che si ripetono nell'elenco. Concesso, questo è un esercizio di prova ed errore, ma sembra 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 "Fallo!" poiché è così che la maggior parte di noi ha sviluppato l'abilità. È un grande dolore vedere quanto si può sbagliare quando si fanno delle stime? Sì, ma se le stime migliorano, alla fine tutti possono essere felici.

Se riesci a scomporre il progetto in attività più piccole e fare stime per quelle, sarai più accurato nel complesso. Qualsiasi attività più grande di un paio di giorni dovrebbe essere ulteriormente suddivisa. Se non riesci a scomporlo oltre ciò che probabilmente hai un gap di requisiti. Se devi fare una stima del back-of-the-tovagliolo per un requisito di una riga bene ... niente può davvero aiutarti molto. Purtroppo molti negozi funzionano così per la maggior parte del tempo.

Invece di scrivere un libro su di esso, offrirò solo un piccolo consiglio su come utilizzare il metodo di stima "scomposta":

• Suddividi il compito in attività di componenti più piccoli. Stimare 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 le attività". Questa attività potrebbe non sembrare utile all'inizio. Tuttavia, quando si utilizza questo metodo di stima "suddiviso", ci sono sempre cose che richiedono tempo per fare "cadere tra le attività" e "mettere insieme le attività". Questo può essere difficile da stimare. Fai del tuo meglio.

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

• Aggiungi le stime dell'attività per ottenere una stima complessiva.

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

  1. Termina le cose che hai trascurato nell'elenco delle attività originali
  2. Termina cose che non avresti potuto sapere prima di iniziare
  3. Incorporare feedback da altre persone e apportare modifiche
  4. Fatti interrompere da altre cose che accadono intorno a te, come le riunioni
  5. Termina prima della stima più spesso che dietro

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

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

La formula che funziona quando lavoro per me:

1. fare una suddivisione di todo con una granularità di 1 - 4 ore. Trovo che di solito sono preciso con questi

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

3. fattore di cambio di contesto: multiplo per 1,5 se lavorerai in un ambiente perfetto (a casa nell'angolo dello studio, ecc.), o 2,5 se lavorerai in un ambiente non adatto (ufficio / luogo affollato, ecc.)

Trovo che questo sia compreso nel +/- 20% del tempo effettivo impiegato !!

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

È anche sempre una buona idea ricordare quanto lavoro era necessario dopo la versione iniziale del lavoro precedente e aggiungerlo alla stima successiva. Ad esempio, la tua ultima attività ha richiesto 2 mesi per essere completata, ma dopo essere diventata attiva, il supporto, gli aggiornamenti rapidi e le modifiche aggiuntive ti sono costati un altro mese, quindi, la prossima volta stima 3 mesi per un'attività simile.

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

Per quello che devo dire dopo, ti aiuterà MOLTO ad aver preso una classe di probabilità e statistica, anche una di base per libri di cucina.

Nessuna stima è perfetta. C'è qualche probabilità di arrivare presto e qualche probabilità di arrivare tardi. 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 ciò che era comune quando ha scritto e pubblicato il libro.

Quando fai la tua ipotesi migliore (e questo è tutto un preventivo), stai includendo quelle probabilità. Se si inserisce la stima, si aumenta la probabilità di arrivare in ritardo. Se aumenti la stima, aumenti la probabilità che arrivi in ​​anticipo o finisca in tempo. Quanto lo tiri dentro o lo fai uscire controlla come cambia la probabilità e deve necessariamente dipendere dalle penalità per essere in anticipo o in ritardo. (Inserisci qui storie horror - 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 programmi sono troppo stretti per essere fatti, indipendentemente dal tipo di eroismo tentato.