Come si può stimare il tempo per le attività che consistono principalmente nella risoluzione di un problema?

Mentre è relativamente possibile per uno sviluppatore esperto stimare quanto tempo ci vorrà per implementare il codice quando lo schema e il problema che il codice sta risolvendo sono ben compresi, come si può fare una buona stima quando, mentre l'obiettivo finale è ben compreso, il l'implementazione è del 95% teorica / problem solving e ha quantità molto piccole di implementazione?

Il mio lavoro consiste spesso in compiti per raggiungere obiettivi ben definiti, tuttavia devo trovare il modo per raggiungere quell'obiettivo e fino a quando non capisco la soluzione, non chiarisco quali barriere aggiuntive potrebbero esserci. Più specificamente, sto spesso lavorando alla generazione di codice o strumenti di manipolazione automatica del codice. Una volta che la soluzione è completamente risolta e lo strumento perfezionato, effettuerà direttamente il 95% delle modifiche effettive molto rapidamente. Tuttavia, non ho modo di stimare quanti problemi aggiuntivi potrebbero dover essere risolti per far sì che lo strumento di generazione o analisi gestisca casi limite imprevedibili.

Ai fini della pianificazione, la mia azienda vuole avere un'idea migliore di quanto tempo ci vorrà, ma dal momento che non so quanti problemi aggiuntivi potrebbero sorgere mentre si lavora attraverso la risoluzione di ogni passaggio della soluzione. Non sono sicuro di come posso avvicinarmi dando una stima migliore.

Prima di andare troppo lontano, lasciatemi dire che la stima del software: demistificare l'arte nera è una risorsa eccellente per le persone che guardano e pensano alle stime. Entrambe le immagini sottostanti sono tratte da quel libro come lo sono le idee presentate di seguito.

Come hai notato, le stime sono una parte importante per poter prevedere e pianificare con precisione il lavoro. Non avere stime rende gli affari ciechi su quanto tempo impiegherà qualcosa. Non è insolito che le aziende abbiano un'idea completamente sbagliata su quanto tempo ci vorrà: ciò che pensano sia facile dura dalle sei alle otto settimane e ciò che si pensa che sia difficile è un trucco del venerdì pomeriggio.

La prima cosa è dare un preventivo. Una stima in sé non è un singolo numero: è un impegno. "Quanto tempo impiegherà ABC" -> "Circa 5 giorni" significa che sono circa 5 giorni. Tuttavia, una buona stima è un intervallo in cui sei sicuro al 90% di averlo in quell'intervallo. Se intendi dire "Sono sicuro al 90% che ci vorranno tra 1 e 5 giorni", dillo. Non lavorare da "Penso che ci vorranno tra 1 e 10 giorni, quindi 5 giorni sono probabilmente nella media" - non è una stima e ti sbaglierai il 50% delle volte.

Bene, almeno il 50% delle volte, i programmatori sono noti sottovalutatori per i tempi delle attività.

Considera il cono di incertezza:

