Quem trabalha com desenvolvimento de software sabe que um dos nossos maiores desafios é conseguir mensurar o tamanho de cada tarefa com uma boa precisão, e, conseqüentemente, conseguir prever quando determinado recurso deverá ser concluído. A forma como fazemos nossas estimativas tem um grande impacto na confiabilidade de nossos prazos, porém, nem sempre as equipes tomam consciência desse fato, e continuam dando pouco valor ou dedicando menos esforço do que deveriam a essa atividade.

Seja qual for a metodologia de trabalho que sua equipe utiliza (scrum + XP ou outra mais tradicional) você pode utilizar diversas técnicas de estimativas. Neste artigo vou apresentar a que é mais utilizada por equipes que empregam metodologias ágeis: o Planning Poker.

Antes de começar, devo introduzir um conceito que pode não ser conhecido ou aceito por todos: uma estimativa é da equipe e não de um programador ou analista em específico, ou seja, o ato de estimar é uma atividade de TODA a equipe, e esse detalhe é primordial para o sucesso do Planning Poker. Com isso em mente, vamos à definição:

O Planning Poker é uma técnica de estimativa baseada no consenso de toda a equipe, onde é utilizado um conjunto de cartas com valores específicos que podem representar pontos relativos ou até mesmo horas (esses valores podem seguir a seqüência de fibonacci) e é praticado como se fosse um jogo. Uma pessoa apresenta a tarefa ou estória para o time, e, após uma breve discussão, cada um escolhe uma carta e coloca virada para baixo sobre uma mesa. Quando todas as cartas estiverem lançadas, elas são viradas e caso não haja consenso nos valores escolhidos, as diferenças são discutidas de forma breve, e uma nova rodada acontece até que haja a convergência.

Vale notar que eu enfatizei que as discussões devem ser breves. Esse ponto é muito importante, pois tem o objetivo de evitar longas argumentações técnicas, que não devem de forma alguma ser o foco de uma estimativa.
Exemplo: quatro membros da equipe jogaram o valor 3 para uma determinada tarefa, e um quinto jogou o valor 8. Houve uma diferença muito grande, e por isso o quinto jogador deve argumentar brevemente porque entendeu que a tarefa demanda mais esforço. Pode ser porque ele não entendeu bem o que deve ser feito, ou porque tem mais experiência naquele tipo de tarefa e conseguiu prever algumas dificuldades que os demais não conseguiram.

Algumas vantagens do Planning Poker:

· Equipe mais comprometida, pois todos participam;

· Força a equipe a ter um conhecimento de negócio mais homogêneo;

· Aumenta bastante a precisão das estimativas, pois considera a experiência de todos;

· Mais atraente (divertida) que as demais técnicas.

Se seu time está tentando implementar o scrum, algumas considerações:

· Estórias são funcionalidades, na forma como tem valor para o cliente (no scrum, o PO ou Product Owner). Exemplo: Eu como usuário quero poder cadastrar um produto;

· Tarefas são as implementações que devem ser feitas para que a funcionalidade seja entregue. Uma estória pode possuir uma ou mais tarefas;

· Nós só conseguimos estimar com precisão as tarefas pequenas. Se estiver estimando em horas, um valor maior que oito já é considerado um ‘chute’, e geralmente significa que aquela tarefa deve ser particionada em pelo menos duas partes, e reestimada, portanto, é recomendável assumir que cada tarefa deve ser pequena o suficiente para poder ser executada em um dia;

· Nem todas as estórias precisam ser detalhadas durante as estimativas. Se você trabalha com scrum, durante o backlog estimate (reunião, geralmente semanal, onde estimamos apenas as estórias de usuário) todas as estórias são reestimadas, e as estórias grandes são quebradas de acordo com a priorização do Product Owner. Dessa forma, as estórias com prioridade mais baixas podem ser estimadas com valores mais altos, e seu detalhamento pode ser postergado para quando se tornarem mais próximas de serem selecionadas para o sprint;

· Estimativas por horas devem ser feitas sem considerar as interrupções, ou seja, o tempo que efetivamente levaríamos para concluir a tarefa em um dia ideal;

· Estimativas por pontos é uma técnica muito boa para se estimar as estórias de usuário e não as tarefas, que usamos estimativas por horas em dias ideais (veja mais sobre estimativas por pontos aqui).

Existe um site bem interessante onde é possível jogar online o Planning Poker com sua equipe: planningpoker.com. Mas note que o poker real, com cartas de papel, é mais recomendável e geralmente mais ágil. Existem vários sites que fornecem as cartas para impressão, como: sprintplanning.com (para mais, deem uma olhada nas referências da Wikipedia).

