Utilizzando i risultati di build continui come parte delle metriche di revisione delle prestazioni? [chiuso]

Il mio capo sta pianificando di utilizzare le metriche della nostra build continua (costruisce ed esegue test su ogni commit) come parte delle nostre revisioni delle prestazioni (nella nostra metrica "qualità"). Questa mi sembra davvero una cattiva idea, ma mi piacerebbe sapere se qualcuno ha studiato questo o visto prima provato.

Il mio pensiero è che i nostri sviluppatori non faranno tutti i test che farebbero altrimenti, per paura che i test falliscano. Sento che sta trasformando un prezioso strumento di sviluppo in un bastone con cui battere gli sviluppatori.

L'ovvia controproposta è che promuoverà le persone a stare più attenti prima di impegnarsi, e quindi a migliorare la qualità.

Sono fuori base qui? Per favore, lascia da parte la domanda se dovremmo fare o meno revisioni delle prestazioni - che ha avuto risposta altrove.

continuous-integration

— Michael Kohne
fonte

Qualsiasi sistema che può essere giocato è un input orribile per una valutazione delle prestazioni.

— Steve Jackson,

Tutti hanno la possibilità di non testare?

— JeffO

@Steve, E "sistemi" che non possono essere giocati ti danno una visione minuscola del quadro più grande. Per tracciare con precisione le prestazioni sarebbe necessario un lavoro sulle gambe.

— maple_shaft

Nota che alcune cose funzionano bene sui computer degli sviluppatori, ma falliscono sul server di compilazione (una dipendenza accidentale da un vaso esterno, un modo sbagliato di usare / e \ su scatole Linux ecc.). Il motivo principale del server di compilazione è catturare queste cose, non molestare nessuno per non averlo testato prima. In altre parole, questa è una cattiva idea.

Follow-up: Dopo aver iniziato a fare questo, ho scoperto che il problema più grande non aveva nulla a che fare con gli altri ingegneri e la volontà di scrivere test adeguati, ma piuttosto con il fatto che i nostri test esistenti erano DAVVERO instabili, quindi ogni commit aveva una possibilità abbastanza grande di non superare alcuna colpa della persona che commette il commit. Questo fattore ha attenuato l'entusiasmo di tutti per i test molto più di qualsiasi effetto della revisione delle prestazioni.

— Michael Kohne,

Risposte:

Le recensioni sulle prestazioni vanno bene, ma che ne dici di metriche utili come:

Percentuale di copertura del test unitario sulle funzionalità
Capacità di rispettare le scadenze
Documentazione chiara e concisa
Seguire le convenzioni di codifica appropriate
Comunica bene con gli altri
Capacità di trasformare requisiti e storie utente in attività

Questi sono tutti buoni modi per misurare le prestazioni, ma i problemi che la gestione sembrano avere con questi sono che in realtà richiedono ... ummm .. beh, sai ... LAVORO EFFETTIVO da parte loro.

Sfortunatamente la maggior parte dei dirigenti ha l'atteggiamento "Al diavolo, voglio giudicare i miei dipendenti su metriche che in realtà non mi richiedono di stare al passo con quello che stanno facendo".

— albero_acero
fonte

+1 per fornire alcune buone scelte su quali metriche sono utili.

— David Ruttka,

A mio avviso, il gioco qui è abbastanza probabile e il tuo capo deve trovare il modo di impedire che ciò diventi realtà. L'altro caso che non hai menzionato è quello in cui gli sviluppatori commettono tonnellate di volte in modo che ci sia questo flusso di check-in in cui il numero di modifiche è relativamente basso come se ci fosse una parte della revisione in cui viene utilizzato il conteggio delle build è qui che questo diventa un nuovo strumento che potrebbe essere usato in modo piuttosto semplice. Sto pensando ai check-in in cui qualcosa viene rinominato o lo spazio bianco viene cambiato è un check-in e conta come una forma di produttività sarebbe la visione pedante.

— JB King
fonte