Quantos bugs abertos você tem no backlog? 100? 1000?
E quanto tempo eles estão lá? Uma semana? Um mês? Anos?
E por que isso acontece? Falta de tempo? É preciso priorizar tarefas mais importantes? "Agora vamos implementar todas as funcionalidades urgentes e depois, com certeza, teremos tempo para resolver os bugs"?

… Alguns usam a Zero Bug Policy, outros têm uma cultura bem desenvolvida para lidar com bugs (atualizam o backlog em tempo hábil, reavaliam erros ao alterar funcionalidades, etc.), e há aqueles que formam mágicos que programam sem bugs (pouco provável, mas, talvez, isso aconteça).

Hoje vou falar sobre a nossa solução para limpar o backlog de bugs — o projeto "Bugeria".

Como tudo começou?

Após revisitar o backlog de bugs abertos que só aumentava, chegamos ao ponto de ebulição. Não podíamos continuar assim, decidimos reduzi-lo a qualquer custo. A ideia era óbvia, mas como fazê-lo? Concluímos que a maneira mais eficaz seria um evento semelhante a um hackathon: separar as equipes das tarefas do dia a dia e dedicar um dia de trabalho apenas para tratar dos bugs.

Elaboramos um regulamento, fizemos um chamado e começamos a esperar. Havia receios de que a participação seria baixa, mas o resultado superou nossas expectativas — 8 equipes se inscreveram (apesar de que, no último minuto, 3 desistiram). O evento foi agendado para um dia inteiro na sexta-feira, e reservamos uma grande sala de reunião. Os almoços foram organizados na cantina do escritório, e para os lanches adicionamos biscoitos.

Implementação

Na manhã do Dia H, reunimos todos os interessados na sala de reunião e realizamos uma breve apresentação.

Regras principais:

• em uma equipe competem de 2 a 5 pessoas, sendo pelo menos uma delas um QA;
• os bugs devem ser corrigidos por um membro da equipe de acordo com todos os padrões de produção internos;
• cada equipe deve ter pelo menos um bug fechado que requeira correções no código;
• somente bugs antigos podem ser corrigidos (data de criação do bug < data de início da Bugeria — 1 mês);
• pontos (de 3 a 10) são atribuídos por bugs corrigidos, dependendo da criticidade (para evitar trapaças, não é permitido alterar a criticidade após o anúncio da data da Bugeria);
• por fechar bugs não relevantes ou não reproduzíveis, é atribuído 1 ponto;
• um time de auditoria supervisiona o cumprimento de todas as regras, que anula pontos por bugs reabertos.

Inicialmente, queríamos fazer um evento "avançado" sobre testes, mas como muitos da equipe não produtiva (SMM, advogados, PR) se inscreveram, tivemos que simplificar bastante o conteúdo e remover casos mais complicados/profissionais.

• Não limitamos ninguém na escolha do local: era possível ficar no trabalho ou sentar-se com todos na sala de reuniões, onde os colegas não eram distraídos e sentia-se a intensidade das emoções.

• Para manter o espírito competitivo, uma tabela de classificação foi exibida na grande tela, enquanto um canal no Slack transmitia constantemente o andamento da disputa. Utilizamos um leaderboard para contar os pontos, que era atualizado via webhooks.

Leaderboard

• A equipe de auditoria cuidou para que todas as regras fossem seguidas (com a experiência, 1 a 2 pessoas são suficientes para isso).
• Uma hora após o término do Bugathon, os resultados revisados foram anunciados.
  Os vencedores receberam um vale-presente para um bar, e todos os participantes ganharam um souvenir (chaveiros com 'bugs').

Resultados

Nos últimos seis meses, realizamos três Bugathons. O que conseguimos, afinal?

• Número médio de equipes - 5.
• Número médio de bugs processados - 103.
• Número médio de bugs não atuais/inreproduzíveis - 57% (e este lixo sempre estava à vista e assustava pela sua quantidade).

Momento do anúncio dos resultados

E agora a resposta à pergunta mais complicada que todos adoram fazer: 'Quantos novos bugs você pegou?'.
Resposta: não mais que 2% de todos os processados.

Comentários

Após a realização dos Bugathons, coletamos feedback dos participantes. Aqui estão as respostas à pergunta 'O que você mais gostou no processo de participação?':

• É muito legal revisar o backlog com essa motivação! Normalmente, esse é um processo muito maçante, precisamos fazer isso periodicamente).
• O entusiasmo, os biscoitos.
• É uma oportunidade tão esperada de corrigir aqueles pequenos detalhes que não são críticos, mas que queremos corrigir.
• Gostei de que foi finalmente possível corrigir bugs antigos e incômodos fora do sprint, pois nunca há tempo para isso, já que sempre haverá tarefas de maior prioridade. Conseguimos reunir em um só lugar todas as pessoas necessárias (na nossa equipe havia um DBA, por exemplo), discutimos coletivamente a relevância dos bugs apresentados e a viabilidade técnica de corrigi-los.

Conclusão

O Bugathon não é uma panaceia, mas é uma opção viável para reduzir o backlog de bugs (em diferentes equipes de 10 a 50%) em apenas um dia. Este evento decolou somente graças a equipes motivadas que se preocupam com o produto e com a satisfação de nossos usuários.

Desejo a todos um ótimo dia e menos bugs!

Fonte: habr.com