Estimativa de um bug sem reprodução
Como estimar um bug sem reprodução: não é possível estimar o tamanho da correção, apenas o tempo de busca. Como definir um prazo para a investigação, em vez de votar em uma história que ninguém pode ver.
Se você não consegue reproduzir o problema, não consegue estimá-lo. Você só consegue estimá-lo se estiver procurando por ele.
Um bug que não pode ser reproduzido é como se duas incógnitas compartilhassem um único ticket. A primeira incógnita é a causa: há um sintoma em produção, mas não há maneira confiável de reproduzi-lo localmente, nem um rastreamento de pilha consistente, nem uma linha nos logs que sempre o preceda. A segunda incógnita é a correção, que depende inteiramente da primeira. Votar em um número para a correção antes que a causa seja conhecida é votar em uma tarefa que a equipe não consegue realmente visualizar.
A correção nem sempre é difícil, uma vez que se descubra a causa; muitas vezes, basta uma alteração de uma linha. O que custa mais é a descoberta. Estimar o tempo de busca é realista; estimar o tempo da correção é uma ilusão.
O que é dito na sala
Engenheiro A: “Acho que é a invalidação do cache.”
Engenheiro B: “Acho que é uma questão de motivação do trabalhador.”
Líder: “Alguém já conseguiu fazer isso acontecer quando quis?”
Pergunta: “Já tentamos vinte coisas. Nada que fosse confiável.”
Suporte: “São três usuários por semana, sempre nas tardes de terça-feira.”
Perguntas que vale a pena fazer antes de votar
- Qual é o sintoma e com que frequência ele aparece?
- Já temos o registro de eventos nas rotas suspeitas ou precisamos adicioná-lo primeiro?
- Existe algum cliente com uma conta que sabemos que apresenta problemas e com a qual possamos reproduzir o problema?
- Qual é o custo desse bug para o cliente por semana, e isso justifica uma análise aprofundada?
- Qual é o prazo previsto para a investigação antes de voltarmos a discutir o assunto?
Duas teorias identificadas e nenhuma reprodução não é um número para se dar como concluído; é uma pesquisa que precisa de financiamento. Atribua um orçamento e estabeleça um marco de referência, e depois faça uma nova estimativa assim que a causa tiver um nome.
Aprovar um orçamento para a investigação. Quando a causa for identificada, fazer uma estimativa do custo do reparo por conta própria.
Consulte como estimar um teste instável para o mesmo tipo de situação e erros comuns no Planning Poker sobre como estimar bugs com precisão de recurso. Confira os outros exemplos práticos de estimativa ou inicie uma sessão gratuita de Planning Poker quando a causa for conhecida.