Come influenzare le priorità dei bug per gli sviluppatori e trattarle di conseguenza?

Abbiamo un processo di bug attualmente in fase di elaborazione.

Abbiamo 3 livelli di bug:

Bug P1: bug che impedisce agli utenti di funzionare. Devono essere risolti sul posto.
Bug P2: bug che hanno un impatto ma che gli utenti possono lavorare
Bug P3: bug che non influiscono e in cui gli utenti possono lavorare.

P1 è obbligatorio e deve essere distribuito sul posto. Ma per P2 e P3, giudichiamo caso per caso.

Con i 3 livelli che abbiamo, il team ha la tendenza a lavorare su nuovi sviluppi più urgenti richiesti dai clienti, invece di occuparsi di P2 e P3, che è quasi come non urgente.

Le domande sono le seguenti:

Dovrei aggiungere un altro livello di priorità, come avere un P4?

Devo anche assegnare loro obiettivi per gestire i biglietti non urgenti come in questa settimana, quando non si assegnano compiti di codifica, è necessario trattare almeno 1 P2?

Al momento, non abbiamo obiettivi come quelli sopra menzionati, ma la mia preoccupazione è che dare loro tali obiettivi può essere brutale. La cosa certa è che devo parlargli degli obiettivi, alla squadra piace essere coinvolta nella discussione, specialmente quando stabiliamo gli obiettivi.

Aggiornare:

Mi è stata proposta questa domanda in termini di somiglianza. Tuttavia non è affatto simile.

La mia domanda è come fare in modo che le persone affrontino i bug, senza imporre un'agenda rigorosa e tuttavia risolverli. Quindi no, la domanda implicita non mi aiuta. Grazie ancora.

agile debugging issue-tracking

— Andy K
fonte

Possibile duplicato di Come posso convincere il management a gestire il debito tecnico?

— moscerino

di solito il livello di priorità non è utile come l'ordinamento di priorità ... "bug X" è più importante di "bug Y". se aggiungi p4 alla fine vorrai p5 e p3.5

— sudo rm -rf slash

Se hai così tanti bug P1 che tutti i tuoi sviluppatori sono sempre occupati a risolverli invece di lavorare su P2 / P3, stai facendo qualcosa di molto sbagliato. Non aggiungere altre funzionalità per un po '. Concentrati sull'analisi approfondita e sulla risoluzione dei problemi architettonici (o del personale) che quasi sicuramente causano molti di questi bug. Se stai codificando in C ++, ad esempio, assicurati di utilizzare RAII ovunque tu sia, quindi non dimenticare di farlo manualmente .release().

— Fondo Monica's Lawsuit,

Qual è il tuo obiettivo? Vuoi che gli sviluppatori lavorino di più sulle correzioni di bug e meno sulle nuove funzionalità? Modifica la tua domanda per chiarire. Inoltre, descrivi in che modo gli sviluppatori attualmente ricevono o prendono lavoro? Cosa viene utilizzato per decidere su cosa si lavora?

— sleske,

funzionalità, bug, modifica come lo chiami, il software non fa quello che deve. L'unica differenza tra un bug e una funzionalità è chi paga per questo.

— Mattnz,

Risposte:

Generalmente hai due assi per i bug: gravità e frequenza.

Quindi ovviamente qualcosa di grave e frequente ha la massima priorità. Tuttavia, qualcosa di grave, ma che accade raramente, dovrebbe essere valutato approssimativamente allo stesso modo di qualcosa che non è grave, ma accade spesso. Quindi supponendo di valutare la gravità da 1 a 3 e la frequenza da 1 a 3, i tipi di bug che probabilmente dovresti correggere sono quelli che attraversano la diagonale definita da gravità 1, frequenza 3 e gravità 3, frequenza 1.

Un errore di blocco o un errore che potrebbe creare un danno potenziale alle informazioni del cliente sarebbe sempre una gravità 3. Allo stesso modo, un errore con la gravità 1 non sarà probabilmente notato dall'utente o avrà una bassa priorità. Se non sei sicuro qui, 2 è probabilmente un numero sicuro da assegnare.

Un errore che l'utente vede ogni volta che viene lanciato il programma avrà una frequenza di 3. Un errore con la frequenza 1 sarà qualcosa che accade raramente se non del tutto. Ancora una volta, se non si è sicuri, 2 è probabilmente un numero sicuro da assegnare.

