Come gestite pile di problemi in costante crescita da risolvere "in qualche modo"?

Stiamo usando JIRA per tenere traccia dei problemi nei nostri progetti software. Un effetto che abbiamo notato è che spesso creiamo un nuovo problema ma non sappiamo ancora quando / se il problema verrà risolto. Quindi abbiamo inventato una finta pietra miliare del 'Distant Future' a cui vengono assegnati tali problemi.

A quanto pare, il mucchio di problemi assegnati a questo traguardo continua a crescere continuamente, quindi sembra che questo non sia un buon approccio. Ce ne sono così tanti ormai che è diventato un bel po 'di lavoro per rivederli tutti per validità. Alcuni di essi non sono più validi poiché il componente a cui sono correlati è stato rimosso. Alcuni di essi sono stati duplicati da altri problemi. Alcuni hanno una descrizione così mal definita che nessuno sa più di cosa si tratti.

In che modo altri team di sviluppo software gestiscono i problemi validi, ma che potrebbero non essere risolti in qualsiasi momento. Ti preoccupi di registrarli? Li assegni alla prossima versione pianificata e poi li guardi di nuovo mentre si avvicina la prossima versione? Qualcos'altro?

Questi sono buoni bug di primo contatto da correggere per i nuovi sviluppatori che si sono appena uniti alla tua azienda. O per gli sviluppatori junior di espandere la loro conoscenza del sistema.

In caso contrario, è possibile contrassegnarli come "non risolverli" se non sono abbastanza seri da giustificare il tempo necessario per risolvere.

È necessario correggere un bug solo se l'applicazione è più preziosa senza il bug.

Se un campo di testo è disallineato e ci vogliono tre giorni per risolverlo, allora il costo è probabilmente troppo alto e dovresti lasciarlo. Al contrario, se gli utenti non riescono a scrivere nel campo di testo, è necessario correggerlo e rapidamente.

In generale, è più facile risolvere un problema immediatamente dopo che è stato scoperto. Se si lascia passare il tempo, gli sviluppatori potrebbero dimenticare come funziona quella parte del codice e correggere l'errore 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 in modo che si accumulino. Fa anche male al morale della squadra vedere un enorme elenco di bug.

Ti suggerisco di trascorrere una giornata solo per risolvere i bug esistenti, decidere quelli che vale la pena correggere e quelli che non lo sono e assegnare quelli da correggere ai membri del team esistenti con l'obiettivo di risolvere i problemi prima del prossimo traguardo .

Nel nostro rilevamento dei problemi, esiste uno stato "a tempo". Se un problema ha diversi mesi o addirittura anni e nessun cliente lo sollecita o lo risolve, questo stato viene utilizzato come stato finale. Ciò non avviene automaticamente, ma manualmente, ogni volta che i gestori ci chiedono di risolvere i problemi aperti. Durante questo processo, è anche probabile che alcuni dei problemi vengano risolti perché sono facili da risolvere e / o relativamente importanti (nonostante non vengano sollecitati o rielaborati).

Non uso JIRA, ho fogbugz al lavoro ma sono sicuro che questo vale per la maggior parte dei bug tracker. 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 al tuo capo importa che troppi biglietti siano aperti, non creare quelli banali in primo luogo. Si dovrebbe essere prgamatici e non aggiungere alcuna funzionalità / correzione che non abbia alcun vantaggio. Se ti semplificherà la vita per lucidare un po 'di codice o modificare l'interfaccia utente, assicurati di aggiungerlo. Non limitarti a lavorare da solo cercando di correggere piccoli difetti nel prodotto, niente è perfetto.
• Inserisci i bug / funzionalità non importanti nella pietra miliare attuale ma con una priorità bassa. Se vengono menzionati più reclami / richieste sul problema, è possibile aumentare la priorità.
• Chiudi / risolvi ciò che puoi, perché non risolvibile, impossibile riprodurre, duplicare, ecc. Alcuni bug sono troppo banali per essere corretti o sono richieste di funzionalità che richiederebbero troppo tempo. A volte devi solo dire alla persona che richiede queste correzioni / funzionalità "No Siamo spiacenti, non abbiamo tempo".
• Dai la priorità ai bug come richiesto e ordina l'elenco dei biglietti in base a priorità e milestone.
• Se non hanno intenzione di raggiungere il traguardo, spostali in un traguardo futuro.
• Se un ticket dipende dal completamento di un altro ticket, contrassegnarlo come bloccato o organizzare i ticket in una gerarchia, quindi è ovvio che ticket-x e ticket-y sono correlati.
• Se un biglietto richiede un feedback da parte di qualcuno, assegnalo a quella persona.

Alla fine avrai sempre un sacco di biglietti a bassa priorità in circolazione, ma i punti sopra dovrebbero aiutarti a minimizzarlo.

Usiamo JIRA e abbiamo un ulteriore stato di risoluzione chiamato Suspended: se una caratteristica / bug è qualcosa a cui dobbiamo rinunciare per un po ', viene risolto come Sospeso. In questo modo non si confonde con l'elenco dei problemi attualmente attivi su cui dobbiamo attirare la nostra attenzione, né con l'elenco dei problemi risolti che sappiamo essere stati gestiti in modo satatico, ed è ancora 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 la possibilità di inserire una data di scadenza su ciascun "ticket". Se non è stato inoltrato, per esigenze di funzionalità o gravità dei bug, all'implementazione entro un certo periodo di tempo, probabilmente non era così importante in primo luogo. Ciò dovrebbe aiutare a mantenere automaticamente la pila tagliata. Ricevo spesso biglietti basati su "non sarebbe bello" o "questo non funziona perfettamente come voglio". Se nessun altro spinge abbastanza per questo, o quell'utente non ha abbastanza influenza, non viene fatto e chiudo il biglietto dopo un paio di mesi.