Tudo o que você sempre quis saber sobre estimativas, mas tinha vergonha de perguntar

(imagem: Serious Scrum)

Se você chegou neste texto por curiosidade, devido ao título sensacionalista, saiba que não teremos aqui nenhuma literatura que se auto-intitule “definitiva” sobre estimativas. A intenção é mostrar quais são as diversas maneiras com que os profissionais tratam esse tema, que ainda traz muita discussão e variadas linhas de pensamento.

Significado de Estimativa: substantivo feminino. Cálculo de valor aproximado; avaliação aproximada que se realiza sobre alguma coisa: estimativa de prejuízos. Avaliação sobre alguém ou sobre alguma circunstância, baseando-se nas evidências ou nos fatos disponíveis; conjectura. Etimologia (origem da palavra estimativa). (Fonte: dicio.com.br)

Importante observar, no significado da palavra estimativa, o adjetivo aproximado, que sugere aproximar-se, próximo. Então só pela etimologia da palavra se é reforçado que a estimativa não está na esfera do comprometimento ou da certeza, mas sim mais próxima da “abstração” (achismo).

Recentemente fiz uma enquete no meu perfil do LinkedIn sobre quais são as estimativas que os colegas têm mais usado, e, de certa forma, me comprometi em elaborar algum material que os ajudasse, pelo menos, a entender o básico para o entendimento e uso (ou não) de estimativas.

Contextualizando

 O cone da incerteza

No gerenciamento de projetos, o cone da incerteza descreve a evolução da quantidade de incerteza do melhor caso durante um projeto (Construx nd). No início dele, comparativamente, pouco se sabe sobre o produto ou os resultados do trabalho e, portanto, as estimativas estão sujeitas a uma grande incógnita.

À medida que mais pesquisa e desenvolvimento são feitos, mais informações sobre o projeto são aprendidas e a incerteza tende a diminuir, chegando a 0% quando todo o risco residual é encerrado ou transferido. Isso geralmente acontece no final do projeto, ou seja, transferindo as responsabilidades para um grupo de manutenção separado.

O termo cone de incerteza é usado no desenvolvimento de software onde os ambientes técnicos e de negócios mudam muito rapidamente. (fonte: Wikipedia)

(image: construx.com)

Estimativas Absolutas x Estimativas Relativas

(image: Google)

Muitas vezes, estimar parece um trabalho de cartomante, mago ou qualquer outro ser que trabalhe com entidades desconhecidas. E aqui vamos contextualizar o entendimento quanto ao jeito “certo” em que as estimativas devem ser tratadas (se não for possível vencê-las, pelo menos faça do jeito mais aceitável).

Uma hora alguém te pergunta: “Quando vai ficar pronto?”, e é humanamente impossível acertar na mosca o tempo exato que será empregado no desenvolvimento de um produto/software. Isso vai de encontro ao que se espera de resultados empíricos, baseado nas experiências vividas e observação das coisas.

Entendendo a dinâmica do trabalho do conhecimento, trabalhar com as estimativas relativas faz mais sentido.

Estimativas Absolutas: Quando tratamos de software, essas estimativas não conseguem prever fatores que possam causar impacto no processo de desenvolvimento. Elas tentam trabalhar dentro de um alto nível de incerteza, olhando especificamente para um único item, sem levar em consideração outros fatores. Mas em contrapartida, existe a alta tentativa de cravar o tempo que levará. Mudanças de membros do time, senioridade, riscos, são de certa forma negligenciados, já que qualquer um desses fatores mexem com as estimativas iniciais.

Estimativas Relativas: Ao estimar relativamente, o tempo inicial não importa, e sim o tamanho e a complexidade.Não há preocupação com a precisão das estimativas, mas a consistência entre elas. Possíveis mudanças no time não influenciarão nas estimativas previamente definidas, já que o tamanho dos itens continuarão os mesmos. É comum trabalhar junto a elas métricas como velocidade e capacidade, trazendo às estimativas modelos mais tangíveis, atrelando o comprometimento do time quanto a entregas.

A enquete

Como dito anteriormente, a ideia de criar a enquete no Linkedin derivou-se das dúvidas que chegavam em conversas com amigos e mentorandos quanto à estimativas. Essas dúvidas surgiam principalmente de quem estava trabalhando com times novos e sem histórico de uso de métricas ou previsibilidade. Essas pessoas me perguntavam sobre qual seria a melhor maneira de estimar.

Como opções de voto, trouxe as estimativas mais conhecidas (e praticadas) pelos respondentes: Fibonacci, No Estimates e T-Shirt Size. A alternativa Carneirinhos poderia ter sido perfeitamente nomeada como Ornitorrinco, ou qualquer outra coisa que promete fazer tudo mas acaba só trazendo disfunções.

E não é que a “Carneirinhos” ganhou uns votos?!? 😀

Fibonacci

É uma sequência numérica utilizada em diversas áreas. No mercado financeiro, é utilizada na análise de tendência, traçando projeções e retrações. Fibonacci é, na matemática, uma sequência em que o número seguinte corresponde à soma dos dois anteriores.

(image: Google)

No contexto de agilidade em equipes que fazem uso do framework Scrum, a sequência é usada em conjunto com a prática do Story Points e usando a dinâmica de Planning Poker, onde os times pontuam os itens que farão parte de uma sprint.

(image: Google)