Aqui tem uma explicação bem legal sobre como funciona a dinâmica do jogo: www.crisp.se/planningpoker

No entanto, a dificuldade em planejar não é desculpa para não fazê-lo. O planejamento reduz o risco, diminui a incerteza, ajuda na tomada de decisões, estabelece uma maior confiança e dissemina informações. Infelizmente, o planejamento tradicional não vem funcionando. Ao tentar combinar e responder às necessidades do trio escopo\cronograma\recursos, o planejamento tradicional não nos leva a respostas e produtos satisfatórios.

E por que o planejamento tradicional não funciona? Mike Cohn, em seu livro Agile Estimating and Planning, elenca 5 causas para as falhas de planejamento.

1. O planejamento é baseado nas tarefas necessárias e não nos recursos desejados.
   É vital o time manter o foco nos requisitos solicitados; são eles que agregam valor para o cliente (veja “Você entrega algo de valor para seu cliente?”). Tarefas por si só não agregam valor algum. Além disso, os planejamentos tradicionais, por basearem-se em tarefas, preocupam-se com a dependência entre elas. Assim, atrasos em qualquer tarefa acumulam-se no final do cronograma, pois são repassados pela cadeia de dependência.
2. Executar tarefas simultaneamente agora acaba gerando atrasos no futuro.
   Com a melhor das intenções, o time pode ver a multitarefa como uma possível solução para atrasos. No entanto, ao trabalhar em duas tarefas ao mesmo tempo, um membro do time provavelmente prorrogará o término das duas. Como outras tarefas dependem das primeiras (lembra do item anterior?), é quase certo que um atraso será embutido na cadeia de dependência, refletindo-se no prazo de entrega final.
3. Não se atende aos requisitos pela prioridade dos mesmos.
   O pensamento tradicional diz que, se todo trabalho é completado, não importa a ordem em que é feito. Nesse caso, é natural que a seqüência e priorização das tarefas siga a conveniência do time de desenvolvimento e não a importância dos requisitos para o cliente. Como conseqüência, é muito provável que no final do projeto, para manter o cronograma, o time acabe descartando requisitos importantes que não foram corretamente priorizados.
4. O planejamento antecipado sempre contém um certo grau de incerteza que é ignorado.
   O planejamento tradicional não considera as incertezas presentes em todo projeto de software. Ele assume que a análise inicial será completa e perfeita e que coletará todos os requisitos do produto. Assume também que os usuários não mudarão de idéia, que nenhuma necessidade nova aparecerá durante a execução do projeto e que sabemos exatamente como os requisitos serão  implementados. É claro que isso não é verdade; tudo o que não sabemos no início do projeto é uma incerteza que deve ser considerada no planejamento, e a melhor forma de lidar com as incertezas é através de iterações curtas com feedbacks rápidos e constantes.
5. Estimativas com alto nível de incertezas e baixa probabilidade de acerto acabam se tornando compromissos.
   Dentro de cada estimativa está embutida uma probabilidade do trabalho ser finalizado no tempo previsto. Uma probabilidade varia de 0 a 100%. Portanto, ao estimar a duração de uma tarefa estamos dizendo que existe uma probabilidade de x % de terminarmos a tarefa em y dias. O problema é que compromissos não podem ser assumidos sobre probabilidades; eles são assumidos sobre uma data.

O planejamento ágil ataca esses problemas focando nos requisitos. A unidade mínima de entrega é um requisito completo; não importa quantas tarefas foram terminadas, se um requisito não está completamente implementado, ele não está entregue. A priorização baseia-se nos requisitos de maior valor para o cliente e não nas tarefas do time de desenvolvimento. O time todo trabalha para entregar um requisito, por isso praticamente não existe multitarefa. O planejamento é incremental; assume-se que no início do projeto sabemos muito pouco sobre o que será feito e sobre como será feito. O time encontrará essas respostas gradativamente, conforme implementa requisito por requisito.

Parece utópico, mas funciona. Qualquer um que desenvolveu software sabe que nunca conseguimos levantar todos os requisitos necessários para um sistema, por maior que seja o esforço. Conheço uma pessoa que trabalha para uma grande empresa indiana que possui a famosa certificação CMM5. Há 2 anos ela realiza levantamento de requisitos para o sistema de um grande banco brasileiro. Dois longos anos de trabalho da equipe; nenhuma linha de código foi escrita, nenhum requisito foi entregue; somente algumas centenas de artefatos obrigatoriamente gerados pela especificação do CMM5. Claro, CMM5 garante qualidade, mesmo que a um custo altíssimo, certo? Mas qual a probabilidade dos requisitos levantados há dois anos ainda serem válidos? Será que ainda representam o que o cliente quer atualmente? Acho pouco provável.

E você, qual sua opinião?