Se vai su Google e cerchi “misurare la produttività degli sviluppatori di software” non troverai un bel po 'di niente. Sul serio — Niente.
Nick Hodges, Misurazione della produttività degli sviluppatori

Ormai dovremmo saperlo tutti non sappiamo come misurare la produttività del programmatore.

Non c'è modo chiaro per misurare quali programmatori stanno facendo un lavoro migliore o più veloce, o per confrontare la produttività tra i team. “Sappiamo” chi sono le stelle di una squadra, su chi possiamo contare per la consegna, e chi sta lottando. E sappiamo se una squadra sta prendendo a calci in culo o se si sta trascinando il culo. Ma come lo proviamo? Come possiamo quantificarlo?

Ogni sorta di cose stupide e malvagie possono accadere quando tu provare a misurare la produttività del programmatore.

Ma facciamolo comunque.

Stiamo scrivendo altro codice, quindi dobbiamo essere più produttivi

Gli sviluppatori sono pagati per scrivere codice. Allora perché non misurare quanto codice scrivono - quante righe di codice ottenere consegnato?

Perché abbiamo conosciuto dagli anni '80 che questo è un modo schifoso per misurare la produttività.

Le righe di codice non possono essere confrontate tra le lingue (ovviamente), o anche tra programmatori che utilizzano lo stesso linguaggio lavorando in framework diversi o seguendo stili diversi. Ed è per questo Punti funzione sono stati inventati - un tentativo di standardizzare e confrontare le dimensioni del lavoro in ambienti diversi. Suona bene, ma punti funzione non ce l'ho fatta nel mainstream, e probabilmente non lo farà mai - pochissime persone sapere come funzionano i punti funzione, come calcolarli e come dovrebbero essere usati.

Il problema più fondamentale è quello di misurare la produttività per linee (o Function Point o altri derivati) digitato non ha alcun senso. Un sacco di lavoro importante nello sviluppo del software, il lavoro più importante, coinvolge pensare e imparare, non digitare.

I migliori programmatori dedicano molto tempo alla comprensione e alla risoluzione di problemi difficili, o aiutare altre persone a capire e risolvere problemi difficili, invece di digitare. Trovano modi per semplificare il codice ed eliminare la duplicazione. E molto del codice che scrivono non conterà comunque, mentre iterano attraverso esperimenti e costruiscono prototipi e buttano via tutto per arrivare a una soluzione ottimale.

I difetti di queste misure sono evidenti se consideriamo i risultati ideali: il minor numero di righe di codice possibile per risolvere un problema, e la creazione di semplificato, processi comuni e interazioni con i clienti che riducono la complessità nei sistemi IT. Le nostre persone più produttive sono quelle che trovano modi ingegnosi per evitare di scrivere alcun codice.
Jez Humble, La Lean Enterprise

Questo è chiaramente uno di quei casi in cui le dimensioni non contano.

Stiamo facendo (o risparmiando) più soldi,
quindi dobbiamo lavorare meglio

Potremmo provare a misurare la produttività ad un livello elevato utilizzando la redditività o il ritorno finanziario su ciò che ogni team sta offrendo, o qualche altra misura aziendale come il numero di clienti che utilizzano il sistema, se gli sviluppatori stanno guadagnando di più per l'azienda (o risparmiando più soldi), Devono fare qualcosa di giusto.

L'utilizzo di misure finanziarie sembra una buona idea a livello esecutivo, soprattutto ora che "ogni azienda è una società di software". Queste sono misure organizzative che gli sviluppatori dovrebbero condividere. Ma non sono misure efficaci o giuste della produttività degli sviluppatori. Ci sono troppi fattori aziendali che sfuggono al controllo del team di sviluppo. Alcuni prodotti o servizi hanno successo anche se le persone che li forniscono stanno facendo un lavoro scadente, o fallire anche se la squadra ha fatto un ottimo lavoro. Concentrarsi in particolare sui risparmi sui costi porta molti manager a tagliare le persone e cercare di "fare di più con meno" invece di investire in reali miglioramenti della produttività.

E come Martin Fowler sottolinea c'è un ritardo, soprattutto nelle grandi organizzazioni: a volte possono volerci mesi o anni per vedere i risultati finanziari reali di un progetto IT, o da miglioramenti della produttività.

Dobbiamo cercare altrove per trovare metriche di produttività significative.

Stiamo andando più veloci, quindi dobbiamo essere più produttivi

Misurare la velocità di sviluppo - velocità in Agile: sembra un altro modo per misurare la produttività a livello di team. Dopotutto, lo scopo dello sviluppo del software è fornire software funzionante. Più velocemente offre una squadra, meglio è.

Ma velocità (quanto lavoro, misurato in story points o feature points o giorni ideali, che il team offre in un periodo di tempo) è davvero una misura di prevedibilità, non produttività. La velocità è pensata per essere utilizzata da un team per misurare quanto lavoro possono svolgere, calibrare le loro stime e pianificare il loro lavoro in avanti.

