Para o pessoal que trabalha com desenvolvimento ágil…
Basicamente nos modelos de desenvolvimento ágil o sistema vai sendo elaborado, desenvolvido e entregue por etapas conforme a necessidade do cliente (me corrijam se eu estiver errado). Deve haver refatoração constante no sistema para que esse não vire um remendo só (isso em qualquer sistema, é claro!). Minha dúvida é: como fica a parte do banco de dados, sendo que esse não é tão fácil ser alterado, principalmente por causa das constraints e dos próprios dados em si! Exemplo: entreguei uma parte do sistema para o cliente e depois de algumas iterações descubro que por causa de uma funcionalidade tenho que fazer uma alteração no modelo, então vou ter que criar um script para “arrumar” esses dados! Isso não acaba ocorrendo com certa freqüência, já que não planejei meu modelo da dados desde o início do projeto?
IMO, pode ser até uma vantagem visto que erros na modelagem podem ser corrigidos o quanto antes e não apenas quando todo o schema ja estiver definido e/ou o DB já com os seus terabytes de dados. Claro que mesmo neste último cenário pode acontecer mudanças.
[quote=ASOBrasil]Para o pessoal que trabalha com desenvolvimento ágil…
Basicamente nos modelos de desenvolvimento ágil o sistema vai sendo elaborado, desenvolvido e entregue por etapas conforme a necessidade do cliente (me corrijam se eu estiver errado). Deve haver refatoração constante no sistema para que esse não vire um remendo só (isso em qualquer sistema, é claro!). Minha dúvida é: como fica a parte do banco de dados, sendo que esse não é tão fácil ser alterado, principalmente por causa das constraints e dos próprios dados em si! Exemplo: entreguei uma parte do sistema para o cliente e depois de algumas iterações descubro que por causa de uma funcionalidade tenho que fazer uma alteração no modelo, então vou ter que criar um script para “arrumar” esses dados! Isso não acaba ocorrendo com certa freqüência, já que não planejei meu modelo da dados desde o início do projeto?
[/quote]
[quote=microfilo]As mudanças no banco de dados que devem ser efetuadas são simplesmente… efetuadas
Normalmente as DMLs são versionadas e a cada “entrega” provavelmente passam uma baseline nelas.
Se por acaso uma coluna sumir ou algo assim, provavelmente a alteração vira acompanhada de um plano de migração (e um baita de um backup antes!).[/quote]
O problema não é somente efetuar a mudança, isso tem que fazer mesmo. Minha preocupação é quantas vezes vou ter que efetuar essas mudanças já que não planejei a modelagem desde o começo! Não sei… ainda não consigo ver a parte de modelagem banco de dados se encaixando no processo de desenvolvimento ágil. Acho que a maioria de nós sabe como geralmente é dificil lidar com DBAs; imagine toda hora tendo que alterar o modelo de dados e fazer migrações porque o negócio não foi planejado, acho que vai ter muita treta na certa.
[quote=ASOBrasil][quote=microfilo]As mudanças no banco de dados que devem ser efetuadas são simplesmente… efetuadas
Normalmente as DMLs são versionadas e a cada “entrega” provavelmente passam uma baseline nelas.
Se por acaso uma coluna sumir ou algo assim, provavelmente a alteração vira acompanhada de um plano de migração (e um baita de um backup antes!).[/quote]
O problema não é somente efetuar a mudança, isso tem que fazer mesmo. Minha preocupação é quantas vezes vou ter que efetuar essas mudanças já que não planejei a modelagem desde o começo! Não sei… ainda não consigo ver a parte de modelagem banco de dados se encaixando no processo de desenvolvimento ágil. Acho que a maioria de nós sabe como geralmente é dificil lidar com DBAs; imagine toda hora tendo que alterar o modelo de dados e fazer migrações porque o negócio não foi planejado, acho que vai ter muita treta na certa.
[/quote]
Obviamente, existem técnicas para se minimizar a quantidade de refatoração em banco de dados.
Scott Ambler possui livros que falam sobre esse assunto.
Agile Database Techniques - Effective Strategies for the Agile Software
A modelagem do banco poderia ser feita de forma incremental a cada iteração.
Não vejo onde isso traz tanto problemas. Se você modelar tudo no inicio, corre o risco de lá na frente ter problemas com o modelo e ter que alterar do mesmo jeito.
Enfim, eu nunca desenvolvi um projeto enorme utilizando desenvolvimento ágil, alguem que já o fez teve problema com a modelagem dos dados?
Amigos, passei por uma experiência assim recentemente, desenvolvemos um sistema de “médio-grande” porte, e utilizamos o desenvolvimento ágil, no inicio parece que o modelagem dos dados esta perfeita mais sempre quando o modelo é revisado, e novos módulos são adicionados surgem modificações na base de dados a solução é ser “bem organizado” versionar o sofware e os backups para nunca se perder se não…
E ainda tivemos vários problemas com o DBA que gostava de modificar as configurações do BD semanalmente …afff
Emfim, é uma boa prática, pos, o cliente sempre tem algo novo e vc sempre se preocupa em entregar um módulo, particionando os esforços…
[quote=microfilo]
Enfim, eu nunca desenvolvi um projeto enorme utilizando desenvolvimento ágil, alguem que já o fez teve problema com a modelagem dos dados?[/quote]
Pois é, teoricamente o problema estaria na questão de ter que entregar uma versão funcional a cada iteração e se essa “bombinha” já estiver em produção.
Em desenvolvimento não vejo grandes problemas, mas levar estas alterações para o cliente pode ser traumático. Acaba que a cada iteração teremos que ter um script de migração para o DB. Então assim, o seu DBA (lado negro da força) também tem que trabalhar de forma iterativa.
[quote=paulohbmetal][quote=microfilo]
Enfim, eu nunca desenvolvi um projeto enorme utilizando desenvolvimento ágil, alguem que já o fez teve problema com a modelagem dos dados?[/quote]
Pois é, teoricamente o problema estaria na questão de ter que entregar uma versão funcional a cada iteração e se essa “bombinha” já estiver em produção.
[/quote]
Na prática é viável tb. Qualquer projeto “enorme” é dividido em módulos/subsistemas. Vc faz entregas parciais desses módulos/subsistemas. Numa semana vc pode ter, por exemplo:
Numa ambiente de desenvolvimento moderno e orientado a objetos isso não costuma ser problemátio. Os piores problemas acotnecem quando cismam em usar o banco de dados para integrar sistemas e isso sempre causa problema, seja num desenvolvimento iterativo ou não.
Com desenvolvimento OO o banco de dados perde seu papel principal. Mudanças no sistema vão afetar muito mais frequentemente o modelo de objetos do que o modelo de dados.
Bancos de dados para integraçã são um roblema porque cada mudança envolve mudar vários sistemas.
[quote=dedejava]
Desculpa me intrometer, mas eu acho que seja isso.
Isso não é garantir um acoplamento baixo?[/quote]
Sem problemas! Isso é um fórum de discussão então você não está se intrometendo!
Preciso pensar a respeito disso ainda. Também como eu faria isso nos sistemas que trabalho hoje e como eu falaria com o DBA a respeito desse meu modelo. :?:
Refatoração nele! Hehe…
Mas eu acho que o baixo acoplamento diminui muitos problemas… inclusive a quantidade de refatoração que deve ser feita. Você mexe no seu modelo de dados e não precisa mexer no de negócio. Eu acredito que seja assim. Aconteça bastante disso em códigos, mas em modelos de negócio, dados e tal eu nunca trabalhei, então não acredite muito na minha conversa hehehe
Essa parte de lidar com o DBA realmente é complicado.
Estou em um desenvolvimento que em uma reunião na sexta-feira passada tive que convencer o DBA que o Banco não iria ser o integrador de 4 sistemas. Ele e a maioria dos demais participantes vieram a reunião para propor isso, quando eu sugeri que isso não fosse feito. O Pessoal me olhou com uma cara de assustado pois estavam achando que isso seria feito, faltava só comunicar aos demais. Ainda bem que explicando as vantagens/desvantagens de cada abordagem os demais participantes concordaram na hora e a integração via DB foi totalmente descartada.
