BT

Lidar com Bugs em um Projeto Ágil/Scrum

por Mark Levison , traduzido por Fernanda Stringassi de Oliveira em 22 Jul 2009 |

BugsUma 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?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

Bugs... by Rodrigo Cabral

Com relação a citação do Manifesto ela é clara, porem cabe a equipe e ao PO definir o que lhes é "pronto", e só desta forma avaliar o nível do bug, pois apesar de ser um erro e necessitar de reparo, possivelmente se ele passou pelo sprint ele não afetou a regra de negócio, ou que o torna passível de reparo posterior.
Aqui nós criamos novas tarefas no backlog para tratar destes bugs que não afetam as regras de negócio.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

1 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT