Guia: Como estimar o esforço de desenvolvimento de software

Iniciar o desenvolvimento de software envolve uma série de desafios, e um dos primeiros obstáculos que se apresentam diante do gestor é como estimar o real esforço necessário para criar um sistema.

Como todo projeto, demonstrar a quem financia a necessidade de recursos para a sua conclusão é parte fundamental, visto que, caso essa primeira etapa não esteja satisfatória, o projeto pode nem começar.

Para auxiliar você na tarefa de estimar o esforço necessário para o desenvolvimento de software, nós criamos este pequeno guia. Nele, você encontrará informações sobre por que realizar uma estimativa, como fazê-lo, as principais técnicas para esse fim e quais dificuldades serão enfrentadas. Continue conosco e tome nota!

Por que fazer estimativa de desenvolvimento de software?

Sempre que surge uma nova concepção de sistema, mesmo que a demanda por ele seja muito grande dentro da empresa, a pergunta principal feita pelos diretores é: “quanto tempo você vai levar para entregar esse projeto?”.

Nesse momento, não adianta ter milhares de horas de experiência em desenvolvimento de software, pois nenhuma resposta poderá precisar com exatidão o tempo necessário para concluir um projeto como esse.

Geralmente, os principais impeditivos que atrapalham os profissionais na hora de estimar os prazos para o desenvolvimento de software são:

• desconhecimento de todos os requisitos envolvidos no processo;
• falta de conhecimento por parte dos desenvolvedores em como metrificar processos de software;
• gerentes de projeto que não realizam uma análise dos requisitos antes de estimar o tempo de desenvolvimento;
• o sistema em si diverge muito de outras soluções já desenvolvidas pela equipe;
• estimativas incorretas que acabam por prejudicar o cronograma geral das atividades;
• o cliente aprova o escopo inicial do projeto e, após o seu início, começa a criar novas demandas;
• existe uma diferença na experiência e produtividade dos desenvolvedores que fazem parte do time.

Os prazos

Por muitas vezes, acabamos por confundir o termo “tempo” com o conceito de prazo. Isso prejudica muito os gestores na hora de buscar por uma estimativa real para a conclusão de determinadas tarefas do projeto.

É preciso primeiro demonstrar o que é cada um desses dois conceitos dentro de uma atividade de estimar o desenvolvimento de software. Tempo é o esforço necessário para se concluir uma determinada tarefa.

Ele pode ser medido em horas, dias ou qualquer outra unidade temporal. Por exemplo, para criar o front-end de um cadastro de fornecedores, podem ser necessárias 20 horas de trabalho. É o tempo que você leva para entregá-lo.

Já o prazo pode ser entendido como um intervalo de tempo, dentro do qual algum processo ou atividade do projeto deve ser finalizado. Se uma determinada tarefa foi estimada em 8 horas, não significa que os desenvolvedores poderão finalizá-la em apenas um dia de trabalho, pois ninguém trabalha ininterruptamente.

Então, se o tempo de conclusão é de 8 horas, o prazo deve levar em conta os tempos de parada do colaborador, além dos imprevistos. Podemos dizer que um cadastro como esse tem prazo para ser entregue em dois dias.

Estimativas

Planejar é uma das principais atividades dentro de qualquer projeto, e, quando falamos em software, não é diferente. Estimar os prazos da melhor forma possível é a garantia de que, ao final da empreitada, será alcançado o sucesso.

O software é desenvolvido para um determinado fim e demanda dedicação da empresa. Com isso, outros setores e colaboradores realizam todo o seu planejamento em cima daquilo que foi divulgado pelo gestor de TI com relação à finalização do projeto.

Quando o desenvolvimento não segue o plano e, por alguma razão, começam a ocorrer atrasos dentro dos prazos estabelecidos, isso pode afetar toda a empresa, aumentando os custos operacionais e até mesmo causando prejuízo.

Ao pensar dessa maneira, podemos observar a importância de realizar uma estimativa o mais próximo da realidade possível, para evitar que atrasos possam prejudicar a empresa.

Estimar com certeza os prazos para a finalização de tarefas dentro do projeto de software é impossível. É normal que algumas entregas não sejam cumpridas, no entanto, é preciso manter o máximo possível todas as atividades dentro do estimado.

Quais são as principais técnicas de estimativa de desenvolvimento de software?

Com a popularização dos métodos ágeis de desenvolvimento, como Scrum, XP, entre outros, surgiu também uma série de técnicas que visam auxiliar os programadores em seu trabalho de estimar atividades do projeto.

Antes mesmo do advento dessas novas técnicas, os programadores realizavam estimativas com metodologias clássicas que constam em livros de Engenharia de Software para tentar encontrar os prazos de suas atividades.

