Le organizzazioni dovrebbero penalizzare gli sviluppatori per la quantità di segnalazioni di difetti archiviate sul codice su cui hanno lavorato? [duplicare]

Sembra che farebbe più male che bene. Ignorando per un momento se è giusto che un manager lo faccia, diamo un'occhiata alla logistica ...

Problema 1: tutti i bug sono uguali?
Lo sviluppatore 1 introduce un bug: cancella tutti i dati dei clienti e li maledice.
Lo sviluppatore 2 introduce due bug: le etichette del modulo non sono allineate a sinistra e la funzionalità di calendario è disattivata di 1 secondo se viene creato un evento che copre due anni bisestili.

Quindi chiaramente lo sviluppatore 2 merita più dolore dal loro manager perché ha il doppio del tasso di errore. Certo che no, quindi vieni con un sistema di classificazione dei bug in modo che gli sviluppatori con bug insignificanti non si sporchino così tanto. Ma aspettate, dovrebbe il fattore di sistema in un modificatore per uno sviluppatore che sta facendo ripetutamente lo stesso errore banale e sprecando il tempo del tester perché non imparano mai dai propri errori? Forse, hmmm. Questo è complicato

Problema 2: ciò che conta come un bug?
Manager : questo rapporto doveva includere un totale parziale, questo è un bug per te!
Sviluppatore : non era nei requisiti, è un FEATURE non un bug.

Problema 3: come raggruppate i bug?
Sviluppatore - "[Nome responsabile], i tester hanno presentato 10 bug contro di me perché le velocità non erano corrette 10 schermate diverse, ma questo era tutto collegato a un singolo bug nella funzione getVelocity. Abbiamo discusso per 3 ore al riguardo, ma non si spostano. Ci piacerebbe un incontro con te per decidere quanti bug devono essere archiviati Oh, a proposito, non c'è modo di colpire il codice entro la scadenza prevista per domani. "

Problema 4: più SLOC probabilmente significa più bug
Lo sviluppatore 1 si siede sul suo sedere tutto il giorno, ma riesce a scrivere 3 linee di codice prive di bug tra argomenti su Reddit sulla legge sull'immigrazione dell'Arizona.
Lo sviluppatore 2 lavora duramente tutto il giorno e sforna un'IA completamente funzionale che non uccide John Connor alla prima occasione. "

Quindi ovviamente vuoi penalizzare lo sviluppatore che fa più progressi e / o prende più rischi innovando, vero?

Riepilogo
Probabilmente ci sono soluzioni praticabili a molti di questi, ma come manager di un team di programmazione che cerca di rispettare una scadenza, vuoi davvero che tutti passino il tempo a discutere su ciò che conta come un bug, ciò che conta come un bug discreto, l'importanza di un bug, ecc.? Nessuna di queste cose muove il tuo progetto in avanti e questo sarà veleno per i team che saranno costretti a competere su problemi che non hanno alcun impatto significativo sul software attuale creato. Per non parlare di ciò che fa alla cultura dei tuoi dipendenti concentrarsi su questo sforzo per trovare modi per assicurarsi che gli errori di ogni dipendente siano registrati meticolosamente in modo che possano essere rigettati in un secondo momento.

Inevitabilmente avrai sviluppatori che blandiranno i tester per aggirare il tuo sistema di tracciamento dei bug e riferiranno direttamente i problemi in modo che possano risolverli senza che entrino nel loro "FILE PERMANENTE". Quindi non hai nemmeno una contabilità accurata dei bug o di ciò su cui le persone stanno realmente lavorando.

Poi c'è il problema dell'impatto negativo. Questo è il discorso delle risorse umane, è meglio avere una buona documentazione prima di iniziare a penalizzare i dipendenti, soprattutto dal punto di vista finanziario. E se qualcuno di loro è una classe protetta (minoranze, veterani, donne, portatori di handicap, ecc.) È meglio essere sicuri che qualunque sistema tu abbia impostato non discrimini uno di essi in base all'appartenenza a quella classe (o che un giudice potrebbe essere convinto in quanto tale), anche se si tratta solo di un indesiderato effetto collaterale del piano.

Quindi alla fine non crei incentivi per creare meno bug, il che è difficile, ma piuttosto per superare i bug minimizzandone l'importanza o incolpandoli su qualcun altro.

Versione breve No.

