Uma pergunta freqüentemente questionada é como Scrum recomenda que a equipe trate os bugs? Eles devem ser colocados no product backlog? Ou em uma lista de bugs separada? Se eles estão no backlog, o Product Owner deve definir as prioridades ou eles são automaticamente os itens mais importantes? Deve existir um sprint em separado para a correção de bugs?
Na equipe do Pascal Maugeri’s, mesmo depois de melhorar a definição de pronto e fazerem “ testes/testes unitários de forma apropriada ", eles ainda encontram bug que escapam do sprint. Ele questiona como resolver este problema.
George Dinwiddie , Agile Coach, sugere levantar a questão com a equipe durante a retrospectiva – ele tem trabalhado com equipes que têm taxas de bug bem baixas. Mark Levison (o próprio autor deste artigo) sugeriu “Eu começaria a perguntar: Por que os bugs não foram encontrados e corrigidos no sprint onde eles ocorreram? Meu foco é reduzir o tempo necessário para descobrir (e então corrigir) problemas. Depois de tudo, se nós descobrirmos bugs na história durante o sprint em que ele foi especificado, então o PO não deveria aceitar a história como pronta. Além disso, descobertas precoces farão com que seja muito mais fácil corrigir já que o código ainda está fresco na mente da equipe de desenvolvimento. ”
Jim Schiel, CST com Artisan Consulting, coloca os bugs no product backlog para serem priorizados pelo Product Owner - “ao menos que seja um bug muito simples, você define a solução durante a reunião de planejamento do sprint e executa a solução durante o Sprint.”
Bruce Kantelis diz que tudo isso está relacionado com o desenvolvimento da cultura de trabalho: Nós categorizamos os bugs. Prioridade 1, que bloqueiam o usuário de trabalhar têm atenção imediata, e o trabalho é interrompido para uma correção ou reparo, já todos os outros se tornam histórias que são colocadas no topo da lista para o próximo sprint. Ao longo do tempo, as equipes percebem que atitudes e medidas de qualidade realmente impactam o trabalho do dia-a-dia e as interrupções são minimizadas. ”
Mike Cohn nos lembra que bugs encontrados dentro do sprint são melhor tratados gritando-os para toda a equipe na sala e descrevendo o bug. Se isto não der certo, um cartão descrevendo o bug pode ser incluído no quadro de tarefas. Embora existam bugs que escapam do sprint – ele prefere adicioná-los no product backlog, deixando que o product owner os priorize. Muitas equipes ainda têm uma base de dados de bugs que precisam continuar usando. Neste caso, ele aconselha manter um backlog de bugs em separado, onde o product owner simplesmente diz quais são as prioridades dele para cada fila: por exemplo, os primeiros dois itens do product backlog, e então os seguintes bugs e finalmente os próximos dois itens do backlog.
Kevlin Henney argumenta que esta abordagem é semelhante ao tratamento do bug o como uma funcionalidade com valor negativo:
Se bugs são vistos como funcionalidades com valor negativo, eles acabam sendo gerenciados como se fossem funcionalidades. Grupos de desenvolvimento armazenam repositórios de bugs priorizados, tratam bugs como histórias, terceirizam a correção dos bugs, e assim por diante. Embora possam ser técnicas úteis ou perspectivas em lidar com projetos em fase de transição ou crise, não é uma visão a longo prazo que deva ser encorajada. Além disso, tudo como o "Manifesto para Desenvolvimento Ágil de Software" diz, "Software funcionando é a primeira medida do progresso". É um pouco desonesto passar adiante como completa e funcionando uma funcionalidade com bugs conhecidos — "Sim, está pronto... mas tem alguns pequenos bugs."
Ron Jeffries transforma todo o problema dizendo que corrigir um bug em uma funcionalidade depois dela estar terminada é sempre mais caro do que fazer certo na primeira vez.
Então quando nós desenvolvemos o software incorretamente e então o corrigimos, o cliente paga mais: ele paga o que ele pagaria antes, mais a pena de ter corrigido um bug.
O cliente deve ser realmente alertado sobre isso. Eu gosto de encorajar o cliente a priorizar todos os bugs, para garantir que ele sentirá o sofrimento de um processo de software inadequado. Eu estou certo de que ele expressará todo este sofrimento e que a equipe terá melhor chance de ter alguma idéia de que fazer bem feito é o melhor.
Você evita bugs em geral? Coloca eles no Product Backlog? Você vê os problemas que Kevlin falou?