È per lo più soggettivo su ciò che costituisce un bug con gravità 3 o un bug con frequenza 3, ma usa il tuo buon senso. Un bug con gravità 1, frequenza 2 è forse un'etichetta errata. Un bug con gravità 2, frequenza 1, potrebbe essere una corretta gestione degli errori quando la connessione al database è inattiva.

Ancora una volta, questa è solo un'idea approssimativa, ma l'idea è quella di dare enfasi a quello che dovrebbe essere al centro del bug fixing come una sorta di triage. Chiaramente non è possibile eliminare tutti i bug, i blocchi o altro, sebbene almeno con questa metodologia, si può tranquillamente affermare che i bug non sono troppo urgenti o troppo frequenti. Se viene confermato solo bug che stanno bloccando gli errori, poi gli errori ad alta frequenza verranno ignorati e gli utenti potranno notare che non è stato risolvere questi bug.

Inoltre, per comodità, potresti scoprire che preferisci fornire i gradi in lettere per gravità o frequenza, quindi puoi dire che un bug è un errore B3 ed è chiaro sia la gravità che la frequenza.

In bocca al lupo!

— Neil
fonte

In realtà, esiste solo una metrica per i bug: il ROI: quanto costerà correggere rispetto a quanto l'azienda perde per non risolverlo. Confrontalo con le caratteristiche. Naturalmente, come si calcola quella metrica coinvolge la gravità, la frequenza, ecc.

— corsiKa

@corsiKa, sì, il ROI è una metrica composita: "ritorno" e "investimento". E per i bug, il ritorno può essere modellato come un composto di "gravità" e "frequenza".

— Paul Draper,

@corsiKa, quel tipo di analisi egoistica a sangue freddo delle decisioni sulla qualità è in realtà estremamente irresponsabile. È la stessa logica che porta le aziende farmaceutiche a eludere le leggi sui test di efficacia se possono "cavarsela" o mantenere sul mercato farmaci redditizi nonostante la gravità e la frequenza degli effetti avversi. È la stessa irresonsabilità che porta a vaste botnet composte da router consumer non sicuri e dispositivi "intelligenti", poiché il produttore non ha potuto vedere alcun valore in dollari in buona sicurezza. Gravità e frequenza sono MOLTO metriche migliori di "impatto sui profitti".

— Wildcard il

@Wildcard Sono letteralmente comunista, quindi sono d'accordo al 100% con te sul fatto che siano migliori. Ciò non cambia il fatto che questo è il modo in cui sono gestite le società di software e andare contro quella corrente, a meno che tu non gestisca la società, ti annegherà. Anche se vale la pena notare, non è egoista. È monoporzione, ma quel singolo non è il sé, è la compagnia. Sto solo buttando questo fuori di qui.

— corsiKa

@Wildcard e corsiKa la compagnia non è grande e non possiamo permetterci di dire "oh, perderemo denaro, quindi facciamo qualcosa, altrimenti continuiamo a tenerlo fermo". Nel grande schema delle cose, tuttavia, non credo che l'approccio che hai citato sia sostenibile a lungo termine. Persone: i clienti sono tutt'altro che stupidi. Le compagnie che hanno predicato quel tipo di vangelo, Sun, per nominarne una, non sono più qui. Ho lavorato nella gestione degli account abbastanza a lungo da non guadagnare soldi in quel modo. A chiunque, se ti capita di lavorare per una società del genere in cui manca la lealtà 1 / n

— Andy K,

Questo si riduce davvero a ciò che consideri più importante. Il bug P2 o la nuova funzionalità?

Di solito un agile sistema di gestione del progetto includerà una sorta di riunione di prioritizzazione in cui le attività sono ordinate per priorità e lavorate in quell'ordine.

Gli sviluppatori non sono autorizzati a scegliere le attività su cui lavorano. Questo è il lavoro del project manager. Chi deve garantire che il progetto abbia il maggior numero possibile di importanti funzionalità incluse prima che il budget si esaurisca.

Questa è davvero la cosa più importante. Regole semplici come "aggiustare almeno 1 P2 a settimana" non aiutano davvero questo obiettivo.

— Ewan
fonte

Il problema nell'assegnare le priorità è che qualunque sia la granularità della benna che si sceglie, si finisce sempre con più di una per benna. Devi mettere le cose in ordine, non solo dire "tutte queste sono PRIMA PRIORITÀ!"

