Novo no Agile e não sei por onde começar. A idéia é criar pequenas partes do projeto em sprints. No entanto, o projeto no qual estou trabalhando exige um banco de dados e o banco de dados deve estar quase funcional para fazer qualquer coisa com o projeto.
Então, como os projetos Agile lidam com isso, você começa criando o banco de dados?
Como você faria isso, por exemplo, se estivesse usando o Scrum, como faria as histórias dos usuários e testaria o banco de dados.
Você prefere fazer partes do banco de dados em uma história que também requer código.
Digamos que você tenha uma história que seja "Como usuário, você deve poder se registrar ...", você criaria a tabela de usuários no banco de dados como parte dessa história?
Como o ágil pode ajudá-lo a projetar o banco de dados?
fonte
Respostas:
Sim, você criará o banco de dados de forma incremental adicionando tabelas e colunas necessárias conforme exigidas pela história. Você geralmente não precisa de todo o banco de dados quando inicia sua primeira história - por exemplo "Como usuário, você deve poder se registrar ..." provavelmente requer uma única tabela com um conjunto de colunas exatamente definido.
Se você tem uma história que realmente requer todo o banco de dados, a história é épica - é simplesmente muito grande e deve ser dividida.
fonte
Depois de ler sua postagem, acho que você está entendendo errado e deve começar lendo o que o ágil realmente significa e tenta realizar.
Perto, mas não perto o suficiente. A idéia é fornecer software de trabalho no final de cada sprint (uma parte do sistema pode caber em um sprint ou não). O banco de dados pode ser visto como software de trabalho se, e somente se, o banco de dados for o que você entrega ao cliente.
Por que tem que ser quase funcional? Todos os recursos do sistema usam todo ou parte do conteúdo do banco de dados? Porque, se não, não há sentido em projetar todo o banco de dados de antemão.
O Agile não lida com design de banco de dados ou sistema. Ele mostra como gerenciar seu projeto. Com isso em mente, você começa identificando todos os recursos do sistema e os coloca no backlog do produto. Em seguida, você, juntamente com o proprietário do produto, atribui prioridades aos recursos no backlog. Depois de fazer isso, comece a usar os recursos do backlog e a criar sprints (geralmente de 2 a 4 semanas). Quando um sprint termina, você deve ter um novo recurso de trabalho no sistema que possa ser entregue ao cliente.
Posso estar errado, mas não faz sentido testar o banco de dados. Você pode testar o código que atualiza o banco de dados. Obviamente, você pode testar sua parte programável do banco de dados, mas isso pode ser alcançado testando o código que o chama.
Sim.
O Agile não é de forma alguma um ponto de destaque para o gerenciamento de projetos e pode significar um desastre quando não é aplicado corretamente. Tente dedicar algum tempo a ler sobre isso (você pode encontrar muitos recursos aqui ou no stackoverflow), talvez encontre alguém que já tenha agido com agilidade e possa ajudá-lo a se atualizar.
fonte
Em grande parte falsa.
Um banco de dados vazio, sim. Em seguida, adicione as tabelas conforme necessário para concluir um sprint.
O que você está perguntando? O Agile não tem nada a ver com o design do banco de dados.
Você escreve a história.
Você cria uma solução.
Você cria tabelas e códigos.
Você testa o código.
Que outra opção existe? Faça todo o banco de dados primeiro? Isso é impossível.
Primeiro, é uma história inútil, já que não há valor em se registrar. Isso é apenas um obstáculo técnico pelo qual os usuários são forçados a passar.
Segundo, você criaria tabelas suficientes para implementar a história.
O que você está perguntando?
Agile é gerenciamento de projetos. Não ajuda em nenhum design.
Apenas ajuda a dividir um grande trabalho em pedaços pequenos.
fonte
Primeiro, siga uma abordagem incremental. Selecione um módulo, defina seus requisitos, calcule a funcionalidade, atinja uma área funcional e, em seguida, faça a modelagem, design de banco de dados, algos, códigos e, finalmente, teste-o e repita o processo.
fonte
Sua pergunta grita com o antipadrão de desenvolvimento AgileFall .
O que é isso? Geralmente, é uma organização que tradicionalmente desenvolveu software no método Waterfall, mas, como percebem que não está funcionando, lutam internamente para adotar as técnicas Agile. O "fail-gasm" resultante geralmente ocorre porque o Agile verdadeiro EXIGE uma alteração organizacional fundamental da maneira como muitas lojas Waterfall estabelecidas são estruturadas. E é claro que eles tenderão a permanecer estruturados dessa maneira, pois muitas pessoas poderosas e seguras sentem que precisam se injetar no processo quando o Agile mostra como essas pessoas são inúteis REALMENTE para o desenvolvimento de software.
Você precisa escapar dessa noção de que, de alguma forma, você começa da parte inferior, projeta e constrói seu banco de dados e depois passa para a camada intermediária e nunca precisa tocar no banco de dados novamente. Essa é a maneira errada de fazer isso no Agile.
Comece no modelo de domínio para uma história de usuário e vá até o banco de dados, e DOWN até a camada intermediária e a apresentação.
fonte