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 da busca. Como definir um prazo para a investigação, em vez de votar em uma tarefa 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 caro é a descoberta. Estimar o tempo de busca é realista; estimar o tempo da correção é uma ilusão.
O que se fala na sala
Engenheiro A: “Acho que é a invalidação do cache.”
Engenheiro B: “Acho que o problema está no operário.”
Líder: “Alguém já conseguiu fazer isso acontecer quando quisesse?”
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 está com problemas e na 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 um prazo, 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 separadamente.
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. Dê uma olhada nos outros exemplos práticos de estimativa ou inicie uma sessão gratuita de Planning Poker quando a causa for conhecida.