项目开始时的敏捷方法和数据库

敏捷的新手，我不确定如何开始。这个想法是在sprint中创建项目的一小部分。但是，我正在处理的项目需要一个数据库，并且该数据库必须具有几乎可以正常运行的功能才能对该项目执行任何操作。

那么，敏捷项目如何处理这个问题，首先要创建数据库吗？

您将如何操作，例如，如果使用Scrum，您将如何处理用户故事并测试数据库。

您是否愿意在还需要代码的故事中做数据库的一部分。

假设您有一个故事“作为用户，您必须能够注册...”，您是否会在数据库中创建user表作为该故事的一部分？

敏捷如何帮助您设计数据库？

是的，您将通过添加故事所需的必需表和列来逐步构建数据库。当您开始第一个故事时，通常不需要整个数据库-例如“作为用户，您必须能够注册...”很可能需要具有完全定义的一组列的单个表。

如果您的故事确实需要整个数据库，那么这个故事就是Epic-它太大了，必须分开。

敏捷的新手，我不确定如何开始。

阅读您的文章后，我认为您误会了它，您应该先阅读敏捷的真正含义并尝试实现。

这个想法是在sprint中创建项目的一小部分。

关闭，但不够接近。这个想法是在每个sprint的末尾提供工作软件（系统的一部分可以适合一个sprint）。当且仅当数据库是您交付给客户的数据库时，该数据库才能被视为有效软件。

但是，我正在处理的项目需要一个数据库，并且该数据库必须具有几乎可以正常运行的功能才能对该项目执行任何操作。

为什么它必须几乎功能正常？系统的每个功能都使用数据库的全部还是大部分内容？因为如果没有，那么事先设计整个数据库是没有意义的。

那么，敏捷项目如何处理这个问题，首先要创建数据库吗？

敏捷不处理数据库或系统设计。它告诉您如何管理您的项目。考虑到这一点，您首先要确定系统的所有功能，并将其放入产品积压中。然后，您与产品所有者一起为积压工作中的功能分配优先级。完成之后，您就可以从待办事项中获取功能并创建冲刺（通常需要2到4周的时间）。冲刺结束后，您应该在系统中具有可以交付给客户的新工作功能。

您将如何操作，例如，如果使用Scrum，您将如何处理用户故事并测试数据库。

我可能是错的，但是测试数据库毫无意义。您可以测试更新数据库的代码。当然，您可以测试数据库的可编程部分，但是可以通过测试调用数据库的代码来实现。

您是否愿意在还需要代码的故事中做数据库的一部分。

是。

敏捷绝不是项目管理的灵丹妙药，如果应用不当，可能会带来灾难。尝试花一些时间来阅读它（您可以在此处或在stackoverflow上找到大量资源），也许找到一个已经做过敏捷并且可以帮助您快速入门的人。

数据库必须具有几乎可以正常运行的功能，才能对项目执行任何操作。

很大程度上是错误的。

那么，敏捷项目如何处理这个问题，首先要创建数据库吗？

一个空的数据库，是的。然后根据需要添加表以完成冲刺。

您将如何处理用户案例并测试数据库？

你在问什么？敏捷与数据库设计无关。

你写的故事。

您设计解决方案。

您创建表和代码。

您测试代码。

您是否愿意在故事中也需要代码的部分数据库？

还有什么其他选择？首先执行所有数据库吗？这不可能。

“作为用户，您必须能够注册...”您是否会在数据库中创建用户表呢？

首先，这是一个无用的故事，因为注册没有任何价值。这仅仅是用户被迫通过的技术障碍。

其次，您将创建足够的表来实现该故事。

敏捷如何帮助您设计数据库？

你在问什么？

敏捷就是项目管理。它对任何设计都没有帮助。

它只是帮助您将大工作分解成小块。

首先，采用增量方法，选择一个模块定义其需求，确定功能，确定功能区域，然后进行建模，数据库设计，算法，代码，最后对其进行测试并重复该过程。

您的问题激怒了AgileFall开发反模式。

它是什么？通常这是一个组织，该组织传统上以Waterfall方法开发软件，但随后由于他们意识到它不起作用，因此在内部难以采用敏捷技术。通常，由于真正的敏捷性要求从许多已建立的Waterfall商店的构造方式上进行根本的组织变革，因此通常会产生“失败的高潮”。当然，他们会趋向于保持结构化，因为当敏捷展示出这些人对软件开发的真正用处时，许多强大而终身的人认为他们需要将自己注入流程。

您需要逃避这个想法，即您从头开始，设计和构建数据库，然后进入中间层，而无需再次接触数据库。这是在敏捷中执行错误的方法。

从用户故事的域模型开始，然后逐步升级到数据库，再向下升级到中间层和演示文稿。