Ore di monitoraggio su un progetto

Personalmente penso che tu abbia colpito i due grandi.

Note sulle coppie:

• La direzione ha detto così - "la ragione contrattuale" può essere "quindi sappiamo dove inviare il conto per il tuo tempo ... non una piccola cosa e qualcosa di cui il programmatore dovrebbe prendere nota.

• Problemi esterni al team: ho utilizzato la funzione di addebito del tempo per annotare i problemi provenienti da fonti esterne che evidenziano i luoghi in cui il team deve ricevere assistenza. Il più notevole è stato il problema di Blue Screen of Death che è emerso più volte al giorno: tenere traccia delle ore di dolore e sofferenza era un buon modo per far prendere nota all'IT. L'ho fatto anche per la rielaborazione a causa della progettazione dell'interfaccia errata da parte di team esterni.

• Equilibrio di tempo all'interno del team - il bilancio di progettazione, sviluppo, bugfix, test, gestione del motore di costruzione, ecc. è corretto? Qualcosa sta prendendo troppo tempo? Un buon argomento di squadra

• Norme di gruppo - specialmente quando nuove persone si uniscono al team, la differenza di aspettativa può causare conflitti. Qualcuno si uccide senza motivo, qualcuno lavora una settimana con un sacco di tempo libero mentre il resto della squadra si uccide. Chi ha speso che il tempo non è per il consumo della squadra, ma è un buon indicatore per la gestione che potrebbe essere necessario intervenire. Ho dovuto farlo di più con i nuovi laureati che si uccidevano quando il programma del progetto NON era in crisi.

" Come programmatore, sei tenuto a fare timesheets? "sarebbe la domanda più simile che ha risposte che potrebbero essere utili anche se non so se hai guardato a quella domanda oppure no.

Sono d'accordo sul fatto che se si cerca di misurare le cose troppo bene ci possono essere problemi nel sapere esattamente quanto tempo ci sia voluto, ad es. qualcuno potrebbe avere tempo qualcosa per il più vicino nanosecondo per alcuni giorni di lavoro regolari senza essere abbastanza frustrato. Allo stesso tempo, può essere utile sapere dove viene svolto il lavoro, ad es. gli sviluppatori lavorano principalmente sul supporto o stanno introducendo nuove funzionalità o correggendo bug? Anche se può sembrare un dettaglio solo per la gestione, potrebbe anche essere utile per la squadra sapere che cosa sembrava una perdita di tempo mentre si lavorava su qualcosa.

Ci sono un certo numero di metriche che possono essere derivate se sai {qualcosa} e tempo.

Solo conoscere l'attività e il tempo è utile dal punto di vista del business per tenere traccia dei costi di un progetto. A livello aziendale, di solito sai quanto stai pagando i tuoi ingegneri, quindi conoscere il tempo ti consente di calcolare il costo delle persone per il progetto. In genere, le persone sono la componente più costosa di un progetto software, quindi sapere questo è un vantaggio enorme a beneficio. Non è l'unico costo, ma è utile.

Dal punto di vista di uno sviluppatore, come hai detto tu, il tempo di conoscenza può essere utile per la stima. Le migliori stime provengono dagli ingegneri e per continuare a fornire stime attendibili, gli ingegneri devono perfezionare continuamente le loro stime. Alcuni ingegneri seguono bene il loro tempo, mentre altri hanno bisogno di un piccolo incoraggiamento. Il monitoraggio dettagliato del tempo è un buon modo per fare (o almeno provare a fare) gli ingegneri a monitorare il loro tempo e migliorare le stime. Tuttavia, è utile solo se l'ingegnere vuole migliorare continuamente: è facile trascurare i dati.

