Il management superiore della nostra azienda ha definito l'obiettivo per il nostro team di software di essere "il 15% più produttivo" nel prossimo anno. Misurare la produttività in un ambiente di sviluppo software è molto soggettivo, ma dobbiamo ancora elaborare una serie di metriche.
Quali tipi di dati possiamo acquisire per misurare la produttività del nostro team?
Cerco molto di non scrivere non risposte su questo sito ma credo che, in questo caso, dovrò farlo. È l'unica risposta giusta. Ma cercherò di aiutarti con più di una battuta e un "non puoi".
In tutta serietà, non esiste una misura valida della produttività degli sviluppatori. So che questo è difficile da gestire per i manager, ma è un dato di fatto. Riferiscili ad alcuni link di persone molto esperte nel campo. Per un paio di esempi:
So not just is business value hard to measure, there's a time lag too. So maybe you can't measure the productivity of a team until a few years after a release of the software they were building.
I can see why measuring productivity is so seductive. If we could do it we could assess software much more easily and objectively than we can now. But false measures only make things worse. This is somewhere I think we have to admit to our ignorance.
Let's start with plain old productivity. It's rather hard to measure programmer productivity; almost any metric you can come up with (lines of debugged code, function points, number of command-line arguments) is trivial to game, and it's very hard to get concrete data on large projects because it's very rare for two programmers to be told to do the same thing.
Chiedi anche a loro chi è responsabile di tale aumento. Quali misure sono autorizzati a prendere ?
È la mia esperienza che i manager hanno fissato questi obiettivi perché non hanno idea di quali siano gli obiettivi da impostare rispetto ai team di sviluppo. Forse puoi aiutarli con quello.
Spiega loro che tu (o il team) vuoi prendere sul serio i tuoi obiettivi, ma devono essere SMART o sono privi di significato. Suggerire loro alcuni obiettivi SMART. hai un build / server CI ? In caso contrario, impostarne uno è un obiettivo SMART. In tal caso, hai qualche modo di visualizzare statistiche di qualità ? Altrimenti, impostarlo è anche un obiettivo SMART.
Se è così, allora hai qualcosa che è molto misurabile: la qualità del codice. Forse abbassare la tua valutazione del debito tecnico è un obiettivo SMART, che a sua volta migliorerà la produttività, a meno che non stiano assumendo che le persone stiano rallentando, nel qual caso hai un problema completamente diverso da risolvere: visibilità.
Aiutali a darti obiettivi che puoi effettivamente ottenere. Non c'è soddisfazione nell'avere obiettivi che non possono essere dimostrati o confutati tra un anno o in cui perderai tempo a giocare al sistema piuttosto che migliorarlo.
One of my most productive days was throwing away 1000 lines of code.
— Ken Thompson, designer of the original Unix operating system
Misurare la produttività del software non è poi così difficile, sebbene sia in qualche modo impreciso. Esamina i tuoi programmatori e chiedi quale percentuale del loro tempo di lavoro è sprecata per compiti non produttivi, e quali sono. Farli concentrare non su problemi di produttività personale, ma su compiti di lavoro assegnati non produttivi. Alcuni esempi sono:
Tuttavia, a causa di un effetto osservatore , è impossibile legare i risultati del sondaggio a qualsiasi tipo di ricompensa o conseguenze per il programmatore, compresa la gestione arrabbiata che la produttività non ha aumentato il 15%. Faranno il gioco al sistema anche se sospetti è così che vengono utilizzati i numeri, e si finisce con una metrica completamente inutile.
Ciò che puoi fare è usare le risposte per spostare la produttività nella giusta direzione. Scegli i peggiori due o tre e mettici un sacco di energie. Il miglioramento può essere facilmente misurato numericamente per molti dei reclami individuali e, auspicabilmente, quando si ripeterà il sondaggio l'anno prossimo, alcuni dei reclami non verranno più elencati, o almeno segnalati da un numero inferiore di programmatori.
In altre parole, puoi osservare il movimento nella giusta direzione, anche se non puoi quantificarlo.
Sono d'accordo con risposta del pdr . Questa è la strada da percorrere. Tuttavia, ecco un altro tentativo.
La maggior parte degli sforzi di miglioramento del processo devono iniziare, come si è fatto, nel decidere cosa misurare e quindi basare le operazioni correnti.
Che cosa usare come base di riferimento?
Se non stai già facendo 11 o 12, allora hai solo bisogno di fare un altro 2 e ottieni un miglioramento del 15%.
Invece di cercare di concentrarti sulle metriche per i programmatori che, come altri hanno suggerito, sono incredibilmente imprecise, prova a suggerire cose non di codice come le seguenti:
Spiega in dettaglio perché ognuna di queste cose renderà effettivamente un programmatore più produttivo.
Questi sono i tipi di cose che possono guidare la produttività del programmatore, non provare a impostare alcuni obiettivi irraggiungibili intorno a LOC o il conteggio degli errori.
Secondo me, per i programmatori c'è solo una metrica che ha senso: il numero di sviluppatori che lasciano fare un lavoro simile per un'altra azienda.
Se un programmatore è abbastanza infelice da trovare un lavoro altrove, è molto probabile che molti altri programmatori siano anche insoddisfatti e non funzionino correttamente.
Penso che sia difficile da fare, ma possibile, se usi un buon software di gestione dei casi come FogBugz e tieni traccia dei vecchi dati. Ovviamente non puoi dire che miglioreremo le prestazioni con un numero esatto come il 15%, ma puoi sicuramente fare qualcosa al riguardo. Quindi supponiamo di avere:
5 sviluppatori
Ciclo di rilascio di 1 mese
Questi devono essere abbastanza coerenti dal rilascio al rilascio, altrimenti la contabilità per quelli può diventare disordinata. Ecco alcune cose che puoi misurare e migliorare.
- Stime vs tempo di sviluppo effettivo .
Simile alla velocità Agile. Se gli sviluppatori stanno pianificando di lavorare tutto il mese, diciamo 20 giorni o 100 giorni per 5 sviluppatori questo mese. Stimarono tutti i loro compiti e dissero al management che potevano adattarsi a tutte le funzionalità. Ma in realtà ci sono voluti 120 giorni invece di 100 giorni.
i 20 giorni (4 giorni extra per 5 sviluppatori), gli sviluppatori sono stati sottoposti a molta pressione e hanno scritto molto codice spaghetti.
Quindi per migliorare le prestazioni - aumentare le stime per il prossimo mese del 20% e vedere quanto più si avvicina al tempo reale. Continua ad aggiornarlo per le versioni future se è ancora lontano dal marchio. Il miglioramento delle prestazioni non sarà del 20%, ma dovrebbe essere sostanziale, dal momento che ci saranno meno stress, bug e fine settimana lavorativi.
- Quantità di tempo speso dagli sviluppatori per correggere i bug rilevati dal QA
Diciamo che per questo lancio ci sono voluti 5 giorni uomo / giorno per testare il QA.
Puoi provare a migliorare questo numero avendo meno bug:
Continua a misurare i bug fixin time ogni release e dovresti vedere dei miglioramenti se presenti le cose sopra.
- Fai qualche ricerca sui colli di bottiglia allo sviluppo
Potresti scoprire che ci sono altre cose, come la comunicazione tra Business Side e sviluppatori, che stanno avendo un enorme effetto negativo sulle prestazioni. Molte volte un progetto può essere ritardato a causa del creep dell'oscilloscopio o dei requisiti delle funzioni non chiaramente comunicati. Questo di solito accade più e più volte.
Questo è un po 'difficile da misurare, ma l'uso può utilizzare misurazioni da 1. per questo.
- digita più veloce ...
Le parole al minuto sono un modo comprovato per misurare le prestazioni non solo per gli sviluppatori ma anche per chiunque altro utilizzi i computer.
- Misurare le prestazioni dello sviluppo non è facile
Come altre persone hanno già menzionato, non è cosa facile da fare, quindi il modo in cui lo comunichi a "alta direzione" è molto importante. Devono capire che misurare lo sviluppo non è come misurare le vendite. Non ci sono numeri difficili, ma ci sono sicuramente alcune cose che puoi migliorare. Quindi puoi dare loro un piano con alcuni dei miglioramenti e utilizzare le misure dei passaggi 1. e 2. per dimostrare se c'è un miglioramento.
Leggi altre domande sui tag project-management productivity