I programmatori sono noti per ottimizzare ciò che i manager iniziano a premiare. Se premi LOC, allora ottieni molti spazi bianchi per riempire le linee della metrica del codice. Se provi a punire per numero di errori, inizierai a entrare in guerre in cui gli sviluppatori sostengono che X non è il loro bug (il bug è nel compilatore o API o solo da qualche altra parte) - e il bug archiviato contro di loro è sbagliato.

L'ultimo posto in cui ho lavorato aveva uno sviluppatore "responsabile" di un prodotto. Mentre lo sviluppo "responsabile" non è mai cambiato nel corso degli anni, altri avrebbero lavorato sul progetto quando il carico stagionale lo rendeva necessario. Nessuno ha puntato le dita e ha detto "hai scritto quell'insetto!" Invece, l'obiettivo era ridurre i bug nei prodotti.

Anche i luoghi in cui ho lavorato con penalità per i bug hanno avuto un turn over molto alto. Il puntamento del dito ha contribuito a creare un ambiente ostile che ha portato alla partenza degli sviluppatori.

Gli sviluppatori dovrebbero ritenersi responsabili della qualità del codice che producono e dovrebbero aspettarsi che il loro manager faccia lo stesso. Ma ciò non significa che alcuni sviluppatori dovrebbero ottenere un demerito ogni volta che viene segnalato un bug. Nessun manager sano di mente direbbe:

Well, Johnson, you checked in 500 lines of code last week, and so far 241 bug reports have been traced to that code.

È molto lavoro capire chi incolpare di ogni piccolo difetto, e il numero di segnalazioni di bug non sempre ti dice molto sulla qualità del codice. Ma un buon manager dovrebbe notare problemi e trovare modi per risolverli. Lui o lei potrebbe dire:

Johnson, that was one stinker of a checkin last week -- we've been getting bug reports at three times the normal rate. We need to get that fixed ASAP, so I've asked 'Eagle-Eye' Ferguson to go over the code with you. I'm sure the two of you will figure it out, and ol' Eagle-Eye might show you a few tricks along the way.

Ogni sviluppatore dovrebbe aspettarsi che il gestore noti le proprie prestazioni, inclusa la qualità generale del proprio codice. Gli sviluppatori dovrebbero anche aspettarsi che i loro colleghi se ne accorgano, dopotutto è tutto a posto nel repository. Quindi se sei quel ragazzo con il numero elevato di bug, non vergognarti di chiedere aiuto. Il resto della squadra probabilmente sa già dove sei, e se farai uno sforzo concertato per migliorare la squadra (e il manager) lo noteremo anche.

Quindi sì , dovresti essere responsabile del codice che scrivi, ma no , l'organizzazione non dovrebbe avere una politica che penalizzi i singoli sviluppatori per specifici difetti , o per il superamento di un certo numero di segnalazioni di difetti. Questo incoraggerà le persone a trovare modi per evitare la colpa, come puntare le dita o essere così attenti che la produttività diminuisce. Non aiuta lo sforzo di sviluppo se le persone hanno paura di accettare la responsabilità di ciò che scrivono. A proposito, anche non aiuta a capovolgerlo e premia le correzioni di bug specifiche . ; -)

No, non dovrebbero. Questo non è lavoro manuale e nessuno crea bug intenzionalmente. Come possiamo aspettarci produttività da un triste programmatore inorridito? Le cose dovrebbero essere fresche intorno a lui. Alla fine nessuno ha beneficiato della penalizzazione.  

Dico che questa è una cattiva idea che farà poco ma creerà un ambiente di lavoro ostile.

Direi anche che QUALSIASI RINFORZO NEGATIVO come motivatore per le prestazioni lavorative creerà una forza lavoro infelice e un alto turnover. Persino i bravi sviluppatori si sentiranno stressati dallo slittamento.

Il rinforzo negativo è persino umiliante per bambini e cani, perché dovresti trattare un professionista in questo modo?

Usa invece rinforzi positivi per i BASSI NUMERI DI DIFETTO e cerca attivamente di aiutare i membri della tua squadra che stanno lottando. Se non funziona con qualcuno a lungo termine, allora lasciali andare.

Coglierò la tendenza qui, esco su un arto e dò un sonoro SÌ! , ma con una certa qualifica: solo per gli sviluppatori che sono almeno una deviazione standard peggiore della loro colleghi.