Independentemente da técnica descrita aqui, o primeiro passo é decompor o projeto, ou seja, você não realiza a estimativa de desenvolvimento de todo o software, e sim de partes menores dele. No final, são agradados todos os prazos e encaminhados para aprovação junto ao cliente.

Vamos listar algumas das principais técnicas utilizadas hoje na indústria de software para estimar o tempo de desenvolvimento.

Planning Poker

Uma das técnicas mais queridas, surgida com as metodologias ágeis, o Planning Poker é uma das metodologias mais utilizadas hoje para realizar estimativas de desenvolvimento de software.

A sua utilização é muito simples e pode ser realizada para qualquer projeto, independentemente do tamanho. Essa técnica tem necessidade de um baralho, sendo possível encontrar esse item para venda em algumas lojas e até mesmo ganhá-lo como brinde em algumas convenções de desenvolvimento.

Os números das cartas aqui são diferentes de um baralho normal, baseados na sequência Fibonacci, ou seja: 1, 2, 3, 5, 8, 13, 21, 34 e 55. Acima disso, a tarefa é grande demais é precisa ser dividida em itens menores para poder ser estimada com mais precisão.

O primeiro passo é escolher qual processo será estimado. São necessários no mínimo dois desenvolvedores, que vão ler os requisitos da atividade, então, cada um escolherá uma carta que apresente quantas horas ele acha que levará para concluir aquela tarefa.

Ambos mostram sua carta ao mesmo tempo. Caso tenham estimado de forma diferente, os dois devem explicar por que escolheram aquele tempo e, depois, refazer a passo acima, escolhendo novamente uma carta, com base em seu conhecimento e de acordo com as explicações do colega.

Em uma situação em que a estimativa continue diferente, é escolhido o maior prazo entre as cartas apresentadas pelos desenvolvedores que estão participando do jogo.

Todas as estimativas são anotadas junto a cada uma das atividades e, ao final, são somadas para apresentar qual o prazo total estimado para aquele projeto de desenvolvimento, sendo tal estimativa repassada ao cliente para a aprovação.

Pomodoro

Essa técnica também surgiu com as novas metodologias de desenvolvimento ágil e utiliza alguns dos elementos apresentados no Planning Poker. Aqui, a sequência Fibonacci também é aplicada, porém de uma maneira diferente.

Essa técnica pode ser usada por um único desenvolvedor ou em equipe. O primeiro passo é escolher qual atividade será estimada, e todos aqueles que estiverem participando da estimativa devem ler seus requisitos.

Ao final da leitura, os envolvidos iniciarão as suas apostas de estimativa baseada em um número de pomodoros. O pomodoro é um período composto por 25 minutos de trabalho e 5 minutos de intervalo, ou seja, meia hora de atividade.

As estimativas devem seguir a sequência Fibonacci, a tarefa pode ser estimada em 1, 2, 3, 5, 8, 13, 21, 34 ou 55. Acima disso, ela é muito grande e deve ser dividida em duas ou mais para que a estimativa fique o mais próximo da realidade.

Comparação

Na maioria das empresas, a equipe de desenvolvimento conta com profissionais com bastante tempo de experiência na criação de software e que, com isso, já participaram de diversos projetos.

Dessa maneira, a técnica de comparação pode ser uma boa forma de estimar o tempo de atividades de desenvolvimento de sistemas. Por meio dela, é possível utilizar dados de projetos anteriores para ter uma base sobre o planejamento atual.

É preciso manter uma documentação consistente, contando com todos os prazos utilizados para o desenvolvimento de cada uma das atividades. Para criar um documento que possa ser utilizado posteriormente, você deve salvar as seguintes informações:

• projeto;
• requisito;
• descrição da atividade;
• framework em uso;
• bibliotecas utilizadas;
• principais problemas enfrentados;
• prazo previsto;
• prazo real (dias);
• duração prevista;
• duração real (horas).

Muitas empresas, no entanto, não documentam consistentemente o desenvolvimento de seus softwares e realizam a comparação simplesmente com dados da memória dos envolvidos. Esse tipo de comparação não é tão segura quanto a baseada em documentos.

Com todas essas informações em mãos, basta encontrar alguma atividade similar e estimar o prazo de acordo com o período real que foi necessário para a conclusão da tarefa anterior.

Essa base de conhecimento pode ir melhorando com o tempo, e as estimativas de sua equipe podem ser cada vez mais próximas da realidade. As desvantagens desse tipo de estimativa é que são necessários esforços de documentação das atividades.

Decomposição

