Planning Poker: uma forma divertida mas séria de se estimar projetos ágeis.

Planning Poker: uma forma divertida mas séria de se estimar projetos ágeis

Figura 1 - Planning Poker.

Com a popularização das metodologias ágeis (SCRUM, XP, FDD, CRISTAL), veio também a necessidade de estimar a complexidade e o tempo das tarefas. Mas como seria possível estimá-los em um grupo que utiliza metodologias ágeis, onde geralmente existem uma quantidade menor de artefatos documentais que burocratizam o processo de desenvolvimento?

Foi pensado nestas questões que James Grenning criou o Planning Poker, em 2002, e que mais tarde foi popularizado por Mike Cohn no livro Agile Estimating and Planning no qual registrou o termo.

O Planning Poker consiste em obter uma estimativa média do custo de tempo e complexidade das tarefas por meio de um jogo de cartas. Todos os integrantes da equipe de desenvolvimento (programadores, testadores, analistas, designs) devem participar. Cada integrante dará a sua percepção de tempo e complexidade para a conclusão de uma tarefa, as opiniões são então comparadas e analisadas até que se chegue a um consenso.

O jogo de cartas

Para se estimar quanto uma tarefa pode custar em termos de tempo e esforço para serem concluídas, cada participante deve dar a sua opinião através de cartas que possuem números ou símbolos escritos nelas. Veja a figura 2 que mostra um exemplo de baralho do Planning Poker.

Figura 2 - Exemplo de baralho de Planning Poker.

Quanto maior o número, mais complexa é a tarefa para quem lançou aquela carta. Geralmente os valores numéricos são definidos seguindo a sequência Fibonacci (0, 1, 2, 3, 5, 8, 13, 20, 40, 100), mas isso fica a critério da equipe. Da mesma forma os símbolos podem ser escolhidos pela equipe, onde devem representar algum significado para auxiliar na predição do esforço. Vamos descrever os significados mais complexos das cartas do jogo:

- Interrogação: é usado quando o seu proprietário não sabe opinar sobre o custo necessário para aquela tarefa.

- Zero: significa que esta tarefa é absolutamente desnecessária e deve ser descartada.

- 1/2 (meio): significa que esta tarefa é extremamente fácil de ser implementada. 

- Infinito: é utilizado quando a tarefa demonstra ter um nível de complexidade muito alto ou até seja impossível de ser concluída.

- Chicara de café: usado quando o o proprietário não entende o objetivo da tarefa e necessita de melhor compreensão da mesma, quando esta carta é jogada uma pausa deve ser feita. Esta pausa é muito importante e deve ser respeitada, os integrantes da equipe não podem fazer o uso excessivo desta carta. 

Lembrando que cada componente deve possuir um baralho próprio e que todos precisam ter os mesmos valores e símbolos.

A sequência Fibonacci

Figura 3 - Gráfico da função Fibonacci.

 Agora que sabemos como são organizadas as cartas do Planning Poker você pode está se perguntando o porque do uso da sequência Fibonacci. Esta sequência é obtida ao somar os dois números antecessores, o resultado irá compor a próxima soma  e assim segue infinitamente, a sequência inicia com os dois valores 0 e 1. A medida que os valores são obtidos, o gráfico cresce indefinidamente o que ajuda na comparação dos valores. Por exemplo, se em uma rodada são jogadas as seguintes cartas: 5, 8 e 13 , desta forma demonstrará o nível de incerteza do grupo com mais força, onde de 5 para 8 existe a diferença de 3, de 8 para 13 existe uma diferença de 5, já de 5 para 13 existe uma diferença de 8. Isto força a discussão entre os envolvidos para chegarem em um consenso. 

Como o Planning Poker é jogado

Definidos os principais conceitos, é hora do Planning Poker ser executado. Toda a equipe participa, inclusive o cliente, mas somente os que vão criar o produto é que podem jogar as cartas. Deve existir um facilitador (uma pessoa neutra) e um cliente (que explica os detalhes das tarefas ou stories). Uma boa técnica para estimar é utilizar pontuações de tarefas passadas, escolhe - se a menor pontuação para ser usada como uma base para tarefas menores. As tarefas são avaliadas segundo as que são consideradas mais fáceis até as chegar as mais difíceis. 

Ao começar a primeira rodada, o cliente conta uma "história" de como deve ser o produto que ele deseja, logo em seguida, o facilitador irá  pedir que joguem as cartas. Depois são analisadas as pontuações. São analisadas as maiores discrepâncias entre os valores, o dono da carta que tiver o maior valor é então questionado, e mais uma vez, as cartas são jogadas até que todas as cartas sejam iguais, ou seja, até que todos entrem em um consenso.

Conclusão

  Como foi discutido neste texto o Planning Poker mostra-se uma ótima técnica "democrática" para estimação de tarefas. Os seus ganhos vão desde melhor entrosamento da equipe e melhor compreensão das suas atividades até o melhor controle por meio dos seus gestores. Os pontos dos cartões ainda podem ser mapeados à custos em dias, esforço ou horas/homem, estas métricas podem ser facilmente definidas pela equipe.

Fonte:

www.culturaagil.com.br/planning-poker-tecnica-baseada-consenso/

www.devmedia.com.br/scrum-e-planning-poker-analise-de-estimativa-de-software/31019

www.slideshare.net/JamesGrenning/beyond-planning-poker-agile-2011

www.metodoagil.com/planning-poker/#fibonacci

Extreme Programming: conceitos e valores.

