Você está na página 1de 12

Como estimar o esforço de desenvolvimento de

software e por que isso é tão difícil?


De Talita Pagani (https://medium.com/@talitapagani)
Adaptado por Eduardo Damasceno

Chega uma nova demanda para desenvolvimento de um projeto ou funcionalidade de um produto e


a pessoa responsável pela gestão do projeto/produto chega pra você e pergunta na reunião: “e aí, quanto
tempo você leva para fazer isso?”.
Por mais que tenhamos experiência em desenvolvimento, estimar tempo e prazo é uma tarefa
desafiadora. O que mais ouço de colegas com relação ao tema é “nossa, é muito difícil falar quanto tempo
vou levar pra desenvolver algo, como você consegue fazer isso?”.
É difícil, mas não impossível. Em quase 13 anos atuando em TI, percebi vários fatores que
impedem desenvolvedores de conseguir estimar software de forma adequada:

• Requisito incompleto e muito subjetivo;


• Falta de conhecimento de desenvolvedores sobre métricas de software para aplicar às suas próprias
tarefas. Nesse ponto, recomendo os livros “Indicadores De Gerenciamento De Projetos” do Armando
Terribili Filho e “Métricas Ágeis” do Raphael Albino;
• Gerentes de projeto querendo que usemos uma bola de cristal para tirar uma estimativa do nada sem
dar tempo para fazermos uma análise dos requisitos;
• Funcionalidade, projeto ou produto muito distinto do que já foi desenvolvido anteriormente, o que
impede uma estimativa por analogia.

Estimativas incorretas podem comprometer as entregas de diversas formas: acabam gerando um


cronograma impreciso (muito apertado ou com muita folga que deixa a equipe ociosa), pode gerar mais
custos para o projeto, horas extras para entregar no prazo acordado com o cliente, entre outros.

1. Tempo x Prazo
Podem parecer sinônimos, mas tempo e prazo de realização para uma atividade são conceitos
distintos, embora complementares. Às vezes, até quem é responsável pela gestão de um projeto se confunde
nesses conceitos no momento de solicitar uma estimativa.

Na perspectiva de desenvolvimento de software, o tempo é o esforço total que você levaria para
desenvolver um determinado requisito ou funcionalidade. Geralmente esse tempo é medido em horas, mas
também pode ser medido em dias e, em casos raros, em semanas.

Exemplo: para fazer o front-end de um formulário de cadastro de clientes, você levaria 16 horas.

Já o prazo é um intervalo ou período de tempo dentro do qual alguma atividade deve ser realizada.
Se você tem uma atividade que leva 8h para ser feita, não significa que ela tem o prazo de um dia ou que
será feita em um dia. Mesmo porque, ninguém trabalha certinho as 8 horas por dia, né (alô gerentes de
projetos que fazem cronograma considerando que todo mundo trabalha 8h, tá errado isso aí).
Exemplo: (1) esse formulário de cadastro de clientes, que leva 16 horas, tem um prazo de cinco dias
para ser desenvolvido e entregue; (2) você pode estimar que o formulário de cadastro, de 16 horas, será
entregue em um prazo de três dias.

2. Como desenvolvedores fazem estimativas?


Eu tenho um grande viés acadêmico-científico, então eu não poderia ficar somente na minha
perspectiva para escrever este post, porque só minha vivência profissional não é um argumento forte para
generalizar uma realidade do mercado.

Precisava de fatos e evidências sobre como pessoas da área de desenvolvimento de software fazem
estimativas e quais as principais dificuldades que elas enfrentam. Assim, eu resolvi fazer um questionário
online no SurveyMonkey:

Vamos a uma breve análise dos resultados.

3. Estrutura do questionário
Primeiramente, obrigada a todas as pessoas que contribuíram com a pesquisa! Obtive 90 respostas
em 3 dias em que deixei o questionário aberto. Não estava tão rigorosa quanto à relevância estatística, então
não tinha a a pretensão de obter um volume maior de respondentes, até mesmo porque o plano gratuito do
SurveyMonkey só permite 100 respostas, rs.

A pesquisa era composta por três questões técnicas e três questões demográficas, um formulário
bem sucinto mesmo, somente com perguntas fechadas de múltipla escolha (radio button) ou seleção múltipla
(checkbox). As questões técnicas foram:

• Quais técnicas ou estratégias você utiliza quando te pedem para estimar o desenvolvimento
de um projeto ou uma funcionalidade de um projeto?
• Como você realiza as estimativas de desenvolvimento?
• Quais as maiores dificuldades que você tem com relação a estimativas de desenvolvimento?

4. Perfil dos respondentes


Dos 90 respondentes, 34% são desenvolvedores de software (back-end, web, mobile), 23% são
desenvolvedores full-stack, 16% são de front-end, 10% são engenheiros(as) de software, 8% são designers e
somente 2% são analistas de teste. Na opção “outros”, há respondentes que são: líder técnico, analista de
suporte, gerente de projetos/analista de sistemas, Product Owner (PO)/analista de requisitos, dev full-stack
/ team leader, e arquiteto de software, sendo um respondente de cada uma dessas funções.
Gráfico de barras com a distribuição das funções ordenadas do maior percentual para o menor,
sendo: 34% desenvolvedor(a) de software — back-end, web ou mobile, 23% desenvolvedor(a) full-stack,
16% desenvolvedor(a) front-end, 10% engenheiro(a) de software, 8% designer — de interação de interface
ou UX, 7% outros e 2% analista de testes.

A maioria dos respondentes são de nível pleno, atuando entre 4 e 6 anos na área (36%). Houve uma
distribuição idêntica de profissionais com mais de 10 anos de experiência em TI (19%) e profissionais
juniores, com 1 a 3 anos de experiência (19%). Outros 18% estão no nível sênior, entre 7 e 10 anos de
atuação e somente 9% dos respondentes possuíam de menos de um ano de atuação (7% = de 6 meses a 1
ano, 2% = menos de 6 meses).

Gráfico de barras com a distribuição do tempo de atuação no mercado, sendo: 2% menos de 6


meses, 7% de 6 meses a 1 ano, 19% de 1 a 3 anos, 36% de 4 a 6 anos, 18% de 7 a 10 anos e 19% mais de 10
anos.
5. As principais técnicas de estimativas utilizadas
Existem diversas técnicas que ajudam desenvolvedores na estimativa de software: de Planning
Poker, vinda dos métodos ágeis, até a Estimativa por Analogia. Mas a mais conhecida ainda é o
famigerado Cálculo Hipotético Universal Técnico Estimativo, o CHUTE.
Brincadeiras à parte, foi surpreendente ver que a técnica de estimativa mais utilizada pelo pessoal,
independente do tempo de atuação no mercado, é justamente o chute (41%), que deu até empate técnico com
o segundo lugar, que foi o Planning Poker (39%)! Em terceiro lugar, vem a Estimativa por Analogia (30%)
e, com uma boa diferença, os Pontos por Caso de Uso (PCU), com 14%, que confesso nunca ter utilizado.

Gráfico de barras com a distribuição das técnicas de estimativas ordenadas do maior percentual para
o menor, sendo: 41% vai no chute mesmo, 39% planning poker, 30% estimativa por analogia, 14% pontos
por caso de uso, 13% pontos de função, 9% estimativa paramétrica, 6% estimativa de três pontos, 4% outros
e 3% técnica Delphi.
Como a pergunta era de seleção múltipla, pode ser que em muitos casos as pessoas usem outras
estratégias mas deixam de lado técnicas estabelecidas e optem por uma estimativa super hipotética porque
foram pegas de surpresa, houve pressão para fornecer um prazo de entrega ou não têm base para poder
estimar o que foi solicitado.
Fazendo um comparativo das técnicas utilizadas por tempo de atuação no mercado, observei uma
tendência curiosa. Profissionais juniores, com 1 a 3 anos de atuação, são muito propensos a “chutar” as
estimativas (59%), mas este percentual cai abruptamente em profissionais de nível pleno (38%) e sênior
(19%), que têm o Planning Poker como a técnica mais utilizada, sendo 41% e 56%, respectivamente. Porém,
o número volta a crescer vertiginosamente nos profissionais com mais de 10 anos de atuação. Cerca de 47%
responderam que usam o chute como técnica de estimativa.
Gráfico de linhas mostrando a mudança no uso das técnicas de estimativas de acordo com diferentes
níveis de senioridade dos profissionais respondentes.

O que será que acontece para eles voltarem a “chutar”? Maior conhecimento? Mais confiança nas
suas habilidades? Maior pressão? Já estão no nível do dane-se e vai assim mesmo? Ainda não descobri, mas
sintam-se à vontade para debater isso nos comentários.

6. Como são realizadas as estimativas


Muitas empresas adotam estratégias colaborativas para estimar os projetos, onde os todo o time se
reúne para discutir o escopo, realizar o planejamento e entrar em consenso sobre as estimativas.

Em times que usam métodos ágeis, como Scrum, esse processo é realizado no Planning Poker
(https://www.culturaagil.com.br/planning-poker-tecnica-baseada-consenso/ ).

Mas há casos em que os gestores perguntam individualmente para cada membro do time as
estimativas para suas respectivas partes. E há momentos em que não nos sentimos seguros sobre como
estimar e consultamos colegas mais experientes ou a pessoa que coordena o time. Eu mesma já passei por
todas essas situações, mas queria entender o que é mais comum no mercado.

A forma mais utilizada (58%) é a realização das estimativas em conjunto com os colegas de
trabalho, chegando em um acordo sobre as estimativas. Já a segunda é a realização de estimativas sozinho,
com 33%. A terceira, com 31%, é a realização as estimativas com os colegas somente consultando as
pessoas quando há dúvidas.
Gráfico de barras com a forma mais utilizada para fazer as estimativas, sendo: 33% sozinho, 31%
consultando os colegas de trabalho, 58% em consenso com os colegas de trabalho, 28% em conjunto com a
pessoa que coordena o time e 2% outros.

Comparando novamente por tempo de atuação, 53% dos profissionais juniores realizam as
estimativas em consenso com os colegas, mas também fazem estimativas sozinhos (29%) ou somente
consultando os colegas (29%). Já entre os profissionais de nível pleno e especialista (mais de 10 anos de
mercado), 65% trabalham com este método de estimativas em consenso. E foi interessante observar como os
profissionais especialistas valorizam a opinião dos colegas de trabalho: 59% indicaram que consultam seus
pares no momento de realizar as estimativas.

Gráfico de barras com a forma de realizar estimativas por tempo de atuação, sendo: De 1 a 3 anos
— 29% sozinho, 29% consultando colegas de trabalho, 53% em consenso com colegas de trabalho, 18% em
conjunto com a pessoa que coordena o time; De 4 a 6 anos — 31% sozinho, 19% consultando colegas de
trabalho, 66% em consenso com colegas de trabalho, 34% em conjunto com a pessoa que coordena o time;
De 7 a 10 anos — 38% sozinho, 25% consultando colegas de trabalho, 50% em consenso com colegas de
trabalho, 19% em conjunto com a pessoa que coordena o time; Mais de 10 anos — 35% sozinho, 59%
consultando colegas de trabalho, 65% em consenso com colegas de trabalho, 29% em conjunto com a pessoa
que coordena o time e 12% outros.

Mesmo que sua empresa não adote métodos ágeis ou técnica de Planning Poker, realizar
estimativas de forma colaborativa entre todos os membros do time é muito válido para aumentar o
comprometimento na entrega, tirar dúvidas, trocar ideias, esclarecer requisitos e perceber riscos que você
não perceberia sozinho(a).

7. As maiores dificuldades
Por fim, será que minhas hipóteses apresentadas no início do texto sobre as dificuldades em estimar
projetos estariam corretas? Além da subjetividade de requisitos, que é algo que foge do controle de quem é
dev e vem de cima, pensei que um dos maiores problemas seria a própria habilidade de desenvolvedores em
estimar.

O que percebi, foi que os maiores problemas vêm da definição de escopo e análise de requisitos dos
projetos. Para 62% dos respondentes, a subjetividade do projeto ou da funcionalidade a ser desenvolvida é
uma das maiores dificuldades no momento de estimar os esforços, seguido da falta de requisitos (54%).

Em seguida, vêm as dificuldades que são mais relacionadas à habilidade de cada dev: acabar
estimando tempo/esforço demais ou pouco tempo/esforço (47%); além de estimar tempo, conseguir estimar
o prazo de entrega (41%); dificuldade em saber como calcular quanto tempo levaria para desenvolver o que
foi solicitado (40%).

Gráfico de barras horizontais com os maiores problemas para estimar os requisitos, sendo: 62%
subjetividade do projeto ou da funcionalidade a ser desenvolvida, 54% falta de requisitos, 47% acabar
estimando tempo/esforço demais ou pouco tempo/esforço, 41% além de estimar tempo, conseguir estimar o
prazo de entrega, 40% dificuldade em saber como calcular quanto tempo eu levo para desenvolver o que foi
solicitado, 30% dificuldade de analisar os requisitos do que tem que ser desenvolvido e 1% outros.

Comparando por tempo de atuação, a preocupação com a subjetividade dos requisitos tende a ser
uma preocupação maior com o passar do tempo. Enquanto este fator é preocupante para 41% dos
profissionais juniores, ele acaba sendo uma dificuldade para 76% dos especialistas. Já a dificuldade em saber
como calcular quanto tempo levaria para desenvolver o que foi solicitado cai de 53% nos profissionais
juniores para 19% nos profissionais seniores, porém, aumenta um pouco para 35% nos profissionais
especialistas.

Gráfico de linhas mostrando a mudança nas dificuldades para estimar projetos de acordo com
diferentes níveis de senioridade dos profissionais respondentes.

Ou seja, a tendência é irmos refinando nossa habilidade em realizar estimativas com o avanço na
carreira, porém, passamos a ter uma preocupação maior com as dificuldades que fogem da nossa alçada e
são de responsabilidade da gestão do projeto/produto. Mas mesmo nesses casos, há formas de contornar os
empecilhos.

Agora é hora de entrar na parte que me motivou a escrever esta série de posts: compartilhar a
minha experiência sobre esse assunto junto com algumas dicas, algo que muitas pessoas já
me pediram informalmente. Longe de ser uma técnica formal ou receita de bolo, são dicas sobre organização
pessoal que podem ser aplicadas independente da abordagem que você já utiliza.

Elas são baseadas na minha vivência em diversos projetos da área de desenvolvimento ao longo
desses 13 anos de atuação na área. A intenção não é esgotar este assunto que é tão amplo, tampouco
apresentar algo que vai funcionar magicamente para qualquer situação em que é preciso fornecer
estimativas.

Eu sempre fui muito preocupada em fornecer estimativas minimamente realistas e o conteúdo sobre
gestão de tempo na especialização em gerenciamento de projetos me ajudou muito a refinar a perspectiva
sobre como estimar requisitos. Mas foi com a prática e com técnicas próprias que consegui me organizar
para não errar feio e “queimar meu filme” quando preciso fornecer estimativas (não que às vezes eu não dê
umas derrapadas).

Tem uma frase bem batida que diz que “não se pode controlar aquilo que não se pode medir”
atribuída ao Peter Drucker e quem tem várias adaptações. Com relação a estimativas, isso faz sentido em
vários momentos, visto que é frequente desenvolvermos recursos ou funcionalidades que são semelhantes a
algo que já foi desenvolvido anteriormente. Ter essas métricas ajudam também a acompanhar a nossa
evolução enquanto profissionais.

8. Documente suas tarefas para criar uma base de conhecimento


Como você irá lembrar quanto tempo leva para fazer um determinado recurso se você não tem isso
documentado? Possivelmente, são nesses momentos que entram os chutes nas estimativas, o famoso “olha,
se não me engano, leva X tempo pra fazer isso, mas eu tenho que dar uma olhada aí”.

Uma estratégia que adoto desde 2012 para me ajudar nas estimativas é documentar a duração real
de determinadas tarefas em uma planilha após tê-las realizado. Essa documentação não tem somente a
duração, mas detalhes da tarefa, o que precisava ser entregue, qual era o requisito e quais problemas
ocorreram.

Ter uma base histórica do que já fizemos, quanto esforço dispendemos e como fizemos ajuda
também a não reinventar a roda, até mesmo porque não dá pra confiar só na memória.

Na imagem a seguir, apresento o modelo que usava para documentar as atividades de QA, quando
atuei como analista de testes, uma função nova para mim na época na qual eu não tinha experiência.
Documentar as tarefas que eu fazia começou a me ajudar muito quando precisava fornecer
estimativas, mesmo para atividades novas. A estrutura da planilha pode variar muito de acordo com sua
função e as suas necessidades. Para front-end, eu coloco outros atributos e para análise de negócios e
requisitos (quando atuei nessa função) eram outras informações a serem registradas.

Planilha de documentação das minhas métricas de teste com as colunas: projeto, tipo de teste,
descrição do teste, condições do teste e duração da tarefa quando realizei, em horas. Há outras colunas que
não estão sendo exibidas na imagem, como observações e data da primeira realização da atividade.
Essa estrutura é semelhante a de uma biblioteca de padrões (pattern library), onde documenta-se
soluções de sucesso para problemas recorrentes em um determinado contexto, com a diferença de que aqui
não há a preocupação de documentar um problema recorrente e suas soluções, mas sim fazer como se fosse
um log de desenvolvimento.
Uma planilha de desenvolvimento front-end poderia ter a seguinte estrutura:
• Projeto/Produto
• Requisito ou Caso de Uso
• Descrição da implementação
• Framework utilizado
• Bibliotecas utilizadas
• Problemas encontrados
• Duração prevista
• Duração real (em horas)
• Prazo previsto
• Período real (em dias)
Se você realizar uma atividade semelhante em outro projeto/produto, vale a pena registrar
novamente na tabela para ter um comparativo entre os tempos/prazos, se foram encontrados problemas
diferentes, se você as durações reais se aproximaram das estimativas e se você agora consegue produzir a
mesma funcionalidade de forma mais rápida com o passar do tempo.
Mas como eu contabilizo esse tempo? Vou ter que ficar com um timer, marcando no relógio?
Não! Tem muitas ferramentas que podem te ajudar a automatizar essa contagem:
• WakaTime: contabiliza quanto tempo você programou por dia fornecendo métricas por linguagem,
editor, sistema operacional e, se você usa GitHub, por projeto do GitHub. Integra com diversos
editores e até com o navegador;
• RescueTime: para quem não trabalha com código (e pra quem trabalha também), o RescueTime
mede quanto tempo quando você passa em aplicações e sites, categorizando cada aplicação e
classificando entre ferramentas produtivas, neutras ou improdutivas. É um ótimo recurso para
acompanhar sua produtividade também;
• Traxmo: É uma aplicação web de gerenciamento de projetos gratuita para usuários únicos que
permite criar projetos e tarefas da forma como quiser. Para as tarefas, você pode inserir o tempo
manualmente ou usar um cronômetro, o que é muito útil. Essa ferramenta eu uso constantemente
quando faço freelas.
Essas ferramentas também ajudam a medir quanto tempo, em média, você passa codificando ou
usando as ferramentas técnicas do dia-a-dia, permitindo que você saiba o seu tempo produtivo diário e use
isso como parâmetro para estimativas futuras. Se você programa cerca de 3,5 horas por dia, uma tarefa que
leva 8 horas pode ser estimada com um prazo de 3 dias.
Tem alguma outra sugestão? Deixe nos comentários :)
Organize a forma como você faz os commits para ajudar em estimativas futuras
Você pode resgatar o histórico de commits de uma funcionalidade para estimar ao menos o prazo de
realização de uma funcionalidade semelhante a outra que você já fez. Mas isso vai depender uma boa
estruturação dos commits e das mensagens de commit.
Eu costumo aplicar a técnica de commits atômicos. Eles facilitam a revisão de código, a reversão
caso algo tenha sido mal-sucedido ao longo do desenvolvimento da funcionalidade e facilitam no momento
de descrever os commits. Traduzindo o exemplo desse post de Nathan Rambeck, uma série de commits
atômicos (e suas respectivas mensagens) no desenvolvimento de um formulário poderia ser:
• Criado o HTML para o formulário
• Estilização do formulário
• Adição de validação HTML5
• Correção de alguns erros de JS
• Adição da submissão do formulário via AJAX com resultados do servidor ‘mockados’ do PHP
• Adição de validação JS ao formulário
• Log dos resultados do formulário no banco de dados
• Estilização da validação de formulário e de mensagens de erro/sucesso
Se alguém perguntar como fazer um formulário semelhante, você tem registros disso. Se alguém
pedir um prazo para estilizar um formulário e as mensagens de validação, você tem registros disso também.
Triangulando as informações desses commits com os registros do WakaTime, por exemplo, você consegue
ter uma base para estimar tanto tempo quanto prazo através de uma estimativa por analogia.
Reduza riscos de potenciais atrasos com a estimativa de três pontos
Dar um prazo acurado não significa dar um prazo justo. Sempre podem acontecer imprevistos que
acabam atrasando alguma tarefa. Por isso, a gente tem que contar com a famosa “gordurinha” nas
estimativas que fornecemos já contando com alguns riscos e imprevistos. O problema é que colocar essa
“gordurinha” pode ser subjetivo também.
Particularmente, gosto muito de usar a técnica PERT, também chamada de estimativa de três
pontos. Ela consiste em calcular a duração média de uma tarefa utilizando uma estimativa otimista (O), mais
provável (MP) e pessimista (P) aplicando o seguinte cálculo:
PERT = (O + 4 x MP + P) / 6
Se você tem uma tarefa A com estimativa otimista de 12h, mais provável de 17h e pessimista
de 28h, o resultado seria uma média de 18h para realizá-la:
A = (O + 4 x MP + P) / 6 = (12 + 4 x 17 + 28) / 6 = 18 h
Bom, apenas uma hora de respiro pode não ser suficiente. Então você pode, se desejar, aliar ao
cálculo também a variância entre a estimativa pessimista e otimista (V = ((P-O)/6)²) e o desvio padrão (DV =
(P-O)/6), que mostra o quanto a duração da atividade pode variar para mais ou para menos dentro dessa
estimativa. Costumo somar o desvio padrão ao resultado do PERT, para ter um respiro ainda maior sem ficar
muito próximo à estimativa pessimista.
Considerações Finais
Estimativas de software são uma tarefa desafiadora para profissionais de TI em qualquer momento
da carreira. Há muita pressão nessa atividade e ocorre excesso de confiança para confiar em uma percepção
subjetiva pessoal (o chute).

Porém, os maiores problemas para estimar software partem da forma como os requisitos chegam até
à equipe: incompletos, subjetivos ou inexistentes. E aí entra um processo em que precisamos ter um trabalho
de tentar extrair mais informações e decompor o que já sabemos para transformar um requisito abstrato em
um conjunto de partes concretas.

Existem inúmeras técnicas de estimativas. Não existe a melhor, existe a estratégia que pode ser mais
adequada a você, ao seu time e ao projeto/produto em que você está trabalhando. Neste artigo compartilhei
algumas técnicas que venho utilizado ao longo dos anos e têm se mostrado efetivas, sendo meus “2 centavos”
para contribuir com esse tema que é tão vasto e polêmico.
Mas as técnicas não ajudam se não houver uma gestão eficiente e se o projeto já começar errado sem
elencar adequadamente os requisitos, como pode ser percebido pelos resultados da pesquisa apresentadas na
Parte 1. Metodologias, processos e ferramentas não salvam projeto/produto mal gerenciado. Devs: cobrem
levantamento de requisitos, conversem com partes interessadas e usuários e se envolvam nesse processo.
Gestores: não levem projetos adiante por pressão se não souberem minimamente o que precisa ser feito.
Requisitos podem sim ser elicitados de forma iterativa, mas isso não significa começar a desenvolver a partir
de uma página em branco.

Você também pode gostar