Estimativa de um protótipo
Como avaliar um protótipo: trata-se de um produto desenvolvido com o objetivo de aprender, não para ser utilizado. 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 chegam a 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, em seguida, colocar essa versão em 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 se fala na sala
Engenheiro: “Posso montar algo em alguns dias.”
Introdução: “Qual é a pergunta que estamos tentando responder?”
PM: “Isso vai ser divulgado aos 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
- 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?
- O que é o intervalo de tempo e o que acontece ao final dele?
- 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: inclua o protótipo no orçamento como parte da solução e trate a versão de produção como um projeto à parte, para que a ideia de “jogar fora” não seja adotada por padrão.
Crie um protótipo com base na resposta, não no produto final, e planeje a reformulação antes que o cronograma o faça por você.
Assim como na estimativa de um pico de pesquisa, o resultado esperado é o conhecimento; trate-os da mesma forma. Veja os erros comuns do Planning Poker relacionados à investigação que se infiltram na história e os outros exemplos práticos de estimativa.