Sobre Estimativas de Software

Publicado em Julho 22, 2017

Com certeza há muito assunto e trabalho sobre estimativas em desenvolvimento de software. Esteja você em uma grande empresa, uma pequena agência ou o famoso projeto com o “exército de um homem só”, a ideia de que você possa prever quanto tempo levará para construir um sistema é amplamente difundida e adotada por todos.

Qualquer princípio de gestão ou cronograma de projeto tem isso como um mínimo para operar. Isso é útil para que você possa planejar com antecedência e lidar com os projetos em uma ordem sã, evitando armadilhas óbvias e erros de negócios. Em um ambiente de várias equipes, ele é usado para coordenar as entregas de forma que uma equipe não bloqueie a outra, mapeando as dependências e adequando o trabalho de forma saudável.

O único problema é que, na maioria dos casos, as estimativas de software estão erradas. Freqüentemente, por uma grande margem.

É provavelmente um dos problemas mais analisados da indústria, e ainda, um dos mais não resolvidos.

Apresentando o Elefante na Sala

As estimativas de projetos de software falham em enorme escala desde o surgimento de software.

Antigamente, com metodologias de Cascata, esse problema geralmente se perdia no meio de todo o processo. Era fácil culpar os testadores pelo tempo que levava para encontrar os bugs, e mais fácil ainda culpar os sysadmins pelos atrasos que ocorriam durante as tentativas de implantação. A segmentação de todo o fluxo e a ideia de que o tempo do projeto consistia principalmente na “Fase de Codificação” mantiveram oculto o problema específico de estimativa de tempo. A criação de equipes multifuncionais ajudou a trazer o problema para o centro dos holofotes, mas pouco pôde fazer em um projeto de meses (ou anos) de duração.

A disseminação do desenvolvimento ágil, realizado pelo Manifesto para Desenvolvimento Ágil, identificou esse problema e criou uma série de maneiras de lidar com ele e tornar a estimativa mais acertiva. Existem Sequências de Fibonacci, Histórias de Usuário em Tamanho de Camiseta, Velocidade do Sprint e muitos outros, e a ideia de quebrar projetos inteiros em uma série de pequenos recursos minimizou a questão, porque, é claro, uma estimativa de uma semana errada é muito melhor que a de um mês. Outra melhoria em relação aos métodos mais antigos é a reação e a priorização trazidas por uma lista de requisitos clara nas mãos do Product Owner. Poder mudar de curso durante a chamada “Fase de Construção” é, provavelmente, a lição mais valiosa que o Ágil trouxe para o mundo do software.

(que devemos estar sempre na “Fase de Construção” é assunto para outro post)

Com a soma de equipes multifuncionais, quebra de funcionalidades e priorização, fomos capazes de trazer todos os envolvidos no processo de uma forma que deixasse claro os esforços de construção de software. Com isso, poderíamos explicar por que a funcionalidade X está demorando tanto para ser concluída e por que a equipe Y está tendo um bom desempenho. A taxa de entregas e o valor entregue de cada peça tornaram-se mais claros e palpáveis.

No entanto, os projetos longos ou complexos ainda erram suas estimativas. Tal falha é tão difundida que algumas empresas simplesmente deixam de estimar e, mesmo com a transparência de todo o processo, ainda lutamos para encontrar um método lógico que traga algum nível (qualquer nível) de assertividade.

Por que devemos nos importar?

Curto muito o Software Craftsmanship Manifesto. Acho que, no estado atual do mercado, o Desenvolvimento de Software está mais próximo da arte do que da ciência. Pegue dez desenvolvedores e peça a cada um deles a mesma tarefa. Veja como eles chegarão a você em momentos diferentes, com diferentes questões sobre a tarefa e soluções completamente diferentes, cada uma com alguma parte móvel estranha e especial.

(essa é a razão pela qual eu acho que os desenvolvedores de software, apesar do estresse, estão geralmente felizes com sua ocupação. Talvez não felizes na empresa atual, mas feliz com seu ofício)

