Il mio capo ha deciso di aggiungere un campo "persona da incolpare" a ogni segnalazione di bug. Come posso convincerlo che è una cattiva idea?

In una delle ultime mosse "WTF", il mio capo ha deciso che l'aggiunta di un campo "Person To Blame" al nostro modello di tracciamento dei bug aumenterà la responsabilità (anche se abbiamo già un modo di legare i bug a funzionalità / storie). Le mie argomentazioni secondo cui ciò ridurrà il morale, aumenteranno il puntamento del dito e non spiegherebbero le caratteristiche mancanti / incomprese riportate come bug non sono state ascoltate.

Quali sono alcuni altri argomenti forti contro questa pratica che posso usare? C'è qualche scritto su questo argomento che posso condividere con il team e il capo?

Dì loro che questo è solo un nome amatoriale per il campo Causa principale utilizzato dai professionisti (quando il tracker dei problemi non ha un campo dedicato, è possibile utilizzare i commenti per quello).

Cerca nel web per qualcosa come l'analisi del software bug delle cause , ci sono un sacco di risorse per giustificare questo ragionamento ^{1 , 2 , 3 , 4 , ...} .

... una causa principale di un difetto non è sempre un singolo sviluppatore (che è il punto principale di questo campo) ...

Questo è esattamente il motivo per cui la "causa principale" è professionale mentre la "persona da incolpare" è amatoriale. La responsabilità personale è ottima, ma ci sono casi in cui si pone semplicemente "al di fuori" del team di sviluppo.

Dire al vostro capo quando v'è un singolo sviluppatore la colpa, radice di campo causa sarà sicuramente coprire tale ( "errore di codifica fatta da Bob a commettere 1234, persa da Jim in revisione 567" ). Il punto di usare il termine causa principale è quello di coprire casi del genere, insieme a casi che esulano dal campo di applicazione del team di sviluppo.

^{Ad esempio, se il bug è stato causato da un hardware difettoso (con la persona da incolpare essendo qualcuno al di fuori del team che lo ha acquistato e testato), il campo della causa principale consente di coprirlo, mentre "singolo sviluppatore da incolpare" semplicemente romperebbe il flusso di tracciamento dei problemi .}

^{Lo stesso vale per altri bug causati da persone esterne al team di sviluppo: errori del tester, modifica dei requisiti e decisioni di gestione. Supponiamo che se il management decide di saltare gli investimenti nell'hardware di disaster recovery, "incolpare un singolo sviluppatore" per un'interruzione di elettricità nel data center non avrebbe senso.}

Un altro probabile risultato di tale politica è che le persone non segnaleranno bug se pensano di essere la "persona da incolpare", quindi ridurranno effettivamente il numero di bug segnalati dal team.

L'argomento principale che vorrei usare contro di esso è quello di chiedere quale problema sta cercando di risolvere. Ci sono quasi certamente modi migliori per risolvere lo stesso problema.

Per prima cosa, c'è davvero solo una persona da incolpare? Se c'è, stai facendo qualcos'altro che non va. Un buon processo richiede un lavoro attraverso un analista, un programmatore, un revisore e un tester prima che arrivi alla produzione. Se non stai eseguendo tutte queste fasi, forse questa è la soluzione al problema che il tuo capo sta cercando di risolvere. Se sei allora quale è la colpa? Potrebbe non essere nessuno di questi, potrebbe essere la colpa del codice legacy.

Non va bene avere persone che mordono e puntano le dita, cercando di evitare un segno nero che non scompare una volta impostato. Non risolve nulla. Pochissime persone sono negligenti. Devi fare una retrospettiva adeguata , vedere cosa è andato storto e cosa puoi fare per assicurarti che non vada di nuovo storto.

Da ciò vedrai chiaramente se una persona è regolarmente in colpa e questo potrebbe essere un problema diverso da affrontare.

Il trucco per fermare un manager impostato sulla creazione di responsabilità è offrirlo liberamente , ma in un modo che ha effettivamente senso per te.

Ci sono almeno tre problemi con quel campo.

Il primo è che incolpare le persone non fa bene al morale. Ok. Ma forse non gli importa del morale e vuole licenziare i cattivi sviluppatori. Difficile discutere.

Il secondo è che ottenere quel campo giusto sarà difficile e un grande spreco di tempo. È più complesso che scoprire chi ha scritto il codice errato. E qualsiasi informazione potenzialmente difficile da capire può essere saccheggiata / tradita. Ma forse è pronto a pagare quel costo e controllare le informazioni. Belle.