Permettetemi di discuterne un po ', perché qui ci sono alcuni problemi caricati. Il primo è la parola "pari". Non è certamente giusto paragonare il lavoro di un veterano di 10 anni con quello di una nuova assunzione fresca al college. Il principiante ha meno esperienza, ma al professionista vengono assegnati compiti più difficili.

Il prossimo è la deviazione standard. Da un lato, i programmatori da un lato resistono a qualsiasi tentativo di misurazione quantitativa del loro lavoro con pretese di gioco delle metriche, e dall'altro praticano l'arte di trovare quotidianamente modi per quantificare il non quantificabile attraverso il software e di quotare metriche su come i programmatori rockstar sono X tempi più produttivi rispetto alla media. C'è una verità ovvia da entrambe le parti.

La mia convinzione è che le metriche migliori di utilizzo, anche quelle semplicistiche come "linee di codice", servono per identificare gli stand-out. Si imposta un limite di una deviazione standard o due rispetto alla norma, in modo tale che i programmatori individuali non saranno in grado di rompere il pacchetto. Non cercare il programmatore in alto o in basso. L'intero punto qui è che la maggior parte delle volte, nessuno viene identificato e quindi non c'è niente da giocare. Ma di tanto in tanto ti aiuterà a trovare la gemma di un programmatore, o ti dirò chi è il tuo vero sottoproletario. E poi sai cosa fai? Niente . Almeno all'inizio. Invece, pensalo come intelligenza non confermata. Usa le informazioni per guardare la persona e cerca di confermarla altrove.

Se hai un programmatore che sta controllando i bug di un ordine di grandezza più spesso dei suoi pari, prima trova qualcosa che corrobori la sua performance generale e poi vai a parlare con lui. E la prima volta, probabilmente dovrebbe essere solo un discorso.

La mia opinione non è perché se un'organizzazione penalizza gli sviluppatori per la quantità di bug depositati contro di loro, allora lo sviluppatore potrebbe essere meno produttivo al fine di evitare le penalità presumendo che siano sostanziali. Ci può anche essere conflitto su quali bug verrebbero archiviati contro uno sviluppatore in quanto potrebbe esserci una persona di controllo qualità che ha una visione liberale di ciò che costituisce un bug che è un altro fattore qui. Mentre si potrebbe tentare di bilanciare i rigori, sarei curioso di vedere quanto bene ciò sia fatto nella realtà.

Il mio ex collega mi ha raccontato la storia di un luogo in cui questa pratica è stata effettivamente applicata: gli sviluppatori sono stati penalizzati per ogni bug trovato nel loro codice e il QA è stato premiato per ogni bug scoperto. Il risultato è stato che gli sviluppatori hanno semplicemente smesso di sviluppare un nuovo codice perché quello era l'unico modo per proteggersi dai rigori.

Gli sviluppatori non sono naturalmente pigri o ignoranti per ciò che è meglio. A mio parere, sarebbe più produttivo dare agli sviluppatori una timeline più accurata e specifiche migliori prima dell'avvio del progetto.

Assolutamente no.

È come fare a meno dei dottori perché alcuni di questi pazienti muoiono, senza considerare la gravità della malattia / infortunio.

Ci sono alcuni progetti in cui i Difetti sono inevitabili. Se disponi di sponsor di progetto con esigenze contrastanti, requisiti dell'utente in conflitto con le linee guida sulla sicurezza, mal visti i cambiamenti dell'ultimo minuto, allora ci saranno dei difetti innalzati indipendentemente dalla qualità del tuo codice.

C'è anche il problema perenne (almeno nella maggior parte delle grandi organizzazioni) dell'infrastruttura che sta cambiando intorno a te. Si codifica per V1.25 del database su V3.8 del sistema operativo, ma un altro reparto si aggiorna a V2.0 e V4.0 appena prima di andare in diretta. (O downgrade, in un caso abbiamo codificato per V5.0 J2EE solo per annullare l'upgrade e doversi ritirare fino a V4.0 giorni prima del rilascio - c'erano molti difetti.)

Infine, abbiamo gli utenti pragmatici che sollevano i difetti anziché le richieste di modifica in quanto l'onere burocratico è significativamente inferiore.

