Estimativa de software: finalidades, público-alvo e agilidade

O conteúdo desse artigo foi baseado em experiências e no curso de Estimates in Agile software development por Nicolae Andronic. 

Estimar execução de tarefas de desenvolvimento de software é planejar aproximadamente o tempo que será gasto para finalizar a tarefa. O tempo estimado não é exatamente o tempo real gasto, mas deve ser aproximado. Muitos fatores influenciam no resultado da estimativa, como:

• Conhecimento sobre o contexto e sobre o que deve ser feito
• Interferências internas e externas
• Maturidade do time entre outros.  

Quanto maior a incerteza maior é a estimativa, podemos visualizar essa colocação por meio do cone de incertezas. 

O cone descreve a incerteza ao longo da vida do projeto. No início, pouco se sabe e a incerteza é grande. À medida que progredimos no projeto, aprendemos e a incerteza diminui. Antes do inicio do projeto a incerteza sobre tempo e custo pode variar de 4 vezes até ¼ do inicialmente estimado. 

Qual a importância de estimar?

É importante para gerar insumo para a gestão tomar as decisões estratégicas visando atingir o objetivo. A tarefa de estimar se estende a todo o time de desenvolvimento, desenvolvedores, QAs e analistas.   

Atualmente existem várias técnicas de estimativa de desenvolvimento de software, porém as técnicas entregam estimativas para finalidades e púbicos diferentes.

Esse artigo reúne as principais técnicas de estimativa de software em modelo ágil e o intuito não é explicar como utilizar as técnicas, mas sim dizer quais delas podemos utilizar para qual finalidade e público-alvo. 

 

1- Estimativas iniciais 

A princípio temos estimativa top down e bottom up.  

Top down

É utilizada para estimar o projeto como um todo. Costuma ser estimada por POs, stakeholdes, área de negócio e gestores para verificar a viabilidade. Tem menor assertividade e é baseada em experiências passadas, projetos similares e dados disponíveis.  

Bottom up

É utilizada para dar mais assertividade às estimativas top down, costuma ser estimada pelo time de desenvolvimento. Tem maior assertividade e é estimada a menor tarefa, posteriormente as tarefas estimadas são totalizadas para apresentar o total estimado do projeto. 

Na fase inicial do projeto podem ser utilizadas técnicas com a finalidade de definir a viabilidade e custo do projeto, entregando estimativas com medidas como: dias, semanas, meses, etc, que são entendidas por todas as pessoas que têm interesse no projeto e apresentadas em uma linguagem natural.  

Vamos apresentar duas técnicas: 

ROM – Ordem aproximada de magnitude

• Finalidade: Decidir se vale a pena;
• Estimada: Gestão;
• Assertividade: De -25% a 75% – Baixa assertividade
• Utiliza: Top Down;
• Baseada: Experiências.

 Budget – Custo

• Finalidade: Realizar planejamento e custo;
• Estimada: Gestão e time de desenvolvimento;
• Assertividade: De -10% a 25%, sendo esse mais assertivo que ROM
• Baseada: Experiência, riscos, *CPM.

* CPM – Critical Path Method, é uma técnica utilizada para encontrar caminho crítico identificando detalhes da tarefas como, dependências entre as elas, quais podem ser executadas em paralelo e quais se atrasarem reflete diretamente na estimativa final.  

Sugiro esse modelo: 

 

2 – Estimativa definitiva 

A estimativa definitiva é feita pelo e para o time de desenvolvimento, essa estimativa será utilizada no trabalho diário do time. Tem assertividade de -5% até 10%. 

As metodologias ágeis utilizam ‘Ideal days’, mas como sabemos, no processo de desenvolvimento ocorrem problemas, divergências de estimativas e senioridades, interrupções para outras atividades como reuniões, treinamentos, café, etc. Então a unidade de medida mais indicada a utilizar dentro do time de desenvolvimento são pontos.  

Estimativa em pontos

Estimativas em pontos não tem utilidade fora do time de desenvolvimento, mas tem as seguintes vantagens: as pessoas que estimam não necessariamente irão realizar a tarefa, estimativas mais rápidas e a comparação é mais simplificada (comparação é forma natural para humanos estimar algo).

Ao estimar deve considerar o esforço, riscos, complexidade e conexões que aquela tarefa terá com os outros módulos e funcionalidades. Como a estimativa é feita pelo time de desenvolvimento, então é estimado tarefa por tarefa (sendo estimado a menor parte possível da tarefa).

Após algumas rodadas de estimativa (Scrum – algumas sprints) é possível recalibrar as estimativas e ter uma baseline estável. Ainda utilizando o modelo de scrum, por exemplo: US1 é 1 ponto para ser desenvolvida, US2 é 5 vezes maior que a US1 então US2 são 5 pontos e assim sucessivamente. 