Il problema più fondamentale è che questo campo non sarà una buona metrica su cui agire. Certo, avrà una buona classifica del cui codice causa la maggior parte dei difetti. Ma indovina chi sarà in cima a quella lista? Probabilmente il fondatore dell'azienda, o forse uno dei migliori sviluppatori che ha un tasso di difetti molto basso ma è così produttivo da scrivere una porzione sproporzionata del codice. Quindi finirà per licenziare il suo miglior sviluppatore o lo farà rallentare così tanto da non essere più il suo miglior sviluppatore. E quelli che scrivono una riga di codice al mese - preferibilmente commenti - saranno probabilmente premiati per i suoi numeri a basso difetto.

Ancora un altro errore della metrica del software.

La causa principale di un difetto sul campo non è mai una sola persona. Le persone perfettamente coscienziose commetteranno errori e un processo che si aspetta che siano infallibili è irragionevole. Se non si verificano modifiche ai sistemi di produzione prima della distribuzione, manualmente o tramite test automatizzati, i bug sono inevitabili.

Sbagliato:

Bob dimentica di controllare l'input e il programma si è arrestato in modo anomalo dividendo per zero.

Giusto:

Il codice vulnerabile a un errore di divisione per zero non è stato rilevato prima della distribuzione. Sono stati aggiunti nuovi casi di test per verificare la corretta gestione di input non validi. Il codice è stato corretto e tutti i nuovi casi di test stanno superando.

Cambia "Persona da incolpare" in "Persona da lodare"

La persona principale che corregge i bug prende il loro nome.

Semplice risposta.

Il campo "Blame" non verrà utilizzato per nient'altro che capro espiatorio e fingerpoint, il morale precipiterà, la fiducia della squadra verrà distrutta e tutti cercheranno di trovare modi per dimostrare che qualcosa non è colpa loro invece di risolverli. Le persone saranno anche più inclini a tacere sui bug invece di segnalarli, perché non vogliono che un collega si metta nei guai. È completamente controproducente.

Cosa c'è di più importante, vittimizzare qualcuno per aver fatto un errore onesto o risolvere il problema il più rapidamente possibile?

Il tuo capo sembra pensare che i bachi siano un segno di pigrizia o sciattezza. Loro non sono. Sono un dato di fatto. Quante patch Microsoft distribuisce in un anno?

Se hai una piccola disobbedienza civile, fai in modo che il team accetti di mettere un elenco di tutti gli sviluppatori in quel campo per ogni errore. Se ciò non si adatta, scrivi "Sono Spartacus!" anziché. Il punto, ovviamente, è che siete tutti responsabili di tutti i bug e non siete contenti di dover segnalare l'individuo che ha creato un singolo bug.

Un'altra opzione: giocare insieme. Non fare nulla in particolare - fai solo un buon lavoro e compila il campo nel modo più preciso possibile per alcuni mesi. Spiega quindi al capo che assegnare la colpa a ciascun errore rende infelici e scomodi tutti i membri del team. Digli che tutti sentono che c'è poca correlazione tra i bug creati e qualsiasi altra cosa (abilità, sforzo, sanità mentale). (Aiuterà se è possibile eseguire alcuni numeri che mostrano che in realtà non esiste una correlazione.)

Gandhian Civil Disobedience: metti il ​​tuo nome su ogni campo (a meno che altri sviluppatori non aumentino e metta il loro nome per i loro bug) e accetti la colpa per ogni bug, che sia tuo o meno. Nulla renderà quel campo o l'idea di incolpare qualcuno di più inutile di così. Se il tuo capo ti chiede perché il tuo nome è su tutti i campi, allora puoi spiegare "perché non credo che lo sviluppo sia un gioco di colpa, se hai davvero bisogno di persone da incolpare e crocifiggere, allora crocifiggimi per tutto e lascia che il mio team lavori pacificamente ".

Una volta ho avuto un capo implementare un sistema molto simile a questo, e sebbene non fosse una programmazione (era un progetto di stampa per un quotidiano) il concetto e la risposta appropriata erano gli stessi.

Quello che ha fatto è stato invece di aggiungere un campo "persona da incolpare" alle nostre scartoffie e ha dato a ciascuno dei designer una serie di adesivi colorati. Ogni designer ha ottenuto un adesivo di colore diverso ed è stato istruito che per qualsiasi disegno lavorato o addirittura toccato l'adesivo doveva essere aggiunto alle scartoffie di quel disegno.

L'obiettivo dichiarato del capo per "l'iniziativa dell'autoadesivo" era stabilire la fonte di tutti gli errori del nostro dipartimento (errori nelle scartoffie, misfilings, cattiva copia, essenzialmente l'equivalente di stampa dei bug)

Ciò che abbiamo fatto è stato di dare a ciascuno degli altri designer un quarto dei nostri adesivi in ​​modo che ognuno di noi avesse tutti i colori e invece di mettere solo il nostro colore su ogni disegno, abbiamo messo tutti e quattro i colori dei designer.

