Qual è il flusso di lavoro del bug sul tuo team agile / Scrum?

Qualsiasi cosa relativa al lavoro nello sprint corrente è corretta, non li consideriamo nemmeno bug e non li scriviamo come tali. Consideriamo solo un bug se fa parte di qualcosa che abbiamo già considerato Fatto.

Quando si verifica un nuovo bug, lo aggiungiamo al backlog e riceviamo la priorità dai nostri stakeholder. Se abbiamo tempo a disposizione per 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 fosse solo una storia che ha già fallito un test, quindi è meglio definita rispetto alla tipica prima stesura di storie per feature.

Quindi, se sei convinto che i bug sono storie, trattali come faresti con altre storie riguardo a stime e priorità.

Penso che il modo migliore per avvicinarsi a questo è determinare per primo cosa vuoi considerare un Bug.

Molti sviluppatori non prenderanno in considerazione qualcosa che non funziona come previsto a cui stanno lavorando attualmente come un bug, perché non è onestamente un bug. Se stai lavorando su qualcosa e ha ancora dei difetti, allora il bug specifico non è completo, quindi non c'è un difetto reale. L'inverso si applica al lavoro completato, se hai determinato che qualcosa è completo e pronto per il test / rilascio / produzione e successivamente trovi un difetto nel codice o usi allora hai sicuramente un bug.

La mia azienda utilizza la seguente metodologia per determinare quando correggere un errore:

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

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

perché questo è il flusso ideale ci sono delle evidenti perdite e, a volte, le cose che non sono "critiche" da una prospettiva di programmazione possono aver bisogno di essere completate immediatamente se la direzione decide che deve essere completata prima di quanto pensiamo dovrebbe essere completato.

In un secondo penso che la cosa migliore da fare sia scegliere una struttura e poi seguirla. Alcune delle maggiori perdite di produttività iniziano quando si inizia a fare cose senza struttura. Una volta che inizi a degradare la tua struttura, è molto facile che tutto vada in discesa.

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

Facciamo lavori di difetti in corso. Analogamente alla configurazione, se esiste un problema critico relativo al lavoro corrente, lo risolviamo come parte del lavoro. Dopo tutto, non è possibile chiamare una storia "fatta" se c'è 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 risolvere i bug prima di tornare alle normali funzioni.

Gli errori trovati durante lo Sprint sono solo una parte dello sviluppo.

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