Essa é uma técnica muito simples, porém, não é tão utilizada pelos desenvolvedores por demorar demais quando se trata de um grande projeto. Aqui, o ideal é dividir todas as atividades dentro de um projeto até atingir tarefas mínimas, que possam ser estimadas com exatidão.

Por exemplo, um cadastro de clientes é uma atividade a ser estimada com outras técnicas; já nessa metodologia, é preciso decompor ainda mais. Poderíamos dividir o cadastro em cadastrar, editar, excluir.

Sendo assim, fica mais fácil para o desenvolvedor estimar o real tempo que ele levaria em cada uma dessas pequenas tarefas. Ao finalizar todas as estimativas, basta somar os prazos para verificar qual o período geral para a finalização do projeto.

Quando falamos em sistemas grandes, utilizar a decomposição pode não ser uma boa ideia, uma vez que esses projetos são compostos por muitas atividades, e decompor cada uma delas tornaria a estimativa muito complexa e demorada.

Adivinhação

Pode parecer uma piada em um primeiro momento, mas a adivinhação ainda é utilizada por muitos desenvolvedores na hora de estimar o prazo de entrega de alguma atividade dentro de um projeto.

Isso se deve a vários fatores, mas podemos citar principalmente a falta de comprometimento da equipe e o desconhecimento acerca das técnicas de estimativa. Outro ponto que pode levar os profissionais a recorrer à adivinhação para determinar os prazos do projeto é a falta de experiência.

Quando uma equipe se compromete com o desenvolvimento de um sistema com o qual nenhum dos colaboradores teve contato anterior, não há dados em que se basear, com isso, o famoso “chute” entra em ação.

Pontos por caso de uso

Essa é uma metodologia clássica de estimativa em software e já existe desde 1993, quando Gustav Karner a idealizou com base nos casos de uso criados com auxílio de UML, Unified Modeling Language.

Essa linguagem de modelagem é utilizada em projetos de software que investem muito tempo na confecção de documentação. É utilizada para demonstrar de maneira gráfica todas as interações dentro do sistema.

Ou seja, cada caso de uso é uma tarefa, e o desenvolvedor deve atribuir uma pontuação de acordo com a sua complexidade. Criar um cadastro é uma atividade simples, já desenvolver uma integração com outro sistema pode ser mais complexo.

Cada ponto deve ser equivalente a uma unidade de tempo, podendo ser descrito em horas de trabalho. Sendo assim, quanto mais complexa uma tarefa, maior será a quantidade de pontos atribuídos e o prazo para a sua conclusão.

Técnica Delphi

A técnica Delphi tem como principal diferencial impedir que a opinião de um dos membros da equipe acabe por influenciar as respostas de todos os outros profissionais.

Isso acontece, geralmente, quando alguém da equipe é um profissional renomado. Ao dar sua opinião sobre o tempo necessário para uma atividade, os outros colaboradores podem ficar intimidados para discordar.

Nela, é preciso criar um questionário simples com cada atividade que faça parte do projeto para que o profissional descreva o prazo necessário para a sua conclusão. Depois disso, todos colocam suas respostas em um recipiente e um facilitador que não está participando da estimativa analisa a resposta.

Assim, nenhum dos envolvidos pode precisar de quem é cada resposta, não sendo influenciado por ninguém. Caso não haja um consenso sobre o prazo necessário, pode-se realizar novas rodadas.

Ponto de função

A análise de ponto de função não é uma técnica para estimar o tempo de desenvolvimento especificamente, mas sim para ter uma ideia geral do tamanho do software, informação essencial para a estimativa.

Os pontos de função são baseados naquilo que se espera que o sistema seja capaz de fazer, e não como ele deverá ser desenvolvido, isso com base nos requisitos lógicos levantados junto ao cliente pela equipe.

Essa é uma técnica bem complexa e capaz de estimar com precisão o tamanho de um sistema. Cada funcionalidade, na visão do usuário, recebe uma determinada pontuação de acordo com a sua complexidade.

Ao final, tem-se uma ideia geral do tamanho do software que deverá ser construído e, com isso, pode-se aplicar as técnicas de estimativa para se construir um prazo geral para conclusão de todas as atividades do projeto.

Técnica paramétrica

A estimativa paramétrica utiliza o conhecimento acumulado anteriormente, transformando os dados em informações estatísticas que poderão ser utilizadas para realizar a estimativa do tempo de trabalho necessário para o desenvolvimento de cada atividade.

Por exemplo, em uma média histórica, um desenvolvedor necessita de 1 dia de trabalho para escrever um código de 1.000 linhas. Ao levantar quantas linhas de código serão necessárias para criar um determinado sistema, você poderá calcular qual o prazo para a conclusão do projeto.

