Alternative alle metodologie di tracciamento del tempo [chiuso]

Le stime del software sono sempre difficili. Il software è un business creativo e la creatività cresce e cala. Sto appena iniziando a riprendermi dopo una settimana di grave esaurimento - l'altra sera mi ci sono volute ore per svolgere un'attività che avrebbe dovuto essere di 15-30 minuti ...

Considera inoltre che ogni sviluppatore ha diverse abilità di stima. Gli sviluppatori più disciplinati o senior tenderanno ad essere più precisi e gli sviluppatori più giovani o indisciplinati saranno meno precisi. Inoltre, la loro precisione cambia nel tempo (non sempre per il meglio).

Nella mia esperienza di consulenza personale cerco di fondere una stima realistica con un massimale. Sostanzialmente dicendo "Mi aspetto che questa funzione duri 7-10 ore, ma potrebbe arrivare a 18 - al massimo, anche se occorrono 40 ore, ti verranno addebitati per 18". Di solito questo tipo di approccio è nuovo per i clienti e alcuni flat-out lo respingono con "dammi un prezzo fisso" - quei clienti ottengono la stima del massimale (o declino gentilmente i loro affari). Per i clienti che accettano questo approccio, capiscono che seguirò onestamente il tempo e il loro conto finale effettivo rifletterà il mio tempo trascorso (ma non supererà il mio massimale). Essenzialmente questo è un approccio lean con una garanzia aggiunta; e il cliente è consapevole che eventuali modifiche ai requisiti introducono modifiche alle stime.

Nel complesso questo approccio ha funzionato bene per i clienti disposti ad accettarlo. Il mio obiettivo personale è quello di ottenere la loro fiducia e ripetere gli affari, quindi è nel mio interesse essere onesto e cercare di entrare bene sotto il soffitto - ed è nel loro interesse essere utile per tenermi sotto le mie stime (evitando l'incertezza, modifiche tardive, ecc. - Correggo le stime se le modifiche sono qualcosa che va oltre il minore).

Se non lo fai, ti suggerisco di leggere Il Mese di Mythical Man

Dai un'occhiata alla programmazione basata sull'evidenza . Può davvero aiutarti a capire quanto saranno accurate le tue stime.

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...

Il problema con questo metodo è che non tiene conto del rischio intrinseco nelle stime. Una best practice per qualsiasi stima è di esprimerla come intervallo di tempo, ad es. 50 ore ± 15 ore o qualcosa di simile. Il termine dell'errore è difficile da inventare, ma nessuno ritiene che occorreranno comunque esattamente 50 ore.

Ci sono altri approcci oltre al modello dei prezzi fissi; potresti utilizzare una tariffa più bassa e fatturare ore dirette, ma in questi giorni i tuoi clienti probabilmente vorranno trasferirti il rischio. Va bene, ma significa che è necessario addebitare un premio di rischio ragionevole in base al range di stime di tempo che si presentano.

Facciamo stime con un fattore di "incertezza", piuttosto che tentare di stimare con fattori "+/-". I programmatori possono facilmente dirti quanto tempo ci vorrà "assumendo che nulla vada storto". Quello che non possono facilmente dirti è quanto tempo ci vorrà se qualcosa va storto. Quindi aggiungiamo un fattore di incertezza: "L" significa "aggiungi 25%" - "M" significa "aggiungi 50%" e "H" significa "aggiungi 100% - potrebbe raddoppiare". Il tempo reale tende ad essere compreso tra il tempo stimato e la stima più il tempo di incertezza.

Per quanto riguarda TRACKING il tuo tempo, il metodo più accurato è scrivere un programma che compaia una finestra di dialogo ogni minuto e ti chiede "cosa stai facendo?", con una casella di riepilogo a discesa delle attività possibili. L'unica voce di cui hai veramente bisogno in quella casella di riepilogo a discesa è il "tempo di tracciamento", perché se sei interrotto ogni minuto, non otterrai mai qualcos'altro. Lo stesso principio vale anche per intervalli di 15 minuti, ma non altrettanto male.

Quello che facciamo è eseguire un piccolo programma che ci consente di aggiungere compiti a un elenco e selezionare su quale stiamo lavorando, facendo in modo che sommi il tempo. Se ci dimentichiamo di spostare il selettore sul compito corretto, i totali sono modificabili. Tutto ciò che non è in una delle righe va a "misc". Non è completamente preciso, ma la precisione totale è meno importante di ottenere il tempo di flusso.