BT
x Por favor preencha a pesquisa do InfoQ !

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?

Avalie esse artigo

Relevância
Estilo/Redação

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
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

Percebemos que você está utilizando um bloqueador de propagandas

Nós entendemos porquê utilizar um bloqueador de propagandas. No entanto, nós precisamos da sua ajuda para manter o InfoQ gratuito. O InfoQ não compartilhará seus dados com nenhum terceiro sem que você autorize. Procuramos trabalhar com anúncios de empresas e produtos que sejam relevantes para nossos leitores. Por favor, considere adicionar o InfoQ como uma exceção no seu bloqueador de propagandas.