Fazendo Estimativas com Planning Poker

 

O Planning Poker é uma técnica usada pelas equipes ágeis para fazer estimativas. A meta é obter o consenso.

O primeiro ponto aqui é que o projeto é executado em iterações ou ciclos. Apenas para exemplificar, podemos dizer que no Scrum essas iterações são chamadas de sprints. Dessa forma, para criar um plano para cada iteração é necessário saber o que precisa ser feito (que são as atividades ou tarefas), quanto tempo cada atividade vai demorar (que é a duração de cada atividade) e as atividades que serão feitas em primeiro lugar e as que serão feitas depois destas, e assim por diante (que define as prioridades).

Quando falamos em termos do que precisa ser feito, estamos falando dos requisitos de cada atividade. Também é importante fazer comparações para saber o quanto uma atividade é maior (leva mais tempo para ser feita/é mais complexa/custa mais caro) ou menor (leva menos tempo pra ser feita/é menos complexa/custa mais barato) que outra. Além disso, precisamos saber o que precisa ser feito que é mais importante para o negócio (se estamos em um projeto interno) ou para o cliente ou o negócio desse cliente (se estamos executando um projeto para outra empresa que nos contratou). Essa última parte relacionada as prioridades parte do princípio que os donos do negócio sabem, melhor do que ninguém, que inclui também a equipe que executa o projeto, o que é mais importante e prioritário para o seu negócio, independentemente de existirem ou não dependências.

Este é um bom momento para revisar a questão das dependências entre atividades ou tarefas. Vamos considerar, em primeiro lugar, um projeto de desenvolvimento de software, com partes que podem ser experimentadas e utilizadas pelos usuários. Alguns dessas partes são, por exemplo: (i)pagamento por Pix, (ii)seleção de produtos em ordem crescente de preços, (iii)opção para que o cliente desista do serviço, (iv)criação de playlist, e assim por diante. Cada um dos exemplos anteriores será criado através de códigos escritos por um programador (também chamado de desenvolvedor) em uma determinada linguagem de programação e podem ser produtos mínimos viáveis. Quem define o que deve ser feito em primeiro lugar, ou seja, quem define as prioridades é o dono do negócio. Nesse caso, não há dependências obrigatórias que amarrem a ordem das prioridades.

Agora, vamos pensar em projetos que não sejam construídos com partes de software e ver como as dependências funcionam. Vamos imaginar um prédio de apartamentos, um avião de transporte de passageiros ou um carro de passeio. Os três exemplos citados só ficam prontos quando tudo está pronto. Não se pode fazer o telhado em primeiro lugar, antes do alicerce e das paredes. No caso do avião de passageiros, primeiro se monta a fuselagem, dividida em grandes seções, ai vem as asas, depois o trem de pouso, as turbinas, e por aí vai até a pintura da aeronave. Para o carro de passeio também há passos muito bem definidos que incluem diferentes áreas como, por exemplo, motor, transmissão, suspensão, dinâmica veicular, carroceria e freios. Um prédio de apartamentos, um avião de passageiros e um carro de passeio são projetos que têm dependências obrigatórias. Isso quer dizer que não se pode escolher o que é feito em primeiro lugar e o que vem a seguir. Estes são exemplos muito diferentes dos projetos de desenvolvimento de software. Nesses projetos, com duração de 2 anos ou mais e envolvendo equipes com mais de 1000 profissionais, entre pessoal da empresa executora e terceiros, não existe o chamado produto mínimo viável, como nos projetos de software. O prédio de apartamentos, o avião de passageiros e o carro de passeio só são viáveis para serem usados quando estão totalmente prontos. Dito isso, vamos voltar as estimativas com a técnica Planning Poker, usadas nos projetos ágeis, que envolvem equipes pequenas e são executados em rodadas ou iterações.

O Planning Poker é colaborativo e são justamente os membros da equipe do projeto que fazem as estimativas. Para facilitar o entendimento dessa técnica, vamos imaginar uma equipe com 4 membros que precisa fazer estimativas para planejar uma iteração. Cada membro da equipe, no papel de pessoa que faz uma estimativa, pega um conjunto de cartas impressas com os números 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 e, opcionalmente, uma carta onde o sinal de interrogação (?) está impresso, para indicar casos em que a pessoa que faz a estimativa simplesmente não tem ideia do valor a ser estimado.

