Come posso monitorare la produttività della programmazione su base giornaliera? [chiuso]

Come posso monitorare che sto sviluppando software più o meno produttivo rispetto ai giorni precedenti?

C'è una risposta semplice: non puoi. E inoltre, non dovresti.

Vuoi misurare la tua produttività, ma puoi generalizzare: come puoi misurare la produttività dei programmatori? Prima di tutto devi definire cosa intendi per "produttività": quantità di codice prodotta? Quantità di progettazione (o specifica) implementata? Numero di problemi risolti? Qualità del codice prodotto? (Sì, la qualità è un contatore di produttività, è possibile produrre molti codici errati o pochi codici validi, cosa è stato più produttivo?). Tutti questi valori possono difficilmente essere mappati su una base giornaliera e qualsiasi tentativo di tracciare la produttività giornaliera è pericoloso per il progetto, per l'azienda e per il programmatore.

Il mio consiglio è di definire chiaramente ciò che intendi come "produttività", quindi definire un'unità di misura e applicarla su base settimanale e mensile.

Direi che il modo migliore per misurare la tua produttività è fissare un obiettivo ogni giorno per quello che vuoi aver fatto quel giorno e, se lo completi, lo consideri produttivo. È una misura abbastanza soggettiva, ma molto probabilmente la troverai molto più gratificante di una oggettiva.

