Acredito que você já teve a ideia de adiantar algum serviço para economizar tempo, não é? Por exemplo, antes de cozinhar, você pode deixar os ingredientes cortados e separados na mesa para adiantar o tempo de preparação. Você acha que aplicar essa mesma ideia no desenvolvimento de um software é uma vantagem? É mais provável que o desenvolvedor ganhe ou perca tempo?
Introdução
No desenvolvimento de software, existe uma cultura que se resume em “adivinhar” o que o cliente deseja, ou melhor, prever os seus requisitos. A vantagem, de acordo com essa cultura, é adiantar o projeto de software antes que a fase de desenvolvimento comece. Dessa forma, uma parte do software já estará desenvolvida logo no início do projeto, garantindo um maior tempo para a finalização das atividades posteriores. Essa cultura é conhecida como BDUF – Big Design Up Front.
Considere o seguinte cenário: uma empresa de desenvolvimento de software fechou um contrato com um cliente para desenvolver um software para loja de calçados. O contrato, aprovado pelo cliente, menciona que o início do levantamento de requisitos será daqui a 30 dias.
“30 dias?! Então temos praticamente um mês de vantagem para adiantar algo!” – esse é o pensamento dos gestores que já consideram a possibilidade de praticar o BDUF. Para aproveitar esse tempo, a empresa procura prever os requisitos do cliente e começa a desenvolver algumas telas básicas, relatórios e funcionalidades, mesmo sem conhecer exatamente quais e como realmente serão essas telas.
Então BDUF é benefício?
Continue acompanhando a história…
30 dias depois, ao levantar os requisitos com o cliente, os gestores notaram que MUITAS diferenças do que já foi feito. As telas básicas possuem mais campos, os relatórios apresentam outro formato e as funcionalidades exigem validações não planejadas. Enfim, a maioria dos artefatos desenvolvidos estão bem divergentes do que o cliente pediu. E agora, o que fazer?
Simples. Vamos refazer tudo, já que o prazo não foi afetado.
Neste caso, você literalmente perdeu 30 dias de esforço. Todos os desenvolvedores alocados e o tempo gasto foram simplesmente em vão. Estes recursos poderiam ter sido utilizados em outros projetos em andamento, treinamentos, atividades de programação (Coding Dojos), atualização de ferramentas ou até mesmo férias para alguns desenvolvedores enquanto o novo projeto ainda não estivesse ativo. Além disso, imagine o quão ruim seria informar os desenvolvedores de que todo o esforço expendido nos últimos 30 dias foi praticamente inútil. Eu, se fosse um destes desenvolvedores, me sentiria improdutivo.
Bom, então basta reaproveitar o que foi feito.
Aqui mora um grande problema! Ao tentar reaproveitar as funcionalidades previamente desenvolvidas, já estaremos criando um princípio de dívida técnica. Teremos que analisar os métodos que serão descartados e as linhas de código que poderão ser reaproveitadas. Em outras palavras, será necessário realizar uma manutenção em um código que nem sequer entrou em produção. Estranho, não? Na prática, ajustar o código existente poderá levar muito mais tempo do que reescrever todo o código, além de não deixar garantias de que não haverá código desnecessário.
Digo isso porque, certa vez, fui vítima da consequência do BDUF. Desenvolvi uma tela de gerenciamento financeiro com várias opções, tentando prever as necessidades do cliente. No entanto, a forma como me coloquei no lugar do cliente foi totalmente diferente da realidade. Quando eu finalmente recebi os requisitos da gestão financeira, imediatamente identifiquei a necessidade de várias modificações. Passei um bom tempo tentando extrair o que ainda poderia ser reaproveitado e, no final das contas, decidi recomeçar a implementação. Isso causa um cansaço mental.
Solução para o BDUF
Um dos grandes oponentes do BDUF é o Desenvolvimento Ágil! A arte de desenvolver o software em incrementos, recebendo feedback do usuário e descobrindo novos requisitos quebra completamente a cultura do BDUF. A manutenção do software se torna mais pontual, evitando que modificações radicais afetem o software como um todo. Lembre-se de que um dos princípios do Manifesto Ágil é: “Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito”.
E então, eu repito a mesma pergunta que está no início do artigo: adiantar trabalho no desenvolvimento de software realmente é uma vantagem?
Se você pesquisar mais sobre o assunto, também vai se deparar com o acrônimo BRUF – Big Requirements Up Front. Apesar da ligeira diferença no nome, o BRUF anda de mãos dadas com o BDUF, já que também se trata do procedimento de prever os requisitos do cliente.
Cuidado com o BDUF, pessoal!
Até a próxima!