Tudo que você sempre quis saber sobre estimativas, mas tinha vergonha de perguntar…
Se você chegou aqui nesse texto por curiosidade devido ao título sensacionalista, saiba que não teremos aqui nenhuma literatura que se auto-intitule “definitiva” sobre o assunto. A intenção aqui é mostrar quais 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). (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ça 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 estimativas os colegas têm mais usado, e de certa forma me comprometi em elaborar algum material que ajudasse pelo menos a entender qual seria algo 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 de um projeto, comparativamente, pouco se sabe sobre o produto ou os resultados do trabalho e, portanto, as estimativas estão sujeitas a grande incerteza.
À 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)
Estimativas Absolutas x Estimativas Relativas
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 deveriam 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, 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. Essas estimativas tentam trabalhar dentro de alto nível de incerteza, olhando especificamente para um único item sem levar em consideração outros fatores. Mas em contrapartida, existe 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 desses fatores mexem com as estimativas iniciais.
Estimativas Relativas: Ao estimar relativamente, o tempo inicialmente não importa, tamanho e complexidade é o que vai importar.
Não há preocupação com a precisão das estimativas, mas a consistência entre as estimativas. 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 essas estimativas métricas como velocidade e capacidade, trazendo as estimativas modelos mais tangíveis e atrelando o comprometimento do time quanto a entregas.
A enquete
Como dito anteriormente, a ideia da enquete derivou-se das dúvidas que chegavam em conversa com alguns amigos e mentorandos quanto a estimativas, principalmente, trabalhando com times novos e sem histórico de uso de métricas ou previsibilidade, que 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. (o Carneirinhos poderia ter sido perfeitamente nomeado como Ornitorrinco, ou qualquer outra coisa que promete fazer tudo mas acaba só trazendo disfunções.)
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 cada número seguinte corresponde à soma dos dois anteriores.
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.
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 & adaptar como estavam realizando essa prática. Muito impulsionados de 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
O movimento #NoEstimates é visto como um ideologia baseada em tretas! :D
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:
- Por que estamos estimando?
- Qual problema que estamos tentando resolver com a estimativa?
- Qual é a próxima coisa importante que nós queremos aprender?
Entregamos valor mais rápido se não despendermos tanto esforço tentando acertar em quanto tempo uma solução será desenvolvida ou entregue? Importante trazermos a discussão até mesmo o fato 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.
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 desse a oportunidade de experimentar tal “ideologia”, mas muito me agrada pensar que um dia possa experimentar.
T-Shirt Size
A estimativa T-Shirt Size é a que mais indico para times que estão iniciando com estimativas. Acreditando que trazer Fibonacci para início dos trabalhos possa trazer alguma dificuldade no exercício de pensar em complexidade x esforço x risco.
Posso de algum maneira estar errado mas é uma outra maneira de estimar com Fibonacci, mas deixando mais “lúdico” a maneira de entender qual o tamanho do item que está sendo planejado.
Abaixo você vê como o time pode direcionar suas medidas, sempre lembrando que você pode 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 sentido para vocês.
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.
Dica que serviu para o contexto desse amigo, pode não fazer sentido para o seu, e vida que segue!
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 te trazido ainda mais dúvidas do que antes, mas espero realmente que tenha trazido boas reflexões, como: porque meu time estima?, que problemas resolvo estimando?, quais os aprendizados que temos estimando?
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 seu momento e aplique aquilo que mais rápido entrega valor ao cliente e ganhos de “ownership” da equipe. Até a próxima! 😉
