Estimativa de um protótipo
Como estimar um protótipo: trata-se de um produto desenvolvido com o objetivo de aprender, não para ser usado. Como evitar que o protótipo se transforme no código de produção que ninguém havia planejado.
A história cujo resultado é “agora sabemos o que construir”, e não “já construímos”.
Um protótipo é dimensionado para fins de aprendizagem, não para uso. O objetivo é responder a uma pergunta (essa interação parece adequada?, essa abordagem é escalável?, essa API vai se sustentar?) com rapidez suficiente para que você possa mudar de direção antes de se comprometer com ela. Equipes que estimam protótipos da mesma forma que estimam funcionalidades obtêm um número que financia um tipo de trabalho inadequado.
O outro tipo de falha é o oposto: estimar um protótipo pequeno, lançar algo que “simplesmente funcione” o suficiente e, então, levar essa versão para produção porque o cronograma já avançou. O protótipo que se torna o produto é o código mais caro da base de código, porque ninguém planejou as partes que não estão lá.
O que é dito na sala
Engenheiro: “Posso montar algo em alguns dias.”
Introdução: “Qual é a pergunta que estamos tentando responder?”
PM: “Isso vai ser divulgado para os clientes ou é apenas para uso interno?”
Líder: “Se a resposta for sim, jogamos fora e recomeçamos do zero?”
Engenheiro: “Nunca jogamos isso fora.”
Perguntas que vale a pena fazer antes de votar
- A que pergunta o protótipo está respondendo, e como saberemos que temos uma resposta?
- Apenas para uso interno ou na presença dos clientes?
- Por padrão, é descartável, e a equipe está comprometida com isso?
- Qual é o prazo, e o que acontece quando ele terminar?
- Se funcionar, qual é o caminho do protótipo até o código de produção?
A mentalidade do engenheiro de que “nunca jogamos nada fora” é o verdadeiro risco: reserve um orçamento para o protótipo da solução e trate a versão de produção como um projeto à parte, para que a ideia de “descartar” não seja adotada por padrão.
Crie um protótipo para a resposta, não para o produto, e planeje a reformulação antes que o cronograma o faça por você.
Assim como estimar um pico de pesquisa, o resultado esperado é o conhecimento; trate-os da mesma maneira. Consulte erros comuns no Planning Poker sobre a investigação que se infiltra na história e os outros exemplos práticos de estimativa.