Non limitarti a scrivere il tuo nome nella casella [Blame], inserisci il nome di tutti quelli che fanno parte del team / progetto e assicurati che tutto il team faccia lo stesso.

Abbiamo lavorato insieme contro la sua bisbetica orwelliana e di conseguenza abbiamo finito per cogliere l'un l'altro errori e parlarci a vicenda e alla fine abbiamo avuto una significativa riduzione degli errori. Tuttavia era una direttrice di merda, e invece di riconoscere che la sua iniziativa ha finito per unirci a noi e aumentare la produttività, ha ottenuto tutto, sciogliendo il sistema adesivo e dichiarato un fallimento e rimproverato formalmente tutti noi.

Finirà per punire il suo programmatore più prolifico. Le probabilità sono che una o due persone potrebbero essere i migliori dipendenti che hanno lavorato alla maggior parte dei progetti. Se hai, in un dipartimento di 10 persone, un programmatore che è solo una fonte di output e ha scritto il 60% del codice dell'interfaccia, allora il 60% dei bug sarà nel suo codice.

Spiega che questo sistema farebbe sembrare che la persona che scrive la maggior parte del codice sia il peggior programmatore, e la persona che scrive il minimo codice è il miglior programmatore.

Sembra molto simile a quando Scott Adams ha sottolineato la saggezza fallita di un Bug Bounty quando il Boss dai capelli appuntiti in Dilbert. Wally annunciò che sarebbe andato a scrivergli un nuovo Mini Van ".

Fumetti Dilbert per il 13/11/1995 dall'archivio ufficiale dei fumetti Dilbert.

Ricordo una volta quando lo sci sulla neve che qualcuno ha sottolineato che "non cadere" non era il segno di un buon sciatore, ma spesso il segno di uno che non prova nulla (o non scia affatto).

I bug possono essere introdotti nel codice con scarsa programmazione e cattiva progettazione; ma possono anche venire come conseguenza della scrittura di molti codici difficili. Dinging persone che producono il maggior numero di bug è probabile che Ding sviluppatori poveri come quelli altamente produttivi.

Sembra che il tuo capo possa essere frustrato dal numero di difetti. Le persone del tuo gruppo sono appassionate di qualità? Creare un campo "cosa" per la causa anziché un campo "chi" potrebbe essere più produttivo. Esempio: modifica dei requisiti, difetto di progettazione, difetto di implementazione, ecc. Anche questo fallirà a meno che non ci sia un gruppo di esperti per migliorare la qualità del prodotto.

Forse dovresti vederlo come "Chi è nella posizione migliore per correggere il bug?" Anche una parte di me si sente, l'hai rotto, l'hai risolto. Ci dovrebbe essere un po 'di responsabilità.

Non sono d'accordo con il mantenimento di una sorta di punteggio. Alcune persone creano più bug perché lavorano su parti più complesse del codice. Se le righe di codice non sono una metrica utile, dubito che i bug per le righe di codice siano migliori. Il codice non verrà mai verificato.

Ad un certo punto un manager dovrebbe sapere chi sta facendo il proprio lavoro e chi no, e chi lo fa meglio perché il resto della squadra lo fa.

È strano che nessuno lo abbia menzionato prima: l'aggiunta di tale funzionalità al bug tracker motiverebbe i dipendenti a provare a giocare al sistema .

Questo è un problema comune per approcci come quello che la domanda ha presentato, tra le altre idee simili (pagamento per numero di righe di codice, pagamento per numero di bug). Ciò incoraggerà molti a concentrarsi sul raggiungimento di un buon punteggio, anziché sulla risoluzione dei problemi relativi al software su cui stanno lavorando.

Ad esempio, provare a inviare una segnalazione di bug con una formulazione per ridurre la propria colpa e spingerla su qualcun altro può portare agli sviluppatori a fraintendere la causa del problema (o il lavoro che viene dato a un altro sviluppatore che non conosce quella sezione di un codice buono come quello che ci stava lavorando di più e che era la causa principale del bug) portando a più tempo e sforzi per risolvere il problema.

La tua vera domanda era su come cambiare la cultura prima di lasciare l'azienda, convincendo il tuo capo che aggiungere una persona al campo di colpa per le segnalazioni di bug è una cattiva idea. Ma ovviamente cambiare la cultura richiede che capisca davvero perché questa è una cattiva idea.

Questo è un ordine elevato. Oltre al problema di salvare la faccia dopo aver cambiato idea, c'è il problema di base che le persone che pensano alle soluzioni principalmente in termini di colpa individuale sono generalmente piuttosto fissate in quella mentalità.

