Metrica con cui tenere gli sviluppatori responsabili [duplicato]

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 non scambiabile (il sistema non può essere interpretato da sviluppatori intelligenti). Ci sono semplicemente troppe variabili all'interno dello sviluppo del software per renderlo misurabile come pezzo di lavoro in questo modo.

Il più vicino si ottiene progressi rispetto alle stime: è il numero di attività che stanno completando entro le stime concordate. Il trucco qui è (a) ottenere stime buone ed eque e (b) capire dove sono state superate le stime per buone ragioni per le quali lo sviluppatore non può / non deve essere accusato (questo è qualcosa di veramente più complesso del previsto). In definitiva, se spingi troppo duramente gli sviluppatori, è probabile che le stime si avvicinino gradualmente a un livello in cui vengono sempre soddisfatte non a causa dell'aumento della produttività, ma a causa dei tempi di riempimento.

Vai troppo in termini di stime (riducendole per creare pressione da consegnare) e crei scadenze telefoniche che gli studi hanno dimostrato non aumentano la produttività e possono avere un impatto sul morale della squadra (vedi Peopleware per maggiori informazioni).

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

Se si tratta di non fidarsi di loro di lavorare in remoto, allora è fondamentalmente un problema di fiducia più ampio. Se non ti fidi di loro a lavorare da casa, allora hai bisogno di stabilire quella fiducia, non lasciarli lavorare da casa, o trovare un modo per soddisfare te stesso che stanno effettivamente lavorando quando sono destinati a essere.

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

Comprendo 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 tizio in Messico che tira fuori i quadri di Elvis in velluto nero?

Louis de Broglie ha scritto una tesi di dottorato così breve, che gli esaminatori lo avrebbero respinto - tranne che de Broglie era un aristocratico di alto livello, e avevano bisogno di una buona scusa. Così gli esaminatori lo mandarono a Einstein, che non solo non lo respinse, ma lo indirizzò al comitato del Nobel, e de Broglie ottenne il premio Nobel per la fisica per questo cinque anni dopo.

Le misure numeriche funzionano meglio su un lavoro ripetitivo, come la fusione di ferro o viti avvitabili sulle porte 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 correggerò i bug della geometria delle coordinate e il codice potrebbe ridursi. Se dovessi correggere un bug in un driver del kernel Linux, potrei passare tutto il giorno a fare il debug e non scrivere una riga di nuovo codice.

La produttività del programmatore di misurazione è molto, molto, molto soggettiva .

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

Il miglior sistema numerico che abbia mai visto è stato il piano di poker di Agile. È solo un modo elegante per chiedere a Joe, Sally e Ralph quanto sia difficile che pensino che il prossimo lavoro di Joe sia probabile. Quindi puoi misurare la produttività dei punti per settimana per ogni membro del team. Ma anche così, ci vuole un po 'per calibrare le stime di una squadra, e i numeri sono confusi e facilmente eliminabili.

Molte persone vogliono stime di produttività in modo che possano pianificare la pianificazione. È una specie di "collegalo a MS Project, guarda il percorso critico e la tua teoria della data di spedizione". Non ho mai visto quel lavoro, ci sono troppe incognite. Se lo vuoi, usa Waterfall, progetta tutto in anticipo, non permettere ordini di cambio e preparati ad essere deluso comunque.

L'unica metrica che utilizzo è la quantità di software funzionante che produce per una determinata quantità di denaro che ho investito.

Indipendentemente dal suo programma, se lavora da remoto o meno, il numero di pause che lui / lei prende, le metodologie che utilizza o il numero di ore di lavoro.

Per software funzionante intendo:

List of features defined by user/customer that meets the required quality level

Per ammontare di denaro :

How much the user/customer paid for the defined features + maintenance costs

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

È necessario uno sviluppatore esperto o un caposquadra (che non è associato a quei programmatori remoti) per stimare quanto tempo potrebbe impiegare qualche attività e l'efficacia è misurata confrontando il tempo richiesto con le stime. Per essere sicuro che le stime siano buone, potresti scegliere alcune attività a caso e farle eseguire da una squadra interna che hai sotto controllo.

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

• un punto per scrivere un test automatizzabile (e passare recensioni) e aggiungerlo alla suite di test di regressione,
• un punto per farli passare, senza causare altri errori di test di regressione.

Lo sviluppatore e il gestore possono migliorare il sistema congiuntamente:

• concordando congiuntamente le aree importanti di sviluppo e test
• revisione e gestione in autonomia della suite di test.
• decidere di non costruire una funzionalità che ha un beneficio aziendale limitato ma richiede un sacco di sviluppo e test necessari per fornire tale funzionalità. (La linea di codice più produttiva è quella che hai deciso di non scrivere perché non offre alcun vantaggio commerciale).
• partizionamento del sistema in un'architettura (come model-view-controller) che facilita lo sviluppo incrementale delle funzionalità senza interrompere 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 gestore.
• i test a grana fine miglioreranno la qualità del sistema.

