许多圈子都赞扬了数据管理中的敏捷过程，因为它具有包容性，快速的方法，据称涉及企业的不同方面。然而，根据InfoAdvisors的Karen Lopez和Embarcadero的Ron Huizenga主持的2015年企业数据世界举办的题为“ER / Studio和数据建模特别兴趣小组”的特殊兴趣小组，这些圈子通常不包括专门从事数据建模的专业人士。

敏捷过程经常使数据建模的关键组件在其以多种关键方式产生的各种应用程序和数据库中变得复杂，包括：

• 排除：在各种开发人员，Scrum主人和业务分析师处于实际需要某些数据的阶段之前，数据建模者通常不会进入敏捷过程。更糟糕的是，正如洛佩兹所指出的那样，“因为我是一名顾问，通常我会参与一个敏捷的项目，这个项目是敏捷的，他们没有数据建模者，也没有数据架构师，他们已经构建了这个数据库而他们不能获取或输出数据或不执行数据。通常是一团糟。“
• 开发人员与建模者：开发人员和数据建模人员的目标，方法和需求之间存在许多区别，这些差异提供了各种冲突点。由于敏捷周期通常以开发人员开始和结束，他们的倾向会加剧建模人员的参与。
• 玩捉鬼：由于敏捷项目一开始就被排除在外，建模人员通常必须追赶一个理想情况下应该在冲刺之前工作的过程。许多建模者同时在几个不同的敏捷团队中工作并不罕见。

特殊利益集团坦诚地讨论了这些问题和其他问题，这些问题产生了大量关于数据建模必要性的解决方案和见解。

敏捷环境中的数据建模异同

从理论上讲，数据建模的基本原理在敏捷环境中的存在与在它们之外的情况相同。建模人员通常负责在概念，逻辑和物理层面实施数据，同时还要考虑企业数据模型。但是，在敏捷环境中，它们还必须适应可能存在关键差异的项目模型。故事取代了上述模型中提供的要求 - 这些要求往往缺乏前者的细节。洛佩兹提到：

“通常当我被引入时，我会在开发人员和DBA同时获得故事，开发人员就像'我的桌子在哪里'？而且我想，'我甚至没有读过这些故事'。顺便说一句，这些故事总是废话，因为他们说的话，“然后我们必须收取销售税”，这就是要求的程度，我知道销售税既复杂又疯狂。在一个真实的数据模型中，它需要大约70个表才能正确完成。“

很多时候，建模人员可以从业务分析师那里获得足够的要求，甚至可以使他们能够及时了解冲刺及其目标。 Huizenga观察到：

“我不是在抨击开发人员或程序员，但他们往往知道自己需要包含哪些内容，因此很短视。所以我发现如果我能与商业分析师合作，或者在那里与谁一起瞥见......我发现它很顺利。“

开发者现实

更重要的是，也许，建模者经常被拉入以开发者为中心的世界，在这两个群体之间存在许多误解，包括：

• 数据建模的概念：许多开发人员认为只有一种数据模型适用于敏捷项目，而实际上这种假设并不属实。根据Lopez的说法：“他们认为有一种数据模型，它与所有生产环境相匹配。然后，如果他们在他们的每台笔记本电脑上使用他们自己的开发环境，现在甚至是150。所以我无法比较他们一直在玩的开发环境，但我可以比较他们在QA中提出的建议。“
• 目标建模：许多开发人员经常没有意识到 - 或者关心 - 建模人员必须将数据建模定位到多个环境。这些包括开发人员，QA，预生产和生产。此外，这些不同的环境需要在不同时间点建模数据，这大大增加了敏捷过程中建模的复杂性。
• 敏捷性：一些建模者甚至遇到过敏捷性的灵活方面与重用设计模式的实际需求形成对比的情况。这种需求随着延迟参与而增加，并且项目建模者的潜在多样性可能正在发挥作用。

前期建模

前期建模的实践当然可以帮助数据建模人员跟上敏捷环境的快速性，这些专业人员负责的所有模型都会加剧这种速度。各种环境所需的模型乘以特定用户所需的特定模型。根据Lopez的说法：“无论它们是物理上独立的模型，还是快照或分支机构，我都在处理所有那些真正概念上相同模型的版本。我可能同时拥有15或20个。“利用前期建模和与建模相关的某些预先设想的模式可以帮助减少这么多模型的复杂性，同时还可以减少创建和实现它们的时间。 Lopez说，开发人员“有时候对此不太感兴趣，因为他们认为这是一个很大的前期建模。” “是的，这是预先的，但它认为已经完成 - 就像你的代码模式一样。”

分支

在时间密集的敏捷环境中进行数据建模的另一个方法是使用分支。在需要不同版本的模型和数据的其他方面的情境要求的情况下，分支通常是可取的。在这种情况下，建模者可以仅“分支”当前模型​​，然后最终合并回主模型，而不是在这种情况下创建完全独立的模型。另一种考虑敏捷流程创建的时间敏感环境的方法是让建模者直接在开发人员沙箱中工作 - 这有助于开发人员了解模型约束以及如何适应它们。这种策略有助于促进敏捷方法已知的交互性和协作。 Huizenga反思这种方法：

“我过去常常与开发人员合作开始说，'这就是我认为你需要'。我们会将它放入桌面上的开发人员沙箱中。我们会玩它，看看有什么可以使它工作。然后我会做一个比较并合并然后把它带回来然后说'好吧，那不行，但是，让我们以这种方式融合'，然后我们就会继续前进。“

打破构建并修复它

在敏捷环境中工作时，数据建模的现实面临巨大挑战，因为严格的期限通常会给所涉及的每个人带来时间限制。建模者可以帮助抵消一些主要存在的问题，这些问题主要是由于假设，误解以及开发人员在几个方面普遍无知。其中包括从业务部门获得有关要求的澄清，并征求其参与以扩大项目范围。除了直接在开发人员沙箱中工作外，它们还包括利用前期建模和分支，使开发人员了解数据建模标准。实际上，在开发人员沙箱中工作可以帮助创建理想的情况，在这种情况下，开发人员可以近乎实时地访问他们与建模需求的一致性。根据Huizenga的说法：

“在我救出的一个项目中，我们把它带到了我们有五个不同的团队前进的地步，一旦检查了一些东西，如果它打破了构建，我们实际上有红色闪烁的灯连接到计算机。基本上，每个人都知道这一切都是在甲板上找出错误，修复构建，继续使用，然后离开你。令人惊讶的是，合作水平将会提升。这只是让每个人都在一起工作。作为其中一部分的业务团队，他们只是喜欢它，这些东西是实时发生的，他们是对正在发生的事情的见证。“

原文：https://www.dataversity.net/fundamentals-of-data-modeling-in-agile-environments/

本文：https://pub.intelligentx.net/fundamentals-data-modeling-agile-environments

讨论：请加入知识星球或者小红圈【首席架构师圈】