Hai chiesto di scrivere su questo argomento e mi viene in mente Peopleware . È molto apprezzato e parla in termini generali di come gestire le persone facendo un lavoro creativo in cui l'output è difficile da misurare. Il problema è che leggerlo non sarà di grande aiuto, il tuo capo dovrebbe leggerlo e crederci almeno in parte.

Stranamente, poiché il problema qui riguarda più le persone che le segnalazioni di bug, molto probabilmente appartiene più a Workplace che ai programmatori. Ma il successo dei progetti software è di solito abbastanza riconducibile all'interazione sociale umana, quindi le vere risposte sono spesso principalmente su cose che trascendono il software.

Il mio unico altro suggerimento, mezzo serio, è quello di dire (o convincere un collega a dire, dato che hai intenzione di partire) che sei disposto ad assumerti la piena responsabilità del successo del progetto, e il tuo nome dovrebbe sempre andare sul campo , poiché anche se qualcun altro ha commesso l'errore direttamente, hai assunto la responsabilità di assicurarti che tutti i membri del team svolgano un lavoro di qualità.

Ovviamente non ha senso, come hai potuto sostenerlo, ma alcune persone (specialmente le persone che hanno una grande colpa) mangiano davvero quella roba. Ronald Reagan accettava pubblicamente la responsabilità personale ogni volta che un membro della sua amministrazione veniva preso in uno scandalo (e ce n'erano parecchi) e in realtà funzionava abbastanza bene politicamente ogni volta. La parte migliore per te è che la responsabilità generalmente non ha conseguenze reali, pensano solo che sei un tipo in piedi per assumerti la responsabilità.

O forse non è così che andrà giù. Non ha alcun senso per me, quindi è difficile per me prevedere quando funzionerà, ma ho visto che funziona quando sembrava che non ci fossero affari (sul posto di lavoro, non solo nell'esempio di Reagan).

Le persone non vanno al lavoro intenzionate a commettere errori, e nessuna strategia messa in atto, per attribuire in modo specifico la colpa a ciò che potrebbe essere o non essere stato un errore umano è ridicola - per non parlare di estremamente poco professionale.

Per lo meno, una "parte responsabile" incaricata di prendere in carico e "risolvere" il problema, o escogitare un piano per tracciare e / o prevenire il verificarsi di eventi simili, sarebbe buona. A volte la soluzione non è altro che formazione aggiuntiva. Ho lavorato per diverse aziende in cui faceva parte della descrizione del tuo lavoro, per ottenere un'istruzione "azienda pagata / tempo dell'azienda". Un posto ha persino costruito un intero "centro di formazione", che il college locale "prende in prestito" in occasione, per i loro corsi di tecnologie industriali.

Ho lavorato in un ambiente di produzione negli ultimi 20 anni, in cui gli errori di programmazione non solo causano errori, distruggono fisicamente le cose e, o peggio, fanno ferire le persone. Tuttavia, una costante in ogni campo della produzione che è forte, è che non c'è mai, in nessuna circostanza, qualcuno da incolpare. Perché è un difetto nel sistema, chiaro e semplice, non un difetto nelle persone. Guardalo in questo modo - l'uso del correttore ortografico - uno strumento molto efficace, per i meno fortunati nell'area del virtuosismo testuale, o forse solo per quelli un po 'troppo lavorati ... ma non è affatto un metodo di colpa o responsabilità.

Un ambiente di lavoro, indipendentemente dal tipo o dallo scopo, è un sistema. Un sistema composto da singoli componenti, che se opportunamente "in sintonia", funziona in totale armonia - o in qualche modo simile.

Lettura consigliata da parte del tuo capo: Le 7 abitudini di persone altamente efficaci

Sembra che potrebbe usare un po 'di umiltà, se non un controllo della realtà. Fa altrettanto parte della squadra, come tutti gli altri, e deve rendersene conto - o semplicemente non funzionerà, e alla fine, terrà la borsa a prescindere.

Lettura e / o ricerca suggerite da parte vostra:

Guarda 5 perché l'analisi, l'analisi della causa principale ... qualsiasi cosa ti metta in una posizione migliore per offrire una soluzione, non un problema . E il tuo disaccordo con il tuo capo, è proprio questo, un problema, non una soluzione. Offrigli qualcosa di meglio, qualcosa che abbia un senso e sia anche pronto a permettergli di prendersi il merito dell'idea.

In questo momento non sembra che sia pronto a sistemare nulla, perché non ha una ferma comprensione di ciò che è rotto, se c'è qualcosa di rotto, tranne la sua mentalità "Sono il capo".

In bocca al lupo! Spero che riuscirai a superare questo, in un modo accettabile per tutti, specialmente in questi tempi.

EDIT: Personalmente, per esperienza personale ... "Vai avanti, incolpami. Perché abbastanza sicuro, lo aggiusterò, e lungo la strada, quando succederà di nuovo, chi sarà lì per salvare la giornata? Sì, tu indovinato ... io, con un gran sorriso oleoso. "

Per responsabilità non vorrei un person to blamecampo, vorrei un Person who knows the codecampo o un person who can fixcampo, in modo da sapere dove inviare il ticket di supporto.

Ciò accelererebbe il processo di correzione del bug stesso e darebbe responsabilità, un po 'come uccidere due uccelli con una fava. Personalmente lo porterei a lui e gli lascerei decidere se ciò contribuirebbe ad aumentare il morale e la responsabilità senza far sentire a nessuno il fallimento. I test estremi non rilevano tutti i bug, altrimenti non ci sarebbero segnalazioni di bug.

Digli che "la colpa" è negativa. Modificalo in "persona da correggere", quindi almeno è inquadrato in modo positivo e lo stesso lavoro viene ancora svolto. Come possono lavorare le persone se vengono "incolpate" ?!

Se il mio capo facesse che ciò accada, in questo preciso ordine:

1) Comincerei immediatamente a cercare un nuovo lavoro.

2) Ogni volta che viene segnalato un errore con una persona da incolpare, il nome del mio capo appare lì, e un commento sul perché un cattivo processo nella squadra è responsabile per questo. E CC quello al suo capo (preferibilmente in una partita). Hai dei test unitari? Altrimenti significa che il processo di sviluppo è interrotto, quindi il bug. Avete test di integrazione automatizzati costanti con tutti i sistemi esterni? Quindi il processo di sviluppo viene interrotto, quindi il bug. Hai la possibilità di rendere identico ogni ambiente nella produzione tramite script per non consentire errori umani? Quindi il processo di sviluppo viene interrotto, quindi il bug. Uno sviluppatore è terribile? Quindi i criteri di assunzione sono badm quindi colpa del capo. Tutti gli sviluppatori commettono stupidi errori a causa della mancanza di riposo perché lavorano 12 ore al giorno? Quindi il processo di sviluppo viene interrotto.

