Um Pouco Sobre Estimativa Ágil

Visualizado 1562 vezes.

Pensando na Estimativa Ágil

O principal ponto é pensarmos em um objetivo que desejamos atingir.
Quando começamos a planejar como atingiremos um objetivo, pensamos nas tarefas que precisamos completar e no que é necessário em termos de recursos – esforço, tempo, dinheiro. É importante frisar que a estimativa é a base de todos os projetos, seja ele, Ágil ou tradicional.
A confiabilidade de um cronograma está diretamente ligada às estimativas utilizadas para sua elaboração. Obviamente, que as estimativas não têm por objetivo serem 100% precisas, por isso chamam-se estimativas.

Métodos Diferentes?

Áreas diferentes possuem métodos diferentes de estimativa. Pegamos como exemplo o desenvolvimento de sistemas, um método denominado Análise de Pontos de Função é utilizado, algumas vezes, para estimar os módulos do software. Na construção, o método de estimativa de escolha é o Método de Quantidade Total e assim cada área tem a sua forma de medir as estimativas. Geralmente, o SCRUM usa StoryPoints como referência.

A Estimativa Relativa no SCRUM é feita por uma equipe que utiliza uma ou mais histórias de referência, com as quais trabalhou no passado e cujo esforço despendido e complexidade são conhecidos. Todas (ou quase todas) as novas histórias de usuário são estimadas em relação às histórias de referência.

Nesse processo de estimativa:

  1. o ProductOwner explica a história com informações e definições adicionais.
  2. todos os membros da equipe estimam a história relativamente.
  3. um consenso é alcançado.
Veja Também:  Cloud Computing - Algumas características

0 processo de estimativa fará mais sentido à medida que formos abordando os outros demais conceitos de estimativas SCRUM.

O que é Estimativa Participativa?

É importante falar sobre esse tipo de estimativa. No livro A sabedoria das multidões, James Surowiecki citou uma história em que uma multidão, em uma feira agrícola, estimou o peso de um boi. Calculou-se a média dos palpites individuais, que chegou mais próxima do peso real do boi do que as estimativas individuais da maioria dos integrantes da multidão e as estimativas separadas, feitas por especialistas de gado. Tenha isso em mente.

Mesmo a equipe SCRUM sendo menor do que muitos considerariam uma multidão, o conceito é exatamente o mesmo utilizado no parágrafo anterior. Devemos usar a sabedoria coletiva da equipe para fazer a estimativa. E se pararmos para pensar, esse conceito é bem diferente do conceito de estimativa tradicional.

Entenda que ao estimar módulos de um software, por exemplo, uma pessoa com credencial de Especialista Certificado em Pontos de Função (CFPS) vai desenvolver estimativas de software quase que independentemente.

Utilizando o SCRUM é diferente. As pessoas não estimam softwares “aleatoriamente”. Uma abordagem típica de estimativas coletivas ou participativas é o “poker planning”.

Poker Planning

O poker planning começa com todos os integrantes de uma equipe SCRUM segurando uma série de cartas. Essas cartas têm números escritos, geralmente seguindo a sequência Fibonacci. Depois que o Product Owner explica a história de usuário que está sendo estimada, a equipe faz perguntas até que a definição da história esteja clara. Um membro da equipe designado pode registrar decisões relativas às definições.

Veja Também:  Geometria Computacional - Algoritmo de Cyrus-Beck

Uma vez que a equipe compreendeu, completamente, a intenção da história, deve escolher, em alguns minutos, a carta que representa os Story Points para a história em questão. A equipe mantém a carta sobre a mesa, virada para baixo. O moderador costuma ser o SCRUM Master.

Quando o moderador indicar, todos os integrantes da equipe mostram suas cartas. Se um ou mais integrantes chegaram a um número muito baixo ou muito alto, têm a chance de explicar seu raciocínio.

O jogo de cartas continua até que os integrantes da equipe cheguem a um consenso sobre a estimativa mais adequada, não necessariamente exata, para a história. Esse processo não só gera as estimativas, mas, a partir da discussão e da colaboração, pode levar a um melhor entendimento comum e a uma apropriação da iteração.

Ernst Weber e Gustav Fechner levantaram, no século XIX,  a hipótese de que a percepção humana da intensidade, a exemplo do som e da luz, é mais proporcional, aproximadamente, ao logaritmo da intensidade do que da intensidade em si. O mesmo princípio é empregado quando a série de Fibonacci é utilizada para enumerar as cartas usadas no Planejamento de Pôquer. É um texto complexo porém a utilização das cartas é simples.

Veja Também:  Instalação do Gpg4Win

Estimativa Ágil Usando Série de Fibonacci

350px-Poker_fibonacci

Pensemos no esquema gráfico visto na seção anterior. As cartas levam os números 1, 2, 3, 5, 8, 13, 21, ….

Cada número é a soma dos dois números anteriores. Em alguns casos, os números são arredondados, para cima ou para baixo, para o 5 ou 0 10 mais próximo. Frequentemente um 0 e um 1/2 também são adicionados. 0 (zero) representa uma história que não exige nenhum esforço apreciável para desenvolver. Por exemplo, uma outra história, já sendo concluída, finalizará essa história.

Geralmente, o ponto de interrogação é usado para indicar que um integrante da equipe não tem conhecimento suficiente da história para estimá-la e, e assim, necessita de mais discussão e maior detalhamento da história.

O símbolo do infinito é usado para indicar que uma história é grande demais para ser estimada, ou um épico, precisa ser dividida em histórias menores.

Veja que equipes SCRUM diferentes desenvolvem métodos, protocolos, processos e cartas diferentes, que funcionam melhor para cada equipe. Ou seja, o objetivo é fazer a estimativa relativa e participativa usando uma escala não linear, como a sequência de Fibonacci.

No próximo artigo falarei sobre Gráficos Burndonw. Espero que tenham gostado deste artigo.


Valeu um café? Contribua com R$ 3,00 e ajude a manter o site no ar.



Visualizado 1562 vezes.

Deixe uma resposta