Conheci o Poker do Planejamento lendo o manual do Scrinch, um programa em Java que ajuda tanto no planejamento como no acompanhamento de histórias com o Scrum.
O manual do Scrinch explica, de maneira muito interessante, a forma como a prioridade das histórias é definida. Cada história tem, ao menos, duas propriedades: BV, ou o valor para o negócio (business value), que é a prioridade definida pelo cliente do projeto; e W, a carga de trabalho (workload), que é definida pelos desenvolvedores. A prioridade de cada história é o valor da divisão BV/W. BV e W não são valores exatos, eles não representam horas ou dias, mas os números 1, 2, 3, 5, 8, 13, 21 (uma adequação da sequência de Fibonacci).
“É muito difícil avaliar exata e numericamente o esforço de desenvolvimento que deve ser atribuído a uma história. Então, para que seguir usando horas? É mais fácil dizer que a história A é mais fácil que a história B e atribuir cargas de trabalho proporcionais”, dizem os criadores do Scrinch. O cálculo de horas para uma determinada história é, sempre, muito complexo. Ele exige que se conheça muito bem a tecnologia com a qual se trabalha e a real produtividade de cada membro da equipe. Como precisamos estar sempre de olhos abertos a novas tecnologias e como os membros de uma equipe podem não ser os mesmos no decorrer de todo o tempo da realização de um projeto, que também pode ter (e muito provavelmente terá) seus requisitos ajustados, as variáveis para o cálculo de horas são tantas que essa ideia de usar a sequência de Fibonacci como um fator de relação entre histórias, em vez da atribuição inexata de um número de horas, não parece tão absurda. “É um tanto incômodo no início, mas bastante útil no final”, complementa o manual do Scrinch.
Essa prática de atribuir números da sequência de Fibonacci a uma história tem suas origens, justamente, no Poker do Planejamento: um jogo – e ao mesmo tempo um exercício – de estimativa de desenvolvimento de um projeto a partir da informação que se tem do cliente: especialmente as User Stories.
O Poker do Planejamento é legal para fomentar a interação entre a equipe de uma maneira divertida, servindo também para o Product Owner ter uma ideia dos perfis de estimativa de cada um dos membros. Sempre existirá aquele que é mais ousado e acha possível fazer tudo muito fácil, assim como, no outro extremo, terá aquele que sempre vai encontrar pontos que devem ser mais bem esclarecidos em cada história. Na prática, o Poker do Planejamento funciona como um nivelador para a equipe, para aumentar o entrosamento e para ensinar o Scrum. A Figura 5.2 apresenta o exemplo de um conjunto de cartas que você pode copiar e recortar para montar seus “baralhos” para usar no Poker do Planejamento. Ao final do livro, em Referências, você encontrará fontes a partir das quais poderá baixar um arquivo com as cartas do Poker do Planejamento.
Figura 5.2 – Exemplo de cartas que podem ser usadas no Poker do Planejamento.
| A sucessão de Fibonacci ou sequência de Fibonacci é uma sequência de números naturais, na qual os primeiros dois termos são 0 e 1, e cada termo subsequente corresponde à soma dos dois precedentes. A sequência tem o nome do matemático pisano do século XIII Leonardo de Pisa, conhecido como Leonardo Fibonacci, e os termos da sequência são chamados números de Fibonacci. Os números de Fibonacci são, portanto, os números que compõem a seguinte sequência de números inteiros: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, …. (Fonte: Wikipédia) |
Você já deve ter observado, olhando a Figura 5.2, que há alguns elementos estranhos à sequência de Fibonacci entre as cartas. De fato, se você procurar na web, encontrará várias versões de cartas para o Poker do Planejamento, e você é livre para criar a sua própria versão. A que está na figura 5.2 é a que eu uso, e ela tem se prestado bem à sua finalidade.
O Poker do Planejamento pode ser usado em dois momentos: na priorização das histórias e na estimativa do esforço necessário para realizá-las, assunto que retomarei mais adiante, no Capítulo 8. Por enquanto, tratemos da priorização das histórias na construção do Product Backlog.
Uma vez definidas as histórias principais, seguindo o nosso exercício, normalmente é fácil “sentir” quais histórias possuem valor unânime para todo o grupo. Escolha algumas delas para começar seu jogo de poker. Distribua um conjunto de cartas para todos os presentes e explique como funciona o jogo.
Cada pessoa deve atribuir a uma história o valor correspondente à sua prioridade. Zero significa que a história é absolutamente desnecessária e deveria sair do Product Backlog, e o Infinito (o oito deitado) significa que a história é de vital importância. A interrogação significa que a pessoa não se sente confiante o suficiente para atribuir um valor à história, e o símbolo do café quer dizer que a pessoa precisa de um tempo para pensar antes de atribuir um valor. Essa pausa para o café, independentemente de quem a pede, deve ser respeitada por todos. Você verá que ninguém abusará dela.
Apresente a primeira história (aquela que você julga ser mais ou menos unânime em termos de prioridade) e peça que cada pessoa escolha uma carta que atribua uma prioridade a ela. Eu costumo fazer uma média entre todos os valores entre ½ e 21, usar o número de infinitos para posicionar a história mais acima ou abaixo do backlog (uma história com dez votos de valor infinito tem mais prioridade que outra com cinco) e, havendo poucos extremos (infinitos ou zero), peço que aqueles que votaram no extremo expliquem seu voto aos demais, tentando buscar aliados ou sendo convencidos a mudar seu voto pelos demais.
Mantenha seu Product Backlog sempre em sincronia com o mapa mental do projeto para que todos tenham sempre a visão integral do que está acontecendo.
As notas adesivas, as cartas do poker e o mapa mental têm a função de tornar o processo de planejamento algo lúdico e não entediante, focando as pessoas naquilo que é realmente mais importante para a realização de um bom projeto e dando voz a todos. As pessoas devem, de fato, se sentir envolvidas e beneficiadas com o que será o resultado do projeto e devem ser incentivadas a colaborar. Esse Sprint Zero pode durar um dia, pode exigir mais de uma sessão de refinamento, com o intervalo de alguns dias para as pessoas respirarem. Pode ser feito em sessões diárias de duas horas para que ninguém precise abandonar integralmente suas demais tarefas. A partir do Sprint Um, porém, o time Scrum que desenvolve o projeto (ou produto, ou serviço) deve ter dedicação integral a ele.
Pessoalmente, já atribuo ao Sprint Zero a mesma duração que terão os demais Sprints (uma ou duas semanas) e já aproveito para carregá-lo, além da apresentação do Product Backlog com a ideia do que será o Mínimo Produto Viável (a primeira versão a ser entregue aos usuários), com o esboço das versões seguintes (que podem mudar posteriormente) e com a definição das ferramentas (linguagem e framework de programação, bases de dados, bibliotecas para desenvolvimento web) que serão utilizadas.
O agilista Lasse Ziegler sugere que os números das cartas do Scrum Poker sejam multiplicados por mil e que elas sejam tratadas como valores financeiros, perguntando aos patrocinadores do projeto quanto eles pagariam por cada uma das histórias. Segundo Lasse, os patrocinadores tendem a priorizar melhor as histórias dessa maneira. Nesse caso, é melhor deixar de lado a carta que representa o infinito.
Caso o número de histórias do Product Backlog seja pequeno, sua priorização pode ser feita de maneira bem mais simples. Escolha duas histórias arbitrariamente e pergunte aos patrocinadores qual é mais importante. Faça o mesmo com uma outra história, perguntando se ela é mais ou menos importante que as anteriores e, assim, vá colocando-as em ordem.
