Assegnazione della colpa per i bug contro la ricompensa per le correzioni [duplicato]

Il tuo manichino di vergogna risulterà in effetti il rallentamento dei bug. Le persone sono solo persone, avranno un backlog segreto di bug così quando passeranno il manichino, troveranno "miracolosamente" un'altra perdita di risorse per gli sviluppatori prima che il giorno sia finito.

Si tratta di incentivi, la tua politica non promuove la ricerca di perdite, promuove la scoperta di 1 perdita, e questa è la perdita che trovi subito dopo che hai passato il manichino.

Inoltre il fatto che rimanga con te fino alla prossima perdita significa che la "punizione" non ha nulla a che fare con la gravità del bug. Qualcuno può fare una grande perdita di risorse, avere il manichino per un giorno, trovare un piccolo problema il giorno dopo, passare il manichino e potrebbe rimanere con quello che ha reso il piccolo problema più a lungo del ragazzo che ha fatto il grande oops.

Non penso che tu sia irragionevole nel pensarlo.

Come l'idioma diventa You can catch more flies with honey than with vinegar

Non siamo perfetti, le persone sbagliano di tanto in tanto e piuttosto che concentrarsi su incolpare qualcuno e poi svergognarle pubblicamente, sarebbe nel migliore interesse del team far correggere il bug il più velocemente possibile piuttosto che spedire il codice fallito.

Per attenuare la perdita di senso della proprietà del codice che potrebbe essere causata da questa mossa pro-team, puoi porre delle restrizioni che il proprietario del codice da cui ha origine il bug deve ancora risolverlo da solo. è un bug che va oltre la capacità del programmatore di risolvere.

Per quanto riguarda i motivi per cui taglie o incentivi per i bug, controlla il commento di MichaelIT.

È importante distinguere tra "bug" e "qualità del codice".

I bug sono inevitabili nello sviluppo di software, quindi allegare uno stigma negativo ai bug è, in effetti, attaccare uno stigma negativo alla creazione di qualsiasi nuovo codice. In genere è meglio gestire il processo generale di sviluppo del codice. Un processo più efficiente potrebbe causare la cattura di questi bug in una fase precedente di sviluppo e consentire un tempo di risposta migliore per i bug che vengono scoperti in seguito.

Per iniziare, esamina il processo di sviluppo e identifica le aree di confusione, che potrebbero includere:

• Requisiti aziendali "X dovrebbe essere in grado di eseguire Y"
• Scomposizione tecnica dei requisiti aziendali (servizi interessati, ui necessari, test di accettazione)
• Standard di codifica, test, stile (in una certa misura)
• Frequenza del codice commit
• Possibilità di correggere i bug prima di scrivere nuove funzionalità.

Se c'è una cultura di correggere i bug prima di sviluppare nuove funzionalità, dovrebbe esserci una "policy" che circonda le correzioni dei bug? Se lo sviluppo del codice di qualità diventa un processo naturale, se la risoluzione dei bug diventa un processo naturale, allora la necessità di rendere le politiche e i sistemi di ricompensa sarà attenuata.

Oltre alle premesse della domanda, come la stessa domanda (sul pensiero irragionevole) si applica all'insegnamento in classe:

Immagina due insegnanti che partecipano frequentemente alla classe ponendo domande come "Qualcuno conosce la risposta?"

Quando gli studenti in classe si alzano le mani, potrebbero conoscere o non conoscere la risposta, o raggiungere il punto da qualche parte. Concentriamoci sulle "risposte non così giuste" che vengono selezionate.

L'insegnante Uno si avvicinerebbe con l'approccio "manichino della vergogna". Se la risposta non è corretta, o molto vicino a correggere ... Lo studente è ridicolizzato con "Quanto scarsa risposta, vergogna per te".

L'insegnante due si sarebbe avvicinato con incoraggiamento. Quando la risposta non è corretta, tutti sono incoraggiati con "Buona risposta, spiega X e Y sulla domanda ma c'è dell'altro". (poi continuando a spiegarlo, non chiedendo a nessuno di "correggere" la prima risposta perché creerebbe un ambiente competitivo.)

Ora pensa a quale di questi insegnanti ha più mani alzate quando fai domande come questa. L'Insegnante Due crea un ambiente in cui tutti possono partecipare senza timore di non comprenderlo appieno.

Questo può essere applicato alla domanda originale. Nella programmazione a squadre partecipano tutti, il che dovrebbe essere incoraggiato. Quando viene trovato un bug di perdita di memoria, come un'altra risposta affermata, fare in modo che il bug bug risolva offrendo supporto a creare esperienza di apprendimento e portare a meno tali errori commessi in futuro da questo programmatore. È anche più probabile che tutti siano più disposti a partecipare e lavorare come una squadra, non lavorando come " branco di predatori in competizione ".