A maioria das técnicas utilizam sequência de Fibonacci {1, 2, 3, 5, 8, 13, 21, …} acima de 21 pontos os valores costumam ser arredondados 30, 50, 100. Uma dica nesse ponto, se a tarefa for muito grande recomenda-se fatiar, por questão de facilidade no desenvolvimento e melhor acomodação nos fluxos de desenvolvimento. 

Vamos rapidamente apresentar algumas técnicas. 

Complexity Buckets 

Baldes de complexidades, cada número da sequência Fibonacci é um balde onde a tarefa é colocada conforme sua estimativa.

Todos os membros do time estimam e o resultado que for dado mais vezes é a estimativa da tarefa, havendo divergências ocorre uma breve discussão com as pessoas expondo seus pontos. 

Antes de iniciar o processo pode definir regras de desempate para quando ocorrer divergência.  Essa técnica é mais recomentada para times menos experiente ou que não trabalharam juntos anteriormente. 

Fotografia 1 – Complexity Buckets 

Fonte: https://agiledigest.com/ 

Planning Poker 

Essa técnica é a opção mais recomendada e utilizada no scrum.  Ela pode ser feita pessoalmente com cards ou remotamente por apps. Após explicado a tarefa todo o time estima ao mesmo tempo apresentando sua estimativa para a tarefa. Se ocorrer divergência estimativa ocorre uma breve discussão com as pessoas expondo seus pontos e todo o time estima novamente. 

Fotografia 2 – Aplicativo Planning Poker            

Fotografia 3 – Baralho Planning Poker  

Fonte ambas imagens: www.https://www.mountaingoatsoftware.com/ 

White Elephant Size 

Nessa técnica cria-se um board com a sequência Fibonacci. Cada membro do time em fila, na sua vez, lê a tarefa e a estima.

Somente esse membro que está estimando pode fazer perguntas para a área de negócio e/ou PO. Então o outro membro do time pode estimar uma nova tarefa ou alterar a estimativa das que já foram estimadas.

Ao acabar as tarefas, continua a sequência de membros do time até que todos os membros não queiram mais alterar nenhuma estimativa. Nas tarefas que tenha divergência pode optar por planning poker. 

Eu recomendo esse vídeo para entender a dinâmica:

 

Ouija Board 

Nessa técnica o time precisa estar presencialmente e tende a ser mais divertia. A sequência Fibonacci é colocada nas extremidades de um círculo e o card da tarefa a ser estimada no entro do círculo, todos os membros colocam um dedo no card e arrastam juntos para pontuação que julgam mais adequada.

Se for fácil arrastar, todos estão de acordo com a estimativa. Se for difícil arrastar, ocorre uma breve discussão e o card volta para o centro da mesa para ser estimado novamente.  

Fotografia 4: Ouija Board 

Fonte imagem: https://www.tastycupcakes.org/2012/03/ouija-board-estimation/ 

 

3 – Estimativa total do projeto 

Como podemos utilizar as estimativas por pontos para estimar projetos inteiros com medidas conhecida a todos? Ao se tratar de metodologia ágil temos como destaque Scrum e Kanban, vamos falar de ambos separadamente. 

Scrum 

Para estimarmos projetos que utilizam metodologia Scrum precisamos saber o fluxo de trabalho (Sprints) e a velocidade do time.  

Podemos descobrir a velocidade do time da seguinte forma: algumas user stories estimadas em pontos são selecionadas e colocadas na Sprint. Dessas atividades algumas serão entregues, outras não, esse fluxo é feito por 2 ou 3 sprints. As user stories terminadas nas Sprints são consideradas a velocidade da sprint realizando uma média entre elas e com isso é possível saber em pontos quantos pontos são realizados em uma sprint.  

Com essas duas informações é possível identificar quantas sprints são necessárias para finalizar o projeto e trazendo isso para dias calendário se obtém a data de termino do projeto, lembrando de considerar tudo que pode interferir na quantidade de pontos que cabem na sprint, como feriados, fins de semana, dayoffs e etc. 

Kanban 

De início é importante ressaltar que a metodologia Kanban não se estima o processo todo, porque o Kanban é mais apropriado para fluxos contínuos e não para projetos fechados. Para projetos fechados o mais indicado é o Scrum. No Kanban é mais interessante saber a estimativa do ciclo completo.  

Deve levar em consideração que as tarefas (cards) devem ter aproximadamente o mesmo tamanho; que o backlog é estimado até certo ponto  considerando que as tarefas tendem a ter tamanhos aproximados não sendo necessário estimar todas as tarefas depois que já sabe o balizamento do tamanho delas; que as tarefas entre si acabam tendo um certa compensação entre elas. 

Com as informações de quanto tempo uma tarefa gasta para completar o ciclo completo e o limite de tarefas que podem ser executadas simultaneamente é possível estimar as tarefas que serão entregues em determinado período, entregues em releases por exemplo. 

 

4 – Priorização de backlog 