Partimos do princípio que tenhamos escolhido unidades de medidas que irão nortear as discussões sobre como estimar a complexidade do trabalho.

Durante a enquete, um amigo relatou ter encontrado no dia-a-dia a Fibohoras, forma bem-humorada de lidar com uma disfunção comum do mercado (ou talvez, vão chamar de adaptação).

Vantagens:

• Descentralização das decisões baseadas em senioridade;
• Toda opinião é bem-vinda;
• Buscar o conhecimento da capacidade do time;
• Engajamento, senso de pertencimento.

Desvantagens:

• Desconhecimento do produto pode tornar a estimativa bastante variável e, algumas vezes, fora da realidade quanto a complexidade;
• Muitas vezes se conhece riscos dentro das sprints que “inutilizam” as estimativas;

Experiências:

Em contextos onde atuei com essa estimativa, os times que obtiveram sucesso foram aqueles que tiveram disciplina em inspecionar e adaptar como estavam realizando essa prática. Muito impulsionados por um “ambiente seguro” de experimentação e aberto ao novo processo.
Em outros casos, times que estavam em ambientes de mais alta pressão, que não ligavam muito para o empirismo da coisa, a prática de estimar depois de um tempo beira a frustração.

No Estimates

(image: Google)

O movimento #NoEstimates é visto como uma ideologia baseada em tretas! 😀
Brincadeiras à parte, o movimento tenta focar no que realmente é importante, defende que estimar é uma grande perda de tempo em detrimento ao que deve ser feito.

O #NoEstimates traz três questionamentos como sugestão para aqueles que insistem em estimar, são eles:

1. Por que estamos estimando?
2. Qual problema que estamos tentando resolver com a estimativa?
3. Qual é a próxima coisa importante que nós queremos aprender?

 Entregamos valor mais rápido se não dedicarmos tanto esforço tentando acertar em quanto tempo uma solução será desenvolvida ou entregue? Importante trazermos a discussão, de que até quando você é adepto do #NoEstimates de alguma forma você estima, mesmo que seja entendendo o tamanho dos itens que você defende que não seja necessário estimar.

(image: Google)

Outros fatores nos trazem a reflexão de que apresentar uma ideologia como a #NoEstimates sem que seja amparada em previsibilidade, métricas ou outros ferramentais que saciem a ânsia implícita pela resposta da fatídica pergunta: “quando vai ficar pronto?”

Vantagens:

• Foco no que importa;
• Voltada a entrega constante de valor.

Desvantagens:

• Em ambientes com alto teor de microgerenciamento, se não bem embasado, a intenção pode ser interpretada como “anarquia”.

Experiências:

Ainda não trabalhei em ambientes que me dessem a oportunidade de experimentar tal “ideologia”, mas muito me agrada pensar que um dia possa experimentar.

T-Shirt Size

Essa é a que mais indico para times que estão iniciando com estimativas. Acreditando que trazer Fibonacci para o início dos trabalhos possa apresentar alguma dificuldade no exercício de pensar em complexidade x esforço x risco.

(image: Google)

Posso de alguma maneira estar errado, mas vejo com uma outra forma de estimar com Fibonacci. Só que com ela há uma forma mais “lúdica” de entender qual é o tamanho do item que está sendo planejado.

Abaixo, você vê como o time pode direcionar as suas medidas, sempre lembrando que é possível optar por usar aquilo que é aderente ao seu contexto. Eu já trabalhei com equipes que abriram mão de ter as medidas PP e XGG, por exemplo. Escolha então, o que faz mais sentido para vocês.

(image: Google)

Um grande amigo que impulsionou a enquete, e que creio que irá tirar boas impressões desse artigo, teve em seu contexto a necessidade de estimar os pontos em horas, o contexto dele pedia isso…

A minha sugestão foi criar algo assim:

PP – Realizável em menos de 1 hora;

P – 2 horas;

M – 4 horas;

G – 7 horas (levando em consideração uma porcentagem de slack no trabalho conhecimento);

GG – Mais de um dia para trabalhar no item ou item ainda muito “nebuloso”, de preferência, voltar para o backlog do produto para ser refinado.

A dica que serviu para o contexto desse amigo, pode não fazer sentido para o seu, e vida que segue!

(image: imagem: https: //www.slideshare.net/agiledad/agile-estimating-planning)

 Vantagens:

• Técnica informal;
• Fácil relação com exemplos reais;

Desvantagens:

• Repito a mesma desvantagem no uso do Fibonacci “puro”, conhecer riscos dentro das sprints que possam inutilizar as estimativas;

Experiências:

Técnica de fácil assimilação e uso rápido, sempre levando em consideração os contextos para a melhor aplicabilidade.

Conclusão

Talvez eu tenha trazido ainda mais dúvidas do que antes, mas espero realmente que tenha abordado boas reflexões, como: por que meu time estima? Quais problemas vou resolver estimando? Quais são os aprendizados que temos estimado?

Tudo isso sem abandonar a análise do seu contexto, pode ser que tudo que eu falei aqui você considere “falácia para acalentar bovino”, não tinha como objetivo trazer conceitos ou “receitas de bolo” mas o que tenho experimentado pelas equipes em que passei.

Portanto, entenda o seu momento e aplique aquilo que rapidamente entrega valor ao cliente e ganhos de “ownership” da equipe. Até a próxima!