Come gestire il backlog del tracker di un problema

In primo luogo, fai in modo che ogni sviluppatore guardi ciascuno degli articoli e riveda / test ogni voce per vedere se è ancora un problema (potrebbe funzionare meglio dividerli tra le persone). Quindi, chiudi quelli che non sono 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 appena utilizzata per classificare più facilmente i progetti e per aiutare a riunire le cose. Se tutto è già stimato, sarà d'aiuto, ma non rimanere impigliato nelle ore. Basta andare con un rapido controllo dell'intestino. Funziona spesso per ottenere gli sviluppatori in una stanza e basta esaminare ciascun elemento e utilizzare lo sforzo che la maggior parte delle persone ritiene sia appropriato.

Esamina ciascuno dei tre gruppi di sforzo e contrassegna ciascun elemento nel gruppo con una priorità di Valore critico, Alto valore commerciale, Valore tecnico elevato, Valore medio, Valore basso e Nessuna soluzione da correggere.

A questo punto, conosci davvero la lista e comprendi davvero il lavoro che è coinvolto nel tuo backlog e puoi iniziare a prendere davvero una decisione su cosa fare con gli oggetti. Prendi tutti gli elementi contrassegnati come non li sistemerai mai e li archivierai dal tuo arretrato.

Ora, quando pianifichi gli elementi da inserire nella prossima versione, puoi utilizzare gli elementi critici e di alta importanza come nucleo del tuo rilascio. Controlla l'elenco degli elementi a media e bassa priorità e aggiungi quelli che possono essere elaborati 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 cose su cui le persone possono lavorare quando hanno un po 'di tempo libero o come formazione per i nuovi dipendenti. Trovo sempre che sia bello avere una persona nel team durante ogni iterazione che lavora su questi elementi e aiutare il resto del team dove necessario. In questo modo, stai ancora completando il lavoro sull'attuale iterazione ma hai qualcuno che è flessibile e può aiutarti a spegnere gli incendi quando necessario, ma sta gestendo i problemi che normalmente non riceverebbero attenzione.

Una cosa che abbiamo trovato interessante è che, tra ogni iterazione, abbiamo avuto un breve periodo di 2 settimane in cui l'intero team lavorava solo su elementi contrassegnati da un piccolo sforzo di sviluppo. Concentreremo la chiusura di un numero elevato di biglietti in breve tempo.

Trac ha un'impostazione di priorità? Qualcosa come 1 per i principali show-stop e circa 5 per cose che sarebbe bello aver fatto prima o poi?

Se puoi ordinare in base alla priorità, per ora puoi ignorare la priorità più bassa.

leggi: link

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

Seriamente se non hai intenzione di sistemarlo, dimenticalo. Vedi Programmazione estrema.

Ma Per gli articoli sul codice. Potresti metterli in un sistema di revisione del codice, come osservazioni minori. Questo sistema può essere impostato per segnalare problemi quando quella parte del sistema è stata modificata. Ho scoperto che questo non funzionava come collaboratore, pensavo che questo fosse quello che ci si aspettava e non ha preso in considerazione le osservazioni sulla recensione.

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

Questa non è in realtà una questione di controllo della versione tanto quanto una questione di flusso di lavoro e priorità aziendale. Tenere traccia delle cose che si sa essere sbagliate è una buona idea, anche se è improbabile che il "sempre" venga risolto abbia alcuni vantaggi. Per prima cosa, significa che il QA (se hai un team di QA separato) sa di non registrare un nuovo bug per questo. Un altro vantaggio è che se si verifica un nuovo problema, ma la causa principale è dovuta a uno di questi problemi "noi sappiamo a questo proposito ma a bassa priorità", qualsiasi analisi sulla correzione è già tracciata - il che può rendere il più recente, più elevato la versione prioritaria del bug è molto più semplice da risolvere.

Un altro aspetto di questo è che potrebbe esserci un margine di manovra per affrontare parte di questo lavoro, ora o in futuro. Forse un giorno riceverai un tirocinante e potrai assegnarne alcuni di quelli 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 il codice base più facile da gestire per risolverli, ma non hanno alcun valore per il business - potrebbe essere vale la pena di discuterne con gli stakeholder aziendali e vedere se è possibile raggiungere un accordo nel caso in cui tali elementi arretrati vengano recuperati occasionalmente. Ho visto gruppi di scrum fare cose come bloccare 3-5 punti di velocity per sprint per gli item di "technical backlog" - questo può richiedere qualche rifinitura politica a seconda della relazione del team di sviluppo con gli stakeholder del business, ma ho visto funziona molto bene.

Questo dipende davvero da alcune cose.

1. Quanto è grande il team: se il team è abbastanza grande, puoi assegnare i ticket in un modo che consenta di completare gli elementi con priorità più bassa.
2. Quanto spesso fai rilasci: se il ciclo di rilascio è abbastanza lungo puoi farla franca con l'aggiunta di altre cose o aspettare un rilascio fino a quando non avrai risolto tutti i ticket.