Entrambi i suggerimenti che seguono possono essere approssimativamente adottati per le tue necessità, ma in entrambi i casi devi fare preventivi preventivi e poi analizzarli ad hoc (e onestamente, non sono sicuro se esiste un altro modo efficace per misurarlo, sono d'accordo con TheLQ che le righe di codice per periodo di tempo non sono affatto utilizzabili).

Metodologie di sviluppo Agile
Sebbene non sia sicuro dell'efficacia con cui può essere applicato a un singolo scenario di sviluppo, alcuni dei principi utilizzati in Agile possono rivelarsi utili in ciò che si intende realizzare. Agile lavora in cicli in cui gli sviluppatori mirano a implementare storie (attività) che vengono segnate (in punti) in base alla complessità dell'implementazione all'inizio di un ciclo di sviluppo e quindi analizzate alla fine di ogni ciclo. Ciò consente di determinare la velocità, ovvero il numero di punti che uno sviluppatore o una squadra può completare in un singolo ciclo di sviluppo.

Se il modo in cui lavori ti consente di adottare alcuni dei principi e organizzare il tuo lavoro in cicli, puoi utilizzare la metrica della velocità per ciclo di sviluppo per monitorare la tua efficienza. Si noti che i cicli di solito durano 2-3 settimane, tuttavia dovresti essere in grado di accorciarli quando lo usi solo per te stesso. Tutto dipende dal fatto che puoi adottare una tale metodologia nel tuo ambiente.

Pianificazione basata sulle prove
Anche se è principalmente pensata per migliorare le stime, dovresti essere in grado di utilizzarlo in modo efficace per tenere traccia delle tendenze in calo della produttività.

Concordo con Lorenzo, definisci la produttività.

Ho anche fatto questo: 1. Suddividi tutti i compiti (livello superiore o livello inferiore). 2. Stimare l'orario di lavoro per ogni attività (non dimenticare di impostare il buffer di ritardo per ogni attività). 3. Termina l'attività. 4. Rivedi ciascuna delle attività e verifica se sei abbastanza produttivo o meno.

Ecco una misura significativa e accurata della produttività che prevede l'acquisizione di più snapshot di pianificazione basate su prove :

Dopo aver raccolto alcune statistiche per alcuni giorni, esegui la simulazione Monte Carlo e osserva il grafico, che dovrebbe apparire così:

Quindi fai un altro giorno di lavoro ed esegui di nuovo la simulazione. Se quel giorno eri produttivo, il grafico dovrebbe cambiare qualcosa del genere:

Soprattutto, se tu fossi un prodotto quel giorno, la probabilità della data di spedizione in una determinata data dovrebbe aumentare dall'ultima volta che hai eseguito la simulazione prima di quel giorno di lavoro. Se diminuisce, in quel giorno eri meno produttivo.

Naturalmente, l'accuratezza di EBS aumenta con il tempo e l'esperienza, quindi questo può essere un altro motivo per la modifica del valore di probabilità della data di spedizione. Ecco perché vuoi iniziare a farlo almeno dopo alcuni giorni di lavoro campionato. Anche senza questo, però, se tu fossi significativamente più produttivo in un giorno o nell'altro, la probabilità dovrebbe aumentare in modo abbastanza evidente.

Il conteggio delle righe di codice è una misurazione imperfetta in quanto non offre informazioni sulla qualità del codice ma può essere utilizzato per determinare la produttività generale. A seconda della lingua che usi ci sono diversi strumenti che conteranno le righe di codice per te, ma ho richiesto che BitBucket, un repository Git, aggiungesse statistiche relative alla produttività.

https://bitbucket.org/site/master/issue/4307/feature-request-contributor-statistics

Misura il tempo impiegato da te seduto al computer la mattina fino a quando non svolgi alcuna attività non lavorativa, come 9gag, facebook, reddit, ecc. La tua produttività quel giorno è proporzionale a quel numero.

Supponi per un momento che essere produttivi gestisca il tuo tempo in modo tale da utilizzare tutto il tuo tempo di lavoro per lavorare verso il completamento dei tuoi compiti, e che tutto ciò che contribuisce a perdere tempo - vale a dire: il tempo trascorso a non completare i tuoi compiti - non è- produttivo.

L'unica cosa che puoi davvero fare è registrare il tuo tempo quando sei impegnato in varie attività durante la giornata. Il time boxing è una tecnica utilizzata per vari scopi, ma si adatterebbe a questo sforzo per registrare l'attività durante un giorno. Trascorri 15 minuti con un timer semplicemente facendo qualche compito. Se l'attività è qualcosa su cui dovresti lavorare, il tuo tempo è stato produttivo. Se ti sei ritrovato a modificare il tuo blog, a leggere un giornale o a sognare ad occhi aperti quella bella ragazza in contabilità, allora il tuo tempo è stato probabilmente improduttivo. Aggiungi i tuoi minuti alla fine della giornata e avrai un'idea di quanto sei produttivo ...

Ma c'è un problema! Che cosa fai di quegli altri minuti ... sai, fai una pausa di 5 minuti, vai a pranzo, il tuo capo ti interrompe per raccontarti quel grosso pesce che non ha catturato durante la sua ultima battuta di pesca? Accedi anche a tutto ciò. Il tempo trascorso in una pausa non viene perso se contribuisce alla tua salute mentale e al tuo benessere ... solo se non fai una pausa di 5 minuti ogni 10-15 minuti !! Per quanto riguarda il resto, le interruzioni, la gestione di altri problemi relativi al lavoro .. tutto questo può essere monitorato.

Ovviamente puoi trovarti ossessionato da questo genere di cose, e dio ti aiuterà se il capo è una di quelle persone che ti vedono il time-boxing e lo usano per giustificare ragioni per accumulare più lavoro o criticare i tuoi sforzi. Vedete, il problema con l'ossessione per le ore produttive è che si può lavorare per un giorno intero e finire per non ottenere nulla di reale rilevanza. Alcuni giorni puoi scrivere codice come se si stesse sciogliendo il burro dal cervello e su quel sandwich che chiami il tuo schermo ... mentre altri giorni puoi avere un grave blocco mentale mentre provi 357 modi diversi di fare lo stesso cosa, solo per vederlo fallire. Molti direbbero che i "fallimenti" continui possono essere improduttivi e che di per sé non saranno aiutati, non importa quanto tempo cronometri e registri le tue ore durante il giorno.

L'altro modo di vederlo è semplicemente quello di fissare un numero di obiettivi, da completare durante un giorno e una settimana, e quindi lavorare per completarli. Se effettivamente raggiungi i tuoi obiettivi, puoi sostenere che sei stato produttivo e se non li raggiungi, potresti dover capire perché non li hai raggiunti e decidere se eri o non eri produttivo in base ai motivi reali per cui hai perso i tuoi obiettivi. In definitiva, se fornisci il codice di lavoro quando è necessario e se riesci a superare i test e a completare un'attività, sei stato produttivo. Le misurazioni saranno utili solo se esiste un motivo legittimo per analizzarle statisticamente in un secondo momento.