Come dedurre le mie ipotesi su cui ho basato la mia stima del tempo?

Un esempio reale: il mio capo mi ha chiesto quanto tempo mi sarebbe occorso per distribuire il software su un nuovo componente hardware e passare attraverso la procedura di test di accettazione manuale. Avevo già fatto la procedura di test su altri sistemi, quindi sapevo che l'intera operazione richiedeva circa 2 ore. So anche che l'implementazione, l'installazione e la configurazione richiedono circa 30 minuti. Ci sono altri fattori, ma prendiamoli semplicemente. Potrei benissimo dire che mi ci vorranno 3 ore per fare tutto ciò che è stato chiesto ... supponendo che il sistema fosse sulla rete. La mia ipotesi era che l'IT avesse fatto la configurazione della macchina per metterla in rete, e potevo semplicemente accedere e distribuire il software. Se non l'avessero fatto, la mia stima sarebbe già saltata, dato che non potevo fare nulla finché non fosse successo.

Le supposizioni non sono "cose malvagie a cui piace restare nascosti". Sono cose su cui stai contando di essere accadute fuori dal tuo controllo. Puoi presentare il tuo preventivo con questi presupposti che queste altre cose sono accadute e delineare che cosa esattamente hai assunto sarebbe accaduto.

Enumerando e rendendo note le tue ipotesi, non hai fatto un asino da te stesso. In effetti, tutti ora sono sulla stessa pagina. Se ti trovi nella situazione e qualcosa non è accaduto, puoi puntare alle ipotesi su cui hai basato la tua stima e poi ricostituirti sulla base delle tue conoscenze appena scoperte che le assunzioni originali erano sbagliate.

Non sarai in grado di rendere conto di tutto. Alcune cose saranno trascurate. L'unica cosa che puoi fare è tenere traccia, imparare dai tuoi errori e migliorare la prossima volta. Questo è il motivo per cui tu (specialmente a livello di progetto) riesci a rinnovare frequentemente - il Software Engineering Laboratory della NASA stima una volta all'inizio del progetto ... e poi ancora 5 volte nel corso del progetto, rivedendo sulla base di chiarimenti, informazioni apprese, analisi del rischio e ipotesi fatto.

Problem is, by assuming I already made an ass out of myself without realizing it. Assumptions are those evil things that like to stay hidden, things I took for granted.

Non è vero. Devi fare delle ipotesi per fare qualsiasi tipo di stima, se tu sapessi tutto in anticipo non sarebbe una stima. È necessario fare un sacco di presupposti ragionevoli per essere un programmatore efficace.

So when reviewing my estimate, what techniques can I apply to discover the assumptions 
I based my time estimate on?

Se hai fatto il preventivo dovresti avere una buona idea delle condizioni che ti servono per quella stima appropriata. Pensa attraverso tutte le dipendenze del tuo progetto e se potrebbero mai cambiare. Ad esempio, una ipotesi potrebbe essere Tutti i miei utenti utilizzano un browser Web moderno, non è necessario supportare IE6 *. Oppure Il servizio web del mio fornitore avrà tutti i dettagli di reporting degli ordini di cui ho bisogno in una sola chiamata, non ho bisogno di eseguire alcuna ulteriore elaborazione dei dati

- * Questo mi ha già fatto. IE6 è ampiamente utilizzato in alcune organizzazioni ed è un assoluto #### al codice per

La risposta ha menzionato

Make them sit down, read, and agree to your assumptions (or, if you're lucky, get them to give in and give you real requirements).

Quindi questo non è qualcosa che dovrebbe semplicemente rimanere nella tua testa, facendo presupposti che dovrebbero essere un processo di non dare niente per scontato e chiedere continuamente l'accettazione delle ipotesi, al fine di vedere tutti sono sulla stessa pagina.

Solo così puoi essere certo di avere una stima del tempo ragionevole.