Notar que os valores acima formam uma sequência de Fibonacci modificada.

O Planning Poker funciona com os seguintes passos:

1)- O processo se inicia focalizando uma determinada atividade ou tarefa.

2)- Os membros da equipe devem fazer uma discussão sobre a atividade em foco, até que se tenha clareza sobre o que é a atividade que se deve estimar.

3)-  Cada membro da equipe que está fazendo estimativas seleciona uma carta com o número que representa o tamanho da atividade. Uma vez que todos tenham feito suas escolhas, as cartas são apresentadas ao mesmo tempo. Isso evita que a estimativa de uma pessoa influencie a estimativa de outra.

4)- Se não houver um consenso, as pessoas que escolheram as cartas com pontuação mais alta e mais baixa serão perguntadas sobre suas escolhas. Isso adicionará novas percepções sobre a atividade focalizada.

5)- Levando em conta as novas percepções apresentadas, todos fazem uma nova estimativa.

6)- O processo se repete até a obtenção de consenso.

7)- Uma vez obtido o consenso, a pontuação estimada para a atividade ou tarefa é registrada.

Aqui vale mencionar uma unidade arbitrária chamada Story Point. O Story Point é, provavelmente, a unidade de estimativa mais utilizada entre as equipes ágeis atualmente. O nome é derivado da forma como se expressam requisitos de uma tarefa, na forma de User Story (Estória do Usuário).

A pergunta então é a seguinte: Quantos Story Points tem essa User Story?

Um Story Point é uma estimativa relativa ao "tamanho" da atividade que pode ser comparada com outra atividade no projeto. Portanto, espera-se que uma estória de 8 pontos demore quatro vezes mais tempo que uma estória de 2 pontos.

Em uma análise grosseira, pode-se dizer que um Story Point é uma unidade de medida que expressa a estimativa do esforço necessário para implementar uma atividade ou tarefa. Todavia, além da quantidade de esforço devem ser também considerados mais dois aspectos: a complexidade para desenvolver a atividade e o risco para desenvolver essa atividade.

Do ponto de vista prático, os pontos atribuídos para cada atividade são usados para estimar o custo e a duração dessas atividades. Cada equipe ágil pode definir o tamanho de um Story Point em termos de horas ou dias. Isso também leva em consideração a quantidade de recursos (pessoas, chamadas de programadores ou desenvolvedores) previstos para trabalhar na atividade. Por exemplo, para a empresa XYZ, com custo hora do desenvolvedor em $100, uma tarefa estimada para ser concluída (desenvolvimento e testes) com 3 desenvolvedores em uma hora, pode receber a pontuação de 3. Em outras palavras, a pontuação diz que a tarefa levará 1 hora para ser concluída e custará $300.

Para uma mesma tarefa, a pontuação dos Story Points pode ser diferente de empresa para empresa, bem como de equipe para equipe. Em outras palavras, um Story Point é único para a equipe e não pode ser comparado com o Story Point de outra equipe. As equipes podem ser diferentes por diversos fatores como, por exemplo, quantidade de membros, grau de especialização, tipos de competências e experiência, que faz com que diferentes equipes trabalhem em diferentes velocidades. Como a velocidade das equipes é diferente, o tempo para conclusão de atividades poderá ser também diferente.

Algumas equipes adotam a regra de dividir em tarefas menores uma atividade que é estimada com pontuação maior ou igual a 13. A ideia aqui é reduzir o risco quando se lida com tarefas grandes e, geralmente, mais complexas, que são mais difíceis de estimar.

Como o Planning Poker é colaborativo e permite a participação de todos os membros da equipe que executarão a atividade, esta técnica funciona como ferramenta de integração da equipe, uma vez que todos podem contribuir e se comprometer com o plano que está sendo elaborado. Além disso, com a experiência de realizar sucessivas estimativas feitas para várias iterações do projeto (fazer a estimativa, verificar se foi correta e corrigir, se necessário, para melhorar a próxima iteração), o Planning Poker auxilia no planejamento futuro, melhorando a precisão das estimativas.

Bem, é isso aí, até a próxima!