Bancos de dados ágeis

A alguns meses passei por uma situação que me fez refletir um bocado e fortalecer ainda mais a crença de que o fator mais crítico do desenvolvimento de software atualmente está mesmo nas relações sociais.

Estávamos trabalhando em um projeto grande, e já haviamos conseguindo conquistar uma confiança importante da equipe e do cliente em relação aos métodos ágeis. A equipe era formada por programadores da empresa em que trabalho e programadores do cliente, numa espécie de "desenvolvimento a 4 mãos".

Depois que já estávamos conseguindo implantar uma versão toda semana, acertando as estimativas, escrevendo testes e outras coisinhas, deparamos com o problema do banco de dados evolutivo.

Até aquele momento, isso não era realmente um problema, pois ainda não tínhamos uma versão do software efetivamente em produção, o que nos permitia apagar todo o banco e criar de novo, causando problemas (pequenos) apenas para a única pessoa que estava fazendo testes manuais nas versões lançadas toda semana. Mas logo o problema viria à tona, pois o sistema já estava bastante estável e faltavam poucas funcionalidades para que o sistema se torna-se realmente útil e pudesse ser utilizado "no quente".

Nesse momento, durante nossa reunião de planejamento da semana (na segunda feira), gastamos uns 10 minutos discutindo o assunto, e me veio a idéia de implementarmos (em java) algo parecido com as migrations do rails: A idéia era mantermos o modelo do banco em scripts SQL numerados sequenciamente e manter em uma pequena tabela, no banco, o número da "versão" em que o modelo se encontrava, de modo que o modelo e os dados pudessem ser atualizados "automaticamente" pela aplicação, no momento em que ela fosse iniciada.

A princípio a idéia foi bem aceita, e já estávamos pra um post-it e planejar a tarefa, quando um dos membro da equipe torceu a cara e disse algo como "humm.. não sei não, isso de manter o banco de dados é tarefa para DBA. Nós vamos acabar arrumando problemas caso isso dê problema. Melhor não mexermos com isso..."

Puxa, aquilo foi brochante. A equipe, num piscar de olhos, se desmotivou e desistiu da idéia antes que eu pudesse pensar num argumento para desfazer o feitiço que nosso amigo havia jogado. Não escrevemos o post-it e, até onde sei, o sistema até hoje não entrou em produção.

Depois que tudo passou (nem estamos mais trabalhando no projeto), guardo esse caso como um exemplo de como as relações sociais entre os envolvidos com o projeto pode afetar em questões técnicas capitais. A insegurança e falta de iniciativa de um único membro da equipe foi suficiente para descartarmos uma decisão técnica que poderia viabilizar as implantações parciais do sistema, o encurtamento do ciclo de feedback, o aumento de comunicação entre a equipe e o cliente, etc., etc., etc..

Me lembrei desse pequeno incidente hoje, depois de ter assistido ao último programa do OnSoftware pelo Miro, que se trata de alguns comentários do Scott Ambler sobre seu livro "Refactoring Databases": http://media.podhoster.com/pearsoned2/30_SOFT_Ambler_01.mp4