Come gestire il backlog di un tracker di problemi

Usiamo diligentemente Trac da diversi anni e la nostra lista di "biglietti attivi" è cresciuta fino a raggiungere quasi 200 articoli. Questi includono bug che hanno una priorità troppo bassa e per il momento troppo complicati da risolvere, richieste di funzionalità che sono state rinviate, problemi che non hanno mai realmente generato lamentele ma che tutti un giorno dovrebbero essere risolti, rifatturazioni del codice pianificate e altre infelicità di progettazione che non doniamo " voglio perdere la traccia di, ecc.

Di conseguenza, con quasi 200 di questi problemi, l'elenco è quasi schiacciante; non è più utile come fonte di ciò su cui bisogna lavorare adesso.

Qual è il modo migliore per tenere traccia di problemi di questo tipo?

Parte del problema è che alcuni di questi problemi hanno una priorità così bassa che potrebbero non essere mai risolti. Odio perdere traccia di questi oggetti (simile a non voler buttare via qualcosa da casa mia in caso potessi averne bisogno un giorno); devo buttarli fuori a prescindere (contrassegnandoli come wontfix) e supporre che posso trovarli in futuro se mai ne avessi bisogno?

Innanzitutto, chiedi a ciascuno sviluppatore di esaminare ciascuno degli elementi e di rivedere / testare ogni elemento per vedere se è ancora un problema (potrebbe funzionare meglio per dividerli tra le persone). Quindi, chiudere quelli che non rappresentano più un problema o che sono già stati risolti con altri sforzi di sviluppo.

Ora assicurati che ognuno sia contrassegnato come uno sforzo di sviluppo grande, medio o piccolo. Questa è una stima molto approssimativa usata solo per classificare più facilmente i progetti e per aiutare a mettere insieme le cose. Se tutto è già stimato, sarà di aiuto, ma non rimanere impiccato nelle ore. Basta andare con un rapido controllo dell'intestino. Spesso funziona per mettere gli sviluppatori in una stanza e semplicemente esaminare ogni elemento e utilizzare lo sforzo che la maggior parte delle persone ritiene appropriato.

Esaminare ciascuno dei tre gruppi di sforzo e contrassegnare ciascun elemento nel gruppo con una priorità di Critico, Alto valore aziendale, Alto valore tecnico, Medio valore, Basso valore e Mai risolto.

A questo punto, conosci davvero la lista alla rovescia e capisci davvero il lavoro che è coinvolto nel tuo backlog e puoi iniziare a prendere davvero una decisione su cosa fare con gli articoli. Prendi tutti gli elementi contrassegnati come non risolvibili e archiviali dal tuo backlog.

Ora, quando pianifichi che gli elementi entreranno nella tua prossima versione, puoi utilizzare gli elementi critici e di grande importanza come nucleo della tua versione. Esamina l'elenco di elementi a media e bassa priorità e aggiungi quelli su cui è possibile lavorare contemporaneamente agli altri elementi nell'elenco perché gli sviluppatori lavoreranno già in quella parte del sistema.

L'elenco di elementi contrassegnati con priorità media o bassa può essere utilizzato come elenco di elementi su cui le persone possono lavorare quando hanno un po 'di tempo libero o come formazione per i nuovi dipendenti. Trovo sempre piacevole avere una persona nella squadra durante ogni iterazione che lavora su questi elementi e aiuta il resto della squadra, se necessario. In questo modo, stai ancora completando il lavoro sull'iterazione corrente ma hai qualcuno che è flessibile e può aiutare a spegnere gli incendi quando necessario ma sta gestendo i problemi che normalmente non attirerebbero l'attenzione.

Una cosa che abbiamo scoperto è stata piacevole: tra una ripetizione e l'altra, abbiamo trascorso un breve periodo di 2 settimane in cui l'intero team avrebbe lavorato solo su elementi contrassegnati con un piccolo sforzo di sviluppo. Ci concentreremo sulla chiusura di un gran numero di biglietti in breve tempo.

Trac ha un'impostazione di priorità? Qualcosa come 1 per i maggiori show-stopper e 5 o giù di lì per cose che sarebbe bello aver fatto prima o poi?

Se è possibile ordinare in base alla priorità, è possibile ignorare i contenuti con priorità inferiore per ora.

leggi: http://en.wikipedia.org/wiki/5S_%28methodology%29

Mettili in soffitta, aspetta un anno, poi cambia casa. Questo è quello che faccio.

Seriamente se non hai intenzione di ripararlo, allora dimenticalo. Vedi la programmazione estrema.

Ma per articoli sul codice. Potresti metterli in un sistema di revisione del codice, come osservazioni minori. Questo sistema può essere impostato per segnalare problemi quando viene modificata quella parte del sistema. Ho scoperto che questo non ha funzionato come collaboratori, ho pensato che fosse quello che ci si aspettava e non ho risposto alle osservazioni di revisione.

L'unico modo per farlo è la spietata definizione delle priorità. Fallo ora o non preoccuparti.

Questa non è in realtà una domanda di controllo della versione, ma una questione di flusso di lavoro e priorità aziendale. Tracciare cose che sono note per essere sbagliate è una buona idea anche se è improbabile che vengano "riparate" mai, ha alcuni vantaggi. Per prima cosa, significa che il QA (se hai un team di QA separato) sa di non registrare un nuovo bug per esso. Un altro vantaggio è che se si presenta un nuovo problema, ma la sua causa principale è dovuta a uno di questi problemi "lo sappiamo ma è a bassa priorità", qualsiasi analisi sulla correzione è già tracciata, il che può rendere il più nuovo, più alto- versione prioritaria del bug molto più facile da correggere.

Un altro aspetto di questo è che potrebbe esserci un margine di manovra per affrontare alcuni di questi lavori, ora o in futuro. Forse un giorno avrai un tirocinante e puoi assegnargli alcuni dei più semplici come introduzione per bagnare i piedi nella base di codice.

Se gli sviluppatori ritengono che questi problemi possano essere risolti, ad esempio se rappresentano un debito tecnico e renderebbe più semplice lavorare con la base di codice per risolverli, ma non hanno alcun valore aziendale, potrebbe valere la pena discuterne. con gli stakeholder aziendali e vedere se è possibile raggiungere un accordo in cui tali articoli arretrati vengono raccolti occasionalmente. Ho visto che i team di scrum fanno cose come bloccare 3-5 punti di velocità per sprint per elementi di "arretrato tecnico" - questo può richiedere un po 'di fine politico a seconda della relazione del team di sviluppo con gli stakeholder aziendali, ma ho visto funziona molto bene.

Questo dipende davvero da alcune cose.

1. Quanto è grande la squadra: se la squadra è abbastanza grande puoi assegnare i biglietti in un modo che consenta di completare gli articoli con priorità inferiore.
2. Con che frequenza rilasci: se il ciclo di rilascio è abbastanza lungo, puoi evitare di aggiungere altre cose o tenere premuto un rilascio fino a quando non hai risolto tutti i ticket.