Corrigir bugs de forma rápida e fácil
Corrigir bugs já era um desafio no desenvolvimento de software antes do Scrum. As iterações curtas no Agile não facilitam necessariamente a decisão das equipes sobre quais bugs precisam ser corrigidos e quais ainda podem esperar.
A boa notícia é que um Scrum Team normalmente tem muito menos bugs do que uma equipe que trabalha com frameworks de desenvolvimento mais tradicionais. Mas mesmo equipes ágeis encontram um ou outro bug aqui e ali, especialmente quando parte do desenvolvimento vem de uma época anterior à transição da equipe para uma abordagem ágil. E para priorizar esses defeitos, a equipe precisa de uma solução eficaz.
Priorização de Bug Fixes: O que não se deve fazer
No início da minha carreira como programador, meu chefe liberou toda a equipe por uma semana para falar sobre todos os defeitos conhecidos. Conversamos sobre possíveis causas, sobre a gravidade de cada bug, com que frequência ocorria, se podia ser reproduzido, onde no código o erro poderia estar e quem de nós deveria resolver o problema.
Até estimamos quanto tempo levaria para cada bug. Essas estimativas não só eram bastante inúteis na maioria dos casos, como geralmente demorava mais para fazer a estimativa do que simplesmente corrigir o bug.
Quando comecei a liderar equipes após essas experiências iniciais, passei a experimentar outras abordagens mais leves.
Hoje quero apresentar meu método favorito para corrigir bugs.
Diretrizes para a Priorização de Bugs
Em vez de gastar tempo pensando em cada bug individualmente, é melhor criar diretrizes que definam a rapidez com que um bug deve ser corrigido ou qual é a gravidade do defeito, ou seja, o problema quando o bug ocorre.
Exemplo 1: Uma dessas diretrizes poderia ser que qualquer bug que afete drasticamente todos os usuários deve ser corrigido imediatamente, ou seja, o trabalho em andamento no Sprint é interrompido. Outra diretriz poderia estabelecer, por exemplo, que bugs que ocorrem muito raramente e não impedem o usuário de executar as funções mais importantes são anotados e corrigidos sem pressão, assim que houver tempo disponível.
Criar e usar diretrizes também é chamado de priorização por políticas (prioritization by policy).
Exemplo 2: Um exemplo mais concreto seria quando o Product Owner entra em acordo com sua equipe de que qualquer bug que impeça os usuários de fazer pedidos no site de eCommerce deve ser corrigido o mais rápido possível.
Outras diretrizes podem se referir a bugs que só precisam ser corrigidos no final do dia, no final da semana ou até mesmo nunca.
Definir diretrizes de defeitos
Para a formulação de diretrizes de correção de bugs, as seguintes considerações são úteis:
- Probabilidade de um defeito: Com que frequência o problema ocorre?
- Gravidade de um defeito: Quão grave é quando o problema ocorre?
Imagina que na Amazon existe um bug que impede que pedidos com um valor de 1 milhão de dólares sejam realizados, porque um desenvolvedor assumiu que um pedido nunca ultrapassaria o valor de 999.999,99 dólares.
É ruim quando esse caso acontece (alta gravidade), mas acho que a Amazon não recebe muitos pedidos acima de 1 milhão de dólares (baixa probabilidade).
Criação da matriz de diretrizes de defeitos para priorização de bugs
As duas dimensões – severidade e prioridade – podem ser combinadas para definir a política de priorização de um defeito. Uma matriz como esta pode ajudar:
Existem muitas formas de classificar a probabilidade e a gravidade de bugs. No exemplo do site de eCommerce, a probabilidade é expressa pela porcentagem de transações afetadas. Tudo que impacta 10% ou mais das transações é algo bem significativo, por isso defini toda a coluna como prioridade alta ou muito alta.
Para avaliar a gravidade de um defeito, você pode considerar se existe uma solução alternativa e se ela é óbvia ou difícil de encontrar. Em um site de eCommerce, por exemplo, pode haver dois botões "Comprar agora", mas apenas um deles funciona.
As células da matriz mostram qual diretriz se aplica a defeitos com determinada probabilidade e gravidade. Neste exemplo, escolhi cinco níveis de prioridade diferentes – de muito baixa a muito alta. Em alguns casos, três níveis podem ser suficientes. Eu não recomendaria usar mais de cinco, mas já vi isso acontecer.
É assim que eu uso os cinco níveis de prioridade:
Muito alta: É incluído imediatamente na iteração em andamento, mesmo que isso signifique que outros trabalhos fiquem parados. Pode exigir mais de um membro da equipe, possivelmente até a equipe inteira.
Alta: É incluído imediatamente na iteração em andamento, mesmo que isso signifique que outros trabalhos fiquem parados. A equipe decide quem pode resolver melhor o problema.
Média: Pode ser incluído na iteração em andamento a critério do Product Owner.
Baixa: É documentado e discutido na próxima reunião de Planning a critério do Product Owner.
Muito baixa: É documentado na lista de problemas conhecidos. Só é retomado se a probabilidade ou gravidade mudarem, ou a critério do Product Owner.
Vantagens da priorização por diretrizes
A principal vantagem dessa abordagem é que você gasta muito menos tempo discutindo o que fazer com cada defeito individual. Esse tipo de priorização de bugs exige um certo esforço inicial para criar as diretrizes. No entanto, uma vez que essas diretrizes estejam estabelecidas, priorizar novos defeitos se torna extremamente fácil.
O objetivo dessa abordagem é tornar a priorização de defeitos uma questão mais objetiva do que subjetiva. Naturalmente, alguém precisará decidir com que frequência um problema provavelmente ocorrerá, mas tirando isso, a priorização em si não levará mais tempo do que olhar para a matriz de priorização.
Este artigo é do blog de Mike Cohn e foi traduzido por nós para o português.
Seminário de Product Owner
=> Torna-te um Product Owner certificado e participa num dos nossos Treinamentos
Requisitos Não Funcionais
=> Descobre como transformar requisitos não funcionais em User Stories.
Product Scorecard
=> Descubra se o seu produto está alinhado com a estratégia da empresa e use o Product Scorecard.
