Quanto è possibile stimare il tempo per programmare i progetti? [duplicare]

Il nostro ospite Joel raccomanda programmazione basata sull'evidenza , che include metodi per tenere conto di stime imprecise , interruzioni e distrazioni e tutti gli altri soliti sospetti.

Gli elementi bang più grandi:

• La persona che fa un dato lavoro ha l'ultima parola sulla sua stima. Nessun manager, lead o comitati sono autorizzati a superare le stime, solo riassegnare il lavoro a qualcun altro.
• Più interrompi i compiti, più affidabile sarà la stima finale. L'effetto è duplice: in primo luogo, gli errori di sovrastima e sottovalutazione tendono a cancellarsi a vicenda, e in secondo luogo, per eseguire la ripartizione, si finisce per pensare al lavoro in maggiore dettaglio, migliorando l'accuratezza complessiva.

Mi piace molto il libro Stima del software: Demistificare l'arte nera di Steve McConnell. Un paio di punti davvero importanti su cui si concentra:

1. Stai cercando una stima o un obiettivo? Una stima significa "Quanto ci vorrà per implementare queste funzionalità?" Un obiettivo significa "Quante funzionalità posso implementare entro questa data?" Sono due cose diverse, ed è importante assicurarsi che tutte le persone coinvolte sappiano di che cosa stai parlando, e non confondere loro due.

2. Attenzione a dare un preventivo con troppa precisione, specialmente prima. Non dare stime a un punto; se la tua ipotesi migliore all'inizio di un progetto è di 4 settimane, valuta qualcosa come "da 2 a 8 settimane". È impossibile essere più precisi fino a quando non lavorerai attraverso le fasi del progetto (sviluppo dei requisiti, design, ecc.) Che elimini parte dell'incertezza.

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 una bella esperienza con la pianificazione del poker, più la mia squadra lo usa, migliori sono le loro valutazioni (in più è divertente!)

Lavorare come libero professionista è un problema costante per me. Se mi capita di sbagliarmi, perdo soldi.

Il problema con la stima per la programmazione è precisamente quello che molte persone hanno identificato qui - sono le incognite e le trame che possono soffiare e stimare in terre mai più.

Quindi sempre più io quello che uso è un approccio duplice

A. Se il problema è in un dominio noto su un software che conosco perfettamente, eseguo una semplice dissoluzione mentale e fornisco una citazione. Spesso con i clienti chiedono un ballpark in anticipo quando discutono del progetto e con questi sono di solito felice di essere d'accordo - Sono sul lato della cautela, ma questa è solo un'esperienza basata su progetti precedenti.

B. Se il problema è un dominio sconosciuto. In questi casi cercherò di identificare quali sono i problemi chiave in anticipo e codificheremo un caso di test intorno a loro per "scoprire" il problema. A volte si può convincere il cliente a pagare per questo come studio di "fattibilità", ma anche se non si può mettere il tempo a disposizione e il problema è più economico che quotare il client X, trovarlo ha bisogno di nX tempo per risolverlo.

Identificare quali problemi rientrano in A o B, e identificare quali sono gli elementi chiave in B, è un'esperienza negativa, ma penso che la regola generale sia universalmente applicabile: isolare sempre i problemi cruciali in primo piano e affrontarli prima. Una volta che sono a conoscenza, le tecniche più convenzionali possono essere utilizzate con una certa sicurezza.

Questo è il miglior metodo che abbia mai usato: link

Non è ancora perfetto, ma se fatto bene almeno ti porta al ballpark.

Ecco due metodi di stima che ho usato in passato. Funzionano, ma non li consiglio.

1. Stima quanto pensi che dovrebbe essere necessario, quindi raddoppialo. All'inizio di ogni progetto, ho chiarito che le modifiche aumenterebbero il tempo. Vorrei anche ricordarlo ogni volta che veniva richiesto un cambiamento. È molto più che altro il metodo di stima dei tuoi pantaloni, ma era impossibile stabilire qualcosa di realistico perché la società non credeva nelle metodologie o nelle riunioni.

2. Sarà fatto quando sarà finito. Questo di solito funziona solo per i progetti freebie di tempo libero, ma sono riuscito a convincere un ex manager di questo quando è diventato saggio per il metodo double-your-guess. Penso che l'unica ragione per cui ha funzionato è che il beneficio atteso dal progetto era enorme e che la necessità di una soluzione era considerata critica. La loro unica alternativa era comprare software off-the-shelf, che si rifiutavano di fare il 99% delle volte.

Ci vorranno dalle 6 alle 8 settimane.

Trascorri un paio di giorni di pianificazione e abbatti il progetto in unità di 2 o 3 giorni, quindi dedica il tempo necessario alle attività non di sviluppo. Ma per qualcosa di più lungo di qualche settimana, si tratterà di una stima basata su altri progetti di difficoltà simile.

Quando accadono cose inaspettate, reagiamo modificando l'architettura, il design o il codice, ecc. La stima stessa dovrebbe evolvere insieme a quelle cose. Non dovrebbe essere un valore determinato all'inizio di un progetto e mai aggiornato quando tutto altro può essere aggiornato ed evolvere durante il progetto.

Una cosa è che la stima è possibile solo se stai lavorando con qualcosa di familiare, usando tecnologie familiari. Se stai lavorando su qualcosa di veramente nuovo, le stime del tempo certamente non valgono. Tuttavia, fare un piano (rompendo il progetto a pezzi e ordinandoli in qualche modo) è di per sé molto vantaggioso, anche se le stime del tempo sono solo delle ipotesi. Il tuo PM probabilmente lo sa; la cosa principale è rendere una sorta di piano , non che le stime siano corrette.

conta l'esperienza Sai cos'è successo l'ultima volta, e la volta precedente, e sai quanto puoi fare di un particolare tipo di compito - quindi la stima è davvero facile. Scegli un numero fuori dall'aria basandoti su un'ipotesi plausibile. Man mano che acquisisci più esperienza nella stima e nello sviluppo, scoprirai che puoi migliorare.

Non sarai mai abbastanza perfetto per soddisfare un project manager e i suoi diagrammi di Gantt (sospiro, tali cose dovrebbero avere bordi sfocati abilitati di default) ma tu sei stimando il tempo, non dando un garantito tempo.

Per me, è solo qualcosa che viene con l'esperienza. Quando ero un ragazzino come programmatore, mi sembrava di aver sempre sottovalutato la lunghezza di un progetto. Come hai detto, le cose sarebbero venute fuori e il progetto avrebbe richiesto più tempo. Ora che ho "tempo di volo" sono molto più bravo ad anticipare che cosa sono quelle "cose". Le cose inaspettate continueranno a succedere, ma in generale gli intervalli di tempo sono molto più precisi al giorno d'oggi.

Raccomando caldamente "Agile estimating and planing" di Mike Cohn. Descrive la stima relativa basata su punti che è più facile fare dalla natura umana. Questo libro descrive anche la pianificazione del poker che è davvero divertente.