Il gestore non può giocare la metrica perché:

• rifiutare troppi test porterà ad un logorio dello sviluppatore.
• richiedere troppe prove renderà difficile rifiutare una scadenza successiva.

Lo sviluppatore non può rovinare il gestore perché

• Ogni unità di funzionalità consegnata con test deve anche superare la suite di regressione. Ciò costringe lo sviluppatore a sviluppare attentamente senza infrangere altro codice.
• Qualsiasi richiesta di lavoro deve essere dimostrabile superando nuovi test e test di regressione.

Il gestore non può avvitare 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 quando stai ovviamente richiedendo un sacco di lavoro.

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

Il grosso lato negativo del gestore è che lo costringe ad ammettere che il suo sistema è più complesso di quanto sembra nella descrizione di 1 pagina della funzione. L'altro lato negativo è che la trasparenza di questo metodo renderà difficile incolpare gli sviluppatori di errori aziendali.

È certamente possibile escogitare tutti i tipi di metriche complesse per valutare le prestazioni, ma alla fine della giornata una parte significativa del tuo giudizio deve fare affidamento sulla soggettività e l'input da parte di persone vicine alla base di codice.

Ad esempio, è abbastanza probabile che alcuni team riescano a far uscire la briciola internamente orribile e inaffidabile a una velocità molto elevata, e questo potrebbe persino rispettare la scadenza e le specifiche richieste. Ma il debito tecnico accumulato da quel tipo di stile di lavoro è peggiore di quello che avrebbe se la squadra avesse sfornato qualcosa di robusto e mantenibile, ma la scadenza fosse scaduta da poche settimane? Dipende.

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

Questo non si limita a scrivere una specifica, a trovare una squadra, a lanciare le specifiche "oltre il muro" e a fare clic su un cronometro.

Alcune idee:

1. funzionalità implementate
2. bug corretti (anche account per bug successivamente riaperti dal QA)
3. reclami utente risolti (notare che non è lo stesso di 2 - un bug serio può essere dolore al collo mentre 100 errori di battitura potrebbero non essere così importanti)

Potrebbe anche voler monitorare:

1. Copertura del codice tramite test
2. Copertura del codice mediante la documentazione interna
3. Copertura delle caratteristiche tramite documentazione esterna (utente)

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

Crea obiettivi brevi - una settimana o due - e verifica se i programmatori soddisfano gli obiettivi e lo fanno in modo soddisfacente.

Suggerisco caldamente la revisione paritetica del codice, in quanto ciò consente di individuare il codice errato in anticipo.

Che ne è della tariffa di vendita del prodotto / servizio.

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

Le persone comprano buoni prodotti, vero?

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

Quindi, se questo è ciò che vuoi, misuralo.

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

Ora adotta questa metrica e il team di programmazione vorrà interagire con il responsabile delle vendite per due motivi.

• Promovazione insufficiente

• Non vendere prodotti ai clienti in modo efficace

Scrivere codice / Programmare non è come mettere un martello su un'unghia. Molto simile alla "scrittura" in generale, non è qualcosa che puoi applicare in genere anche alle metriche - secondo me.

Non potresti semplicemente guardare i loro check-in, o quello che hanno fatto attraverso la peer-review, la revisione del codice?

O lo sai, se in realtà producono codice funzionante e soluzioni che risolvono i problemi?

Utilizzare una metodologia, in base alla quale la documentazione scritta si sposa con il codice scritto. Inizia la settimana decidendo su cosa fare, ottieni un accordo, quindi aspetta fino alla fine della settimana per vedere se è stato fatto o meno. Mantenere le attività piccole e misurabili come in quanti giorni. Non penso che sia necessario misurare i programmatori per lavoro, ma l'accordo su ciò che deve essere consegnato e quando è un must per il controllo.

La seconda parte di questa soluzione sarebbe la revisione del codice peer-to-peer che è supportata da una sorta di sistema di Versioning che rende chi ha fatto cosa e quando è rintracciabile. Se il consenso è che il codice è buono, allora vai a un vincitore, se è cattivo, quindi scopri perché e come potrebbe essere migliorato.

Gli studi del tempo e del movimento sono un no no per quanto mi riguarda, alcuni codici come Regexes o alcune logiche davvero difficili possono richiedere giorni per svilupparsi, ma possono solo formare un paio di linee di codice. L'unica misura reale è consegnabili in tempo, in un tempo concordato.