Estimar tarefas e projetos está diretamente relacionado a priorização do backlog, é indispensável levar em consideração o custo (estimativa) e o valor da feature a ser desenvolvida.  

Os stakeholders necessita de um alto nível de estimativa para decidir o futuro do produto ou projeto, qual feature compensa ser desenvolvida. 

Uma feature que tem um valor alto, mas tem um custo muito alto, talvez seja menos prioritária que um feature que tem um valor considerável e tem um custo baixo.  Uma forma de priorizar o backlog é utilizando T-shirts, onde pode ser classificado os valores de negócio e os custos das features por tamanhos de camisa.  

Por exemplo: 

Três features foram classificadas por T-shirts em valor de negócio e custo de desenvolvimento.   

São atribuídos valores numéricos combinando valor de negócio versos custo de desenvolvimento criando assim uma matriz. Ao aplicar a classificação das features na matriz resultará na priorização das mesmas, sendo quanto maior o resultado maior a priorização. 

Nesse caso a Feature 1 (F1) é a primeira na priorização, a (F2) foi descartada pois o custo de desenvolvimento é muito caro em relação ao valor de negócio e a (F3) é a segunda na lista de prioridade.  Dessa forma temos o backlog priorizado.  

 

5 – Apresentar estimativas 

Quando o time repassa as estimativas aquele dado é interpretado como compromisso e a gestão verá como comprometimento, ou seja, se não cumprir o compromisso gera situações desconfortáveis.  Essa situação não é totalmente verdade, por isso se chama estimativa e como foi dito no inicio a estimativa é para ser próximo da realidade e não exatamente a realidade. 

Temos três datas importantes que envolve a expectativa de todos os envolvidos. Esse cenário se aplica a projetos com datas fechadas, vejamos: 

Com o objetivo de proteger o time e calcular de forma realista, a probabilidade de termino do projeto são aplicados cálculos estatísticos de probabilidade, como Triangulo de distribuição ou PERT de distribuição e desvio padrão. Baseado nesses cálculos demonstramos percentual de confiança na entrega podendo responder à pergunta “Qual a probabilidade que o projeto termine no prazo acordado?”.

Um exemplo utilizando PERT e desvio padrão: 

Estima-se que o projeto seja entregue visão otimista em 5 semanas, mais provável em 8 semanas e pessimista em 10 semanas.   

Aplicando desvio padrão podemos dizer que a probabilidade e entregar o projeto entre 7 a 8,6 semanas é de 68%, de entregar entre 6,1 a 9,5 semanas é de 95% e entre 5,3 a 10 semanas é de 99%. Com calcular o desvio padrão pode utilizar programas e planilhas para realizar o cálculo.  

Por fim, as estimativas devem ser revistas no decorrer do projeto alinhando as expectativas de todos os envolvidos.  Elas possuem valor em relação ao público destinado e o nível de detalhe deve ser proporcional a necessidade do projeto, então atenção ao tempo desprendido para realiza-las. 

 

6 – Conclusão 

O assunto “estimativa”, além de ser complexo, ainda divide muitas opiniões e temos muitos itens envolvidos. Por exemplo, todas as técnicas de estimativa, experiência dos profissionais envolvidos, dados históricos de implementações anteriores, cálculos de probabilidade, tempo gasto na ação de estimar, opiniões pós e contra estimativa e o movimento #NoEstimate.   

Antes de prosseguir sobre o assunto, gostaria de gerar uma provocação.

Acredito que estamos em um cenário que nos leva a sempre questionar a nós, aos métodos, os modelos e as tarefas que realizamos.  Quando trabalhamos com metodologias ágeis buscamos trazer para o dia a dia agilidade, ser ágil e não simplesmente seguir o cronograma que os modelos ágeis propõem.

Ser ágil é responder de forma rápida às mudanças, errar rápido e corrigir rápido, entregar valor constantemente. Podemos nos questionar, devemos estimar ou não? O que devemos estimar? Quanto tempo devemos gastar em estimativa? Qual o valor que a estimativa agrega ao produto ou projeto? Poderíamos utilizar os dados históricos que temos até esse momento como estimativa? Entre tantas outras questões. 

O NoEstimate não nos diz “deixe de lado todas as estimativas porque isso não serve para nada” pois, sabemos que temos clientes, gestores e stakeholders que necessitam de informações e prazos. 

No meu ponto de vista, NoEstimate nos faz pensar se como estimamos é a forma mais eficiente para o nosso objetivo final, se não gastamos um tempo valioso em estimativas inatingíveis, se não acomodamos o time em um platô de performance, se não geramos pressão extra no time para cumprí-las, se após um sincronismo do time e um histórico confiável de implementações não poderíamos utilizar esses dados para auxiliar nas estimativas das próximas tarefas. Não estimar nada é muito arriscado, mas avaliar o valor do processo de estimativa é ágil. 

 

Camila Stoppa Vicente 

Analista de Negócios