Processo de Estimativa de Software

Um dos pontos críticos no processo de desenvolvimento de software sem dúvidas é conseguir medir com precisão o esforço da equipe para o desenvolvimento de demandas de um produto de software.

Existem várias técnicas que prometem resolver esse problema crítico, mas nenhuma até hoje conseguiu chegar a um nível de acerto de 100% na estimativa. Isso ocorre porque o fator humano está em jogo e todos sabemos que esse fator é imprevisível.

A abordagem que será utilizada aqui para a medição da força de trabalho para tarefas e demandas de um produto de software desenvolvido pela Eagle será Story Points.

Story Points

É uma unidade subjetiva de estimativa utilizada por times ágeis para estimar uma estória de usuário, ou seja, uma demanda fornecida por um usuário é considerada uma estória e essa estória será classificada por um número que identificará a sua complexidade no desenvolvimento, representando assim a quantidade de esforço requerido para implementá-la.

Por que estimar com Story Points e não por unidade de tempo?

Pontos de Estória são baseados em medidas relativas, por comparação de uma Estória contra uma Estória padrão previamente estimada. Medidas relativas tendem a ser mais assertivas em grandes amostragens, em comparação com a tentativa de se estimar isoladamente cada item (Estória).

Como uma analogia, é mais fácil dizer que a distância entre BH e Governador Valadares é três vezes maior do que a distância entre BH e Sete Lagoas, do que dizer que a distância entre BH e Governador Valadares é de 321km.

Times estimarão mais rapidamente se não tiverem de analisar e acertar o exato número de horas/dias necessários para concluir uma atividade.

Classificação das Story Points

Story Points são classificadas seguindo a sequência inicial de Fibonacci: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40 e 100. Cada um desses números são equivalentes a uma pontuação de complexidade de uma demanda/estória do usuário. Ainda em adição a essa sequência temos o símbolo ? para identificar quando ainda existem dúvidas e não se consegue pontuar.

Para a estimação de demandas/estórias, será utilizado a sequência abordado na biografia de SUTHERLAND que utiliza a seguinte sequência de pontuação: 1, 2, 3, 5, 8, 13.

Para que a complexidade seja aplicada aos pontos, devemos escolher uma estória/demanda padrão como elemento relacional. Utilizaremos duas estratégias para escolher qual estória será utilizada como padrão na comparação com as demais estórias:

• A primeira seria a escolha daquela que se acredita ser a menor estória e lhe atribuir o valor 1;
• A segunda seria escolher uma estória com tamanho médio e lhe atribuir um valor entre 3 e 8 inclusive;

Lembrando que a escolha do valor (ponto) para uma estória, deve levar em consideração o esforço necessário para se finalizar esta estória em comparação com o esforço necessário para se finalizar a estória padrão. Por exemplo, se utilizarmos a Estória Cadastrar Endereço como padrão e atribuirmos o valor 1, poderíamos estimar que a Estória Cadastrar Empresa possuirá valor 3, pois seu tamanho é um pouco maior do que duas vezes o tamanho da estória padrão.

Quando realizar as estimativas

As estimativas são realizadas durante a reunião de planejamento do sprint. A equipe definirá as estórias que serão estimadas/pontuadas através de Story Point, baseado na priorização previamente mapeada pelo Product Owner (PO).

Como realizar as estimativas

A realização da estimativa de cada demanda/estória acontecerá através de rodadas de Planning Poker, no qual consiste de um baralho com os 6 números da sequência de Fibonacci mais o símbolo ? que cada membro da equipe portará.

Planning Poker

Passos

• Escolha das demandas/estórias que serão usadas como padrão;
• Escolhe-se uma demanda/estória por vez para ser avaliada;
• Cada integrante do grupo separa a carta que considera corresponder à quantidade de esforço exigida por aquela tarefa e coloca virada para baixo na mesa;
• Em seguida, todo mundo vira sua carta ao mesmo tempo. Se as opiniões de todos estiverem a uma distância de até duas cartas umas das outras (digamos, há um 5, dois 8 e um 13), a equipe apenas soma esses números, tira a média (neste caso 6,6) e atribui o ponto da sequência mais próximo da média, neste caso o 5 e passa para a próxima demanda;
• Caso as cartas escolhidas estiverem a uma distância de mais três números presentes na sequência, quem selecionou a mais alta e a mais baixa explica seu raciocínio e depois todo mundo faz outra rodada para aquela demanda;

É fundamental que as rodadas do Planning Poker sejam feitas pela equipe que executará o trabalho, e não por quaisquer avaliadores ou especialistas externos.

Conclusão

Todo esse processo além de deixar os devs mais tranquilos em relação a prazo, também cria experiências que poderão ser aplicadas no futuro, pois cada demanda desenvolvida poderá ser usada como referência para pontuar demandas posteriores, aumentando assim a assertividade.

Depois de aplicado esse processo na Eagle Tecnologia, conseguimos prever com mais precisão quanto tempo levaria para desenvolver uma determinada demanda já levando em consideração possíveis imprevistos. Isso aumentou consideravelmente o comprimento de prazos em versões lançadas.