Come gestisci pile di problemi sempre crescenti da risolvere "da qualche parte"?

Questi sono buoni bug di primo contatto da risolvere per i nuovi sviluppatori che hanno appena aderito alla tua azienda. O per gli sviluppatori juniores spende la loro conoscenza del sistema.

In caso contrario, puoi contrassegnarli "non aggiustarli" se non sono abbastanza seri da giustificare il tempo necessario per la correzione.

Dovresti correggere un bug solo se l'applicazione ha più valore senza il bug.

Se un campo di testo non è allineato e sono necessari tre giorni per risolverlo, il costo è probabilmente troppo alto e dovresti lasciarlo. Al contrario, se gli utenti non possono scrivere del tutto nel campo di testo, allora dovresti correggerlo e rapidamente.

In generale è più facile risolvere un problema immediatamente dopo che è stato scoperto. Se lasci passare il tempo, gli sviluppatori possono dimenticare come funziona quella parte del codice e correggere il bug richiederà più tempo e quindi sarà più costoso.

Alcune aziende non scrivono una riga di nuovo codice se ci sono ancora bug in sospeso. Altri non si preoccupano fino alla fase di test prima della consegna.

Nella tua azienda stai ovviamente lasciando passare molto tempo prima di correggere nuovi bug, quindi si stanno accumulando. È anche un male per il morale della squadra vedere un elenco enorme di bug.

Ti suggerisco di passare una giornata solo per risolvere i bug esistenti, decidendo quelli che valgono la pena risolvere e quelli che non lo sono e assegnando quelli da correggere ai membri del team esistenti con l'obiettivo di risolvere i problemi prima il prossimo traguardo.

Nel nostro monitoraggio dei problemi, c'è uno stato "time-barred". Se un problema è di diversi mesi o anni, e nessun cliente sollecita o modifica il problema, questo stato viene utilizzato come stato finale. Questo non viene fatto automaticamente, ma manualmente, ogni volta che i gestori ci chiedono di ripulire i problemi aperti. Durante questo processo, è anche probabile che alcuni dei problemi siano risolti perché sono facili da correggere e / o relativamente importanti (nonostante non siano stati sollecitati o modificati).

Non uso JIRA, ho fogbugz al lavoro ma sono sicuro che questo si applica alla maggior parte degli inseguitori di bug. Mentre scrivevo questo, mi sono reso conto che il modo in cui lavoro è più agile della cascata, le scadenze non sono concrete per me e ciò che conta è la priorità.

• Se il tuo capo si preoccupa che troppi biglietti siano aperti, in primo luogo non creare quelli banali. Dovresti essere prgamatic e non aggiungere funzioni / correzioni che non hanno benefici. Se renderà la tua vita più facile lucidare un po 'di codice o modificare l'interfaccia utente, allora sicuro, aggiungilo. Non limitarti a lavorare da solo cercando di correggere piccoli difetti nel prodotto, nulla è perfetto.
• Inserisci gli errori / le caratteristiche non importanti nella milestone attuale ma con una bassa priorità. Se vengono segnalati più reclami / richieste sul problema, è possibile aumentare la priorità.
• Chiudi / risolvi ciò che puoi come non aggiusterai, non potrai riprodurre, duplicare, ecc. Alcuni bug sono troppo banali da risolvere o sono richieste di funzionalità che richiederebbero troppo tempo. A volte devi solo dire alla persona che richiede queste correzioni / caratteristiche "No, non abbiamo tempo"
• Dai la priorità ai bug come richiesto e ordina la lista dei tuoi biglietti in base alla priorità e al traguardo.
• Se non stanno per fare il punto cardine, spostali in una pietra miliare futura.
• Se un ticket dipende dal completamento di un altro ticket, contrassegnalo come bloccato o organizza i ticket in una gerarchia, quindi è ovvio che ticket-x e ticket-y sono correlati.
• Se un ticket richiede un feedback da qualcuno, assegnarlo a quella persona.

Alla fine avrai sempre un sacco di biglietti a bassa priorità seduti, ma i punti sopra dovrebbero aiutarti a ridurli al minimo.

Usiamo JIRA e abbiamo uno stato di risoluzione aggiuntivo chiamato Suspended - se una funzionalità / bug è qualcosa su cui dobbiamo semplicemente rinunciare per un po ', viene risolto come sospeso. In questo modo non si confonde con l'elenco dei problemi attualmente attivi su cui dobbiamo concentrare la nostra attenzione, o l'elenco dei problemi risolti che sappiamo essere stati gestiti satistfactory, ed è ancora presente nel database.

L'elenco dei problemi sospesi è qualcosa che rivedo periodicamente (ma non molto spesso) per riaprire se necessario.

Non sei sicuro della terminologia JIRA corretta, ma considera di mettere una data di scadenza su ogni "ticket". Se non è stato escalation, per esigenze di funzionalità o gravità del bug, per l'implementazione entro un certo periodo di tempo, probabilmente non era così importante in primo luogo. Questo dovrebbe aiutare a mantenere automaticamente il pelo tagliato. Spesso ricevo biglietti basati su "non sarebbe bello" o "questo non funziona perfettamente come voglio". Se nessun altro ne spinge abbastanza, o quell'utente non ha abbastanza peso, non viene fatto e chiudo il biglietto dopo un paio di mesi.