it-swarm.it

Metrica con cui rendere responsabili gli sviluppatori

Ho fatto una domanda sulle righe di codice all'ora e ne ho strappata una nuova. Quindi la mia domanda di follow-up maturata è questa:

Se non linee di codice, allora qual è una buona metrica con cui misurare (per ora/giorno/unità di tempo) l'efficacia dei programmatori remoti?

72
Kyle

In 16 anni non ho mai trovato una metrica realizzabile del tipo che stai cercando.

Essenzialmente per essere utile, qualsiasi cosa dovrebbe essere misurabile, rappresentativa e insostituibile (cioè il sistema non può essere giocato da sviluppatori intelligenti). Esistono semplicemente troppe variabili nello sviluppo del software per renderlo misurabile come lavoro pezzo in questo modo.

Il più vicino si ottengono progressi rispetto alle stime, ovvero quante attività stanno completando all'interno delle stime concordate. Il trucco qui è (a) ottenere stime buone ed eque e (b) capire dove sono state superate le stime per buoni motivi per i quali lo sviluppatore non può/non deve essere biasimato (è qualcosa che era davvero più complesso del previsto). In definitiva, se spingi troppo forte gli sviluppatori, è probabile che tu stia trovando gradualmente delle stime che si avvicinano a un livello in cui vengono sempre rispettate non a causa di una maggiore produttività ma a causa di tempistiche ridotte.

Andare troppo oltre in termini di stime (riducendole per creare pressioni da consegnare) e si creano scadenze fasulle che gli studi hanno dimostrato non aumentano la produttività e possono avere un impatto sul morale del team (vedere Peopleware per ulteriori informazioni ).

Ma essenzialmente mi chiedo se stai osservando un problema leggermente falso. Perché i programmatori remoti sono diversi dagli altri programmatori quando si tratta di misurare la produttività? Come si misura la produttività dei programmatori non remoti?

Se si tratta di non fidarsi di loro per lavorare in remoto, questo è fondamentalmente un problema di fiducia più ampio. Se non ti fidi che lavorino da casa, allora o devi stabilire quella fiducia, non lasciarli lavorare da casa, o trovare un modo per accontentarti che stanno effettivamente lavorando quando dovrebbero essere.

101
Jon Hopkins

Le metriche funzionano meglio nelle fabbriche e i programmatori non lavorano su una catena di montaggio.

Capisco perfettamente il desiderio di misurare la produttività.

Ma useresti la stessa metrica per un medico di famiglia e un cardiochirurgo? Che ne dici di Michelangelo che dipinge la Cappella Sistina e di un ragazzo in Messico che fa scattare quadri Elvis di velluto nero?

Louis de Broglie scrisse una tesi di dottorato che era così breve che gli esaminatori la avrebbero respinta - tranne che de Broglie era un aristocratico di alto livello e avevano bisogno di una buona scusa. Quindi gli esaminatori lo inviarono a Einstein, che non solo non lo respinse, ma lo deferì al comitato Nobel, e de Broglie ottenne il Premio Nobel per la fisica cinque anni dopo.

Le misure numeriche funzionano meglio su lavori ripetitivi, come ghisa o bulloni di avvitatura sulle portiere delle auto. Ma se stai ripetendo il codice che è stato fatto prima, non hai bisogno di un programmatore, hai solo bisogno di un copia e incolla. La programmazione è fondamentalmente una disciplina creativa e la produttività dipende interamente da ciò che stai facendo.

Alcuni giorni, estraggo 1000 righe di codice. Oggi risolverò i bug della geometria delle coordinate e il codice potrebbe ridursi. Se dovessi correggere un bug in un driver del kernel Linux, potrei dedicare tutto il giorno al debug e non scrivere una nuova riga di codice.

Misurare la produttività del programmatore è molto, molto, molto soggettivo.

Se vuoi sapere se Joe è produttivo, trova Sally e Ralph, che sanno cosa sta facendo Joe e sono competenti nelle stesse aree, e chiediglielo.