Isso é, obviamente, um problema para qualquer negócio sério. Planejar com antecedência, e mais importante planejar assertivamente, é a diferença entre a vida e a morte de uma empresa. Esta é a forma atual de calcular valores num orçamento, monitorar metas e definir o sucesso ou o fracasso de um projeto, e ser incapaz de fazer isso de forma concreta é o que torna o “Departamento de TI” o mais complexo de ser gerenciado em qualquer tipo de campo da indústria.

Deixar de trazer qualquer tipo de estimativa real e assertiva é uma falha em toda a indústria e prejudica todos os setores que dependem de software (ou seja, “todos os setores”). Resolvê-lo, ou apenas melhorá-lo um pouco, nos aproximaria de formas mais maduras de engenharia.

(É por isso que geralmente evito o termo “Engenheiro de Software”, mas esse também é um assunto para outra postagem)

Tentativas da indústria até o momento

Como dito acima, o Manifesto Ágil abordou esse problema e trouxe algumas formas de mitigá-lo. Listarei abaixo algumas das abordagens que experimentei e minha opinião sobre elas.

• Sequência de Fibonacci: A forma mais difundida num primeiro momento de estimativa de tempo. O Scrum foi o principal responsável pela sua disseminação. O principal problema com este é que uma história de tamanho 13 não é o mesmo que duas histórias 5 e uma de 3 (!). Por isso, é necessário tabelar a velocidade historica do time em cada tamanho de historia e tentar encaixar o proximo sprint em algo similar ao que já passou para trazer uma estimativa confiável.
• Pontos de função: Este é realmente complicado e… bem, ruim. Ele calcula um número que simboliza a complexidade dos requisitos, com base nas entradas e saídas do usuário e interfaces externas (entre outras coisas). Como as entradas do usuário são diferentes umas das outras e as interfaces externas são muito diferentes entre si (tente integrar com um serviço Rest e um Soap e me diga quanto tempo cada uma vai demorar), o número sempre falha.
• Histórias do mesmo tamanho: tente dividir todas as suas histórias em um tamanho semelhante para que você possa obter uma mediana do tempo gasto em cada uma. Dessa forma, você saberá que, se um projeto tiver X histórias, demorará X * “tempo por história” para terminar. A parte complicada é: “Como dividir histórias do mesmo tamanho?”
• T Shirt Sizes: Mais são, é claro, do que pontos Fibonacci, porque uma história de tamanho M não é do mesmo tamanho que duas de tamanho P. No entanto, isso traz dois problemas: identificar a diferença entre um M e um G (e assim por diante) e calcular o tamanho do sprint apropriado. Simplificando, se sua equipe passou três meses fazendo apenas tamanho M, agora que você só tem G s, quanto tempo eles vão demorar para terminar?

Conclusão

Não existe uma solução simples para o problema, mas a melhor maneira de mitigá-lo é dividir o trabalho em pequenos passos. Pessoalmente, não gosto de quebrá-los muito pequenos, porque cada história tem uma sobrecarga no processo (ou seja, uma história que é apenas uma mudança de caracter levará mais tempo para escrever e validar do que fazê-la de fato), mas um tamanho “menor que uma semana” é bom o suficiente.

Pela minha experiência, vale a pena tentar quebrar as histórias no mesmo tamanho, ou o mais próximo possível. A principal ressalva é que os desenvolvedores precisarão ajudar a dividir as histórias, porque eles são os únicos capazes (já que conhecem os aspectos internos do sistema). Você também precisará estar OK com fatias não ideais em favor da previsibilidade.

Além disso, tudo se resume ao gerenciamento de expectativas. Deixe claro para todos os envolvidos os planos e marcos. Quando as histórias começarem a se prolongar além do esperado, reexamine o problema e as estimativas. Transmita o passo a passo. Dessa forma, as partes interessadas podem planejar e reagir de acordo.

Não resolve o problema, mas atenua-o e deixa o processo mais saudável e transparente.