Computer Science Master » Planning poker: o que é e como usá-lo?
Você sabe o que é o Planning Poker? Essa ferramenta foi criada para auxiliar times de desenvolvimento na criação de estimativas de tempo e esforço para realizar tarefas. Uma das vantagens de usar essa ferramenta é que o time de desenvolvimento e o dono do software (Product Owner) possuem uma metodologia bem definida para chegar a um consenso sobre a quantidade de horas necessárias para implementar as funcionalidades do software. Porém, antes de continuar, precisamos entender melhor a definição de Planning Poker.
Planning Poker é uma ferramenta usada por desenvolvedores de software que auxilia na criação de estimativas. Ela não é verdadeiramente um "jogo", no entanto, ela utiliza um baralho para auxiliar no processo de decisão. Essa ferramenta foi criada no contexto das metodologias ágeis (por exemplo, o Scrum). Sendo assim, a sua utilização faz muito mais sentido quando consideramos um cenário onde os desenvolvedores utilizam alguma metodologia ágil.
Devido aos princípios ágeis, é muito importante dizer que ao usar essa técnica não precisamos detalhar ao máximo as atividades definindo o tempo em horas para cada tarefa. O trabalho deve ser feito baseando-se nas User Stories do projeto, onde a equipe com sua experiência registra o quanto um recurso, uma User Story, é maior que a outra.
Exemplo de cartas de planning poker
As User Stories são construídas com base nos requisitos funcionais e não funcionais de um projeto de software. Portanto, o primeiro passo para "jogar" o Planning Poker é conhecer os requisitos (necessidades do cliente) e ter uma lista de User Stories representando o escopo do seu projeto. Com a lista criada, o time é reunido visando trabalhar nestas estimativas. Os Story Points são usados como métrica para representar um valor abstrato de tamanho. É importante dizer que essa não é uma estimativa em horas, mesmo que muitas pessoas convertam para tal.
Funcionamento e as regras do "jogo"
Antes de mais nada devemos entender quais são as cartas disponíveis para os participantes. Cada membro da equipe recebe em mãos as cartas do baralho, e cada um com um valor diferente de Story Point. Os possíveis valores são: 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40 e 100. Esses valores representam o esforço necessário para realizar uma tarefa. Porém, alguns decks possuem ainda as cartas de 'interrogação', 'infinito' e 'café'.
Interrogação (?): Como dito antes, a equipe precisa discutir cada User Story antes da votação para que todos os membros entendam do que a mesma se trata. Mas as vezes um membro da equipe não faz ideia de como estimar. Então ele utiliza a carta 'Interrogação (?)' para sinalizar que precisa discutir mais a User Story até que todo o time tenha realmente entendido do que ela se trata.
Zero (0): As vezes a User Story é tão simples que a equipe não quer prejudicar a capacidade de entrega da sprint com ela. Por exemplo: uma User Story diz que precisamos mover o botão 'salvar' da tela do aplicativo da direita para a esquerda. A equipe acredita que isso pode ser feito em poucos minutos. Então ao invés de usar a carta 1/2, utiliza a carta 0.
Infinito: Essa carta é o oposto do zero. A User Story é tão grande que não se encaixa na carta "100". Nesse caso, a equipe não se sente confortável em estimar o esforço necessário para essa tarefa, portanto utiliza a carta 'infinito'. A User Story deveria ser melhor entendida ou talvez quebrada em User Stories menores.
Carta Café: Esta carta serve para sinalizar que é preciso fazer uma pausa, o que pode aumentar significativamente o rendimento da equipe e também a precisão das estimativas. Logicamente, o Scrum Master pode ajudar a definir o tempo de intervalo e decidir quando o time deve voltar a se reunir.
Agora que nós já compreendemos quais cartas estão disponíveis, vamos nos aprofundar na dinâmica do jogo. Primeiro, alguém da equipe faz a leitura da User Story em voz alta. É interessante que o User Story seja apresentado em um slide na TV ou simplesmente escrito no quadro branco. A seguir, a equipe deve discutir o critério de aceitação (inicialmente definido pelo Product Owner) e todos tiram todas as dúvidas sobre a User Story. Os membros (exceto o Product Owner) devem decidir quantos pontos essa User Story merece e selecionam a carta do seu baralho que corresponde a complexidade daquela tarefa, porém não mostram aos demais. Portanto, quando todos os membros já tiverem feito sua decisão de pontuação para a story, todos devem virar as cartas ao mesmo tempo (isso evita que os membros enviesem a decisão dos demais). Se houverem divergências na opinião dos membros, cada um deve apresentar uma justificativa para o valor mais alto ou mais baixo. Por fim, o time deve votar novamente até que o grupo chegue a um acordo para uma pontuação adequada para o story.
Ainda é comum que existam divergências difíceis de se resolver, porém, se não existir um acordo espontâneo é possível que o Scrum Master intervenha. Com base nos argumentos apresentados pelo time, o Scrum Master pode solicitar que todos entrem em acordo de qual seria a melhor estimativa. Outro detalhe importante é que a escolha não é sempre pela maioria ou pela média. Sendo assim, a equipe pode confiar no participante que afirma já ter desenvolvido o mesmo trabalho da User Story e não vê dificuldades ou preferir o voto da maioria. Em verdade, o time deve decidir. Por fim, é importante não esquecer de estimar também novas User Stories que irão surgindo ao longo do projeto. Nesse caso o time pode se reunir e fazer uma estimativa usando Planning Poker.
O conflito entre gestores e equipe de desenvolvimento
Em um projeto de software é comum que as partes interessadas tenham dificuldades para compreender o conceito de horas ou dias chamados de ideais. Por exemplo, caso o seu time afirme que leva 30 dias ideais para implementar uma User Story, é comum que os envolvidos no projeto (principalmente os relacionados à área de negócio) se esqueçam da parte que afirma que esses dias são ideais e lembrem apenas dos 30 dias. Então, automaticamente o pensamento é que o trabalho será feito em apenas 30 dias. Além disso, outro problema é a capacidade técnica da equipe. Podemos dizer que enquanto um membro sênior pode dizer que termina o desenvolvimento da User Story em apenas 1 hora, aquele que possui menos experiência pode informar que levará 10. Quando usamos Story Points, isso elimina esse problema pois separamos o tamanho da User Story do tempo que realmente levará para desenvolver. Desta forma a equipe conseguirá estimar com mais eficiência o tamanho relativo das User Stories.
Quando dizemos 'Horas Ideais' estamos nos referindo a horas efetivamente trabalhadas em uma atividade. Portanto, se considerarmos os dias possuem 8 horas úteis, podemos afirmar que (em média) apenas 5 ou 6 horas são ideais, descontando, por exemplo: reuniões, café, tempo de ida ao banheiro, momentos de socialização, etc. Sendo assim, as horas ideias são as efetivamente trabalhadas na atividade, sem interrupções.
E ai você gostou do Planning Poker?
Uma dica legal é que na internet você encontra diversos modelos para download, além de alguns sites vendendo modelos impressos.
Clique aqui para acessar uma versão excelente para imprimir!
Ao utilizar o Planning Poker você fornece uma forma mais sistemática de estimar o esforço em tarefas de um projeto. Além disso, com o tempo, a equipe pode fornecer resultados mais rápidos com um ótimo nível de precisão. A equipe envolvida no projeto tem a oportunidade de contribuir igualitariamente e discutir cada User Story, gerando maior entendimento do projeto como um todo, o que acelera o desenvolvimento, dado que todos sabem exatamente o rumo do projeto. Ao utilizar essa técnica existe uma chance maior de acertarmos nas estimativas, visto que elas são criadas por meio de um consenso da equipe e não pelas opiniões individuais ou por um membro experiente isolado.