Il miglior sistema numerico che abbia mai visto è stato la pianificazione dei punti di poker di Agile. Questo è solo un modo stravagante di chiedere a Joe, Sally e Ralph quanto credano che il prossimo lavoro di Joe sarà probabilmente. Quindi è possibile misurare la produttività punti per settimana per ciascun membro del team. Ma anche allora, ci vuole un po 'di tempo per calibrare le stime di una squadra, e i numeri sono sfocati e facilmente eliminabili.

Molte persone desiderano stime di produttività in modo da poter pianificare la pianificazione. È una specie di teoria "collegalo a MS Project, guarda il percorso critico e c'è la tua data di spedizione". Non ho mai visto quel lavoro, ci sono troppe incognite. Se lo desideri, usa Waterfall, progetta tutto in anticipo, non consentire ordini di modifica ed essere comunque deluso.

48
Bob Murphy

L'unica metrica che utilizzo è quantità di software funzionante che produce per un dato quantità di denaro ho investito.

Indipendentemente dal suo programma, se lavora in remoto o no, il numero di pause che prende, le metodologie che usa o il numero di ore lavorative.

Per software funzionante Intendo:

Elenco delle funzioni definite dall'utente/cliente che soddisfano il livello di qualità richiesto

Per quantità di denaro:

Quanto l'utente/cliente ha pagato per le funzionalità definite + i costi di manutenzione

Quindi ha una diretta su come è costruito e sulla qualità del lavoro prodotto ma non è legato a nessuna metrica della linea di codice sorgente.

42
user2567

È necessario uno sviluppatore o un caposquadra con esperienza (che non è associato a quei programmatori remoti) per stimare quanto tempo può richiedere un'attività e l'efficacia viene misurata confrontando il tempo richiesto con le stime. Per essere sicuri che le stime siano buone, puoi scegliere casualmente alcune attività e farle eseguire da un team interno che hai sotto controllo.

23
user281377

Un altro modo interessante per misurare la produttività sarebbe contare i test automatizzabili revisionati da un manager al giorno. Lo sviluppatore ottiene:

  • un punto per scrivere un test automatizzabile (e passare la recensione) e aggiungerlo alla suite di test di regressione,
  • un punto per farli passare, senza causare altri fallimenti del test di regressione.

Lo sviluppatore e il gestore possono migliorare congiuntamente il sistema:

  • concordare congiuntamente le aree importanti di sviluppo e sperimentazione
  • revisione ed esecuzione indipendenti della suite di test.
  • decidere di non creare una funzionalità che abbia vantaggi commerciali limitati ma richiede molti sviluppi e test necessari per fornire tale funzionalità. (La riga di codice più produttiva è quella che hai deciso di non scrivere perché non offre alcun vantaggio commerciale).
  • partizionare il sistema in un'architettura (come model-view-controller) che facilita lo sviluppo incrementale delle funzionalità senza rompere l'intero sistema.

Lo sviluppatore non può giocare la metrica perché:

  • i test ridondanti verranno bloccati dalla revisione del gestore.
  • i test a grana fine possono essere bloccati dalla revisione del responsabile.
  • test a grana fine miglioreranno la qualità del sistema.

Il gestore non può giocare la metrica perché:

  • rifiutare troppi test porterà all'attrito degli sviluppatori.
  • richiedere troppi test renderà difficile rifiutare una scadenza successiva.

Lo sviluppatore non può fregare il manager perché

  • Ogni unità di funzionalità fornita con i test deve anche superare la suite di regressione. vale a dire, questo costringe lo sviluppatore a svilupparsi attentamente senza rompere altro codice.
  • Qualsiasi rivendicazione di lavoro deve essere dimostrabile superando nuovi test e test di regressione.

Il manager non può fregare lo sviluppatore perché.

  • Ogni unità di funzionalità richiesta deve includere casi di test chiave e una stima del numero di casi di test necessari per completare il lavoro.
  • È difficile chiedere un programma aggressivo e/o straordinari gratuiti quando stai ovviamente chiedendo molto lavoro.

