Domanda

Voglio dire il nome di un progetto di programmazione che hai fatto e quanto tempo hai impiegato, per favore. Il capo non si è mai lamentato, ma a volte sento che le cose impiegano troppo tempo. Ma questo potrebbe essere perché anch'io sono impaziente. Fammi sapere le tue esperienze per il confronto.

Ho anche notato che le cose sembrano sempre impiegare più tempo, a volte molto più a lungo di quanto inizialmente previsto. Non so perché non iniziamo a pianificarlo, ma penso che forse sia per scopi motivazionali.

Ryan

È stato utile?

Soluzione

È meglio semplicemente cronometrare te stesso, registrare le tue stime e determinare la percentuale media di sconto. Dato che, purché tu sia coerente, puoi stimare in modo appropriato i tempi effettivi in ??base a quando credevi di averlo fatto. Non si tratta semplicemente di determinare quanto male si sta valutando, ma piuttosto di tenere conto della regolarità delle inevitabili distrazioni (sia personali che basate sul capo / cliente).

Questo si basa sulla Pianificazione basata sulle prove di Joel Spolsky, essenziale leggendo, poiché spiega che l'altro aspetto importante principale è la suddivisione dei compiti in compiti di dimensioni ridotte (massimo 16 ore), stimando e sommando quelli insieme per arrivare al totale finale del progetto.

Altri suggerimenti

Le stime basate sull'intestino derivano dall'esperienza, ma è necessario dettagliare i compiti coinvolti per ottenere qualcosa di ragionevole.

Se si dispone di una specifica o almeno di alcuni vincoli, è possibile iniziare a creare attività (progettare la pagina degli utenti, progettare la pagina dei tag, implementare la pagina degli utenti, implementare la pagina dei tag, scrivere tag query, ...).

Dopo averlo fatto, aggiungilo e raddoppialo. Se devi coordinarti con gli altri, triplica.

Registra dettagliatamente il tuo tempo reale man mano che procedi in modo da poter valutare la tua accuratezza quando il progetto è completo e affinare le tue capacità di stima.

Sono completamente d'accordo con i poster precedenti ... non dimenticare anche il carico di lavoro della tua squadra. Solo perché hai stimato che un progetto richiederebbe 3 mesi, ciò non significa che verrà realizzato ovunque.

Lavoro in un team più piccolo (5 sviluppatori, 1 lead), molti di noi lavorano su diversi progetti contemporaneamente: alcuni grandi, altri piccoli. A seconda della priorità del progetto, dei capricci della gestione e della disponibilità di altri team (se necessario), il lavoro su un progetto viene intervallato tra gli altri.

Quindi, sì, 3 mesi di lavoro potrebbero essere morti, ma potrebbero essere 3 mesi di lavoro in un periodo di 6 mesi.

Ho realizzato progetti tra 1 e 6 mesi da solo e tendo sempre a raddoppiare o quadruplicare le mie stime originali.

È effettivamente impossibile confrontare due progetti di programmazione, poiché ci sono troppi fattori che significano che le metriche da solo non sono applicabili a un altro (ad esempio, tecnologie specifiche utilizzate, esperienza precedente degli sviluppatori, requisiti di spostamento). A meno che tu non stia eliminando un altro sistema quasi identico a quello che hai creato in precedenza, le tue stime avranno una bassa probabilità di essere accurate.

Un avvertimento è quando stai costruendo la prossima revisione di un sistema esistente con lo stesso team; l'esperienza specifica acquisita migliora la capacità di stimare il prossimo lotto di lavoro.

Ho visto troppi tentativi di metodologia di stima e nessuno ha funzionato. Potrebbero avere un fascino pseudo-scientifico, ma non funzionano nella pratica.

L'unica risposta significativa è l'iterazione relativamente breve, come sostenuto da agili sostenitori: scegliere un ambito di lavoro che può essere eseguito in un breve lasso di tempo, consegnarlo e quindi passare al turno successivo. I budget vengono quindi assegnati a breve termine, con le parti interessate in grado di valutare se i loro soldi vengono effettivamente spesi. Se ci vuole troppo tempo per arrivare ovunque, possono abbandonare il progetto.

Legge di Hofstadter:

"Ci vuole sempre più tempo del previsto, anche quando si tiene conto della Legge di Hofstadter."

Credo che questo sia perché:

  • Il lavoro si espande per riempire il tempo disponibile per farlo. Non importa quanto spietato stia tagliando funzioni inutili, saresti stato più brutale se le scadenze fossero ancora più strette.
  • Si verificano problemi imprevisti durante il progetto.

In ogni caso, è davvero fuorviante confrontare aneddoti, in parte perché le persone hanno ricordi selettivi. Se ti dico che una volta mi ci sono volute due ore per scrivere un quicksort completamente ottimizzato, quindi forse sto dimenticando il fatto che sapevo che avrei avuto quel compito con una settimana di anticipo, e avevo riflettuto sulle idee. Forse sto dimenticando che c'era un bug che ho trascorso altre due ore a riparare una settimana dopo.

Quasi certamente tralascerò tutto il lavoro di non programmazione che continua: incontri, progettazione di architettura, consulenza ad altri che sono bloccati su qualcosa che mi capita di conoscere, admin. Quindi è ingiusto da parte tua pensare a un ritmo di lavoro che sembra plausibile in termini di "seduta lì codifica", e aspettarti che sia sostenuto per tutto il tempo. Questa è la fonte di molti sentimenti dopo il fatto che tu avresti dovuto essere più veloce.

Faccio progetti da 2 settimane a 1 anno. Generalmente le mie stime sono abbastanza buone, a posteriori . All'inizio del progetto, tuttavia, generalmente mi vergogno perché le mie stime sono considerate troppo grandi.

Questo perché considero molte cose che la gente dimentica:

  • Tempo per la correzione dei bug
  • Tempo per le distribuzioni
  • Tempo di gestione / riunioni / interazione
  • Tempo per consentire ai proprietari dei requisiti di cambiare idea
  • etc

Il trucco è usare una pianificazione basata su prove (vedi Joel sul software).

Il fatto è che, se pianifichi un po 'di tempo extra, lo userai per migliorare la base di codice se non sorgono problemi. Se sorgono problemi, sei ancora all'interno delle stime.

Credo che Joel abbia scritto un articolo su questo: ciò che puoi fare è chiedere a ogni sviluppatore del team di definire dettagliatamente il suo compito (quali sono tutti i passaggi che devono essere fatti) e chiedere loro di stimare il tempo necessario per ogni passaggio. Successivamente, al termine del progetto, confronta il tempo reale con il tempo stimato e otterrai la distorsione per ogni sviluppatore. Quando viene avviato un nuovo progetto, chiedi loro di valutare nuovamente il tempo e moltiplicalo con il pregiudizio di ogni sviluppatore per avvicinare i valori a ciò che realmente si aspetta.

Dopo alcuni progetti, dovresti avere ottime stime.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top