Cosa posso fare per ottenere una stima migliore di quanto tempo ci vorranno i progetti? [duplicare]

Devi chiedere un po 'di tempo prima di dare una risposta alla direzione. Torna indietro e studia l'attività:

• Annota un approccio generale
• Forse fai qualche esplorazione del codice per qualche ora
• Suddividi l'attività in passaggi in un excel (suggerirei Microsoft Project, ma potrebbe essere eccessivo)
• Contro ogni attività cerca di assegnare la tua migliore stima della stima
• Aggiungili e aggiungi un buffer del 20-30% e fornisci a Gestione

Nel tempo migliorerai.

Aggiornamento:

Bene, non deve essere 2 giorni. Fondamentalmente non dai una risposta subito. Non è possibile sapere (tranne che per i compiti più banali) quanto impegno ci vorrà subito. Se è un compito di grandi dimensioni (forse 3-4 settimane) ci vorrà un paio di giorni per stimarlo, ma se è un compito che è un 3-4 giorni, allora ci vorranno solo 3-4 ore per romperlo su e stima.

Questa domanda ha una risposta lunga e una risposta leggermente più lunga (ma nessuna risposta breve).

La lunga risposta è di 255 pagine (e alcune appendici) e si chiama " Stima del software: Demistificare l'arte nera "di Steve McConnell. Viene altamente raccomandato.

La risposta leggermente meno lunga è in realtà solo un insieme di euristiche / suggerimenti:

1. Suddividi l'attività in piccoli elementi, preferibilmente 1-3 giorni ciascuno
2. Prova a trovare un'attività simile, nello stesso dominio o che coinvolge tecnologie simili. Non è quasi mai il caso di stimare un'attività che hai già fatto prima (perché è già fatta ...). Esempio: se il tuo compito è "potenziare SharePoint in modo X", forse hai svolto un'attività che implicava l'integrazione con SharePoint e / o un altro prodotto Office e / o un altro "Sistema di gestione dei contenuti"
3. Fornisci la stima come un intervallo anziché una stima a un singolo punto
4. Comprendi i tuoi margini - se stai valutando qualcosa di completamente nuovo potresti dover prendere un fattore del 100% o addirittura del 400% (cioè se la tua stima è di 2 giorni e il fattore è del 400%, potrebbe richiedere tra .5 a giorno a 8 giorni). Maggiore è l'incertezza, maggiore è il fattore.
5. Comprendi che mentre procedi nell'attività, devi rivedere e perfezionare la stima
6. Comunicare, comunicare, comunicare! Assicurati che la direzione sia consapevole di quanto sia affidabile (o meno) una stima specifica.
7. Fornisci stime in una scala e in numeri che riflettono l'accuratezza (ad esempio, la stima in ore implica una maggiore accuratezza rispetto alla stessa stima in giorni; la stima impiegherebbe 3,75 giorni fa supporre automaticamente che la stima sia più accurata di una stima di 4 sarebbe stato dato)
8. Riconosci il "Cono dell'incertezza" (vedi più dettagli sotto)
9. Quando si dà un preventivo, diciamo "3 giorni", pensa alla seguente domanda: "Possono essere necessari meno di 3 giorni?". Se la risposta è No, allora questa è una stima ottimistica, dato che ci vorrebbero 3 giorni se e solo se nulla va storto ...

Diverse altre note:

• Le inesattezze possono andare in entrambe le direzioni, sia verso l'alto o verso il basso (sebbene i progetti software siano noti per sottostimensioni piuttosto che per sovrastima)
• Si noti che gli effetti della sottovalutazione sono di solito più dannosi per il progetto che non sovrastimando (questo è anche discusso nella prima parte del suddetto libro)

Il Cono dell'Incertezza:

L'idea di "cono" è che inizi un progetto con stime di alto livello / bassa accuratezza e la tua sicurezza e accuratezza aumentano man mano che fai progressi sul progetto. Ad esempio:

• Al momento della raccolta dei requisiti le tue stime sono molto meno accurate rispetto a quando il design di alto livello è pronto
• Che sono molto meno precisi di dopo la progettazione dettagliata
• Il che è meno accurato della metà della codifica.

