No post passado começamos a falar sobre princípios de como desenvolver software usando como base a leitura do livro Use a Cabeça: Desenvolvimento de Software. Foi explicado que dividindo o nosso projeto em iterações podemos nos aproximar daquilo que o cliente realmente precisa, obtendo seu feedback e mostrando o andamento do projeto em pequenas partes de Software funcional.
Vimos também que é muito importante que o cliente priorize as funcionalidades a serem desenvolvidas, pois temos um prazo a cumprir e nem sempre tudo caberá no período acordado para entrega do produto.
Para dar ao cliente um prazo, a nossa equipe precisa realizar a estimativa de tempo de cada tarefa a ser construída durante o nosso processo de desenvolvimento. Uma forma de se fazer é reunir a equipe e mostrar uma funcionalidade, daí cada membro dará sua estimativa para que ela seja desenvolvida. É importante que um membro do time não saiba previamente a estimativa do outro para não ser influenciado, todos podem escrever em uma plaquinha e mostrar simultaneamente quando solicitado pelo líder da reunião. Os “palpites” devem ter unidade definida antes da reunião começar e normalmente é utilizado dia/programador, ou seja, quantos dias um programador sozinho leva para realizar determinada atividade.
Fonte: superstock.com
É necessário que não hajam suposições sobre o que se refere a funcionalidade estimada, caso os participantes estejam em dúvida é aconselhado entrarem em contato com o cliente para esclarer realmente do que se trata. Após entrarem em consenso, passamos para a próxima funcionalidade até terminar todas.
No final, basta somar cada uma e teremos o prazo do projeto. Mas e quando as estimativas forem muito diferentes uma das outras? O que posso fazer? Bom, é extremamente aconselhável que os valores sejam colocados com confiança, e para isso todos precisam saber exatamente sobre o que se trata a funcionalidade em questão. Existe uma técnica conhecida como Pôquer do Planejamento que nos auxilia em casos de divergências na Estimativa.
Planning Poker – (Pôquer do Planejamento)
O pôquer do planejamento é uma técnica para auxiliar na estimativa de estórias ou funcionalidades quando há muita divergência por parte da equipe. Pode ser feito da seguinte forma:
- Colocar um cartão com o nome da funcionalidade/estória e sua descrição no centro de uma mesa onde todos participantes possam ver.
- Distribui um baralho com 13 cartas a todos os membros do time. O baralho pode ser visto na figura.
- Todos escolhem uma carta com o valor estimado e colocam virada para baixo.
- Ao combinado, todos viram sua carta ao mesmo tempo.
- O responsável por comandar a reunião anota o valor das cartas.
- Cada um explica o motivo da escolha.
- Participantes conversam para entrar num acordo.
Fonte: crisp.se
Cada carta da imagem corresponde ao valor numérico em dias, o valor “0″ informa que a funcionalidade já está pronta, a carta “?” significa que a pessoa não tem a mínima idéia e a carta com uma xícara significa “que tal uma pausa para o café?”.
É importante ressaltar que as estimativas devem levar em conta todas as etapas seguidas no nosso processo de desenvolvimento, ou seja, cada uma deve ter projeto, codificação, teste e entrega. Intervalos grandes de valores podem significar mal-entendido e é sempre bom contactar o cliente.
Enfim, como deu para perceber a idéia é sempre a mesma. Entrar em acordo e esclarecer as dúvidas sobre o que deve ser feito. Se não quiser realizar o pôquer do planejamento pode simplesmente trancar os membros da equipe em uma sala, dar-lhes Coca-Cola e pizza e dizer “Só saiam daí quando tiverem um valor”.
Esta postagem foi escrita com base no livro Use a cabeça: Desenvolvimento de Software e continua.
acho muito legal essas maneiras de iteragir com os programadores, afinal todas elas usam o orgulho deles contra eles! se o josé fala que demora 5 horas ele vai se esforçar para demorar isso pois ele deu a palavra dele, é mais facil as pessoas fazerem o que escolheu fazer do que foi imposto a eles fazerem… legal post mesmo…
Fala cara!
Você é um fanfarrão hehe.
Mas nos processos ágeis de desenvolvimento existe muito disso, se o cara disse na frente de todos que faria ele se sentirá incomodado caso não termine, não pq foi pressionado, mas por uma questão de honra. A idéia de colocar o backlog em um local que todos possam ver tem o mesmo sentido. A equipe vê o quanto falta para atingir a meta, olha para ele constantemente, e quando um programador termina uma tarefa e vai pegar outra no quadro, é visto pelos demais. Criando até uma certa competição saudável.
Abraços
Eu trabalho assim.
Só que no lugar dos pontos as tarefas são estimadas em horas.
Realmente a pressão psicológica é muito maior… Não que você fica desesperado, mas você se cobra um pouco mais. Pelo menos é assim comigo.
Outra coisa legal é que você vai se conhecendo, e com o tempo as estimativas vão ficando precisas.
[]s