Estimativa em projetos ágeis.

Como prometi post anterior, este post irá falar sobre estimativa em projetos ágeis. Já vi alguns projetos de software tradicionais(walterfall) morrerem na “ilusão da previsibilidade” (COHN, 2006) ao fazerem previsões com alto grau de detalhamento e não conseguir cumprir com o estimado. Essa ilusão de previsibilidade é uma armadilha muito perigosa e decorrente em projetos de software, se existe certeza é que alguma coisa mudará ao longo de um projeto. Projetos tradicionais realizam uma grande carga de trabalho, conhecida também por  big design up-front, visando obter uma estimativa de máxima e ainda assim as estimativas não são alcançadas.

Em projetos ágeis a coisa é bem diferente, as estimativas são tomadas realisticamente, não como verdades ou metas, mas como expressões da percepção atual sobre o projeto, a serem refinadas e revistas no decorrer do trabalho que é executado. Diferentemente de um projeto tradicional, as estimativas em projetos ágeis são feitas em grupo, tende-se a minimizar posições individuais que sejam demasiado otimistas ou pessimistas. As estimativas devem ser feitas por história, ou seja, por funcionalidades que sejam visíveis ao usuário e lhe gerem valor agregado e não é usado tempo para estimar, mas sim story points (ou simplesmente, pontos de esforço).

Cone da incertteza

Cone da incerteza

Na agilidade preza-se a transparência e assim assumimos que existe sim um cone da incerteza e que por alguns motivos o projeto terá sim variações. A NASA, agência espacial americana, trabalha no início dos seus projetos, com uma variação de 4 vezes para mais ou para menos. Significa dizer que, eles assumem o risco de um projeto estimado em 1 milhão de dólares custar 4 milhões ou 250 mil. E por que varia? Oras, porque é uma estimativa e não uma medida, simples assim. Claro que ao longo do projeto o time irá conhecendo melhor a tecnologia utilizada, a linguagem e principalmente o negócio. Com o passar do tempo e a maturidade chegando ao time, suas estimativas melhoram assim ficando mais previsível o término do projeto.

Pontos

O ponto é uma medida do tamanho ou esforço necessário à implementação de uma história. Não há uma fórmula exata para calcular os pontos, a estimativa sempre é baseada na experiência da equipe e na discussão realizada em grupo. Pontos não têm uma correspondência com uma medida concreta de esforço, eles são relativos uns aos outros dentro de um determinado projeto ou equipe. Um exemplo disso é que se você pedir a dois times para medirem o esforço de um conjunto com as mesmas histórias, sem um interferir no outro, o resultado pode ser o mesmo, porém o mais provável é que as histórias tenham esforços diferentes, o que não está errado, depende da percepção do time e da velocidade que ele assume que pode trabalhar. Ou seja, a definição de quanto esforço real está embutido em um ponto varia de projeto para projeto e/ou de equipe para equipe.

Estimativas em pontos são relativas entre si. No início do projeto, a equipe escolhe uma história e lhe atribui um valor em pontos, digamos, 2( não assumimos 1 ponto para a menor, pois conforme o trabalho é descoberto ao longo, podemos ver que há uma ou outra história menor que a inicial de 2 pontos). A partir daí, todas as histórias serão estimadas com base nesta: caso estime-se que uma história tem a metade do tamanho da primeira, ela terá 1 ponto. Se for estimada como tendo o dobro do tamanho, 4; 150% do tamanho, 3, e assim por diante.

Cohn (2006), cita duas estratégias comuns para escolher com qual história iniciar a estimativa, ou seja, como escolher a história que servirá de referencial para as demais. A primeira seria escolher aquela que se acredita ser a menor e lhe atribuir o valor 1; a segunda seria procurar uma história que tivesse um tamanho médio e lhe conferir o valor em pontos que se deseja ser também um valor médio. É muito comum que projetos estimem com uma quantidade de pontos que não seja muito maior do que 10, Já que estamos estimando e estimativa pode variar, assumimos que uma história de 3 pontos pode variar para 5, ou mesmo 2 pontos. Diferenças maiores que isto tornariam difícil estimar relativamente, pois é muito difícil afirmar que uma história é 20 vezes maior que outra (por que 20 e não 15 ou 25, por exemplo? Nesta escala, as estimativas são muito mais nebulosas). Algumas equipes escolhem valores específicos, sendo os mais comuns a sequência de dobros (1, 2, 4, 8) e os primeiros elementos da série de Fibonacci (1, 2, 3, 5 e 8). Quando as histórias se tornarem muito nebulosas é necessário dividi-las.