Questo è un fatto della vita, e invece di combatterlo, questa comprensione dovrebbe essere incorporata nel tuo piano. Questo è per lo più rilevante quando si stima un intero progetto o un grande compito (vale a dire più di 2 settimane), dal momento che suddividerlo in oggetti a grana fine come suggerito nell'articolo 1 non è realmente fattibile (o economico).

Prova pianificazione basata sull'evidenza .

Over the last year or so at Fog Creek we’ve been developing a system that’s so easy even our grouchiest developers are willing to go along with it. And as far as we can tell, it produces extremely reliable schedules. It’s called Evidence-Based Scheduling, or EBS. You gather evidence, mostly from historical timesheet data, that you feed back into your schedules. What you get is not just one ship date: you get a confidence distribution curve, showing the probability that you will ship on any given date. It looks like this:

The steeper the curve, the more confident you are that the ship date is real.

Here’s how you do it...

Puoi provare a leggere questi due libri, sono entrambi fantastici (li ho letti più di una volta)

• Stima del software
• Sviluppo rapido

E si occupano anche dell'aspetto umano nella costruzione del software (che sembra possa esserti utile)

stimare rapidamente, ri-stimare regolarmente e, soprattutto, mantenere aggiornata la gestione.

Si tratta di gestire le aspettative, quindi assicurati che capiscano i limiti della tua stima, questa è la chiave, specialmente per i project manager non tecnici.

Nonostante il suo avvertimento che è ormai obsoleto, l'articolo di Joel su Programmi software indolore è estremamente utile se si è nuovo al concetto.

So, you have to make a schedule. This is something almost no programmer wants to do. In my experience, the vast majority just try to get away with not making a schedule at all. Of the few that make a schedule, most are only doing it because their boss made them do it, halfheartedly, and nobody actually believes the schedule except for upper management, which simultaneously believes that "no software project is ever on time" and in the existence of UFOs...

Here's a simple, painless way to make schedules that are actually correct...

Questo può sembrare sciocco, ma in realtà aiuta. Ho avuto un paio di clienti interni nel corso degli anni che sarebbero scoppiati nel mio ufficio con una nuova idea. "Quanto ci vorrà per scrivere una nuova funzionalità per il nostro grande programma che fa [descrizione estremamente vaga]?" Ho scoperto che chiedere più dettagli era spesso inutile. "Dammi solo una stima approssimativa", lui o lei vorrebbe.

Quindi allungo la mano nel cassetto della mia scrivania e tiro fuori un dado a sei facce. Lo scuotevo in mano e lo buttavo sulla scrivania. "Quattro settimane", pronuncerei.

"Dai, sii serio", il cliente si lamenterebbe.

A quel punto, spiegherei che senza almeno un'idea coerente di come funzionerebbe questa nuova funzione, non ne avevo assolutamente idea, e rotolare il dado era buono come qualsiasi altro metodo di stima. Alla fine, hanno tutti il suggerimento. La maggior parte delle idee sono andate via per morire. Con il resto, il mio cliente tornerebbe con qualcosa su cui potrei lavorare.

In poche parole, quello che stavo facendo era illustrare l'assurdità di cercare di fornire una stima praticamente senza informazioni. Un'immagine vale più di mille parole, come si suol dire.

C'è del materiale scritto piuttosto buono là fuori sul tema della stima. I libri di Steve McConnell (precedentemente menzionati qui) sono eccellenti, e consiglierei anche il Agile Estimating and Planning di Mike Cohn.

Ho studiato questo libro prima di pianificare e stimato un grande progetto con il mio team 18 mesi fa, ed è stato estremamente utile. Gli approcci e le tecniche del libro non sono solo per grandi progetti, tuttavia sono utili per qualsiasi dimensione di compito.

Stimare è difficile. Lavorare con NO preventivi è un sogno irrealizzabile. Quindi è una specie di male necessario.