Puoi collegare il tempo trascorso alle attività all'efficacia del tuo processo. Ad esempio, diciamo che stai seguendo una metodologia agile. In una determinata iterazione, trascorri 6 ore uomo nelle revisioni del codice e il 35% dei tuoi difetti passa attraverso i test di sistema. Nella prossima iterazione, hai impiegato 12 ore uomo e ora il 30% dei tuoi difetti è stato sottoposto a test del sistema. Hai speso il doppio delle recensioni di codice, ma hai rilevato solo il 5% di difetti in più: ciò solleva una bandiera rossa che il processo di revisione del codice deve essere rivisto. È possibile applicare le stesse tecniche ai requisiti di ingegneria, progettazione, test e così via.

Anche lo sforzo del progetto viene generalmente misurato nel tempo. È abbastanza risaputo che SLOC / time è una misura scarsa di sforzo, ma spesso viene utilizzato un certo livello di output / tempo (funzionalità, story point, valore guadagnato). A volte, viene monitorato solo il numero totale di ore uomo del progetto. In ogni caso, ti consente di sapere quanto tempo le persone stanno inserendo nel progetto.

Se si tiene traccia del tempo a un livello relativamente accurato, lo staff può quindi osservare ciò che sta facendo e può essere incoraggiato a gestire anche il proprio tempo. Se so che il mio capo vedrà che trascorro 5 ore in riunioni che non hanno portato a nulla di significativo, penserò a un modo più rapido per fare le cose. Non conosco la tua squadra, tuttavia, in base alla mia esperienza con un gran numero di persone, puoi vedere tutti i tipi.

La mia idea qui non è quella di usarlo come uno strumento minaccioso, ma di provare a collegare il deliverable con il costo (tempo) delle risorse.

Per ottenere un monitoraggio del tempo quasi accurato, è necessario specificare le attività su un livello coerente. Ad esempio, Crea rapporto come attività può comportare molte altre attività secondarie, pertanto il team deve conoscere il livello di analisi da utilizzare in modo che i dati diventino significativi. Questo non è un lavoro banale per te!

Un altro vantaggio che otterrebbe la tua organizzazione è che se conservi buoni record, potrebbe aiutarti a fare stime in futuro.

Il rovescio della medaglia è che immagino che il 99% dei programmatori odia il foglio temporale e conosco alcune persone che sono state quasi insultate quando gli è stato chiesto di prepararle!

Un altro vantaggio è che perderai tempo nella raccolta di informazioni sul tempo e nell'analisi di queste informazioni.

Il motivo più importante per stimare le ore di sviluppo precise al livello delle ore è

Economia

È perché le parti interessate vogliono sapere quanto costerebbe loro sviluppare un progetto, implementare una funzione o persino svolgere un'attività. Il nostro proprietario del prodotto dice sempre:

How many hours would it cost? Tell me that, and I'll tell you whether to implement it or not.

Dipende dalla precisione di cui stai parlando.

Per quanto mi riguarda, la prassi migliore è misurare fino a circa 15-30 minuti a che ora hai speso per quale progetto. Questa volta non si tratta solo della programmazione o del tempo di progettazione, ma si verificano pause bagno o chiacchiere da ufficio. Se lo fai, ti dirà di più delle semplici stime e fatturazione. Ti consente, il programmatore, di tracciare la tua performance.

Dovresti chiederti quanto dovrebbe durare questo progetto? Quanto dovrebbe durare questo compito? Quindi determinare quanto tempo è effettivamente occorso. Ti sei comportato molto velocemente rispetto a quanto avresti stimato? Quali fattori interni sono cambiati e sembra aver accelerato le cose? Quali fattori esterni? Ci è voluto più tempo? Perché? Conoscere queste cose può prepararti meglio per progetti futuri e manutenzione.

Tuttavia, avvertirò di rintracciare i numeri a grana fine (1-15 minuti). È inutile. Prima di tutto, qualsiasi attività su cui lavori (dove un'attività è definita come un problema nel sistema di tracciamento dei bug) che viene adeguatamente documentata, registrata e codificata richiederà almeno 15 minuti, probabilmente più vicini a 30. Dico stick con 30, quando fornisci interruttori di contesto, documentazione, interruzioni per il bagno, ecc ... che dovrebbero essere tanto dettagliati quanto devi ottenere.