A Programação Extrema, ou simplesmente o XP, é uma metodologia ágil cujo foco está no desenvolvimento de software com requisitos vagos e em constante mudança. É adota a estratégia de constante acompanhamento e realização de vários ajustes durante o desenvolvimento de software. O XP foi criado em 1997 por Kent Beck e tornou-se notório após a OOPLSA 2000 (Conferência de Programação Orientada a Objetos, Sistemas, Liguagens e Aplicações).

O objetivo do XP é otimizar o uso das boas práticas na engenharia de software. Entre elas podemos citar o teste, visto que procurar defeitos é perda de tempo, nós temos que constantemente testar. Entre outras práticas, o XP diz que:

• Já que testar é bom, que todos testem o tempo todo;
• Já que revisão é bom, que se revise o tempo todo;
• Se projetar é bom, então refatorar o tempo todo;
• Se teste de integração é bom, então que se integre o tempo todo;
• Se simplicidade é bom, desenvolva uma solução não apenas que funcione, mas que seja a mais simples possível;
• Se iterações curtas é bom, então mantenha-as realmente curtas;

O XP já foi utilizado por grandes empresas como a Chrysler no seu sistema de folha de pagamento global que envolvia seus 90 mil empregados ao redor de todo o mundo. Esse projeto tem 2.000 classes e 30.000 métodos, e foi para produção sem nenhum atraso.

As práticas da Programação Extrema são fundamentadas nos seguintes valores:

1.      Comunicação: segundo Beck “Os problemas nos projetos invariavelmente recaem sobre alguém não falando com alguém sobre algo importante”. Assim, a comunicação enfatiza que devemos sempre estar se comunicando seja entre desenvolvedores ou com os clientes. O XP é organizado em práticas que não podem ocorrer se não houver comunicação. Para um projeto de sucesso é necessária muita interação entre os membros da equipe, programadores, cliente, treinador. O time precisa ter muita qualidade nos canais de comunicação, sendo conversas cara-a-cara uma das melhores formas, mas também são utilizados telefonemas ou e-mails.

2.      Feedback: quanto antes, melhor. Para sabermos se estamos fazendo a coisa correta, precisa ser concreto perguntando diretamente ao código e precisa ser constante através de iterações curtas, incrementos e releases. Aqui garantimos constantemente junto ao cliente se estamos fazendo certo e se o prazo está de acordo com o planejamento. As respostas às decisões tomadas devem ser rápidas e visíveis. Os envolvidos precisam estar cintes do que está acontecendo. E os clientes devem se manter próximos dos desenvolvedores, para sempre que necessário passar informações sobre qualquer dúvidas ao longo do projeto.

3.      Coragem: muitas vezes não fazemos as coisas porque não temos coragem de fazer as mudanças. XP diz que devemos ter coragem de sempre colocar o cliente a par do que está acontecendo. Porém, em equipes XP consideram que errar é algo natural, e que quebrar eventualmente o que já estava funcionando pode ocorrer, por isso, é necessário ter a devida coragem para lidar com esse tipo de risco, as práticas do XP são voltadas para proteger o software das mais variadas formas, e as equipes confiam nessas práticas, o que os tornam adeptos as mudanças quando necessário, em vez de impedir as ideias do cliente e evitar mudanças.

4.      Simplicidade: para atender rapidamente às necessidades do cliente, quase sempre um dos valores mais importantes é simplicidade. Normalmente o que o cliente quer é muito mais simples do que aquilo que os programadores constroem. O XP se empenha em assegurar que a equipe se concentre em desenvolver primeiramente o que é realmente necessário, em vez de rechear o projeto com várias funcionalidades que o cliente um dia possa a vir utilizar.

5.      Respeito: é o valor mais básico de todos, é o que dá sustentação aos demais. Todos têm sua importância dentro da equipe e devem ser respeitados e valorizados. Isso ajuda a garantir que o projeto seja bem-sucedido. A falta do respeito dentro de um projeto, pode ser o suficiente para que o mesmo enfrente muitos problemas, causando até a impossibilidade de sua continuação.

A ao contrário do que se acredita, o XP pode ser aplicada em projetos de vários portes, pois seu dinamismo é tão latente, que permite seu uso por equipes criativas em qualquer projeto.

A metodologia Extreme Programming é dinâmica e flexível, porém é necessária muita disciplina para usá-la em um projeto. Para demonstrar isso, será apresentado uma postagem com o conjunto sugerido de "boas práticas". 

Fonte: https://www.devmedia.com.br/praticas-em-xp-extreme-programming/29330

http://blog.locaweb.com.br/artigos/metodologias-ageis/programacao-extrema-extreme-programming-ou-simplesmente-xp/

http://www.redspark.io/metodologias-parte-2-xp-extreme-programming/

Os doze princípios do Manifesto Ágil

A cada dia que passa, vem se tornando cada vez mais comum as metodologias ágeis, entretanto a grande maioria delas não cumprem com todos os requisitos para serem consideradas metologias ágeis. 

Pouco se sabe da existência de um Manifesto que aborda os princípios de toda essa ideia de gerenciamento ágil de projetos. Para aqueles que ainda não conhecem, existe os 12 Princípios do Manifesto Ágil, são eles:

• 1- Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.

• 2- Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.

• 3- Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.

• 4- Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.

• 5- Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.

• 6- O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.

• 7- Software funcional é a medida primária de progresso.

• 8- Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.

• 9- Contínua atenção à excelência técnica e bom design, aumenta a agilidade.

• 10- Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.

• 11- As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.

• 12- Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

Fonte: http://www.manifestoagil.com.br