• Inizia mettendo in chiaro che le stime iniziali sono lontane, quindi se ti trovi in una stima di X Unit, dai un intervallo di 0.6X - 1.6X.
• Poi c'è il trucco di raddoppiare la stima (tuttavia dire che un ~ 2 anno impiegherà 4 anni potrebbe essere un problema)
• (Ce n'è uno in più che implica il ridimensionamento della magnitura e il bumping alla successiva unità superiore. Devi fare riferimento al mio libro per questo.)

Di seguito viene la parte di come posso raggiungere tale stima in modo che possa raddoppiare / moltiplicare? Nessuna risposta facile.

• Le tendenze storiche hanno senso se stai facendo lo stesso tipo di progetto con lo stesso livello di abilità di squadra.
• Il prossimo è 'Lasciami guidare la nave per 2-3 iterazioni' e poi tornerò con una stima migliore.
• Finalmente arriva il "Dimmi quanto costerà ... Fino a quel momento nessuno lavora su questo". In questo caso, non hai un angelo custode. Siediti e abbattilo e poi applica supposizioni frammentarie finché non hai una stima cumulativa. Quindi fai il double-n-bump.

Nei miei 5 anni di vita in trincea .. L'unica cosa che ho visto è la stima di "indovinare dalla posizione dei pantaloni" ... Nessuna FP .. Nessun processo .. aiuta nei vincoli del mondo reale. Ancora cose possono migliorare ... per questo suggerirei di ottenere il libro di Mike Cohn "Agile Estimating and Planning" - questo è il libro che è più vicino a noi programmatori e realtà peccaminosi. Il resto sono predicatori sui loro alti cavalli ... Caper Jones quale pianeta è la tua dimora?

Bella domanda .. Continuo a chiederlo quando inizia ogni progetto e poi una volta alla settimana sto facendo il GRIND. Ancora nessuna risposta dalle voci nella mia testa.

Inoltre, dal momento che sembra che tu non lavori in una società puramente software, tieni presente che da nessuna parte il 100% del tempo degli sviluppatori è dedicato alla codifica. Assicurati di mettere in tempo per la pianificazione, documentazione, ricerca, test. Questi sono di solito i passi che la gestione vorrebbe ritagliare dal processo, ma non saranno contenti dei risultati se lo faranno. Se riscontri dei contraccolpi dovresti ricordare loro che A) finirai per passare il tempo su quegli articoli comunque, sia che siano in budget non siano B). Finirai per passare più tempo a mantenere e correggere i bug senza una pianificazione adeguata. Se non hai letto "The Mythical Man Month" di Frederick Brooks, lo consiglierei vivamente. Ha molti buoni concetti e probabilmente ti riferirai più di un po 'ad alcuni degli scenari. Alcuni articoli sono un po 'datati, ma ci sono molte buone informazioni e dovresti essere in grado di ottenerne uno a buon mercato.

Non stimare. Invece, utilizzare una tecnica di project management che non dipende dalla stima. Scrum, ad esempio, sottolinea facendo lavoro piuttosto che parlando di facendo lavoro (cioè stime).

Se trascorri un giorno o due o cinque o qualsiasi altra stima, non sarebbe meglio avere codificato o progettato o testato in quei giorni, invece di passare il tempo a "stimare"?

Ricorda la legge di Hofstadter:

It always takes longer than you expect, even when you take into account Hofstadter's Law.

È divertente e tutto, ma in realtà io di solito faccio delle stime ragionevoli, poi ne aggiungo (almeno) il 10% e poi arrotondo tutto. In occasioni in cui non mi è stato permesso di farlo, mi dispiace dire che ho finito per fallire miseramente nel mantenere il ritmo.

Raddoppia la stima iniziale.

Seriamente, prova a suddividere l'attività in bit più piccoli, stimabili. E poi raddoppialo.

Per lo più è solo una questione di pratica.

Ecco alcune cose importanti da ricordare durante la stima:

1. Utilizza il metodo per tenere traccia di quanto tempo hai pensato che avrebbe dovuto prendere rispetto a quanto tempo effettivamente impiegato.
2. Assicurati di suddividere le tue attività nel minor numero possibile di passaggi prima di calcolare la stima.
3. Non dimenticare di includere il tempo di test / correzione dei bug nella tua stima.
4. Non lasciare che le persone ti costringano a programmi artificiali.

L'articolo di Joel che harpo menziona è una grande espansione di queste idee.

Non penso che ci sia una prescrizione passo-passo universale.

Ogni progetto è diverso. Se conosci il tuo codice e conosci i tuoi processi, allora sai abbastanza per fare una stima seria. Basta pensare a tutti i passaggi, a tutti i componenti e essere realistici. Non essere eccessivamente ottimista. Costruisci contingenze per tutti i luoghi in cui esiste un rischio potenziale. È molto meglio preciso che essere veloce.

