BT
x A sua opinião é importante! Por favor preencha a pesquisa do InfoQ sobre os seus hábitos de leitura!

Jogar Fora Seus Sistemas de Bug Tracking?

por Mike Bria , traduzido por Vinicius Assef em 31 Mar 2009 |

Elisabeth Hendrickson, também conhecida como "testObsessed", apresenta uma postura provocativa sobre a priorização de bugs em um projeto ágil. Ela discorre sobre sua impressão de que os problemas encontrados durante a iteração não são "bugs", que somente o Product Owner teria autoridade para considerar algo como "bug" e que uma equipe Ágil saudável não teria a necessidade de um sistema de bug tracking.

Hendrickson inicia sua discussão com uma definição do que realmente é um "bug":

Num contexto ágil, eu defino um bug como sendo um comportamento em uma estória "Pronta" que viola as expectativas válidas do Product Owner.

Depois de esclarecer como ela define o "Product Owner" e de discutir seu entendimento sobre o que são as "expectativas", Hendrickson apresenta sua opinião sobre as coisas encontradas no software antes de estar "PRONTO" que não satisfazem essas "expectativas do Product Owner". Ela explica que isso não deveria ser apontado como "bug", ainda mais porque a única coisa que alguém precisa fazer é consertar o problema imediatamente:

Se encontrarmos alguma coisa que não satisfaz as expectativas do Product Owner antes de dizermos que uma estória está "Pronta", nós a consertamos. Nós não questionamos sobre o problema, não discutimos ou priorizamos, simplesmente consertamos. Isso é o que significa ter tolerância zero com os bugs.
...
E já que as consertamos sempre que as encontramos, nós não precisamos de um nome para isso. Nós não precisamos priorizá-las. Nem precisamos controlá-las num sistema de bug tracking. Nós simplesmente cuidamos delas no mesmo instante.

Dito isto, Hendrickson explica o que ela acha que realmente são "bugs" e o que fazer com eles:

Depois que uma estória está Pronta e Aceita, devemos aprender sobre as circunstâncias que fazem com que ela não sobreviva às expectativas do Product Owner. É aí que temos um bug.

Se fizermos as coisas certas, essas situações não deveriam acontecer com frequência. Priorizar e acompanhar os bugs num banco de dados elaborado não faz muito sentido se o que temos for algo da ordem de 5 problemas abertos em determinado momento. O Product Owner vai priorizar o acerto dos problemas em relação a outros itens do product backlog e a equipe vai continuar andando.

E se não estivermos fazendo a coisa certa, vamos descobrir uma enorme quantidade de pequenas coisas escapando ao controle. É quando sabemos que temos um problema de verdade em nosso processo. Ao invés de gastar todo o tempo tentando gerenciar todos os bugs, precisamos dar um passo atrás e tentar descobrir o que está causando a infestação. Parar os bugs na origem ao invés de tentar juntar e gerenciar todos eles.

No mesmo artigo, Hendrickson dá uma dica sobre o que fazer com as coisas que alguém pensa estarem erradas no software, mas o Product Owner diz que "não são um problema".  Ela diz para não registrar isso:

Muitas das equipes tradicionais que trabalhei (antes de começar a trabalhar com equipes Ágeis) tinham um banco de dados de bugs transbordando de coisas que nunca seriam consertadas. Normalmente eram coisas relatadas por pessoas da equipe, geralmente testadores e classificadas como "enfeite" ou "baixa prioridade".

Essa coleção de problemas de baixa prioridade nunca adiciona valor: nós nunca fizemos nada com essa informação. E ainda assim guardávamos esses dados indefinidamente com a crença errônea de que era valioso acompanhar tudo que alguém relatava, mesmo que fosse um detalhezinho que a empresa simplesmente não se preocupava.

O banco de dados tornou-se mais como uma base de segurança do que um recurso do projeto. Nós gastávamos horas e horas em reuniões discutindo os problemas, fazendo listas do que seria corrigido e trocando os ajustes de prioridade e de severidade, só para ter toda essa decisão desfeita quando o próximo bug real em uma funcionalidade crítica aparecia. Se isso lhe soa familiar, é hora de admitir que esse tipo de informação não está ajudando a fazer o projeto ir em frente. Então, pare de coletá-la. Ela está atrapalhando mais do que ajudando.

Em resumo, Hendrickson nos desafia a sermos mais restritos com o que nos permitimos chamar de "bug". Mais especificamente, ela sugere reduzirmos drasticamente as coisas que registramos como "para consertar depois"; até o ponto de que usar qualquer tipo de sistema de bug tracking seja um exagero. E, finalmente, ela nos encoraja a reconhecer que quando acharmos que precisamos de um sistema desse tipo por causa da quantidade de bugs, é melhor reexaminarmos e melhorarmos o processo de desenvolvimento do que usarmos um sistema de bug tracking.

Pode ser radical para alguns. Independente disso, leia o artigo dela na íntegra (já que citamos somente uma pequena parte aqui), pense seriamente sobre a mensagem, e junte-se à nossa discussão com seus pensamentos e experiências.

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

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

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