Planning Poker: como estimar tempo de desenvolvimento de software

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 (Pôker 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.

Quem não gosta da técnica tende a argumentar que o Planning Poker é uma arma na mão de equipes preguiçosas, que a palavra final não deveria ser dos desenvolvedores que podem querer “jogar” as métricas para o alto para ganhar mais tempo. Mas aí eu pergunto: o culpado é o Planning Pôker? Ou é o seu time preguiçoso?

Não culpe a ferramenta pela pela imperícia do usuário…

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, 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 Scrum Master (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 Scrum Master 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 Scrum Master é 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 houverem 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?!

Mas e o tempo?

Note que não existe um cálculo mágico para converter os pontos do Planning Poker em horas de trabalho, mas que depois de duas ou três sprints é comum o time encontrar um consenso e descobrir a sua velocidade, sendo que o Scrum Master deve auxiliar nesse processo de descoberta. Os tempos estimados que menciono junto às cartas são apenas uma ideia de valores que funcionam para os times de desenvolvimento com os quais trabalhei. No fundo, os números do Planning Poker são uma medida relacional, conforme mencionei na etapa 1, geralmente sendo usadas as tarefas mais fáceis para estimar as mais difíceis. Perguntas como: “A tarefa x é mais difícil que a y, que estimamos em z?” norteiam as jogadas pois é mais fácil estimar empiricamente, baseados em nosso conhecimento prévio, do que pensando no futuro.

Um ponto importante que vale ressaltar é que as métricas são coletivas, ou seja, a responsabilidade é de todos e não apenas do desenvolvedor que provavelmente irá pegar a tarefa pra si. Assim, não vale jogar qualquer carta apenas porque você acha que não terá de botar a mão naquela tarefa. Afinal, se o time falhar em entregar no prazo, a culpa será de todos, pois foi o time que estimou as tarefas.

E por fim, é válido comentar novamente que o Planning Poker funciona melhor no mundo agile, principalmente quando usado em conjunto de um Kanban e de um Burndown Chart. Geralmente ao término da Sprint Planning o Scrum Master organiza as tarefas do Sprint Backlog em cards no Kanban (se ainda não o fez) e constrói o Burndown Chart baseado no número de pontos da soma das tarefas desta sprint versus o tempo da Sprint. Pretendo falar destas duas ferramentas em outros posts aqui no blog em breve, pois elas são muito importantes para os pilares de inspeção e adaptação do Scrum, que mencionei neste post.

Ah, e se você buscar por Planning Poker no Google Imagens, irá encontrar diversas imagens prontas para impressão e uso na sua empresa, semelhante as que usei para ilustrar o post.

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso (abaixo) sobre o mesmo assunto!