Come qualsiasi altra cosa: si sta meglio stimando facendo molto. Più ti costringi (o sei costretto) a fare stime, meglio riuscirai a farlo.

Per migliorare le stime, è necessario confrontare le stime precedenti con il tempo effettivo impiegato e cercare modelli nella differenza.

Come altri hanno suggerito, il primo passo è quello di rompere il progetto il più lontano possibile in modo da poter lavorare con attività discrete gestibili. Registra le tue stime per ogni attività e poi, mentre fai il lavoro, registra il tempo reale necessario (compreso il tempo per tutti i bit che hai dimenticato quando fai la stima - sono spesso dove si trovano i maggiori problemi).

Alla fine del progetto, confronta le tue due serie di figure per vedere dove sei andato storto (perché, anche dopo anni di esperienza, ci sbagliamo tutti da qualche parte). È quindi possibile cercare di migliorare in due modi:

• Cerca di individuare dove stai costantemente sottovalutando o dimenticando le attività e poi portalo avanti alla tua prossima stima, cioè prova a migliorare l'accuratezza con cui valuti ogni attività. Più lavori ogni volta su progetti simili, più è facile farlo.

• Cerca anche uno schema generale nella differenza tra la stima totale e il tempo effettivo impiegato. Se stai prendendo costantemente, diciamo, il 50% in più di quanto stimato per ciascun progetto, hai una linea guida per aumentare le stime future. Quindi, anche se l'accuratezza delle stime delle singole attività non migliora, dovresti avere un esimate più realistico.

Puoi beneficiare del primo approccio dopo un progetto: il secondo approccio diventa più efficace in quanto hai più figure da confrontare.

Inoltre, ritengo che il secondo approccio sia più utile se è necessario stimare il tempo che gli altri sviluppatori impiegheranno. Trovo difficile stimare a nome di un altro sviluppatore di un team, ma so che certe persone impiegano costantemente più o meno tempo rispetto a me per determinati tipi di attività. Quindi, piuttosto che cercare di capire quanto tempo ci vorrà, valuto quanto tempo impiegherò e quindi applicherò un moltiplicatore generale basato su progetti precedenti. (Idealmente, naturalmente, li porterei a fare le loro stime, ma questo non è sempre possibile.)

Chiedi al tuo capo quali decisioni prenderà in base alla stima che fornisci.

Le stime sono supporto decisionale. Ciò che la maggior parte delle persone vuole veramente sono le decisioni migliori.

Forse possiamo ottenere ciò migliorando le nostre stime (e ci sono stati molti buoni suggerimenti dati) ma, ammettiamolo, le stime non saranno mai accurate come il PM medio, né tanto basse quanto la media vuole un venditore.

Tutte le stime sono intervalli e probabilità (anche quando siamo obbligati a fornire un singolo numero) e puoi fornire un supporto decisionale molto migliore se sai per quale motivo verrà utilizzata la stima.

C'è molto di più da dire su questo, ma volevo ottenere la prospettiva là fuori come nessun altro l'ha menzionata.

George, ho trascorso gran parte della mia carriera come team di un solo uomo, quindi so di cosa stai parlando.

Qualcuno ha suggerito di ottenere MS Project, se hai una grande esperienza con Project, potrebbe essere ok. Ma se no, IMHO renderà le cose più complicate.

Il mio primo vero approfondimento sulle stime è venuto da Programmi software indolore di Joel Spolsky. Joel ora suggerisce di utilizzare invece Schedulazione basata sull'evidenza , che credo sia nel loro software di tracciamento dei bug < a href="http://www.fogcreek.com/FogBugz/"> FogBugz . Non l'ho usato, ma sono sicuro che è molto meglio di quello che sto per dirti ... ma se vuoi percorrere la strada del fai-da-te:

