A resposta para essa questão ainda se divide entre sim e não. Como desenvolvedores experientes, somos sempre levados a pensar lá na frente. Temos a tendência de implementar coisas que não são necessárias no momento, mas que nós sabemos (ou achamos que sabemos) que serão úteis depois. Note que não estou falando de BDUP, mas sim de YAGNI. Esse povo de TI adora sopa de letrinhas, né?

Por exemplo, em um projeto mais antigo aqui na Qualidata, decidimos implementar logo nos primeiros sprints funcionalidades relacionadas à permissão dos usuários. Um primeiro equívoco, pois claramente essas funcionalidades não agregavam muito valor para o cliente e não eram tão importantes.

Era importante distinguirmos os usuários, mas isso não significava controlar perfis e permissões nas funcionalidades. Além disso, pensando lá na frente, definimos um esquema de perfis de usuário com herança, que era uma evolução dos mecanismos que utilizávamos em outros sistemas mais antigos.

Em outras palavras, não só priorizamos funcionalidades que agregavam pouco valor para o cliente em termos de visibilidade do software que estava sendo construído, mas incluímos requisitos que não sabemos se seriam realmente úteis para esse software em particular.

Não estou dizendo que eles não eram úteis, mas nós poderíamos tranquilamente implementá-los de forma mínima e depois evoluirmos para uma solução mais sofisticada quando a necessidade surgisse.

Temos buscado seguir o princípio YAGNI na Qualidata, mas de forma madura, pois um remédio mal administrado pode virar veneno. No último projeto que iniciamos, temos priorizado o que realmente importa – os requisitos funcionais, em ordem de importância segundo o cliente.

Nos primeiros sprints, a persistência (NHibernate) não estava mapeada de forma definitiva. Sem problemas! Havia algumas indefinições sobre como persistir objetos de valor (ValueObjects do DDD), pois não queríamos criar IDs para eles, mas para o banco de dados (e para o NHibernate) seria importante termos propriedades que funcionassem como chaves primárias.

Para resolver, criamos inicialmente os IDs no domínio e fizemos um automapeamento bem trivial no NHibernate. Sem problemas! Depois resolvemos isso e retiramos os IDs, pois não existiam em nossa linguagem ubíqua.

Embora uma ideia geral da arquitetura já tivesse sido definida num tipo de Sprint 0 que chamamos de setup do projeto – no qual avaliamos arquiteturas candidatas e definimos em linhas gerais como será estruturado o software -, muita coisa precisava ser definida e construída na infra do sistema. Sem problemas, decidimos resolver isso aos poucos, ao longo do desenvolvimento.

Apesar de termos requisitos não funcionais fortes na questão da segurança da informação, envolvendo criptografia de todos os dados persistidos e uso de certificados e assinaturas digitais válidos (ICP-Brasil), não precisamos resolver tudo isso no início do projeto. Precisamos muitas vezes construir pequenos projetinhos pilotos para testar as tecnologias envolvidas (um tipo de estudo de viabilidade) e nos dar o mínimo de segurança de que temos condições de mais adiante adicionar essas funcionalidades ao software sem termos grandes impactos no que está construído.

Concluindo, não é errado pensar lá na frente. A experiência nos traz a habilidade de prever problemas e necessidades, e devemos utilizar esse conhecimento de forma sábia. Mas isso não significa que precisamos resolver tudo isso no início de um projeto, construindo toda uma parafernália que não será inicialmente (e talvez nunca) utilizada – com a justificativa de que estamos investindo agora para colher lá na frente.

Muitas vezes o custo de desenvolvermos boa parte desses recursos mais adiante será praticamente o mesmo. Precisamos pensar lá na frente o mínimo necessário para estarmos seguros de que no final tudo vai se encaixar adequadamente.

Para finalizar, um exemplo emblemático dessa situação aconteceu em um projeto de que participei há alguns anos. Planejamos que dedicaríamos o primeiro mês para a implementação de funcionalidades infraestruturais do software e, ao longo desse mês, acabamos decidindo construir todo um framework.

A estimativa é de que levaríamos aproximadamente dois meses para construí-lo e que ele nos daria um considerável ganho de produtividade, que no final valeria a pena. Para encurtar a história, gastamos 6 meses construindo o bendito framework. Tivemos, sim, ganho de produtividade, mesmo com esse atraso todo, mas depois não foi lá essas coisas. Ainda ficamos todo esse tempo sem mostrar nenhuma funcionalidade para os usuários.

Entre os gestores da empresa cliente, que sempre perguntavam sobre o andamento do projeto e que não eram de TI, a palavra framework virou piada e sinônimo de enganação. Sempre que eles tinham de dar alguma desculpa esfarrapada entre eles, brincavam dizendo “estou construindo um framework (…) mas vamos ganhar muito lá na frente”.

Resumindo: ganhe produtividade, ofereça funcionalidades e pense lá na frente quando for preciso, mas não perca tempo. Até a próxima!