Planning Poker

Planning Poker
No mundo do desenvolvimento de software, poucas coisas são tão difíceis

quanto estimar o tempo de desenvolvimento de um projeto. Existe
inúmeras técnicas, métodos, ferramentas e abordagens, mas em sua
maioria, elas falham ao serem unilaterais: o gerente do projeto estima
quanto tempo cada tarefa vai levar (usando seu método favorito), soma as
tarefas e diz ao time que eles tem de desenvolver o “Google” nos próximos
30 dias.
Quem nunca passou por esse tipo de situação?
O Planning Poker (Poker de Planejamento), ao contrário, conduz o time a
encontrar métricas que funcionem para todos e a construir o escopo do que
será feito na próxima fase de desenvolvimento de maneira colaborativa.
Ok, o gerente ainda tem um papel essencial aqui: o de priorizar o que deve
ser feito primeiro, mas não é ele quem decide quanto tempo o time vai
levar para realizar seu intento. Apenas o time pode decidir isso. Soa
estranho? Mas não deveria…
Invenção oriunda do mundo dos Métodos Ágeis de desenvolvimento de
software (como o Scrum), o Planning Poker parte do pressuposto que
somente os responsáveis por executar uma tarefa podem dizer quanto
tempo ela vai levar para ser desenvolvida. E ninguém mais. Isso por duas
razões básicas:
 O Planning Poker incentiva a colaboração e, dessa maneira, os prazos
estimados serão lapidados por todos do time ao longo do processo
(como verá mais adiante), ajudando a mitigar erros de estimativas de
gerentes otimistas ou de programadores pessimistas.
 Uma vez que todos colaboram no processo de estimativa, existe um
sentimento de comprometimento compartilhado com o projeto. Se o
time não entregar no prazo, a culpa pelo atraso é inteiramente deles,
uma vez que o prazo não foi dado pela gerência.
O Planning Poker ajuda nas métricas.
Poker?
O Poker no nome vem por conta de as estimativas serem feitas com um
baralho. Não um barulho comum, mas um que usa a Sequência de
Fibonacci (ou um cálculo próximo dela). Pra quem não conhece, a
Sequência de Fibonacci é mais uma invenção (ou seria melhor dizer
“formalização”?) feita por um matemático italiano para descrever o
comportamento do crescimento de uma população de coelhos. Daí para ser
usada em estimativas de projetos é um pulo (com o perdão da referência),
uma vez que o crescimento dos números (e consequentemente do prazo)
vai se tornando exponencial conforme a complexidade do software
aumenta e nos leva para o desconhecido.
Na Sequência, que começa com os números inteiros 0 e 1, cada número é
resultado da soma dos dois números anteriores, ou seja, temos 0, 1, 2, 3, 5,
8, 13, 21, 34, 55, 89…No baralho de Planning Poker essa escala foi
simplificada, mas a ideia é essa mesmo. Conforme a complexidade e o
tamanho de um software aumentam, não há como dizer com precisão
quanto tempo vai levar para desenvolvê-lo. E antes de torcer o nariz para o
que estou dizendo, vai por mim, estou há 10 anos nesse ramo. Já vi um
bocado de projetos estourarem prazo pela gerência não querer entender que
não dá para estimar o desconhecido com precisão.
Mas voltando ao baralho, a escala usada nos gera as seguintes cartas:
0, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?
Algumas variações também incluem uma carta para o infinito, e outra para
o café, algumas vezes removendo a carta 100. Vou explicar cada uma mais
adiante.
Cada jogador (i.e. desenvolvedor do time) deve ter um desses baralhos no
dia em que for feita a estimativa do tempo que o projeto irá levar.
Como funciona?
Primeiramente existe um tema de casa que deve ser feito pelo gerente do
projeto e/ou pelo analista de sistemas, dependendo de como isso está
organizado na sua empresa. Obviamente o Planning Poker funciona melhor
caso a empresa já esteja adotando métodos ágeis no desenvolvimento de
seus projetos e, no caso do Scrum, o Scrum Master deve sentar com o
Product Owner antes da Sprint Planning para elucidar as tarefas e ver quais
são as prioridades para a próxima Sprint.
Uma vez que o Product Backlog está organizado, o PO (que não joga
Poker) senta junto com o time com o topo do Product Backlog priorizado e
quebrado em tarefas. A dinâmica funciona da seguinte maneira, para cada
uma das tarefas (que podem ser cards, caso esteja usando Kanban)
executamos essas ações:
1) O PO lê a tarefa em voz alta e responde dúvidas dos desenvolvedores,
cada qual com seu baralho de Planning Poker em mãos. O ideal é que ele
comece com a tarefa mais fácil de todas, para que possamos usar ela como
referência depois, para estimar as demais.
2) Cada desenvolvedor escolhe uma carta do seu baralho, em segredo,
baseado no quão complexo acha a tarefa. Aqui vale uma explicação sobre
as cartas numéricas (os valores em horas são apenas para ter uma ideia):
 Carta 0: a tarefa não precisa ser feita por algum motivo (talvez já
esteja pronta)
 Carta 1: a tarefa é muito, mas muito simples, provavelmente menos de
