20 dezembro 2007

Melhoria continua

Não, infelizmente não vou falar sobre melhoria contínua. O título do post é só uma referência vaga ao belo nome que o ViniciusTeles arrumou para a ImproveIT.

Enfim, não tenho como não me expressar sobre o último post do Vinicius no site da ImproveIT. Há tanto para se refletir e discutir a respeito dele que nem vou me atrever a entrar em detalhes. Só gostaria de mencionar a forma como as coisas se parecem pra mim.

Lembro bem a primeira vez que vi o livro de XP do Vinícius numa livraria. Tava esperando a hora do cinema, mexendo nos livros e então me deparei com o livro dele: XP. Caramba, já tem gente falando de XP no Brasil, que massa!

Fiquei empolgado mesmo, pois na época nunca imaginava que o XP ia prosperar tanto. De lá pra cá (lá se vão uns 2 ou 3 anos), é simplesmente impressionante como o próprio conceito Agilidade se incorporou na cultura empresarial brasileira.

O Vinícius comentou no referido post exatamente a visão que tenho sobre a disseminação do Scrum e sua relação com todo esse movimento de agilidade. É bem verdade que o Scrum trouxe essa visão oportunista (pra não dizer vigarista/charlatã) que ironicamente alavancou as coisas por aqui. É duro que nosso país viva nessas sombras imperialistas até hoje, especialmente na área de tecnologia...

Mas por outro lado, notemos a importância de iniciativas como a do Vinicius e da ImproveIt. A quantidade de comentários solidários no post, num período muito curto de tempo (algumas horas) ilustra o tamanho da comunidade que se formou em torno deles. (Da qual, aliás, também faço parte.)

Claro que eu também teria rios de opniões pra debater todos os pontos levantados naquele post, mas vou me conter a felicitar o pessoal da ImproveIt pela coragem e pela sinceridade da iniciativa.

Por um lado, a notícia causou certa tristeza, pois teve um leve tom de "desistência" diante das incoerências desse mercado. Mas por outro, estou tranqüilo, pois sei que o Vinícius e os demais da ImproveIt continuarão "por perto", participando e contribuindo para o amadurecimento de nossa "indústria", como sempre estiveram. Certamente ainda veremos palestras, podcasts, posts, artigos e tudo mais.

Obrigado Vinícius!

07 dezembro 2007

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