Come puoi stimare il tempo per le attività che consistono principalmente nel trovare un problema?

Prima di andare troppo lontano, lasciami dire che Stima del software: Demistificare la Black Art è un'ottima risorsa per le persone che guardano e pensano alle stime. Entrambe le immagini sottostanti sono tratte da quel libro, così come lo sono le idee presentate di seguito.

Come hai notato, le stime sono una parte importante per essere in grado di prevedere e pianificare accuratamente il lavoro. Non avere stime rende il business cieco per quanto tempo ci vorrà qualcosa. Non è insolito per le imprese avere un'idea completamente sbagliata su quanto tempo ci vorrà: ciò che pensano sia facile da sei a otto settimane e quello che si pensa sia difficile è un hack del venerdì pomeriggio.

La prima cosa è dare una stima. Una stima in sé non è un numero singolo - questo è un impegno. "Quanto ci vorrà ABC" - > "Circa 5 giorni" significa che è di circa 5 giorni. Tuttavia, una buona stima è un intervallo in cui sei sicuro al 90% che lo avrai in tale intervallo. Se intendi dire "Sono sicuro al 90% che ci vorranno tra 1 e 5 giorni", allora dillo. Non funziona da "Penso che ci vorranno tra 1 e 10 giorni, quindi 5 giorni è probabilmente sulla media" - questo non è una stima e ti sbagli il 50% delle volte.

Bene, il 50% o più delle volte, i programmatori sono famosi sottostimanti per i tempi di attività.

Considera il cono dell'incertezza: link

^{_{Immagine dal link - articolo completo su link}}

Renditi conto che la prima stima in quell'intervallo è 16x. È come dire "Penso che ci vorranno tra un pomeriggio e due settimane" - ma non lo sai ancora. Man mano che avanzi con il design, la gamma si restringe a 4x. Ciò significa che non significa che ci vorrà una settimana, significa che dovresti invece dire "dopo averlo guardato un po ', ci vorranno tra tre settimane" - sì, la stima è aumentata, ma anche l'intervallo della stima è andato giù.

Con ogni stima che fornisci, devi essere sicuro al 90% che la stima sia all'interno di tale intervallo. Puoi sbagliare: il 10% delle volte che cadrà fuori da questo intervallo.

Ci sono molti modi per stimare la dimensione dei progetti. Confrontandolo con progetti passati, usando un proxy (penso che ci vorrebbero 1000 righe di codice che richiederebbero 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 funzionano per alcuni progetti, altri funzionano per altri progetti.

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

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

L'attribuzione troppo precisa di una stima troppo presto nel processo può essere molto soggetta a errori. Se non ne sei sicuro, dai un preventivo ampio e poi torna con un'altra stima dopo un certo periodo di tempo per una maggiore introspezione nel problema e, possibilmente, delineare come lo farai, osservando quanto codice hai scritto per l'ultimo problema simile e altri fattori che incideranno sulla stima.

Le stime richiedono un po 'di riflessione - non dare stime del polsino. Questi hanno spesso enormi errori associati a loro rispetto a ciò che serve quando ci pensi un po '.

Da Come rispondere quando viene richiesto un preventivo?

What to Say When Asked for an Estimate

You say "I'll get back to you."

You almost always get better results if you slow the process down and spend some time going through the steps we describe in this section. Estimates given at the coffee machine will (like the coffee) come back to haunt you.

Dal capitolo 4 della stima del software:

Si noti che in questo caso, le stime dopo un po 'di revisione sono sistematicamente meno selvagge e soggette a errori rispetto alle stime a sorpresa. Non fare stime del polsino. Siediti e pensa al compito e stimalo dopo un po 'di riflessione su di esso.

Boss: AJ, We have 3 dogs, 2 rabbits, a catapult, and a nun. We need to find a way to get all 7 (yes, the catapult too) over a 20-foot wall and into the lake on the other side without the dogs eating any rabbits, and without drowning the nun. How long will it take you to come up with the solution?

Vedi, il problema di stimare quanto tempo ci vorrà per risolvere un problema è che ci vogliono persone diverse per un periodo di tempo diverso. Se hai una storia di risoluzione di problemi simili, puoi stimare in base a quanto tempo ti ha portato in passato. Se non lo fai, allora non stai valutando, stai solo indovinando.

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

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

Quando progetti una soluzione per il cliente I, non firmerò un contratto finché non avrò abbastanza del progetto generale completo che so quale sarà 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 viene eseguito), ma è meglio che essere a rischio di una significativa sotto-fatturazione per il lavoro svolto .