Come nota a margine: ogni buon manager dello sviluppo è consapevole di ciò che ho scritto sopra. E le strategie agili dovrebbero indicare al capo o ai suoi sostenitori il motivo per cui dev sta rallentando: guarda, stiamo spendendo il 50% del nostro tempo a correggere bug. Vediamo le strategie per ridurle in modo da poter dedicare il 40% del tempo a correggere i bug, quindi rivisitare questo problema portandolo al 30%. eccetera.

Sfortunatamente sembra che tu non abbia un buon manager a causa del campo. Quindi suggerisco di fare (1) e di non dirlo al manager (tranne durante l'intervista di uscita)

Sembra che il tuo capo non abbia una conoscenza approfondita del software e forse non lo intende nemmeno. Quindi ha una lingua diversa, una cultura diversa.

Lasciare un lavoro per un problema come questo, prima ancora di provare ad avanzare per una soluzione è solo essere una persona che lascia. Smettere è smettere. Non smettere fino a quando non ti assicura di non capirti mai. Per essere sicuri, dovresti prima provare.

Dal momento che non conosce la nostra lingua ed è il capo, il primo passo qui sarebbe cercare di parlargli nella sua lingua. Cosa intendo con lingua? Pensiamo insieme:

Noi software people, molti di noi adorano il lavoro che facciamo, abbiamo una profonda connessione con ciò che stiamo facendo. Altrimenti non funziona e non si può continuare a lungo in questo business senza amarlo o essere un completo ... riempi gli spazi vuoti ...

Tuttavia, vede le cose in modo molto diverso. Con ogni segnalazione di bug, mentre la maggior parte di noi è entusiasta di far funzionare meglio la cosa (no, anche se a volte è davvero molto stressante, amiamo i problemi, ammettiamolo!), Lo vede come un fallimento, una misura dell'essere senza esito. La prima cosa che dovrebbe voler capire è che i bug sono buoni. I bug fanno amare i clienti dell'azienda. (Ora questa è la sua lingua) Quando un cliente segnala un bug o quando ne troviamo uno noi stessi, dopo che è stato risolto, è molto meglio della situazione in cui non si è mai verificato. I bug creano fedeltà per i clienti (sono serio!), I bug creano un'ottima scusa per la comunicazione tra il consumatore e il produttore del software.

Per "aumentare il profitto dei bug" dovresti offrire di rendere ancora più aperte le segnalazioni di bug. Con ogni segnalazione di bug e la sua soluzione rapida, pulita e buona, i clienti sentono e vedono che "wow, questi ragazzi sono fantastici! Lavorano davvero duramente. Guarda queste cose che stanno risolvendo. Non eravamo nemmeno consapevoli che il software fosse così complesso cosa!" blah blah e blah ...

Fai la tua mossa, parla nella sua lingua. I bug sono ottimi per un'azienda di software, non è un problema. Ci fanno vivere.

Per etica di gruppo, efficienza o qualsiasi tipo di discorso che faresti potrebbe funzionare nel modo opposto a quello che intendevi. Se vuoi smettere, penserà "aha, la mia soluzione ha iniziato a funzionare fin dal primo giorno! I collegamenti cattivi hanno già iniziato a cadere da soli prima che vengano esposti!" Crede nella sua idea di trovare i cattivi nella compagnia ed è molto difficile convincerlo altrimenti. Soprattutto quando potresti essere uno di quei cattivi ragazzi!

Quindi, concentrati sul suo vero problema: i bug. Dimostragli che i bug possono essere molto utili. Senza problemi, una relazione è noiosa. Tutto ciò che non ti uccide ti rende più forte. Ogni bug è una grande opportunità che puoi usare per aumentare la felicità del cliente.

Questa è solo una cosa che puoi dire. Pensa alle sue preoccupazioni e troverai molti altri elementi da aggiungere al tuo elenco. La chiave d'oro è offrire una cosa alternativa invece di combattere con la sua idea!

Se stai facendo Agile, e sembra che tu sia dal commento di caratteristiche / storie . La persona da incolpare sarebbe la persona con QA che ha lasciato passare il bug o il Product Owner / Customer che ha accettato la funzione / storia come completa con il bug in essa contenuto.

Ho fatto la composizione nel corso della giornata, ecco la mia opinione su di esso.

Questo è come incolpare un compositore per errori di ortografia e altre cose che un correttore di bozze avrebbe dovuto trovare ma mancava. Il compositore ha fatto l'ortografia, ma il correttore di bozze l'ha mancato, quindi è il correttore di bozze a incolpare l'errore di stampa, non la persona che ha commesso l'errore in primo luogo.

In un ambiente Agile è responsabilità delle persone addette al controllo qualità rilevare errori (bug) ed è responsabilità dei proprietari dei prodotti non accettare le cose che non sono corrette. Si tratta di due livelli di lettori di prove che dovrebbero isolare gli sviluppatori dalle cose che vengono rilasciate, che è l'unico modo in cui qualsiasi cosa dovrebbe essere classificata come un bug in un ambiente Agile.

Penso che il tuo manager stia cercando di risolvere un problema con la soluzione sbagliata. Penso che forse ci sia un problema nel rilascio di troppi bug e il tuo manager vuole che gli sviluppatori prendano più proprietà e responsabilità nei confronti del codice che scrivono.

L'uso dello sviluppo guidato dai test e l'installazione di un server di integrazione continua (come Jenkins ) aiuteranno a risolvere questo problema, senza introdurre il "gioco della colpa". Un server di integrazione continua è importante per questo perché quando qualcuno commette codice che "interrompe la build", un'e-mail viene inviata al team che mostra la persona da incolpare. Poiché questo codice non è stato rilasciato in un ambiente di produzione, questo tipo di colpa è più proattivo e incoraggiante (e divertente!).

Il risultato è che gli sviluppatori acquisiranno più proprietà, si sentiranno più sicuri e ci saranno meno bug nel codice di produzione.

Fai notare che se l'errore di una sola persona causa la fine di un bug nella produzione, allora c'è qualcosa che non va nella tua metodologia o nel tuo modo globale di sviluppare software. Fai notare che impedire che i bug arrivino alla produzione è responsabilità dell'intero team.

Usando uno di questi due argomenti, vedi se riesci a convincere il tuo capo che avere il campo "di chi è la colpa" come campo a selezione singola sarebbe fuorviante; e che quindi, è necessario assicurarsi che il campo "a chi dare la colpa" sia un campo a selezione multipla. Una volta ottenuto questo, assicurati che per ogni bug, il nome di tutti sia nel campo. Il tuo capo alla fine vedrà che qualsiasi segnalazione sul campo è futile.

Per dare credito al capo, il concetto di "assegnazione di colpa" è già inserito in strumenti come SVN e un uso appropriato dei dati può essere costruttivo per gli sviluppatori nel "scoprire con chi parlare" durante il debug, ad esempio: http: / /www.codinghorror.com/blog/2007/11/who-wrote-this-crap.html

Mentre sono d'accordo con la risposta di gnat sopra che un campo Causa principale è una buona cosa, questa non è la stessa informazione e "denormalizzare" il campo per assegnare a volte i nomi degli sviluppatori precedenti alla fonte interessata, e talvolta avere un la descrizione tecnica (ad es. "non è stata adattata a 10000 utenti") confonderà le acque. Sostenerei di mantenere una Causa principaleinserire chiaramente una descrizione tecnica (ad es. anche quando si verifica un chiaro errore del programmatore, fare in modo che acquisisca dettagli come "Eccezione IndexOutOfRange quando fooData = 999") Questo può potenzialmente fornire un feedback utile se rivisto in massa e consentire l'adozione di alcune azioni correttive per risolvere intere classi di problemi con modifiche all'architettura o al framework (ad es. miglioramento delle classi di container personalizzate, gestione delle eccezioni di livello superiore)

Detto questo, l'aggiunta di un campo Person To Blame può chiaramente inviare un messaggio pessimo e un messaggio distruttivo a un team di software che la direzione vuole individuare e punire i singoli sviluppatori che infrangono il codice più spesso. Sospetto che il manager ritenga che questo controllo pubblico farà sì che gli sviluppatori siano più attenti e autoregolamentati per evitare di mettere i loro nomi su questo "muro della vergogna", e non capisce perché gli sviluppatori si sentirebbero minacciati da questo, specialmente se viene aggiunto genericamente ad ogni segnalazione di bug.

I problemi con l'aggiunta di questo come campo bug / potenziale metrica sono facili da iniziare con l'enumerazione:

1. I bug sono altamente variabili nella difficoltà da risolvere e una semplice statistica del conteggio / sviluppatore non lo rifletterà.
2. Gli sviluppatori hanno capacità molto variabili "" "" "" "" "" "
3. Molti sistemi software hanno componenti che necessitano di refactoring, tuttavia i refactoring dei componenti legacy (in particolare se la base legacy non ha / limitano le strutture di test delle unità) introdurranno inizialmente dei bug. È probabile che gli sviluppatori siano scoraggiati da questa "buona" attività, se c'è uno stigma / paura associati alla generazione di nuovi bug (anche se questi sono banali da risolvere e il risultato finale è un notevole miglioramento del sistema.)
4. I tester possono presentare un numero molto variabile di bug relativi allo stesso problema, con conseguenti conteggi / sviluppatori molto distorti, a meno che non venga eseguita un'analisi più dettagliata.

Questa è solo la punta dell'iceberg. Combina questi elementi con l'indicazione di chi si aspettava quale comportamento dell'API, risultati previsti errati nei test e problemi "precedenti nella catena" con requisiti errati / mancanti, e dovrebbe essere ovvio che una metrica come questa è condannata come senza valore (a meno che l'obiettivo è danneggiare il morale e provocare un esodo di massa.)