Un altro grande vantaggio per il gestore è che può attirare nuovi sviluppatori e sapere che non saranno in grado di fornire codice che rompe silenziosamente il sistema (perché la suite di test di regressione lo rileva).

Il grande svantaggio per il manager è che lo costringe ad ammettere che il suo sistema è più complesso di quanto sembri nella descrizione di 1 pagina della funzione. L'altro aspetto negativo è che la trasparenza di questo metodo renderà difficile incolpare gli sviluppatori per fallimento aziendale.

7
Jay Godse

È certamente possibile elaborare tutti i tipi di metriche complesse per valutare le prestazioni, ma alla fine una parte significativa del tuo giudizio deve fare affidamento sulla soggettività e sul contributo di persone vicine alla base di codice.

Ad esempio, è possibile che alcuni team riescano a far esplodere uno slop orribile non mantenibile internamente a una velocità molto elevata, e ciò potrebbe anche rispettare la scadenza e le specifiche richieste. Ma il debito tecnico maturato da quel tipo di stile di lavoro è peggiore di quello che se il team avesse sfornato qualcosa di robusto e mantenibile, ma ha perso la scadenza di alcune settimane? Dipende.

Se lo scopo della domanda è risolvere un tipo di problema di produttività, direi che ciò che il manager fa effettivamente per facilitare il lavoro del team è altrettanto o più importante di qualsiasi tecnica di misurazione utilizzata per valutare il team. È una strada a doppio senso. In altre parole, sto dicendo che le metriche vanno bene, ma se vuoi di più da qualsiasi squadra la domanda finale è se il manager fa tutto il possibile per garantire che la squadra possa essere produttiva.

Questo va ben oltre la scrittura di una specifica, la ricerca di una squadra, il lancio della specifica "oltre il muro" e facendo clic su un cronometro.

6
Angelo

Qualche idea:

  1. funzionalità implementate
  2. bug corretti (tengono conto anche dei bug successivamente riaperti dal QA)
  3. i reclami degli utenti sono stati risolti (notare che non è lo stesso di 2 - un errore grave può essere dolore al collo mentre 100 errori di battitura potrebbero non essere così importanti)

Inoltre potrebbe voler tracciare:

  1. Copertura del codice mediante test
  2. Copertura del codice con documentazione interna
  3. Copertura delle funzionalità mediante documentazione esterna (utente)
2
StasM

Misura allo stesso modo in cui sei misurato dal cliente. In termini di codice funzionale, ma su scala ridotta.

Fai obiettivi brevi - una settimana o due - e vedi se i programmatori raggiungono gli obiettivi e fallo in modo soddisfacente.

Consiglio vivamente la revisione tra pari del codice, in quanto ciò consente di rilevare in anticipo il codice errato.

2
user1249

Che ne dici di tasso di vendita del prodotto/servizio.

A volte ho sentito che si chiama una commissione/percentuale del lordo

Le persone acquistano buoni prodotti, vero?

L'azienda vuole vendere il prodotto (o forse servizio, stessa differenza per questo)

Quindi, se è quello che vuoi, misuralo.

Un po 'come dire che le persone che progettano un'auto che ottiene buone recensioni e vende bene hanno fatto davvero un buon lavoro.

Ora adotta questa metrica e il team di programmazione vorrà interagire con l'addetto alle vendite per due motivi.

  • Promuovere subliverable

  • Non vendere prodotti ai clienti in modo efficace

1
Tim Williscroft

Scrivere codice/programmare non è come mettere un martello a un chiodo. Proprio come "scrivere" in generale, non è qualcosa che si può applicare anche in genere metriche - secondo me.

Non potresti semplicemente dare un'occhiata ai loro check-in o cosa hanno fatto attraverso la revisione tra pari, la revisione del codice?

O sai, se effettivamente producono codice funzionante e soluzioni che risolvono i problemi?

0
Jack Marchetti