Qual é o fluxo de trabalho de bugs na sua equipe ágil / Scrum?

Qual é o fluxo de trabalho de bugs na sua equipe ágil / Scrum?

Aqui está o nosso: - Se o bug estiver relacionado a uma história no sprint atual, nós o corrigimos. - Se o bug não estiver relacionado a uma história no sprint atual e não for crítico, ele será enviado ao proprietário do produto para priorização. - Se o bug não estiver relacionado a uma história no sprint e for crítico, nós o corrigimos.

Qualquer coisa relacionada ao trabalho no sprint atual é corrigida, nós nem os consideramos bugs e não os escrevemos como tal. Só consideramos algo um bug se fizer parte de algo que já consideramos Concluído.

Quando um novo bug surge, nós o adicionamos ao backlog e ele é priorizado por nossas partes interessadas. Se tivermos tempo restante em um sprint, tendemos a lidar com bugs mais fáceis que podem ter prioridade mais baixa, mas são algo que podemos concluir no tempo restante.

Eu sempre pensei que um bug é apenas uma história que já tem um teste com falha, portanto é melhor definida do que o primeiro rascunho típico de história para recursos.

Portanto, se você está convencido de que bugs são histórias, trate-os como trataria outras histórias em relação a estimativas e prioridades.

Eu acho que a melhor maneira de abordar isso é determinar primeiro o que você realmente deseja considerar um bug.

Muitos desenvolvedores não consideram algo que não está funcionando como planejado, mas atualmente não é um bug, porque honestamente não é um bug. Se você está trabalhando em algo e ainda possui defeitos, o bug específico não está completo e, portanto, não existe um defeito real. O inverso se aplica ao trabalho concluído, se você determinou que algo está completo e pronto para teste / liberação / produção e, posteriormente, encontra um defeito no código ou no uso, você definitivamente tem um bug.

Minha empresa usa a seguinte metodologia para determinar quando um bug deve ser corrigido:

Se o bug for crítico, ele será adicionado ao sprint atual relacionado a esse produto, na prioridade apropriada. Normalmente, planejamos aproximadamente 10% de tempo extra para permitir isso em um sprint, além de ter as coisas extras que realmente não planejamos concluir, mas se não tivermos bugs ou se algo foi concluído mais rápido do que esperávamos, podemos completo.

Se um bug não for crítico, basta adicioná-lo ao backlog e normalmente o concluímos no próximo sprint.

Por que esse é o fluxo ideal, existe algum vazamento óbvio e, às vezes, coisas que não são "críticas" da perspectiva da programação podem precisar ser concluídas imediatamente se o gerenciamento decidir que precisa ser concluído mais cedo do que pensamos que deveria ser concluída.

Em um lado, acho que a melhor coisa a fazer é escolher uma estrutura e depois ficar com ela. Algumas das maiores perdas de produtividade começam a ocorrer quando você começa a fazer coisas sem estrutura. Uma vez que você começa a degradar sua estrutura, é muito fácil descer tudo em declive.

Isso pode ter respondido demais à sua pergunta, mas esses são apenas meus pensamentos sobre como essas coisas devem ser tratadas.

Trabalhamos com defeitos em andamento. Semelhante à sua configuração, se houver um problema crítico relacionado ao trabalho atual, nós o corrigimos como parte do trabalho. Afinal, não é possível chamar uma história de "concluída" se houver um defeito relacionado a ela.

Para outros erros, geralmente os corrigimos conforme o tempo permite. Se houver problemas urgentes, recuamos algumas histórias e gastamos tempo em correções de bugs antes de voltar ao trabalho normal de recursos.

Os erros encontrados durante o Sprint são apenas parte do desenvolvimento.

Os erros encontrados após o final do Sprint entram no Backlog do Produto. Nunca discutimos com os usuários se algo é um bug, um aprimoramento ou uma alteração. Se o usuário quiser chamá-lo de bug, tudo bem, mas ele ainda entra no PB, como qualquer outro trabalho novo.