Ciò di cui hai bisogno è un modo semplice per gestire un elenco di attività. Personalmente, ho aggiunto 4 campi personalizzati al mio software bugtracker (io uso BugTracker.NET ), un minimo, massimo, probabile ed effettivo stimare i tempi. Aggiungo tutte le attività e le funzionalità a bugtracker insieme al mio min, max, & stime probabili. Quando termino ogni attività, aggiorno il tempo reale. Mentre passo attraverso i miei compiti, posso vedere dalla mia storia che, in media, le mie stime "probabili" sono scese di X% (per me è del 26%), quindi posso prendermi il mio tempo totale e proiettare tutte le attività rimanenti con il mio tempo probabile minimo, massimo e aggiustato. Quindi su attività o progetti futuri, posso passare attraverso la mia storia di attività simili e i loro tempi effettivi e formulare le mie stime da quelle. Avere la cronologia aiuterà anche a evitare le attività mancanti.

Se lo fai, potresti anche imbatterti in BS politico. Quando ho iniziato, ho dato accesso al mio manager, gli ho mostrato come funziona e come avrebbe potuto impostare le mie priorità e capire i progressi del progetto da solo. Tuttavia, poiché il software è uno strumento di tracciamento dei bug, credo che tutte le funzionalità, i miglioramenti e le attività vengano segnalate come bug! Questa è una cosa che vorrei annullare.

E il Steve McConnell libro è fantastico.

Qualcosa che uso è COCOMO. È una tecnica che fornisce modelli probabilistici per la stima dei costi del software. È qualcosa che i tuoi PM (se formalmente addestrati) probabilmente conosceranno. Invece di preoccuparti delle ore, devi semplicemente stimare lo SLOC (linee di codice sorgente) che ti aspetti di scrivere. Quello giusto dovrebbe far scattare alcuni allarmi, ma è solo un pezzo della tecnica. Quindi collega queste stime a un modello e regola le metriche per la regolazione fine.

• Numero di sviluppatori
• Capacità di ogni sviluppatore
• Il tuo calendario di lavoro (ore settimanali, per risorsa)
• Linguaggi di sviluppo e amp; percentuali (se si utilizza più di una)
• Familiarità con il dominio (qualcuno ha mai scritto questo tipo di app)?
• Stile di gestione
• Processo di sviluppo (Agile, waterfall, RUP, ...)
• ecc.

Ciò che fa questo intero processo ti consente di concentrarti su ciò che sei bravo a stimare: codice. La stima temporale è astratta e incapsulata dal modello stesso. Ogni modello è stato costruito analizzando centinaia di progetti reali. Puoi persino sintonizzarti da solo, collegando i tuoi dati reali.

Ho avuto molta resistenza a questo metodo, specialmente quando mi dimentico di arrotondare. "Oh, giusto, ci vorranno 29.02 ore." Tutto sommato, è stato il metodo più accurato per me. I miei colleghi non sono d'accordo con l'uso di SLOC tutto ciò che vogliono, ma non possono discutere la scienza che è stata creata per creare questa tecnica.

Come unico sviluppatore, l'ho usato, ma all'inizio avevo problemi con il mio ego. Non volevo ammettere che le mie abilità in C ++ erano più deboli di quanto pensassi all'epoca. Mi ha fatto sottovalutare. Dopo aver collegato i miei livelli di abilità, tutto si è allineato. Lezione appresa.

Un'altra tecnica che lancio sopra (alcuni strumenti fanno questo per te), è la tecnica delle tre stime, che è ampiamente applicabile in tutti i posti. Prendi il tuo caso peggiore, il caso migliore e il caso previsto, quindi calcoli insieme. Pesa il tuo atteso di un fattore quattro. Quindi ... "(worst + best + expected * 4) / 6" È un moderato aiuto per il rischio, ma in realtà è un trucco psicologico per ottenere stime accurate più rapidamente ... a favore del tuo istinto.

Sovrastimare e abbattere il progetto in più piccoli compiti che possono essere suddivisi in 15 minuti, 30 minuti, 1 ora, 2 ore, 4 ore o 8 ore; Se non si adatta in 8 ore, ripartire nuovamente l'attività. Questo dovrebbe dare un'idea chiara di quanto tempo occorre.

La stima dei progetti software è uno sparo al buio. Non permettere a nessuno di dirti altrimenti. I project manager, in particolare i project manager non tecnici, spesso non se ne rendono conto.

