Aprenda o que fazer para estimar o esforço de desenvolvimento de software

Você sabe, com exatidão, quanto tempo leva para que um sistema fique pronto? Existem várias técnicas para estimar o esforço de desenvolvimento de software, cada uma adequada a um tipo de necessidade e a um modelo de desenvolvimento.

Estimar o esforço de desenvolvimento de software é uma forma de criar um planejamento com previsibilidade de tempo, custo, mão de obra, entre outros fatores. O benefício reflete tanto na equipe interna quanto no cliente final de uma empresa.

A seguir, vamos detalhar algumas técnicas para avaliar o esforço de desenvolvimento de software. Confira!

A importância da estimativa de esforço de desenvolvimento de software

A estimativa de esforço é uma importante ferramenta para determinar em quanto tempo o sistema ficará pronto. Esta informação é bastante valiosa no momento de fazer um acordo com o cliente, especificando detalhes sobre prazo.

Uma boa mensuração deixa as expectativas do cliente alinhadas à realidade da empresa, o que reflete diretamente no time. Com isso, são minimizadas cobranças e pressões que ocorreriam em virtude de um prazo irrealista.

Veja agora quais são as técnicas para obter esses resultados!

Planning Poker

O Planning Poker é a forma como os times de desenvolvimento ágil que adotam SCRUM estimam o esforço de desenvolvimento de software. Tendo isso em vista, a técnica faz parte da reunião de planning, realizada no início de cada sprint.

Nela, são apresentadas as funcionalidades em ordem de prioridade, de modo que a mais prioritária é apresentada primeiro. Com base em sprints anteriores, a equipe conhece quantos pontos pode entregar a cada um deles — informação que é usada para definir quais funcionalidades entram no sprint.

Na prática, a técnica consiste em separar as funcionalidades do sistema e reunir a equipe. Nesta reunião, serão apresentadas as funcionalidades que o sistema deve ter, e a equipe, então, votará como em um jogo de poker, usando cartas. Cada carta terá um valor decidido pelo membro da equipe.

Quanto maior o valor impresso na carta, maior o nível de dificuldade daquela tarefa. A seguir, a equipe debate e cada membro justifica seus votos, discutindo sobre eventuais divergências. Uma vez que a equipe atinja a um consenso, é feito um somatório dos valores que cada membro votou: esse será o número de pontos daquela funcionalidade.

Isso será feito para todas as funcionalidades, até que se chegue ao número máximo de pontos para o sprint. Quando este valor for atingido, significa que aquelas funcionalidades votadas serão entregues até o final do sprint. As demais serão analisadas em uma próxima reunião, no início do sprint seguinte.

Pomodoro

A técnica consiste em quebrar o dia de trabalho em pequenas partes. A cada parte, se dá o nome de um Pomodoro, sendo que, entre uma etapa e outra, se tem uma pausa. Normalmente, um Pomodoro separa o tempo em 15 minutos trabalhados e 5 minutos de descanso, valores baseados em estudos sobre o tempo médio em que se consegue manter o máximo de concentração.

Assim, no momento de estimar o esforço de desenvolvimento de software, é possível fazer isso estabelecendo o número de Pomodoros que aquela tarefa vai durar, com base no histórico de tempo que atividades parecidas costumam levar.

O uso da técnica é aconselhável porque tende a manter a concentração do time elevada durante todo o expediente. Por isso, mais do que uma técnica para estimar o esforço de desenvolvimento de software, o Pomodoro é uma ótima ferramenta para melhorar o desempenho das equipes.

O alto nível de concentração mantido durante todo o dia faz com que os sistemas sejam entregues mais rapidamente, sem falar na redução de erros. Por isso, qualquer time pode se beneficiar muito desta técnica. Ao contrário do Planning Poker, o Pomodoro pode ser usado em qualquer modelo de desenvolvimento, além de servir para qualquer atividade intelectual, e não apenas para o desenvolvimento de software.

Técnica Delphi

A vantagem da técnica Delphi é impedir que os integrantes da equipe sejam influenciados pela opinião de outros membros. Assim como no Planning Poker, a equipe inteira é reunida e, a seguir, cada integrante recebe um questionário da atividade a ser desenvolvida.

As respostas de todos os membros são colocadas em uma espécie de urna, que é aberta por um membro neutro, que não faz parte da equipe e deve analisar as respostas de cada um. A partir daí, ele estimará o esforço. Caso as notas dadas pela equipe sejam muito divergentes, deve-se convidar uma nova rodada para que respondam às questões.

Ponto de função

Esta técnica consiste em um modelo matemático para estimar o tamanho de funcionalidades complexas, que também pode ser utilizada para determinar o tamanho total de um software. O método combina bem com modelos de desenvolvimento em cascata, em que se define um prazo antes do início da programação do sistema.

No Ponto de Função, cada funcionalidade levantada do sistema recebe um valor em pontos, que são usados para estimar o tamanho do sistema. Um dos pontos de atenção desta técnica é que ela depende do analista. Como a equipe responsável pelo desenvolvimento não participa, podem ocorrer desvios sobre o planejado.

Comparação

Base do Planning Poker e da estimativa por Pomodoro, a Comparação consiste em estimar esforço de desenvolvimento de software por meio da analogia a atividades parecidas no passado.

Assim, se a equipe levou uma semana para desenvolver 5 CRUDS, é possível concluir que o esforço de cada um deles foi de um dia. A partir daí, sempre que for necessário desenvolver este tipo de funcionalidade, pode-se estimar que o prazo é de um dia.

Para a correta utilização da técnica, é preciso atualizar sempre os valores de cada atividade. Deste modo, há sempre uma estimativa média do tempo que aquele tipo de atividade leva. Progressivamente, isso leva a um nível maior de efetividade das estimativas.

Técnica Paramétrica

Esta técnica usa o mesmo conceito da técnica de Comparação. A diferença é que ela se baseia no número de linhas que cada funcionalidade terá. A partir disso, se compara com o tempo médio por linha de código de desenvolvimento passado.

Um ponto de atenção ao utilizar a técnica se dá quando a equipe muda. Com novos membros entrando e outros saindo, pode-se perder precisão sobre a média de tempo que cada um demora para escrever uma linha de código.

Outro ponto delicado se deve à complexidade diferente entre tarefas. Uma linha de código não é a melhor forma de medir um software. Por isso, nem sempre esta técnica será totalmente certeira.

Agora, você já sabe como estimar o esforço de desenvolvimento de software. Mas lembre-se: para ter estimativas mais curtas, é essencial ser mais produtivo.

Para isso, um ótimo caminho é estar constantemente atualizado sobre ferramentas e técnicas de desenvolvimento. Leia este post para saber como ficar sempre informado sobre atualização de software!