1h de desenvolvimento de qualquer da equipe
 Carta 2: a tarefa é simples, provavelmente leve menos de um turno de
trabalho, como uma manhã por exemplo.
 Carta 3: a tarefa é simples, mas trabalhosa e não deve ser subestimada
ocupando pelo menos um turno de trabalho, como uma tarde
(geralmente é mais longa que uma manhã).
 Carta 5: a tarefa é de complexidade mediana, provavelmente tomando
um dia de trabalho de um desenvolvedor, se não tiver impedimentos
 Carta 8: a tarefa é complexa, vai demandar algum estudo ou muito
desenvolvimento, provavelmente tomando alguns dias da semana, com
2 ou 3 no máximo.
 Carta 13: a tarefa é muito complexa, vai demandar estudo moderado
ou é apenas muito longa de desenvolver, levando em média uma
semana de um desenvolvedor (5 dias úteis)
 Carta 20 em diante: a tarefa é complexa demais e não vale a pena ser
estimada. Sugere-se quebrar a tarefa em tarefas menores, que possam
ser estimadas com mais exatidão
 Carta Interrogação (?): não entendi a tarefa sr. Scrum Master, pode
lê-la de novo e dar mais detalhes?
 Carta Infinito (quando houver, caso contrário, use a 100): não
temos como fazer esta tarefa sr. Scrum Master, ela é longa demais e
não cabe em qualquer pipeline de desenvolvimento. Sugiro quebrarmos
ela em tarefas menores ou dizer ao Product Owner que não tem como
fazermos (mais raro).
 Carta Café (ou Cerveja em algumas empresas): estou cansado de
tanto estimar, que tal tomarmos um café e depois voltamos?
3) Depois que todos escolhem suas cartas em segredo, revelam-se as
escolhas sendo que o PO é o facilitador dessa dinâmica. Compara-se os
resultados e:
 Se todos forem iguais, anota-se o número obtido junto à tarefa e
reinicia-se a dinâmica com a próxima tarefa a ser estimada.
 Se houver divergências, o desenvolvedor que escolheu a carta com
menor valor justifica sua posição. Depois o desenvolvedor que escolheu
a maior carta justifica sua posição. O Scrum Master também é
convidado a explicar melhor esta tarefa. Todos jogam novamente.
 O ideal é sempre chegar em um consenso, mas dependendo do tamanho
do time isso não será possível. Assim, considera-se que se a distância
entre o maior e o menor valor jogados não passar de duas cartas,
assume-se uma média (Fonte: livro do Jeff Sutherland).
4) Depois que todas as tarefas prioritárias foram estimadas (ou ao menos
que o feeling lhe diga que já passaram tempo demais estimando tarefas) o
time de desenvolvimento, baseado nas prioridades, seleciona quais tarefas
ele se compromete a executar nessa Sprint (obviamente de acordo com o
tamanho da Sprint que varia de 15 dias a 1 mês usualmente).
E é isso. Simples, não?!
Nesse momento de pandemia do Covid-19, estamos trabalhando de forma
remota, e a ferramenta que eu recomendo é o ScrumPoker-Online.

Planning Poker

Enviado por

Direitos autorais:

Formatos disponíveis

Planning Poker

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Planning Poker

Enviado por

Direitos autorais:

Formatos disponíveis

Planning Poker

No mundo do desenvolvimento de software, poucas coisas são tão difíceis

Você também pode gostar