No. Sembra cercare di trattare un sintomo, non il problema alla radice. Invece di concentrarsi su quanti bug ci sono in un pezzo di codice e chi li ha introdotti, perché non concentrarsi sullo sviluppo di un sistema che aiuta a eliminare i bug in primo luogo?

Strumenti come Test unitario, Test di integrazione, Sviluppo guidato dal test, Analisi del codice statico, Revisioni del progetto e Revisioni del codice spesso possono catturare un discreto numero di bug prima che entrino nella base del codice. L'integrazione continua aiuta anche a identificare i problemi prima piuttosto che dopo.

BTW, il seguito logico alla domanda OP: se eredito un pezzo di codice pieno di bug, dovrei essere penalizzato per tutti gli altri bug se ne risolvo uno? Con la proposizione originale, dal momento che ho lavorato sul codice, ora sono responsabile dei bug.

Qual è la motivazione per penalizzare gli sviluppatori per i loro tassi di difetti?

Sicuramente l'obiettivo è provare e misurare la qualità del codice scritto dallo sviluppatore.

Il problema è che la qualità è un po 'amorfa: è davvero difficile da misurare. In effetti, non puoi misurarlo direttamente, devi provare ad approssimarlo misurando altre cose.

Inoltre, selezionando un singolo KPI, ad esempio # difetti, si ottiene il gioco del sistema. Se suggerisci di penalizzare ogni sviluppatore di $ 10 per difetto, quanto pensi che sarebbe prima che uno degli sviluppatori faccia un patto con un tester ... Ti pagherò $ 5 per ogni difetto che mi dici riguardo a quello che non fa 't get logged.

Lascia che ripaghino tutti i bug relativi al loro codice, inoltrano loro i reclami dal reparto testing e dovrebbero già sapere che meno bug sono migliori per loro.

E quando tutto va bene, e non ci sono segnalazioni di errori, un applauso sul retro come ricompensa e alcune parole gentili dovrebbero fare il resto.

Anche se non sono d'accordo con la premessa ...

Sarebbe solo fattibile se ricompensi il programmatore che assume anche caratteristiche tecnicamente più impegnative - "rischio maggiore, ricompensa più alta". Altrimenti, perché un programmatore dovrebbe mai impegnarsi in un lavoro stimolante in quell'ambiente, dal momento che qualsiasi sfida tecnica è una responsabilità (non un'opportunità di ricompensa).

Sono d'accordo che creerebbe anche un ambiente molto ostile. Nella mia esperienza, una quantità significativa di difetti è dovuta all'ambiguità dei requisiti o semplicemente alla mancanza di un requisito. Quindi penso che questo potrebbe anche portare a quei difetti che vengono assegnati in modo esplicito all'analista aziendale, all'ingegnere dei sistemi o allo sponsor del progetto e dovrebbero essere soggetti a quella stessa pena - che non sarebbe una brutta cosa.

Direi che il loro conteggio è un errore. Non c'è modo di macinare qualcosa del genere a un numero. Tuttavia, se il codice di un particolare sviluppatore sembra avere più problemi di un codice simile scritto da altri, e questo è un modello coerente, allora direi che lo sviluppatore non è probabilmente buono, a parità di tutte le altre cose. È un dato di fatto da mettere nel mix.

In ogni caso, ho lavorato in questo settore per decenni, e non posso dire di aver mai visto un programmatore che ha avuto un tasso di errore insolitamente alto o insolitamente basso. Ho visto programmatori che erano più veloci o più lenti, programmatori che potevano ottenere un lavoro o che si sono imbattuti in problemi. Ho visto programmatori che naturalmente scrivono codice molto facile da capire, codice molto veloce o codice molto confuso. Ma non ho mai visto un programmatore con un tasso di errore atipicamente alto o basso. Forse non ho prestato abbastanza attenzione.

Non mi oppongo a questa idea, ma SOLO se esiste un consenso sui difetti: un gruppo designato di tecnici senior che li governa. Utenti, BA e dirigenti spesso non sono qualificati per decidere quale sia un difetto del codice - ed è sempre pericoloso mettere qualcosa di simile sotto il controllo di uno (o di qualcuno) individuo.

Ma non penso sia davvero necessario - quando uno sviluppatore scrive costantemente codice cattivo, se i suoi senior e peers stanno facendo il loro lavoro, non sarà un segreto a lungo e lo sviluppatore ne subirà le conseguenze con un sistema formale di "demeriti".