Ti suggerisco di provare qualcosa a metà 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. Soluzione di prototipazione
  3. Soluzione del mondo reale
  4. Valutazione dell'output (test)
• fornire una stima solo per la fase 1 (analisi) in base alla propria esperienza o per le fasi 1 + 2 (analisi + prototipo) alla propria gestione. Quindi, fornisci loro una stima per le fasi 3 + 4 quando le fasi del problema 1 e 2 sono terminate (o almeno abbastanza avanzate in modo da avere fiducia nella tua stima).

La logica dietro è che tu sai per esperienza che hai bisogno di X giorni per analizzare una determinata base di codice (probabilmente a seconda delle sue dimensioni) e avere un seme di strumenti di base o script in esecuzione (e forse fallendo). Quindi, il numero di errori dovrebbe fornire alcune informazioni sulla reale difficoltà del compito a portata di mano.

Questo potrebbe non essere esattamente ciò che vuole la direzione, ma credo sia sempre meglio fare delle stime che effettivamente incontrerai.

Poiché questa domanda riguarda principalmente i tipi di lavoro di ricerca, chiedere agli sviluppatori di software è un approccio coraggioso, una metrica comune è che gli sviluppatori di software impiegano il doppio del tempo in cui la loro stima è probabilmente un buon sviluppatore. Tuttavia, detto questo, le attività di ricerca (e design dell'architettura) sono una parte molto importante della programmazione e vengono spesso saltate / ridotte al minimo. Spesso sono anche difficili da stimare.

La prima domanda che vorrei pormi, è un problema che può essere risolto? Questo non è un problema di intelligenza o di cervello, ma di realtà pratica. A meno che tu non sia nel mondo dei colpi di luna di Google, dove il fallimento è un risultato atteso, la dura realtà è che dovrei consegnare questo , qualunque sia questo essere. Sembra una regola approssimativa, sappiamo già che cosa deve essere il 90% della soluzione?

La seconda domanda che vorrei porre, che altro sarebbe utile sapere nel pensare alla soluzione? Questo è davvero un modo di raddoppiare se sappiamo davvero abbastanza per trovare una soluzione quello sarà accettabile. Può generare una serie di attività di ricerca di 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 è il più adatto nel team 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 consegna qualcosa per la prima volta (anche se lentamente) potrebbe essere una scelta migliore rispetto a dargli il programmatore che sballa all'implementazione rapidamente , ma quando c'è un problema, viene scoperto solo alla fine del processo.

Quindi, il compito effettivo dovrebbe essere quello di pensare a possibili soluzioni, implementazioni e approcci e di avere una scala temporale fissa in cui devono essere segnalati.

Quando vengono segnalati, puoi scegliere di ottenere un insieme più ampio di soluzioni possibili, dando l'ok per implementare una soluzione o riflettere, poiché la soluzione non è ancora definita in modo sufficientemente chiaro

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

"Non ho idea se questo sia possibile, ma potrei passare due giorni a cercarlo. Probabilmente non ci daranno una soluzione, ma forse sarò in grado di escludere alcune cose e probabilmente avere un'idea di quali potrebbero essere i prossimi passi concreti e che tipo di investimento temporale vorrebbe dire, quindi decidere se ha senso fare un altro passo avanti. "

Quindi metti l'incertezza nella direzione opposta - la stima è ben precisa (trascorrerò due giorni), è solo molto imprecisato quello che verrà raggiunto da allora.

Timeboxing, in pratica.