Divisão de histórias

Dividir histórias é algo necessário em algumas situações, costumamos dizer que uma história muito grande é na verdade um tema. Um bom momento para decidir entre dividir ou não um tema é quando se acredita que a implementação de uma história não caberá em uma iteração única, ou quando o tamanho da história dificulta a realização de estimativas. A principal consideração que se deve ter na divisão de histórias é evitar particionar em unidades que não se traduzem em valor agregado para o cliente do software. Ou seja, a divisão de uma história em outras não deve ser por tarefa técnica (design visual, levantamento de requisitos, programação, banco de dados etc.), mas sim uma divisão em que cada parte seja uma funcionalidade completa aos olhos dos clientes.

Planning poker

Um dos métodos de estimativa mais conhecidos e praticados em projetos ágeis é o planning poker. O planning poker é uma abordagem lúdica e que incentiva a participação e a colaboração, gerando estimativas de modo rápido na maioria dos casos, porém confiável.

Planning poker

Planning poker

Toda ao time de desenvolvimento participa do planning poker. No início do planning poker, cada estimador recebe um conjunto de cartas, com cada uma contendo o número de um dos valores válidos que a equipe definiu para as estimativas (por exemplo, 0, 1, 2, 3, 5, 8, 13, 21, 44…).

Cada história a ser estimada tem sua descrição lida por um moderador. O moderador normalmente é o product owner, embora nada impeça que seja qualquer outro. O product owner responde a qualquer dúvida que os estimadores eventualmente tenham, por isso melhor que ele seja o PO ou alguém próximo ao negócio. Após todas as questões serem respondidas, cada estimador seleciona uma carta contendo a sua estimativa. Nenhuma carta escolhida é mostrada até que todos os estimadores tenham selecionado a sua. Quando todos terminam, todos as cartas são colocados ao mesmo tempo sobre a mesa para que todos possam ver cada estimativa.

É comum e até mesmo desejável que as estimativas sejam bem diferentes, o que levará a que os membros da equipe com as estimativas mais extremas, para mais e para menos, expliquem à equipe suas posições. É importante que o espírito não seja de disputa ou ataques pessoais, mas sim de aprendizado mútuo. O grupo tem poucos minutos para discutir, após o qual cada estimador reestima com base nos argumentos fornecidos. Novamente, os cartas só são mostradas após todos reestimarem. A maioria das estimativas se resolve no segundo round; raramente alguma ultrapassa o terceiro. É importante que as discussões sejam realizadas dentro de tempos claramente estabelecidos. O estabelecimento de timeboxes rígidos é importante para que a discussão mantenha-se no foco. A regra geral não é precisão absoluta, que é impossível, mas bom senso.

O planning poker é uma estratégia que costuma trazer bons resultados principalmente porque permite que todos os membros da equipe contribuam, colaborativamente, para as estimativas, sem que para isto sejam necessárias longas e improdutivas reuniões. Isto, além da tendência a trazer estimativas de melhor qualidade, cria um sentimento de responsabilidade de todos com as estimativas, uma vez que as estimativas não são impostas por um pequeno grupo, mas geradas por todos. Além disto, o caráter lúdico do planning poker remove o aspecto burocrático que reuniões de planejamento costumam ter em alguns ambientes.

Tamanho das histórias também pode ser definido utilizando t-shirt sizesque é uma forma relativa de estimar as histórias comparando uma com as outras.

Outro jogo para estimar o tamanho das histórias é o “Team Estimation Game” que merece um post apenas para ele.

Abraços e até o próximo post!

Referências

COHN, M. Agile Estimating and Planning. New York: Addison-Wesley, 2006.

http://planningpoker.com/

4 pensamentos sobre “Estimativa em projetos ágeis.

  1. Pingback: Team Estimation Game – Porque usar! « Blog do Miguel Carlos

  2. Pingback: A ilusão da previsibilidade « Blog do Miguel Carlos

  3. Pingback: Estimativa não é aferição: Cuidado com com as Mães Dináh do Software. | Blog do Miguel Carlos

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s