Una volta che la velocità di una squadra si è stabilizzata, Puoi misurare i cambiamenti di velocità all'interno del team come misura relativa della produttività. Se la velocità della squadra sta rallentando, potrebbe essere un indicatore di problemi nel team, nel progetto o nel sistema. Oppure puoi usare la velocità per misurare l'impatto dei miglioramenti del processo, per vedere se la formazione o nuovi strumenti o nuove pratiche rendono effettivamente il lavoro del team misurabilmente più veloce.

Ma dovrai farlo tenere conto dei cambiamenti nel team, quando le persone si uniscono o se ne vanno. E dovrai ricordare che la velocità è una misura che ha senso solo all'interno di una squadra - quella non puoi confrontare la velocità tra le squadre.

Anche se questo non impedisce alle persone di provarci. Alcuni negozi utilizzano l'idea di una storia di riferimento ben nota che tutti i team in un programma comprendono e utilizzano per basare le stime dei punti della storia su. Finché i team non hanno molta libertà su come elaborare le stime, e fintanto che i team lavorano nello stesso progetto o programma con gli stessi vincoli e presupposti, potresti essere in grado di fare un confronto approssimativo della velocità tra le squadre. Ma Mike Cohn lo avverte

Se le squadre avvertono la minima indicazione che le velocità verranno confrontate tra le squadre, ci sarà una "inflazione puntiforme" graduale ma costante.

ThoughtWorks lo spiega velocità <> produttività nella loro ultima tecnologia Radar:

Continuiamo a vedere team e organizzazioni equiparare velocità e produttività. Se usato correttamente, velocità consente di incorporare "il tempo di ieri" nel processo di pianificazione delle iterazioni interne di un team. La chiave qui è che la velocità è una misura interna per una squadra, è solo una stima della capacità per quel dato team in quel dato momento. Le organizzazioni ei manager che equiparano la velocità interna alla produttività esterna iniziano a fissare obiettivi per la velocità, dimenticando che ciò che conta davvero è far funzionare il software in produzione. Trattare la velocità come produttività porta a comportamenti improduttivi del team che ottimizzano questa metrica a scapito del software funzionante.

Rimani occupato

Un manager che conosco lo dice invece di provare a misurare la produttività

“Siamo solo impegnati. Se siamo impegnati a lavorare come dei maniaci, possiamo cercare problemi e colli di bottiglia, risolverli e andare avanti ".

In questo caso misureresti e ottimizzerai per tempo di ciclo, come nella produzione snella.

Tempo di ciclo: tempo di consegna o modifica del tempo di consegna, da quando l'azienda chiede qualcosa a quando lo mette nelle loro mani e lo vede funzionare - è qualcosa che interessa all'azienda, e qualcosa che tutti possono vedere e misurare. E una volta che inizi a guardare da vicino, sprechi e ritardi verranno visualizzati man mano che si misurano i tempi di attesa / inattività, valore aggiunto vs. lavoro senza valore aggiunto, e efficienza del ciclo di processo (tempo totale a valore aggiunto / tempo di ciclo totale).

"Non è importante definire la produttività, o per misurarlo. È molto più importante identificare le attività non produttive e portarle a zero. "
Erik Simmons, Intel

Le squadre possono usare Kanban monitorare - e limitare - i lavori in corso e identificare ritardi e colli di bottiglia. E Value Stream Mapping per capire i passaggi, code, ritardi e flussi di informazioni che devono essere ottimizzati. Per essere efficace, è necessario esaminare il processo end-to-end da quando le richieste vengono effettuate per la prima volta fino a quando vengono consegnate e in esecuzione, e ottimizzare lungo tutto il percorso, non solo il lavoro in fase di sviluppo. Ciò può significare cambiare il modo in cui l'azienda assegna le priorità, come vengono prese le decisioni e chi prende le decisioni.

In quasi tutti i casi che abbiamo visto, rendere più efficiente un blocco di processo avrà un effetto minimo sul flusso di valore complessivo. Poiché la rilavorazione e i tempi di attesa sono alcuni dei maggiori contributori ai tempi di consegna complessivi, adottare processi “agili” all'interno di un'unica funzione (come lo sviluppo) ha generalmente un impatto minimo sul flusso di valore complessivo, e quindi sui risultati dei clienti.
Jezz Humble, La Lean Enterprise

Il lato negativo di equiparare la velocità di consegna con la produttività? L'ottimizzazione del tempo di ciclo / velocità di consegna da sola potrebbe portare a problemi a lungo termine, perché questo incita le persone a pensare a breve termine, e per tagliare gli angoli e assumersi il debito tecnico.

Stiamo scrivendo software migliore, quindi dobbiamo essere più produttivi

“Il paradosso è che quando i manager si concentrano sulla produttività, i miglioramenti a lungo termine sono raramente realizzati. D'altro canto, quando i manager si concentrano sulla qualità, la produttività migliora continuamente. "
John Seddon, citato in La Lean Enterprise

