Come dici tu - usare i numeri per giudicare le persone finisce quasi sempre male se non è mitigato dal buon senso e da altri fattori.
Personalmente non sono un fan dei parametri di efficienza come quello che descrivi. È davvero importante se una persona impiega 40 ore e fissa 20 bug e un'altra spende 50 ore e risolve 20 bug - se entrambi hanno risolto 20 bug in una settimana, è importante che entrambi siano sullo stipendio? Anche se un ragazzo riesce a risolvere 20 bug in 30 ore, eppure consuma 20 ore di tempo da altre persone mentre lo fa, è meglio o peggio che il ragazzo "meno efficiente" che ha lavorato totalmente da solo e il cui lavoro fa risparmiare sempre tempo per le altre persone in seguito.
Ho esaminato quanto segue, e ho vagamente considerato quanto valore netto è stato dato alla squadra:
Metriche di sviluppo
-
quante funzioni di quale dimensione è in grado di completare ciascuna persona in una fase o in una versione. In cascata, farei questa fase per fase - progettazione di alto livello, progettazione dettagliata, test codice / unità - in Agile, sarebbe sprint a sprint. Di solito ho una sensazione generale di caratteristiche piccole, medie o grandi. Quando si utilizza il senno di poi, vado con le dimensioni che la funzione si è rivelata, rispetto alla dimensione che pensavo sarebbe stata quando abbiamo iniziato.
-
quante volte ogni individuo ha ricevuto una funzione che è cresciuta su di loro? Alcune persone sono migliori di altre nella gestione dell'ambito. Ognuno di noi ha una caratteristica problematica di tanto in tanto che non può essere controllato, ma alcune persone sembrano avere il problema di funzionalità in continua crescita. Se 9 caratteristiche su 10 sono cresciute da piccole a grandi per una singola persona, comincio a capire se quella persona ha problemi nel controllo dell'ambito.
Se possibile, direi a tutti i costi, evitare di entrare in SLOC per sviluppatore. Non solo è un lasso di tempo poiché è davvero difficile capirlo in molti progetti complicati - sta anche misurando la cosa sbagliata. 1 elegante linea di codice vale 100 righe sciatte, e caratteristiche diverse richiedono approcci diversi. SLOC per sviluppatore ti porta quasi sempre ad una posizione "more"="migliore", e non è così. In molti casi, voglio sapere che lo sviluppatore ha preso il codice che avevamo già fatto e fatto fare qualcosa di nuovo con un minimo di rilavorazione e nuovo sviluppo - questo è ciò che farà un grande prodotto nel lungo periodo - e questo è il ragazzo che si fa fregare dalle metriche SLOC - ci vuole molto tempo per aggiungere elegantemente un codice base, e se lo fai bene, aggiungi poche righe di codice nel processo.
Metriche dei bug
Personalmente, ritengo di avere più scorte di metriche relative ai bug rispetto alle metriche di sviluppo. I bug possono creare o distruggere un prodotto, quindi voglio sapere che:
-
stiamo trovando quanti più bug possibili con il minor sforzo possibile
-
quando i bug sono corretti, non introducono nuovi bug che devono essere trovati e risolti
-
introduciamo il minor numero possibile di bug al prodotto quando aggiungiamo funzionalità al prodotto
-
nessuna parte del prodotto è così esoterica che solo un ragazzo può risolvere i bug lì
Da quello, guardo:
-
medie di bugfix - preferibilmente per tipo di bug - rispetto alle medie individuali. Un ragazzo è in grado solo di aggiustare la softball, facile vedere i bug? Un ragazzo è in grado solo di correggere gli errori nella sua area? è un ragazzo che impiega un'eternità a sistemare bug apparentemente semplici? È cattivo o buono? A volte il ragazzo che impiega più tempo è anche il ragazzo che ha dei bug post-bug-fix in modo significativo, perché ha ripulito un'intera area che avrebbe avuto altri 10 bug che ora sono andati ...
-
tasso di rifiuto della correzione dei bug - chi riceve un sacco di bug restituiti perché ha affermato di averli risolti, ma i test successivi hanno mostrato che il bug non era stato risolto?
-
aree di codice errate? - C'è quasi sempre un'area problematica e quasi sempre saprai dove si trova, ma controlla le tue metriche e verifica se è VERAMENTE l'area con il maggior numero di bug. Da dove provengono i bug, quali sono i tipi più comuni di bug? Questo sta esaminando più a fondo i bug caso per caso e vedendo se qualcuno di essi è qualcosa che lo sviluppatore dovrebbe avere / avrebbe potuto trattare prima della fase di test.
Ti suggerisco caldamente di centrare le tue metriche, il più possibile, sul prodotto e non sugli sviluppatori . È più facile estrarre le metriche dai tuoi strumenti in quel modo, dal momento che il tuo CM e il tuo sistema di gestione dei bug sono preoccupati per il tuo prodotto, non per la tua gente. E ti costringe a fare un po 'di interpretazione quando riesamina gli sviluppatori - in ogni momento, da un numero a una persona, hai bisogno di cosa - che cosa riflette questo numero ed è davvero un'indicazione di un problema con una persona, o con il modo in cui il lavoro è fatto?