Anche se ci sono molte linee guida e formule là fuori, non ho mai trovato un modo migliore di prendere semplicemente un progetto precedente, applicare un qualche tipo di fattore di scala e utilizzarlo come riferimento. Ad esempio, il mio ultimo progetto è durato 6 mesi e il mio prossimo ha regole più semplici ma molta più migrazione dei dati più un'altra interfaccia esterna, quindi considero il 50% più difficile = 9 mesi.

Alcuni suggerimenti:

Ci sono molti buoni suggerimenti su come fare la stima, ma tutti richiedono tempo. Per farti avere il tempo di fare una stima correttamente, uso questa tattica.

Quando mi viene chiesto un preventivo senza il tempo necessario per capire quanto tempo impiegherà il progetto, torno sempre e fornisco un preventivo che so che alla dirigenza non piacerà. Diciamo che pensi che un progetto durerà circa 3 mesi. Dirò qualcosa come 6 mesi a un anno. Di solito mi guardano male e dico: "Beh, se mi lasci fare una stima reale, probabilmente posso darti una stima migliore".

Inoltre, MAI dire che un progetto richiederà 2-3 mesi! Stai pensando che il progetto durerà 3 mesi e il tuo manager sentirà solo 2 mesi.

Sono in ritardo nel gioco per questa domanda, ma il tuo commento ha colpito un accordo: ti viene spesso chiesto di sul posto - non c'è tempo per cercare, dettagliare, pianificare, consultare il squadra, ecc. Solo un numero go-with-your-gut - e probabilmente un numero che tornerà a perseguitarti.

Questo succede spesso. Il trucco è fidarti del tuo istinto ma anche compensare i tuoi errori .

In altre parole, prendi la tua ipotesi migliore e moltiplicala per un fattore che aiuta a cancellare la mancanza di informazioni, il tempo per fare un'analisi corretta, l'arroganza eterna e l'ottimismo.

Ad esempio, se le ultime 3 stime erano:

• 1 giorno
• 2 settimane
• 3 mesi

e l'ora effettiva era:

• 4 giorni
• 2 mesi
• 1 anno

quindi chiaramente il tuo "coefficiente di ottimismo" è 4.

Come si migliora nella stima - o evitando di stimare, a seconda del caso - questo coefficiente dovrebbe tendersi verso il basso. Ma potrebbe tornare indietro per un po 'se inizi a lavorare in un dominio o tecnologia o team diversi, ecc. Quindi è importante tenerne traccia, almeno mentalmente.

Per un'area nuova di zecca con poche informazioni e tecnologia sconosciuta in circostanze estreme - come riparare l'hyperdrive su un Hutt battle cruiser nel bel mezzo di uno scontro a fuoco quando non puoi leggere Huttese - è meglio usare la Scotty Rule : due volte e aggiungi qualche ^*