Tornando al punto di vista del capo, è OK che lui / lei voglia scoprire se ci sono sviluppatori che stanno rompendo il codice ripetutamente e provare a fare qualcosa (si spera costruttivo) a riguardo. Cercare di ottenere queste informazioni aggiungendo un campo alle segnalazioni di bug non fornirà informazioni significative per i motivi sopra elencati. Nella mia esperienza, queste informazioni possono essere apprese collegandosi al team, partecipando alla maggior parte delle riunioni del team, integrando (con attenzione) le informazioni apprese in incontri occasionali uno-a-uno con i membri del team e acquisendo familiarità con i sottosistemi in il codice (anche se non possono leggere il codice.)

Lascialo andare. Il tuo capo scoprirà da solo che può causare un problema, se lo fa.

Siamo sinceri, hai un'opinione e anche lui. È il tuo manager e la sua opinione è quella che vince.

Sì, puoi andare in guerra per questo problema, ma ne vale davvero la pena? Dubito che duri più di 3 mesi prima di cadere in disuso.

Ma sabotare attivamente questo o urlare su di esso utilizza solo capitale politico che è meglio risparmiare per chiedere quel tempo libero extra, rilancio successivo, promozione o quando verrà presa una decisione di progettazione davvero critica.

In quel momento, quando conta davvero, non vuoi che il capo ricordi che eri la persona che ha attivamente sabotato la sua idea di "persona da incolpare".

