Qual è il flusso di lavoro dei bug nel tuo team agile / Scrum?

Qual è il flusso di lavoro dei bug nel tuo team agile / Scrum?

Ecco il nostro: - Se il bug è correlato a una storia nello sprint corrente, lo risolviamo. - Se il bug non è correlato a una storia nello sprint corrente e non è critico, viene inviato al proprietario del prodotto per l'assegnazione delle priorità. - Se il bug non è correlato a una storia nello sprint ed è fondamentale, lo risolviamo.

Tutto ciò che riguarda il lavoro nello sprint corrente è stato risolto, non li consideriamo nemmeno bug e non li scriviamo come tali. Consideriamo qualcosa un bug solo se fa parte di qualcosa che abbiamo già considerato Fatto.

Quando si presenta un nuovo bug, lo aggiungiamo al backlog e viene assegnato la priorità dai nostri stakeholder. Se abbiamo tempo rimanendo in uno sprint, tendiamo ad affrontare bug più facili che possono avere una priorità inferiore ma che possiamo completare nel tempo rimanente.

Ho sempre pensato che un bug sia solo una storia che ha già un test fallito, quindi è meglio definito rispetto alla tipica prima bozza di storie per funzionalità.

Quindi, se sei convinto che i bug siano storie, le tratti come faresti con altre storie in merito a stime e priorità.

Penso che il modo migliore per affrontarlo sia quello di determinare prima cosa vuoi veramente considerare un Bug.

Molti sviluppatori non considereranno qualcosa che non funziona come previsto su cui stanno attualmente lavorando come un bug, perché onestamente non è un bug. Se al momento stai lavorando a qualcosa e presenta ancora dei difetti, il bug specifico non è effettivamente completo, quindi non esiste un difetto reale. L'inverso si applica al lavoro completato, se hai stabilito che qualcosa è completo e pronto per il test / rilascio / produzione e in seguito trovi un difetto nel codice o nell'uso, allora hai sicuramente un bug.

La mia azienda utilizza la seguente metodologia per determinare quando un bug deve essere corretto:

Se il bug è critico, viene aggiunto allo sprint corrente relativo a quel prodotto, con la priorità appropriata. In genere prevediamo circa il 10% di tempo in più per consentire questo in uno sprint, oltre ad avere le cose extra che in realtà non prevediamo di completare, ma se non abbiamo bug o qualcosa è stato completato più velocemente di quanto ci aspettassimo, allora completare.

Se un bug non è critico, semplicemente lo aggiungiamo al backlog e normalmente lo completiamo nel prossimo sprint.

perché questo è il flusso ideale, c'è qualche ovvia perdita in esso, e talvolta le cose che non sono "critiche" dal punto di vista della programmazione potrebbero dover essere completate immediatamente se la direzione decide che deve essere completato prima di quanto pensiamo dovrebbe essere completato.

A parte questo, penso che la cosa migliore da fare sia scegliere una struttura e poi attenersi ad essa. Alcune delle maggiori perdite per la produttività iniziano a verificarsi quando inizi a fare cose senza struttura. Una volta che inizi a degradare la tua struttura, è molto facile andare in discesa.

Ciò potrebbe aver risposto eccessivamente alla tua domanda, ma quelli sono solo i miei pensieri su come queste cose dovrebbero essere gestite.

Facciamo un lavoro continuo sui difetti. Simile alla tua configurazione, se c'è un problema critico relativo al lavoro corrente, lo risolviamo come parte del lavoro. Dopotutto, non è possibile definire una storia "completata" se esiste un difetto ad essa correlato.

Per altri bug, generalmente li risolviamo quando il tempo lo consente. Se ci sono problemi urgenti, tiriamo indietro alcune storie e passiamo il tempo a correggere i bug prima di tornare al normale lavoro delle funzionalità.

I bug trovati durante lo Sprint sono solo una parte dello sviluppo.

I bug trovati dopo la fine dello Sprint vanno nel Product Backlog. Non discutiamo mai con gli utenti se qualcosa è un bug, un miglioramento o una modifica. Se l'utente vuole chiamarlo un bug, va bene, ma va ancora nel PB solo per qualsiasi altro nuovo lavoro.