Lo sappiamo correggere i bug in un secondo momento costa di più. Che si tratti di 10x o 100 + x, non importa davvero. E quello i progetti con meno bug vengono consegnati più velocemente - almeno fino a un punto di rendimenti decrescenti per sistemi critici per la sicurezza e critici per la vita.

E sappiamo che i costi di bug ed errori nel software per l'azienda possono essere significativi. Non solo costi di rilavorazione dello sviluppo e costi di manutenzione e supporto. Ma costi diretti per l'azienda. Tempo di inattività. Violazioni della sicurezza. IP perso. Clienti persi. Ammende. Cause legali. Fallimento aziendale.

Suo facile da misurare che stai scrivendo software buono o cattivo. Densità dei difetti. Difetti tassi di fuga (soprattutto i difetti - comprese le vulnerabilità di sicurezza - che sfuggono alla produzione). Metriche di analisi statica sulla base di codice, utilizzando strumenti come SonarQube.

E sappiamo come scrivere un buon software – o dovremmo saperlo ormai. Ma la qualità del software è sufficiente per definire la produttività?

Devops - Misurazione e miglioramento delle prestazioni IT

I team Devops che creano / mantengono e gestiscono / supportano i sistemi estendono la produttività dallo sviluppo alle operazioni. Misurano la produttività attraverso due dimensioni che abbiamo già esaminato: velocità di consegna, e qualità.

Ma devops non si limita alla semplice creazione e distribuzione di codice, bensì esamina le metriche delle prestazioni per la fornitura di servizi IT end-to-end:

1. Velocità effettiva di consegna: frequenza di distribuzione e tempi di consegna, massimizzare il flusso di lavoro in produzione
2. Qualità del servizio: cambiare il tasso di fallimento e MTTR

Non si tratta solo di fornire software più velocemente o meglio. Lo sviluppo e le operazioni collaborano per fornire servizi migliori e più veloci, trovare un equilibrio tra muoversi troppo velocemente o cercare di fare troppo alla volta, ed eccessiva burocrazia e eccessiva cautela con conseguenti sprechi e ritardi. Dev e ops devono condividere responsabilità e responsabilità per il risultato, e per misurare e migliorare la produttività e la qualità.

Come ho sottolineato in un post precedente questo fa metriche operative più importante delle metriche degli sviluppatori. Secondo studi recenti, il successo nel raggiungimento di questi obiettivi porta a miglioramenti nel successo aziendale: non solo produttività, ma quota di mercato e redditività.

Misura i risultati, non output

Nel La Lean Enterprise (che puoi dire che ho appena finito di leggere), Jez Jumble parla dell'importanza di misurare la produttività in base al risultato - misurare le cose che contano per l'organizzazione - non l'output.

"Non importa quante storie completiamo se non otteniamo i risultati di business che ci eravamo prefissati di ottenere sotto forma di condizioni target a livello di programma".

Smetti di provare a misurare produttività individuale dello sviluppatore. È una perdita di tempo.

• Tutti sanno chi sono i migliori artisti. Indirizzali nella giusta direzione, e renderli felici.
• Tutti conoscono le persone che stanno lottando. Ottieni loro l'aiuto di cui hanno bisogno per avere successo.
• Tutti sanno chi non si adatta. Spostali fuori.

Misurare e migliorare la produttività del team o (meglio) livello di organizzazione ti darà ritorni molto più significativi.

Quando si tratta di produttività:

1. Misurare cose che contano - cose che faranno la differenza per il team o per l'organizzazione. Misure chiare, importante, e non sono facili da giocare.
2. Usa le metriche per il bene, non per il male - per guidare l'apprendimento e il miglioramento, non confrontare i risultati tra i team o classificare le persone.

Capisco perché misurare la produttività sia così seducente. Se potessimo farlo, potremmo valutare il software in modo molto più semplice e obiettivo di quanto possiamo fare ora. Ma false misure non fanno che peggiorare le cose.
Martin Fowler, CannotMeasureProductivity

Circa l'autore

Jim Bird è un esperto manager di sviluppo software, project manager e attualmente CTO presso una società di servizi finanziari. È concentrato su problemi difficili nello sviluppo e nella manutenzione del software, qualità e sicurezza del software. Per l'ultimo 15 anni ha gestito team che costruiscono e gestiscono sistemi finanziari ad alte prestazioni. Il suo interesse speciale è come i piccoli team possono essere più efficaci nella creazione di software reale: alta qualità, sistemi sicuri ai limiti estremi di affidabilità, prestazione, e adattabilità. Software che deve funzionare, quello è costruito bene, e costruito per durare. Questo articolo è stato originariamente pubblicato sul suo blog Creazione di software reale.

Un post sul blog rappresenta l'opinione personale dell'autore
e potrebbe non coincidere necessariamente con le politiche ufficiali di Nesma.