SCRUM - Modelagem Banco de Dados - Big Design Up Front?

Assuntos Gerais Agile
#1

Senhor*s,

Como vocês fazem a modelagem do banco de dados, seguindo esse modelo incremental pregado pelo SCRUM?

Aqui na empresa sempre demos muita importância para como o dados são gravados. Sempre tivemos o hábito de tentar criar um modelo completo, o mais próximo da perfeição que abrangesse todas as features do produto. Só que no modelo Waterfall isso é (quase) possível pois temos uma idéia clara (há controvérsias) desde o início, de quais serão essas funcionalidades.

Como vocês lidam com esse “problema” no SCRUM?

Vocês criam as tabelas conforme a necessidade de cada User Story apenas? E nos próximos sprints? E se lá na frente tiver uma User Story que será necessário alterar a estrutura de uma tabela. Imaginem uma alteração grande, de um sistema grande e complexo, com muitos clientes etc.

Além disso estou falando de um produto que está sendo colocado em produção a cada sprint. Changes no banco são sempre chatas e perigosas … vocês sabem disso.

Ou vocês não lidam com esse problema e só eu que estou fazendo essa tempestade no copo d’agua? heheh
Não me surpreenderia se vocês dissessem que sim porque vi pouca ou quase nenhuma discussão sobre o assunto na internet.

Por favor, compartilhem o segredo de vocês! Compartilhem o conhecimento !!! rs

Grande abraço!

#2

Se voce trabalha incrementalmente, suas alteracoes no banco de dados nunca serao tao grandes ou complexas o suficiente para causar problemas. Ou seja, a evolucao da estrutura do banco de dados apenas acompanha a evolucao do sistema como um todo. Isso exige um pouco mais de disciplina para nao quebrar nada a cada mudanca (testes de integracao sao essenciais para isso), mas no longo prazo eh mais facil que tentar adivinhar tudo que voce precisara no seu banco de dados.

De uma olhada em ferramentas como dbdeploy (ou estude migrations do Ruby on Rails). Uso dbdeploy faz tempo e com ele consigo ter diferente bancos suportando diferente versoes do sistema sem maiores problemas.

#3

De qualquer maneira, a sua primeira versão em produção mesmo, vai ter já uma espinha dorsal do sistema como um todo, então como disse o Ivan, as mudanças de banco não devem ser tão grandes assim, a menos que tenham grandes alterações de negócio por exemplo.

[]s

#4