^{_{Immagine da http://www.construx.com - articolo completo su http://www.construx.com/Thought_Leadership/Books/The_Cone_of_Uncertainty/}}

Renditi conto che la prima stima in quell'intervallo è 16x. Questo è simile a dire "Penso che ci vorrà tra un pomeriggio e due settimane" - ma non lo sai ancora. Mentre vai avanti con il design un po ', la gamma si riduce a 4x. Ciò non significa che ci vorrà una settimana, significa che dovresti invece dire "dopo aver guardato un po ', ci vorranno tra tre settimane" - sì, il preventivo è aumentato, ma anche l'intervallo del preventivo è andato giù.

Con ogni stima fornita, devi essere sicuro al 90% che la stima rientri in tale intervallo. Puoi sbagliarti: il 10% delle volte cadrà fuori da questo intervallo.

Esistono molti modi per stimare la dimensione dei progetti. Confrontandolo con i progetti passati, usando un proxy (penso che occorrerebbero 1000 righe di codice che richiederebbe così tanto tempo per scrivere), usando i punti funzione (per convertire in LOC ...), ottenendo stime da un numero di persone e poi perfezionandolo iterativamente ... alcuni lavori per alcuni progetti, altri lavori per altri progetti.

Un capitolo molto importante di questo libro che ho citato all'inizio è il n. 23 che si occupa di politica di stima e di gestione di dirigenti e dirigenti.

La chiave per una stima è il processo iterativo di perfezionarlo dopo averci lavorato un po '.

Fornire una stima troppo precisa troppo presto nel processo può essere molto soggetto a errori. Se non sei sicuro, dai la stima ampia e poi torna con un'altra stima dopo un certo periodo di tempo per ulteriori introspezioni sul problema e possibilmente abbozzando come lo farai, guardando per quanto codice lo hai scritto l'ultimo problema simile e altri fattori che influenzeranno la stima.

Le stime richiedono un pensiero: non dare le stime del bracciale. Questi spesso hanno errori enormi associati a loro rispetto a ciò che serve quando ci pensi un po '.

Da Come rispondere quando viene richiesto un preventivo?

Cosa dire quando viene chiesto un preventivo

Dici "Torno da te."

Otterrai quasi sempre risultati migliori se rallenti il ​​processo e passi un po 'di tempo a seguire i passaggi descritti in questa sezione. Le stime fornite alla macchina del caffè torneranno (come il caffè) a perseguitarti.

Dal capitolo 4 della stima del software:

Si noti che in questo, le stime dopo un po 'di revisione sono sistematicamente meno selvagge e soggette a errori rispetto alle stime fuori borsa. Non eliminare le stime del bracciale. Siediti e pensa al compito e stimalo dopo averci pensato un po '.

Boss : AJ, abbiamo 3 cani, 2 conigli, una catapulta e una suora. Dobbiamo trovare un modo per ottenere tutti e 7 (sì, anche la catapulta) su una parete di 20 piedi e nel lago dall'altra parte senza che i cani mangino conigli e senza annegare la suora. Quanto ci vorrà per trovare la soluzione?

Vedi, il problema che stima quanto tempo ci vorrà per risolvere un problema è che ci vogliono persone diverse per un tempo diverso. Se hai una storia di risoluzione di problemi simili, puoi stimare in base al tempo impiegato in passato. Se non lo fai, non stai stimando, stai solo indovinando.

Inoltre, il problema potrebbe non avere nemmeno una soluzione accettabile. O forse la soluzione richiederà un'ulteriore autorizzazione che potrebbe buttare via l'intero progetto. O forse la soluzione cambia l'intera natura percepita del problema in modo tale che la soluzione diventa del tutto superflua.

La morale della storia è che se non hai abbastanza informazioni per fare una stima ragionevole, allora non farlo . Non ancora. Ottieni maggiori informazioni Ricerca di più. In genere è perfettamente OK dire "Ti risponderò tra 2 giorni con alcuni numeri più solidi".

Durante la progettazione di una soluzione per il mio cliente, non firmerò un contratto fino a quando non avrò abbastanza del progetto generale completo da sapere che aspetto avrà la soluzione e quanto tempo impiegherà il progetto. Ciò significa che sono a rischio di aver svolto un lavoro di progettazione iniziale per il quale non vengo pagato (se il progetto non va a buon fine), ma è meglio che essere a rischio di fatturazione significativa per il lavoro svolto .

Ti suggerirei di provare qualcosa a metà strada tra le risposte di tylerl e MichaelT con il seguente:

• dividere il lavoro da svolgere in 3 o 4 fasi. Le fasi dovrebbero essere:
  1. Analisi del problema
  2. Prototipazione di soluzioni
  3. Soluzione nel mondo reale
  4. Valutazione dell'output (test)
• fornire un preventivo solo per la fase 1 (analisi) in base alla tua esperienza o sulle fasi 1 + 2 (analisi + prototipo) alla tua direzione. Quindi, fornisci loro una stima per le fasi 3 + 4 al termine delle fasi 1 e 2 del problema (o almeno abbastanza avanzate in modo da poter avere fiducia nel tuo preventivo).

La logica alla base è che, per esperienza, sai che hai bisogno di X giorni per analizzare una data base di codice (probabilmente a seconda delle sue dimensioni) e avere una serie di strumenti di base o script in esecuzione (e forse non riusciti). Quindi, il numero di errori dovrebbe fornirti alcune informazioni sull'effettiva difficoltà dell'attività a portata di mano.

Questo potrebbe non essere esattamente quello che vuole la direzione, ma credo che sia sempre meglio elaborare stime che effettivamente si incontreranno.

Poiché questa domanda riguarda principalmente i tipi di lavoro di ricerca, chiedere agli sviluppatori di software è un approccio coraggioso, una metrica comune è che lo sviluppatore di software impiega il doppio del tempo in cui la loro stima è probabilmente un buon sviluppatore. Tuttavia, detto ciò, le attività di ricerca (e progettazione dell'architettura) fanno molto parte della programmazione e sono spesso ignorate / minimizzate. Spesso sono anche difficili da stimare.

La prima domanda che mi pongo è un problema che può essere risolto? Non si tratta di un problema di intelletto o potenza del cervello, ma di realtà pratica. A meno che siate nel mondo di Google colpi di luna, in cui il fallimento è un risultato atteso, la dura realtà è che io sono tenuti a fornire questo , qualunque cosa questo si rivela. Una regola empirica sembra essere: sappiamo già quale deve essere il 90% della soluzione?

La seconda domanda che vorrei porre, cos'altro sarebbe utile sapere nel pensare alla soluzione? Questo è davvero un modo per ricontrollare, sappiamo davvero abbastanza per trovare una soluzione che sarà accettabile. Può generare una serie di attività di accertamento dei fatti che aiutano a definire meglio ciò che la soluzione deve essere, ognuna delle quali è di solito abbastanza facile da definire e stimare.

La terza domanda è: chi è più adatto alla squadra per questo tipo di problema? Chiunque ottenga questo compito condurrà il risultato con il proprio stile. Dare questo tipo di problema a un programmatore che ha 10 milioni di domande all'inizio di un'attività e poi se ne va e offre qualcosa per la prima volta (anche se lentamente) potrebbe essere una scelta migliore rispetto a dargli il programmatore che sbatte fuori l'implementazione rapidamente , ma quando c'è un problema, viene scoperto solo alla fine del processo.

Quindi, il vero compito sarebbe quello di pensare a possibili soluzioni, implementazioni e approcci e di avere una scala temporale fissa in cui devono riferire.

Quando rispondono, hai quindi la possibilità di scegliere una serie più ampia di possibili soluzioni, dare il via libera all'implementazione di una soluzione o riflettere, poiché la soluzione non è ancora definita in modo abbastanza chiaro

Con domande di ricerca in cui non è chiaro che ci sia una risposta, per non parlare di un'idea chiara di ciò che deve essere fatto, di solito propongo di dedicare x una quantità di tempo su di esso come inizio.

"Non ho idea se sia possibile, ma potrei passare due giorni a ricercarlo. Probabilmente non ci darà una soluzione, ma forse potrò escludere alcune cose e probabilmente avrò un'idea quali potrebbero essere i prossimi passi concreti e che tipo di investimento in termini di tempo significherebbero. Quindi possiamo decidere se ha senso fare un altro passo ".

Quindi metti l'incertezza nella direzione opposta: la stima è ben precisa (passerò due giorni), è solo molto non specificato cosa sarà raggiunto da allora.

Timeboxing, in sostanza.