Rispetta l'ufficio anche se non rispetti la decisione.

Salva lo stress e il martellamento della tabella per le decisioni che dureranno molto più a lungo.

Di 'al tuo capo che lo sviluppo in una squadra ha bisogno di abilità sociali. Potrebbe persino annuire.

Ma il problema è che questo è qualcosa con cui gli sviluppatori sono estremamente cattivi. L'aggiunta di strumenti che suggeriscono che la colpa sia più importante di un'adeguata analisi dei problemi è controproducente.

Invece hai bisogno di incentivi per migliorare le abilità sociali e l'infrastruttura di comunicazione che hai dovrebbe supportarla. Ad esempio, conia in modo positivo: nomina una persona che è responsabile di un biglietto, che se ne prende cura.

Inizia anche con le revisioni del codice in modo da poter imparare le une dalle altre. Ciò risparmia le responsabilità in seguito.

Inviagli questa domanda via email. Se è aperto alla ragione, i commenti qui forniranno controlli di sanità mentale per il suo ragionamento. Se non è ragionevole, è improbabile che tu lo convinca con ragioni sensate. Inoltre, sarà in grado di leggere le ragioni al di fuori di una conversazione (che a volte può essere più convincente a causa della motivazione rimossa di "avere ragione" nel calore di una conversazione).

