Como lidar com defeitos/bugs

Há alguns dias recebi um e-mail com a seguinte dúvida:

Se fosse possível eu gostaria que você falasse um pouco de como funciona para vocês o tratamendo de incidentes em produção e defeitos. Como num ambiente ágil isso é tratado? Eles entram no backlog independente do projeto ou existe um tratamendo especial para fix/test/deploy? Alguma equipe específica faz o fix e corrige os testes unitários se for o caso?

Seria legal ter uma luz a respeito disso.

Como esse era um assunto que eu já estava para falar mesmo, aproveitei o gancho para fazer esse post.

Depois de conversar com muitas pessoas ao longo do tempo, o que eu percebí é que cada um trabalha de um jeito. Eu não acredito que exista uma forma certa ou errada de trabalhar, o que existem são formas diferentes que funcionam melhor ou pior em determinado lugar ou outro. Apesar disso, deve-se tomar cuidado para não criar alguma forma de trabalhar que viole os princípios básicos da metodologia/framework (Scrum no nosso caso). E por último, nem sempre conseguimos fazer dessa forma que vou falar, mas no geral é o que tentamos fazer.

Antes de tudo nós tentamos tratar cada tipo de defeito de acordo com sua gravidade. Para auxiliar, assim que um defeito chega para a equipe nós tentamos enquadrá-lo em uma das 3 categorias de defeitos, que para facilitar a explicação acabei de batizar de defeitos simples, importantes e gravíssimos.

Defeitos simples

São defeitos que têm pouco ou nenhum impacto para o usuário. Para citar um exemplo, nós tivemos recentemente um minúsculo defeito de alinhamento em um dos elementos da página do player do Globo Vídeos. Esse defeito não precisou ser visto imediatamente porque ele não impacta o uso do site e também quase não impacta visualmente, visto que o usuário está prestando muito mais atenção ao vídeo do que no resto.

Neste caso o Product Owner é notificado e a regra de priorização normalmente é “quanto antes corrigirmos isso, melhor”.

Defeitos importantes

São defeitos que não são tão simples como meros detalhes visuais mas que não impedem o produto de funcionar. Por exemplo, tivemos um caso que a Macromedia lançou uma nova major version de plugin do Flash e com isso descobrimos que a nossa verificação de versões tinha um problema. O resultado é que a exibição em tela cheia não funcionava corretamente em alguns casos, mas ainda assim o usuário conseguia ver o vídeo numa pop-up que simulava a tela cheia.

Neste caso temos duas opções. A primeira opção é colocar o defeito no backlog para que ele seja a primeira história a ser trabalhada no próximo Sprint. A segunda opção é como normalmente fazemos hoje em dia: o time sempre trabalha a 80~90% da sua capacidade para que quando esses incidentes aconteçam ele possa “puxar” ou assumir mais histórias – desde que todos se sintam confortáveis para isso. Caso não ocorra nenhum incidente durante o Sprint e sobre algum tempo no final, o time pega outra história qualquer que caiba no tempo que sobrou.

Defeitos gravíssimos

São defeitos que impedem o produto de funcionar. Usando mais uma vez o caso do Globo Vídeos, um defeito gravíssimo poderia ser algo que fizesse com que os vídeos parassem de ser exibidos, ou que alguma página estivesse indisponível, ou qualquer outra coisa que impeça os usuários de usarem o produto. Quando os defeitos desse tipo chegam para nós eles já passaram em 2 ou 3 níveis de suporte, então provavelmente trata-se de algum problema do software mesmo (e não de ambiente, de configuração do usuário, etc.) e precisa ser visto com a maior urgência possível.

Neste caso, o mais apropriado seria cancelar o Sprint imediatamente, planejar rapidamente, iniciar um novo Sprint com este item como o primeiro item a ser resolvido e fazer um release o mais rápido possível para corrigir o problema.

Para falar a verdade nunca tivemos esse terceiro caso depois que começamos a trabalhar de uma forma mais organizada com Scrum e cuidando cada vez mais da qualidade do que é entregue. Sendo bem realista, como trata-se de um defeito que coloca em risco a imagem/credibilidade/audiência/dinheiro da empresa, pode ser que seja mais apropriado parar tudo e dar atenção máxima ao problema sem seguir um script específico, afinal de contas o bom funcionamento da empresa deve estar sempre à frente de qualquer coisa. Se isso acontecesse, acho que eu daria o Sprint como cancelado, re-planejaria e começaria um novo Sprint.

Concluindo

Apesar de tudo isso eu pessoalmente sou favorável a corrigir todo e qualquer bug o mais rápido possível, independente de sua gravidade. Eu sou totalmente contra acumular débito técnico porque já sabemos como isso pode afetar a produtividade e velocidade do time a médio/longo prazo. Porém, como já havia dito, dadas as nossas condições e restrições essa foi a forma que melhor funcionou para a nossa realidade – e para ser franco acho que tem funcionado bem.

Tags: , , , , ,

8 Responses to “Como lidar com defeitos/bugs”

  1. Jeveaux says:

    Ótimo texto GC. A priorização da correção dos bugs é realmente um ponto importante e deve ser tratado com o devido cuidado, como é feito aí na webmedia.

    Sobre a sua conclusão, é aquela velha história das Broken Windows, deixe um único problema pra trás e brevemente os resultados serão catastróficos.

    Abraço!

  2. Guanch says:

    O que você quis dizer com 80% / 90% da capacidade? Algo como, numa equipe de 10 pessoas, pelo menos uma ou duas, estariam de “plantão” aguardando este tipo de evento ?

    César

  3. Wellidy Almeida says:

    Muito bom GC. Aqui na Lecom lidamos com a mesma situação e, como você disse, não há uma receita de bolo, mas as diversas formas são parecidas. E ainda hoje estava discutindo com um novo companheiro na equipe sobre um ponto que é fundamental neste tratamento de bugs: feedback.
    Se há um bug há uma ou mais pessoas, clientes, que estão sofrendo com os efeitos ruins e, em alguns momentos, estão com seu trabalho parado, no pior caso, o superior está cobrando. E não basta a equipe de desenvolvimento se concentrar na resolução sem informar ao cliente que está fazendo isso, que está ciente da gravidade, preocupada e comprometida em resolver o quanto antes. Sem dar feedback ao cliente o que ele vai pensar é que ninguém deu a mínima.
    Tenho visto, por experiência, que não importa que a solução demore. O que vai ficar de lembrança é a falha de comunicação.
    Como resolver isso, cara, se o cliente não está ao seu lado, liga pra ele, rápido e efetivo.

  4. Oi Guanch, realmente não ficou muito claro :)

    O que nós tentamos fazer é trabalhar a 90% da capacidade mas sem essa história de ficar alguém de plantão ou ocioso.

    Por exemplo, se o time achava que num determinado Sprint caberiam “n” histórias que totalizam 100 pontos de complexidade, tentamos tirar uma ou duas histórias totalizando algo próximo de 10% do total de pontos para criar essa folga.

    Essas histórias vão para o topo do backlog e, como eu disse, muitas vezes acabam sendo feitas porque não temos incidentes.

    [ ]s, gc

  5. [...] Guilherme Chapiewski Blog sobre desenvolvimento de software e tecnologia « Como lidar com defeitos/bugs [...]

  6. [...] com a série de posts-resposta, vou aproveitar mais um e-mail que recebi para falar de um assunto que é campeão em dúvidas e [...]

  7. [...] ter uma luz a respeito disso. Como esse era um assunto que eu já estava p Veja o post completo clicando aqui. Post indexado de: [...]

Leave a Reply