Em nosso exemplo, se um software necessita, somando todas as suas funcionalidades, de 30.000 linhas, o tempo será de 30 dias, e o prazo, levando em consideração finais de semana, sem feriados, será de 40 dias.

O principal problema dessa técnica é que nem todos os profissionais terão uma produtividade próxima da média, sendo que também é preciso levar em conta a complexidade de cada uma das atividades. Nem sempre o desenvolvedor poderá atingir a meta diária, de acordo com a tarefa sendo desenvolvida.

Como fazer a estimativa de desenvolvimento de software?

Bom, você já deve ter observado a quantidade de técnicas e metodologias que existem para realizar a estimativa de tempo de desenvolvimento de software, no entanto, como aplicar uma delas em sua empresa?

Capacite-se

O primeiro passo é se capacitar da melhor forma possível na técnica que você escolheu para realizar estimativas dentro de sua empresa. Em nosso pequeno guia, não está desenvolvida totalmente cada uma das metodologias, pois se trata apenas de uma apresentação inicial.

Busque entender a que você escolher lendo exemplos e casos de uso de pessoas que já utilizam essas técnicas em seu dia a dia. Para algumas das metodologias descritas, existem cursos e fóruns de discussão em que você pode encontrar muito mais informação.

Adote desenvolvimento ágil

A busca por desenvolver software da forma menos descomplicada possível levou ao surgimento de uma série de metodologias de desenvolvimento ágil. Esse tipo de abordagem costuma facilitar muito o processo de criação de software, inclusive quando se trata de estimar o tempo para finalização do projeto.

Você deve se lembrar de que, nas técnicas descritas acima, as que eram utilizadas em projetos ágeis eram muito mais simples de serem aplicadas.

Busque o comprometimento de sua equipe

Realizar estimativas de desenvolvimento de software não é uma atividade que pode ser feita apenas pelo gestor de TI, mas uma responsabilidade que deve ser compartilhada com a equipe.

No entanto, é preciso exigir o comprometimento de todos com essa atividade, que é chave para a empresa. Uma estimativa malfeita pode levar ao estresse junto ao cliente e desgastar a sua marca, prejudicando a imagem da empresa no mercado.

Analise os requisitos com seriedade

Para estimar, é preciso conhecer o que se está estimando. Invista em um bom analista de requisitos. Esse profissional é o principal responsável por trabalhar junto ao cliente para descobrir quais são as suas expectativas com o software.

Por meio das demandas levantadas pelo analista de requisitos é que sua equipe poderá realizar a estimativa de prazo para o projeto sem correr riscos com o surgimento de novas demandas inesperadas durante o desenvolvimento.

Quais são as dificuldades da estimativa de desenvolvimento de software?

Um estudo da Forecast, empresa americana de gestão de projetos, indica que cerca de 66% dos projetos de desenvolvimento de software extrapolam os prazos determinados na fase de planejamento e acabam por gastar muito mais do que deviam.

Esse tipo de situação causa grande estresse em toda a equipe, que não foi capaz de entregar a solução no prazo determinado, e desgasta a imagem do gestor responsável pelo projeto junto aos diretores da empresa.

Esse tipo de dificuldade vem, geralmente, de duas principais causas:

Falta de comprometimento da equipe

Um erro ocorrido na hora de estimar é a falta de visão da equipe quanto à real importância dessa fase para o desenvolvimento. É preciso responder a uma série de pessoas, incluindo os diretores e clientes.

É necessário que os colaboradores entendam que o nome deles também está em jogo e que deve-se ter seriedade na hora de realizar as estimativas, uma vez que, caso os prazos sejam perdidos e o orçamento descontrolado, seu emprego também está em risco.

Desconhecimento dos requisitos

Por mais que todos saibam que estimar prazos sem conhecer os requisitos é um suicídio, muitos gestores fazem isso constantemente com o intuito de agradar o seu cliente.

É comum que os desenvolvedores devam realizar a estimativa de funcionalidades e, depois de já iniciada a codificação das funções, os clientes acabem por mudar de ideia acerca de seus requisitos iniciais.

Esse tipo de situação faz com que a moral da equipe baixe, sejam exigidas horas extras, se extrapole o orçamento e seja necessário o retrabalho, simplesmente porque os requisitos não foram levantados corretamente.

Esperamos que este guia acerca do esforço para o desenvolvimento de software possa ter auxiliado você a entender o quão importante é essa atividade para a sua empresa e qual a melhor maneira de realizá-la.

Gostou deste post? Quer receber conteúdo exclusivo diretamente em seu e-mail? Então assine agora a nossa newsletter e não perca nenhuma de nossas publicações!