Come influire sulle priorità dei bug per gli sviluppatori e trattarli di conseguenza?

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

Quindi ovviamente qualcosa di grave e frequente è della massima priorità. Tuttavia, qualcosa di serio ma che accade raramente dovrebbe essere soppesato all'incirca come qualcosa che non è serio ma che accade spesso. Quindi supponendo di valutare la gravità da 1 a 3 e la frequenza da 1 a 3, i tipi di bug che dovresti probabilmente correggere sono quelli che attraversano la diagonale definita dalla gravità 1, frequenza 3 e gravità 3, frequenza 1.

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

Un errore che l'utente vede ogni volta che il programma viene lanciato avrà una frequenza di 3. Un errore con frequenza 1 sarà qualcosa che accade raramente se non del tutto. Di nuovo, se non sei sicuro, 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 la corretta gestione degli errori quando la connessione al database non funziona.

Ancora una volta, questa è solo un'idea approssimativa, ma l'idea è di dare enfasi a quello che dovrebbe essere l'obiettivo per la correzione dei bug come una sorta di triage. Chiaramente non è possibile eliminare tutti i bug, i blocchi o altro, anche se almeno con questa metodologia, si può tranquillamente affermare che i bug non sono troppo urgenti o troppo frequenti. Se risolvi solo bug che bloccano errori, allora gli errori ad alta frequenza verranno ignorati e gli utenti noteranno che non hai corretto questi bug.

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

Buona fortuna!

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

In genere un sistema di gestione del progetto agile include una sorta di riunione per la definizione delle priorità in cui le attività vengono ordinate per priorità e lavorate in tale 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 funzionalità importanti incluse prima che il budget scada.

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

È un ciclo piuttosto comune per un software che accumula bug non critici finché qualcosa non dà, quindi accade un grande evento e molti di essi vengono risolti in un momento; magari dedicando uno sprint o due solo a correzioni di bug prima di una nuova grande release, o essendo il software EOL e sopravvissuto agli heap-o-bug.

Quindi sei in buona compagnia se i tuoi sviluppatori le facessero semplicemente scivolare. Ovviamente puoi giocare con "regole" come hai detto ("se non stai lavorando su una nuova funzione, devi lavorare almeno su una P2 alla settimana"), ma questo probabilmente ti renderà impopolare.

My question is how to have people deal with bugs, without imposing a strict agenda and yet to have it resolved.

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

Non dire ai tuoi sviluppatori che devono fare un lavoro che non gli piace; ma prova a cambiare l'atmosfera in modo che gli piaccia lavorare sui bug. Cerca di infondere un senso di orgoglio in un'applicazione senza bug. Rendilo più divertente (sic) lavorare su un bug, consentendo in particolare a loro di correggere effettivamente il motivo sottostante che ha reso tale bug manifest (cioè, non solo soluzioni rapide / hack), se ce n'è. Strappare una struttura di classe rotta e sostituirla con qualcosa di più adatto può essere molto divertente per gli sviluppatori. Se hai qualche pezzo centrale rotto che fa regolarmente manifestare bug, devi fissare il pezzo centrale.

Il modo in cui raggiungi il tuo obiettivo dipende in gran parte dal tuo personaggio e da quello dei tuoi team - non cercare di ingannarli in ciò che vuoi ottenere, ma di avere discussioni aperte, provare a far funzionare un peer, lasciarli escogitare un processo di lavoro autonomamente, e così via.