[ ^* un mio amico insiste sul fatto che la vera regola di stima Montgomery Scott è di prendere la tua migliore stima, arrotondare, moltiplicarla per 10 e passare al successivo ordine superiore di unità. Quindi, se ritieni che un'attività richieda 2,5 ore, puoi arrotondare fino a 3 ore, moltiplicare per 10 per ottenere 30 ore e cambiare le unità da ore a giorni per ottenere la stima finale di 30 giorni.]

Raccomanderei di dividere il compito il più possibile prima di eseguire qualsiasi valutazione, questo esercizio ti costringerà solo ad avere una profonda comprensione di ciò che devi fare e di come pensi di farlo. Una volta fatto questo, aumenti le possibilità di confrontare la sottoattività con qualcosa che hai già fatto e avere qualcosa di più vicino alla realtà. Se le specifiche di ciò che devi fare non sono chiare, lo scoprirai anche in questo momento, che è una buona cosa.

Le attività oltre 40 ore possono difficilmente essere valutate con precisione, se il tuo project manager è buono, lo saprà! È giusto sbagliare, l'esperienza è l'unica cosa reale che farà davvero la differenza nelle tue valutazioni (e alla fine, ti aiuterà solo ad essere più vicino a una risposta corretta, non perfetta).

Ho anche avuto un'esperienza molto piacevole con la pianificazione del poker, più il mio team lo usa, migliori sono le loro valutazioni (in più è divertente!) ma ci vuole più di una persona che non può aiutarti molto.

Ne ho usati molti, ma forse qualcosa come lo strumento di stima a 3 punti potrebbe valere la pena dare un'occhiata.

Strumento di stima a 3 punti

Con questo prendi l'ottimista (se tutto è andato per il piano), Mostly Likely (per quanto tempo pensi che il progetto prenderà) e il Pessimistic (il più lungo che pensi che potrebbe prendere)

È quindi possibile calcolare una media e aggiungere una media ponderata alle parti, se necessario. Più ti rompi proiettando meglio è l'esatto che potresti ottenere.

Come inizio rapido, potresti avere qualcosa di simile a questo come intestazioni principali, con un numero qualsiasi di attività in esse, con le valutazioni Ottimistiche, Più probabili e pessimistiche

• Ricerca
• Funzione Spec
• Specifiche di progettazione
• Codifica
• Test
• distribuzione

Ovviamente potresti voler espandere qualche titolo o aggiungerne uno.

Di solito c'è una funzione di penalità asimmetrica, per il manager e il team di sviluppo. Questo è in realtà parte della logica del padding.

In ritardo: se le persone dicono ai loro capi di aspettarsi Tsched, e invece è più lungo di Tsched, allora i programmi vengono violati e le persone vengono criticate per varie cose e nel peggiore dei casi le vendite vengono perse oi clienti se ne vanno o i progetti vengono riutilizzati organizzato o trash-inscatolato.

Precoce: se la T vera è inferiore a Tsched, allora hey, pacca il team di sviluppo sul retro e datti da fare sul prossimo progetto. Oppure - vietare il cielo - refactoring e migliorare la qualità del codice (no, non farlo ... fai il prossimo progetto .workwork).

Dovresti ascoltare il podcast di stackoverflow e ascoltare il processo di stima di Jeff Atwood per questo sito in cui ti trovi in questo momento. Era un po 'troppo aggressivo e Joel lo ha chiamato fuori.

Questi sono buoni punti da considerare, ma dovrai eliminare le cose che non funzionano o non si applicano. Rivedi i suggerimenti dopo aver fatto più stime e vedi se qualcosa di più rilevante è più applicabile dopo aver utilizzato questi suggerimenti.

Tenere traccia di ciò che hai stimato e quanto tempo impiega effettivamente è un'idea GRANDE, e troppo spesso non seguita, perché devi passare al prossimo "fuoco". Tuttavia, puoi solo valutare meglio se spendi il tempo per determinare come è stata disattivata la stima e per capire cosa cambiare per la prossima volta.

Hai anche detto che stai lavorando con il codice esistente. Man mano che apportate ulteriori modifiche, suggerirei di aumentare il tempo necessario per testare. Devi assicurarti che la modifica funzioni e devi assicurarti che le altre funzionalità del codice funzionino ancora. Se i test sono in qualche modo automatizzati, potrebbe essere necessario modificare il test per verificare questa modifica al software. Se i tuoi test sono manuali, devi essere sicuro di testare ciò che hai cambiato (aggiungere o modificare la modalità di test in precedenza).

Buona fortuna.

Puoi provare a suddividerlo in compiti più piccoli e stimare ogni attività. Ad esempio, puoi suddividerlo in qualcosa di simile:

1. Installa SharePoint
2. Crea una web part proof of concept.
3. Distribuisci codice personalizzato in SharePoint.

Queste sono le attività per cui dovresti essere in grado di trovare tutorial e leggendole, potresti essere in grado di capire quanto tempo ci vorrà (suggerimento: installare SharePoint è lungo!).

Oltre a ciò, sono d'accordo sul fatto che sia difficile stimare attività che non hai mai fatto prima, quindi cerca di suddividerle in attività che siano piccole e comparabili (nello scope) a cose che hai fatto in passato.

Se qualcun altro nella compagnia ha fatto cose simili, urla sul muro del cubo e guarda cosa ne pensano. Confrontalo per quanto tempo ci vuole, quindi quando ottieni un altro compito chiedi allo stesso sviluppatore quanto tempo ci vorrà. Moltiplicate quel risultato per la differenza che avete ottenuto nel compito iniziale. Non c'è davvero un buon modo per stimare nuovi compiti senza una base storica, ma almeno in questo modo ti mostreremo uno sforzo per basare la tua stima su qualche tipo di fatto.