— Ewan,

@Ewan C'è anche la possibilità di un'inflazione prioritaria in cui il tuo livello più alto ha più problemi di quanti tu possa mai sperare di affrontare e nuovi livelli di priorità sono inventati al di fuori del sistema di tracciamento dei bug. Ho sentito gente parlare di problemi di P meno 2.

— Kasperd,

Dire che agli sviluppatori non è permesso scegliere le attività su cui lavorano danneggerà la tua produttività. Se uno sviluppatore è bloccato sul problema con la massima priorità su cui stava lavorando, è meglio se nel frattempo può lavorare su un altro problema piuttosto che non fare nulla mentre il primo problema è bloccato su qualcosa. Inoltre, i problemi che non danneggiano gli utenti ma che danneggiano la produttività degli sviluppatori spesso non hanno la priorità più elevata di quanto dovrebbero essere. Infine, dire agli sviluppatori che non sono autorizzati a prendere decisioni da soli è un modo sicuro per distruggere la motivazione.

— Kasperd,

@kasperd Penso che la maggior parte degli sviluppatori accetti di essere dipendenti oltre che di super geni tecnici e accetta che il loro datore di lavoro decida quali compiti devono essere svolti per primi. Ovviamente se uno è bloccato ti sposteresti al successivo più importante, ma non salti 10 compiti importanti per lavorare su quello interessante.

— Ewan,

Ho scoperto che se il lavoro è completato o bloccato, invece di trascinare un altro compito di sviluppo nello sprint (facendo scrum) un bug dovrebbe invece avere la priorità. MS ha notoriamente dato a tutti i bug la massima priorità rispetto a qualsiasi attività di sviluppo quando si lavora su Windows 2000 - hanno scoperto che era il modo migliore per produrre software non difettoso (uno dei motivi per cui al 2000 piaceva davvero) come se non lo facessero , i bug tendevano a rimanere lasciati, poiché di solito c'era qualche nuovo sviluppo su cui lavorare.

— Baldrickk,

È un ciclo abbastanza comune per un software accumulare bug non critici fino a quando qualcosa non si presenta, quindi accade un grande evento e molti di essi vengono risolti contemporaneamente; forse dedicando uno o due sprint a correzioni di bug solo prima di una nuova grande release, o dal fatto che il software è EOL e è sopravvissuto agli heap-o-bug.

Quindi sei in buona compagnia se i tuoi sviluppatori li lasciano semplicemente scivolare. Ovviamente puoi destreggiarti con "regole" come hai menzionato ("se non stai lavorando su una nuova funzionalità, devi lavorare su almeno una P2 alla settimana"), ma probabilmente ti renderà impopolare.

La mia domanda è come fare in modo che le persone affrontino i bug, senza imporre un'agenda rigorosa e tuttavia risolverli.

Invece, suggerirei di cambiare un po 'la mentalità generale e di rendere i bug più simili a quelli delle funzionalità, nel senso che sono cittadini di prima classe nel tuo backlog. Sì, le nuove funzionalità sono fantastiche; sì, la gestione e le vendite fanno molto affidamento sulle nuove funzionalità. Ma è importante avere un'applicazione stabile e ben funzionante invece di un enorme mucchio di bug disordinati.

Non dire ai tuoi sviluppatori che devono fare un lavoro che non gli piace; ma prova a cambiare l'atmosfera in modo che a loro piaccia lavorare sui bug. Cerca di infondere orgoglio in un'applicazione senza bug. Rendi più divertente (sic) lavorare su un bug, consentendo loro in modo specifico di risolvere effettivamente il motivo sottostante che ha reso manifesto quel bug (cioè non solo soluzioni alternative / hack), se ce ne sono. Strappare qualche struttura di classe rotta e sostituirla con qualcosa di più adatto può essere molto divertente per gli sviluppatori. Se hai un pezzo centrale rotto che fa regolarmente manifestare bug altrove, correggi il pezzo centrale.

Il modo in cui raggiungi il tuo obiettivo dipende in larga misura dal tuo personaggio e da quello delle tue squadre: non tentare di ingannarli in ciò che desideri raggiungere, ma fai discussioni aperte, cerca di ottenere un effetto peer running, lascia che escano un processo lavorativo e così via.

— Anoe
fonte