Potresti anche provare a capovolgerlo. Il campo potrebbe essere "possibili passi per evitare che si verifichi un errore simile" o qualcosa di più breve in tal senso. Quindi potresti raggruppare le soluzioni e votare quali implementare per migliorare il tuo posto di lavoro. Forse un approccio orientato alla soluzione è più produttivo e probabilmente meglio ricevuto (a condizione che ci sia un seguito effettivo sulla rivisitazione dei suggerimenti).

Vedo due possibilità qui: vuole essere in grado di punire le persone che commettono errori, o semplicemente non ci ha pensato. Fagli sapere che la percezione per tutti sarà che intende punire coloro che commettono errori. Chiedigli se questa è la cultura che vuole incoraggiare.

il mio capo ha deciso che l'aggiunta di un campo "Person To Blame" al nostro modello di tracciamento dei bug aumenterà la responsabilità

Nella mia esperienza, quando il management vuole "rendere le persone più responsabili", ciò che vogliono dire è che vogliono essere in grado di punire il fallimento. Che si tratti di licenziare performer poveri, o semplicemente lasciarli oscurare nella revisione annuale dello stipendio ("Mi dispiace, Bob, hai segnalato 17 errori come colpa, e questo è oltre il limite di 15"), è una punizione.

Probabilmente dirà "Oh, no, non lo vogliamo", quindi chiedigli come verranno utilizzati quei dati. Ricordagli che non aggiungi punti dati a un database a meno che non lo utilizzerai. Vuole selezionare su un determinato criterio ("Mostrami tutti i bug aperti nel sottosistema creatore di rapporti"), in modo che tu possa lavorare su cose o essere in grado di ottenere dati aggregati ("Quale sottosistema ha avuto più bugs "), in modo da poter eseguire analisi post mortem. Prevede una sorta di tote board del fallimento in cui le persone possono essere umiliate pubblicamente?

Quindi quale intende? Vuole essere in grado di dire "Mostrami tutti i bug che sono colpa di Bob?" Perché? O vuole essere in grado di dire "Mostrami chi è in colpa la maggior parte del tempo?" Perché? Il primo non è significativo e il secondo è solo punitivo. O la terza opzione è che non ha una vera ragione.

Ammetto che esiste la possibilità che stia cercando quei programmatori nel team che hanno bisogno di aiuto per migliorare le proprie capacità. In tal caso, esistono modi migliori per acquisire queste informazioni che non creano una cultura del puntamento del dito.

Credo che l'aspetto chiave da tenere d'occhio qui sia quanto sia aperta la comunicazione nella squadra verso il "capo" e viceversa. Il puntamento del dito non è mai buono, tuttavia, dal punto di vista della gestione, se uno dei tuoi sviluppatori cade più volte nello stesso problema, potrebbe essere il momento di intervenire e provare ad aiutarlo a superare questo problema ripetitivo (ad esempio John non sta testando correttamente il codice: 3 bug di produzione negli ultimi 3 mesi, diamo una lista di controllo in modo che ricordi come dovrebbe essere il suo codice e come dovrebbe testarlo).

Da un punto di vista dello sviluppo, la "colpa" è già incorporata in uno strumento tradizionale come SVN, quindi non vedo alcun danno nell'andare "John, per favore, aggiusta quel pezzo di merda che hai scritto" e mettendo un nome accanto a esso. JIRA incorpora anche il nome di una persona quando presenti un bug (tuttavia il campo non è pensato per la persona responsabile, è praticamente così che qualcuno lo risolve).

Ecco la cosa però, come molti sopra menzionati da molti, se sorge un bug, è una responsabilità condivisa: dallo sviluppatore, ai tester, al QA, ai manager. Se il tuo capo ad un certo punto gestisce un cliente arrabbiato al telefono con cose del tipo " Mi dispiace tanto, John non lo ha mai testato correttamente ", allora sicuramente avrei cercato un altro lavoro. Un buon capo dovrebbe andare "ci penseremo noi". Nessun nome, nessun puntamento del dito, solo soluzioni.

Ancora una volta, credo che tutto riguardi la comunicazione. Forse l'unica cosa che il tuo capo vuole fare è vedere chi sta avendo problemi nella squadra di sviluppo, o che tipo di problemi sta avendo la squadra (forse per le sessioni di allenamento?), Ma non credo che scoprirai esattamente cosa c'è dietro decisione (o meglio, noi poster / lettori) a meno che tu non parli con il tuo capo e l'intero team.