Antes de mais nada o conceito
O Planning Poker é uma técnica de estimativa baseada no consenso de toda a equipe, onde é utilizado um conjunto de cartas com valores específicos que podem representar pontos relativos ou até mesmo horas (esses valores podem seguir a seqüência de fibonacci) e é praticado como se fosse um jogo. Uma pessoa apresenta a tarefa ou estória para o time, e, após uma breve discussão, cada um escolhe uma carta e coloca virada para baixo sobre uma mesa. Quando todas as cartas estiverem lançadas, elas são viradas e caso não haja consenso nos valores escolhidos, as diferenças são discutidas de forma breve, e uma nova rodada acontece até que haja a convergência.
Porque usar o Planning Poker?
Quem trabalha com desenvolvimento de software sabe que um dos nossos maiores desafios é conseguir mensurar o tamanho de cada tarefa com uma boa precisão, e, conseqüentemente, conseguir prever quando determinado recurso deverá ser concluído. A forma como fazemos nossas estimativas tem um grande impacto na confiabilidade de nossos prazos, porém, nem sempre as equipes tomam consciência desse fato, e continuam dando pouco valor ou dedicando menos esforço do que deveriam a essa atividade.
Seja qual for a metodologia de trabalho que sua equipe utiliza (scrum + XP ou outra mais tradicional) você pode utilizar diversas técnicas de estimativas.
Algumas vantagens do Planning Poker:
· Equipe mais comprometida, pois todos participam;
· Força a equipe a ter um conhecimento de negócio mais homogêneo;
· Aumenta bastante a precisão das estimativas, pois considera a experiência de todos;
· Mais atraente (divertida) que as demais técnicas.
Se seu time está tentando implementar o scrum, algumas considerações:
· Estórias são funcionalidades, na forma como tem valor para o cliente (no scrum, o PO ou Product Owner). Exemplo: Eu como usuário quero poder cadastrar um produto;
· Tarefas são as implementações que devem ser feitas para que a funcionalidade seja entregue. Uma estória pode possuir uma ou mais tarefas;
· Nós só conseguimos estimar com precisão as tarefas pequenas. Se estiver estimando em horas, um valor maior que oito já é considerado um ‘chute’, e geralmente significa que aquela tarefa deve ser particionada em pelo menos duas partes, e reestimada, portanto, é recomendável assumir que cada tarefa deve ser pequena o suficiente para poder ser executada em um dia;
· Nem todas as estórias precisam ser detalhadas durante as estimativas. Se você trabalha com scrum, durante o backlog estimate (reunião, geralmente semanal, onde estimamos apenas as estórias de usuário) todas as estórias são reestimadas, e as estórias grandes são quebradas de acordo com a priorização do Product Owner. Dessa forma, as estórias com prioridade mais baixas podem ser estimadas com valores mais altos, e seu detalhamento pode ser postergado para quando se tornarem mais próximas de serem selecionadas para o sprint;
· Estimativas por horas devem ser feitas sem considerar as interrupções, ou seja, o tempo que efetivamente levaríamos para concluir a tarefa em um dia ideal;
· Estimativas por pontos é uma técnica muito boa para se estimar as estórias de usuário e não as tarefas, que usamos estimativas por horas em dias ideais (veja mais sobre estimativas por pontos aqui).
Existe um site bem interessante onde é possível jogar online o Planning Poker com sua equipe: planningpoker.com. Mas note que o poker real, com cartas de papel, é mais recomendável e geralmente mais ágil. Existem vários sites que fornecem as cartas para impressão, como: sprintplanning.com (para mais, deem uma olhada nas referências da Wikipedia).
Aqui tem uma explicação bem legal sobre como funciona a dinâmica do jogo:www.crisp.se/planningpoker
Links que serviram de base para este post
