Entendendo mais sobre estimativas em projetos de desenvolvimento de software

Você é chamado para uma reunião sobre um novo sistema ou simplesmente uma nova funcionalidade no projeto que está desenvolvendo, te passam detalhes das necessidades do cliente e de como querem que funcione. Ao final, o gerente vai sempre chegar e te perguntar: “quanto tempo você leva para fazer isso?”, “quantas pessoas vamos precisar?”, “não é complicado para fazer, não é?”.

Estimar é uma tarefa complexa

Iniciar o desenvolvimento de uma nova demanda de software envolve uma série de desafios. Neste cenário, uma das tarefas mais complexas é a realização de estimativas. Muitos fatores precisam ser analisados e, ao mesmo tempo, o gerente precisa dar um retorno para o cliente.

Estimativa de software com derivações em tempo, prazo e esforço é um desafio comum em empresas e institutos de TIC. Dada a natureza abstrata do produto, fazer previsões é uma tarefa desafiadora seja em metodologias tradicionais ou em métodos ágeis. Na maioria das vezes a equipe não sabe ainda como fazer algo ou sequer o que deve ser feito como um todo, entretanto, a mesma precisa fazer uma estimativa.

Por que é difícil estimar?

Por mais que tenhamos experiência em desenvolvimento, estimar é uma tarefa complexa. O que mais escutamos de colegas em reuniões de estimativas é: “eu nunca fiz isso, como saberei o tempo para terminar?”, “eu já fiz algo parecido no projeto passado, mas este tem algo diferente”, “eu acho que consigo fazer em pouco tempo, mas não tenho certeza”.

O software possui características abstratas que dificultam o processo de estimativas comparado a produtos de outras engenharias. Somado a isso coloque incertezas de IDE’s, quem nunca ouviu essas frases: “funciona na minha máquina, mas quando coloco no servidor dá erro”, “fiz exatamente igual e hoje o projeto não compila”. Somado a isso coloque características do processo como pouca documentação, métodos baseados exclusivamente na experiência dos times e falta de histórico.

Existe, inclusive, uma tendência no mundo de projetos ágeis conhecida como #NoEstimate. Porém, os próprios fundadores do Scrum, Ken Schwaber e Jeff Sutherland, em uma entrevista recente falam sobre a importância de estimativas. Mencionam que em uma pesquisa com 70.000 membros de equipes Scrum foi verificado que aqueles que evitavam estimar produziram entregas mais lentas.

A estimativa de software não deve ser difícil, onerosa ou ineficiente. Feita corretamente, poderá ser uma ferramenta altamente efetiva que pode ajudar os gerentes de projetos a entregar valor a suas organizações. Entretanto, errar as estimativas colabora para o fracasso de projetos. É comum nestes cenários observar um excesso de pessoas, orçamentos acima do previsto e sistemas com defeitos significativos.

Métodos

Muitos são os métodos de estimativas em metodologias tradicionais de gestão. O Program Evaluation and Review Technique, ou PERT como é mais conhecida é uma técnica bastante utilizada. Outra que merece destaque é a Estimativa por Analogia, utiliza-se dos custos ou tempo reais de projetos similares anteriores em tamanho, escopo e complexidade para a definição das estimativas do projeto atual.

Os métodos de estimativa em projetos ágeis são baseados principalmente na avaliação subjetiva da equipe. O Planning Poker é a técnica mais utilizada, cujo objetivo é estimar os valores relativos a tarefas e User Stories, a fim de representar o esforço necessário para implementar recursos ou funcionalidades específicas. Outro método utilizado em projetos ágeis é o Julgamento do Especialista, esta técnica é baseada na realização de brainstorming de um ou mais especialistas que têm experiência em projetos similares, chegando a um consenso que produz uma estimativa.

Por fim, vamos compreender um pouco a diferença de alguns conceitos:

Tempo x Prazo

Por muitas vezes, acabamos por confundir o termo “tempo” com o conceito de prazo. Podem parecer sinônimos, mas tempo e prazo de realização para uma atividade são conceitos distintos. O tempo é o esforço necessário para desenvolver uma determinada funcionalidade. O prazo é o intervalo ou período de tempo dentro do qual alguma atividade deve ser realizada. Por exemplo, eu posso estimar o tempo de fazer um CRUD em 8 horas, mas trabalhando 4 horas por dia, o prazo de entrega seriam de 2 dias.

Tamanho x Esforço

Outros conceitos que parecem sinônimos são tamanho e esforço. O primeiro tem relação com “comprimento”, no caso de software está mais relacionado ao número de módulos, classes ou simplesmente linhas de código. O método mais consolidado para estimativas de tamanho em projetos de software é APF (Análise de Ponto de Função). Por outro lado, o esforço é um conceito mais abstrato, normalmente relacionado a quantidade de homens/hora para executar uma tarefa. Em metodologias ágeis, uma medida utilizada com sucesso para estimar esforço são os Story Points.

E o futuro?

Uma tendência observada consiste em utilizar abordagens baseadas em análise de dados para apoiar o processo de estimativas de esforço [1]. Busca-se utilizar dados históricos da organização para realizar previsões em novos projetos. As soluções normalmente utilizam técnicas de Machine Learning (ML) para realizar estimativas [2] com o objetivo de agilizar a tomada de decisão e reduzir a dependência de especialistas.

Algumas pesquisas são realizadas sobre estimativas de esforço pelo grupo ISE (Intelligent Software Engineering) no Laboratório Embedded da UFCG. Como exemplo de resultados, foram realizados estudos e uma revisão da literatura sobre estimativas de esforço, além de uma avaliação de uma ferramenta que usa um algoritmo de ML para esse fim.

Saiba mais em:

[1] DANTAS, EMANUEL; PERKUSICH, MIRKO ; DILORENZO, EDNALDO ; SANTOS, DANILO F. S. ; ALMEIDA, HYGGO ; PERKUSICH, ANGELO . Effort Estimation in Agile Software Development: An Updated Review. INTERNATIONAL JOURNAL OF SOFTWARE ENGINEERING AND KNOWLEDGE ENGINEERING, v. 28, p. 1811–1831, 2018.

[2] DANTAS, EMANUEL; COSTA, ALEXANDRE ; VINICIUS, MARCUS ; PERKUSICH, MIRKO ; ALMEIDA, HYGGO ; PERKUSICH, ANGELO . An Effort Estimation Support Tool for Agile Software Development: An Empirical Evaluation. In: The 31st International Conference on Software Engineering and Knowledge Engineering, 2019.