Data Vault 2.0方法论之敏捷项目管理

项目管理

如《Data Vault 2.0方法论——项目计划》所述，Data Vault 2.0方法论促进了定义的、可重复的和治理的开发过程，以及其他特征。然而，这并不意味着目标会过度定义或限制开发过程。我们的目标是使用结构化而敏捷的方法来开发商业智能解决方案。业务敏捷性是指快速适应业务环境变化的能力。为了支持这种能力，数据仓库开发团队也必须应对这些快速变化。IT应该尽可能地避免长期的项目计划，而将重点放在迭代和增量开发上。他们需要能够在两周内适应不断变化的业务需求。这条规则的一个例外是在组织的程序或企业级别上需要的长期(或整体)计划。

为了实现这一目标，需要跨职能团队，如《Data Vault 2.0方法论——项目计划》所述。任何时候都需要每个团队成员之间、业务和IT之间的协作。如果业务决定更改需求(因为外部因素迫使他们这样做，或者因为他们在整个过程中由于任何原因改变了主意)，开发团队必须尽快知道这一点。改变方向不应该被避免，而应该被促进，以便交付正确的产品，满足用户的期望。然而，这需要适应性规划和数据仓库开发的渐进方法。通过从hub-and-spoke（中心辐射）网络模型(后续文章《中级数据仓库建模》中进行描述)派生出Data Vault2.0模型，它从一开始就被设计为支持这种演化方法。

建立Data Vault模型是一个自然的过程。实现基于Data Vault2.0的数据仓库的最佳方法是关注一个定义良好的小范围问题，其范围是业务键跨多个功能区域。应该避免像典型架构及其构建方法中常见的那样立即尝试对整个企业建模，这在《数据仓库架构》中介绍了。在这些遗留架构中，需要立即对整个企业建模，因为修改初始模型(第三范式或星型模式)的工作量太大了。因此，开发人员试图在初始模型中实现尽可能多的特性，以减少未来的更改。然而，考虑到不断变化的业务环境，这种方法是不可靠的。Data Vault 2.0的设计是为了快速吸收模型的变化，以及其他设计特征。决定使用Data Vault 2.0的组织应该通过有组织地扩展其模型来发挥这一特性，以便从Data Vault建模中充分获得优势。

但是敏捷性不仅取决于Data Vault模型或架构。 还取决于人员：团队中的项目成员和支持核心开发团队的外部人员。一个成功的敏捷项目需要经过适当培训并遵循有纪律的协作方法的人员。同样重要的是，让所有对要交付的数据仓库感兴趣的各方参与。这不仅是业务用户。开发团队在开发过程的早期往往忘记了参与操作和支持人员。

操作和支持人员需要在生产中支持解决方案。因此，他们对解决方案的配置、文档和推出有具体要求。Data Vault 2.0方法论的进化方法在这方面也有帮助：由于数据仓库是以增量方式交付的，因此除了业务用户提供的反馈之外，操作和支持还可以提供早期反馈。开发应该通过频繁地交付有效的软件来最大限度地利用这种潜在的反馈。最后，频繁的测试不仅是由IT在sprint冲刺期间执行的，也是由业务用户（技术业务分析师）、操作和支持执行的。

最终，敏捷交付的目标是：

• 扩展敏捷：这不仅是要扩展团队规模，而且还要在位置上（扩展团队的分布)、遵从性、复杂性(域、技术和组织）以及进入企业环境。
• 避免混乱：运行和管理不善的项目会遇到与非托管项目相同的问题。 没有敏捷的纪律，就不要“敏捷”了。从过去sprint冲刺中所犯的错误中吸取教训，并不断改进你的过程。
• 有效启动：在实际构建系统之前，应该澄清业务问题，找出可行的技术解决方案，计划的方法，以及工作环境和团队的建立。这也是重要的，以获得利益相关方对所选择的方法和实施战略的承诺。
• 从个人到敏捷团队的转变：团队中的每个人都应该集中精力协同工作，以实现项目的目标，而不是个人利益。
• 增量构建：每个sprint冲刺都应该生成一个可以被其业务用户消费的解决方案。只有这样，他们才能对当前的解决方案提供现实和有价值的反馈。目标不是预览某件事-它是把它投入实际的生产。
• 部署敏捷解决方案：当今的业务和技术环境是复杂的。 敏捷解决方案必须部署到这样的环境中。
• 利用企业学科：Data Vault2.0方法论已经利用已经建立和证明的企业方法，如CMMI、Scrum、六西格玛、PMP等。 还有其他企业学科可以帮助您部署、维护和支持解决方案，例如信息技术基础设施库(ITIL)。使用这些已被证明的学科，特别是如果它们已经在您的组织中使用。
• 适应治理策略：敏捷项目的治理应该在冲刺中保持一致。随着解决方案即将在冲刺阶段结束，应审查遵守组织制定的标准和规则的情况。

这些目标来自纪律敏捷交付(DAD)，在企业组织中用于敏捷交付软件。 它是一种混合的方法，它将敏捷建模(AM)、极限编程(XP)和统一过程(UP)等经过验证的策略扩展到Scrum。 因此，它遵循与Data Vault 2.0方法论类似的策略，并且明确关注数据仓库和商业智能。

Scrum

传统的软件开发生命周期，也称为瀑布法，有几个优点和缺点。如果一切顺利（并按计划进行），瀑布法是执行项目最有效的方法。只实现，测试和部署所需的功能。该过程产生了一套非常好的文档，特别是在项目的需求和设计阶段。然而，在客户对需求和想法不太具体以及业务需求随时间演变的情况下，几乎不可能开展更大的项目。

因此，开发了敏捷方法，使软件开发更加灵活，总体上更加成功。 Scrum是这种敏捷方法的一个例子，将在下面的章节中描述。 它是在20世纪90年代末推出的已经成为“压倒性的[敏捷]最受欢迎的”。

在Scrum中，用户需求被维护为产品待办事项中的用户故事。它们按业务价值排序，包括有关客户请求、新功能、可用性增强、错误修复、性能改进、重新架构等的需求。用户故事是在称为“sprints”的迭代中实现的，迭代通常持续两到四周。在冲刺期间，用户故事根据项目的优先级从产品待办事项中删除，并由团队实现。Scrum的目标是用每一个sprint创建一个潜在的可交付增量，这是系统的一个新版本，可以呈现给业务用户并潜在地投入生产（图3.7）。

图 3.7 需求在Scrum过程中的流程

这需要一个用户故事作为一个整体来实现和测试，包括属于这个故事的所有业务逻辑。所有利益相关者，如业务用户和开发团队，都可以在下一次冲刺开始之前检查新的、有效的特性，并提供反馈或建议对用户故事的更改。Scrum支持重新调整产品待办事项的优先级，并欢迎在sprint之间更改业务需求（图3.8）。

图 3.8 在Scrum中的快速流转

这有助于以满足业务用户期望的方式改进项目的结果。为了确保这一点，客户应该尽可能地成为Scrum团队的一部分。
下一节将更详细地解释Scrum的元素。

迭代方法

上一节已经讨论了Scrum使用迭代方法来开发最终系统。每次迭代都是朝着最终解决方案迈出的一小步，为产品增加了更多的价值。这种方法背后的想法是，由于更改或大致指定的业务需求，大多数初始计划需要随着时间的推移而得到纠正。因此，团队和业务用户应该有可能在项目进行期间采取纠正行动。然而，这需要业务用户尽早从项目中获得价值。图3.9显示了这一概念。

图 3.9 在Scrum的项目控制

在第一个项目基础历程中，每次迭代只需要一天时间。在迭代之后，所有涉众都会检查当前的“潜在可交付”系统，并检查它是否仍然符合预期。如果项目的利益相关者之一在项目中发现了需要纠正的问题，这种纠正将相对较快。例如，可以修改业务需求，并在下一次迭代中更改系统。在许多情况下，变化将相对较小，因为它是在早期发现的。在最坏的情况下，整个迭代需要回滚并再次执行。在这种情况下，只有一天的工作是丢失的。

如果迭代周期(sprint)更长，例如一个月，将实现更多的需求，以用户故事表示。因为经常有相互依赖的需求，所以用许多依赖项来更改需求将比在第一种情况下使用较短的冲刺长度需要更多的纠正工作。

产品和Sprint待办事项

Scrum项目中的主要工件是用户故事。用户故事从用户的角度描述功能，并保存在产品待办事项中，直到团队成员选择用户故事进行实现。在项目开始时，用户故事往往更笼统，大致描述了业务用户的主要特征。它们主要用于开始产品之间的讨论所有者（我们在下面的部分中讨论的项目角色）和开发团队。随着团队了解更多的功能，客户了解更多的产品，新的和更详细的用户故事被添加到产品待办事项。

在将每个用户故事添加到产品待办事项之前，将其优先排序。开发人员必须严格按照优先的顺序从待办事项中获取用户故事。在每次迭代开始时，应该实现的用户故事将从产品待办事项中删除，并移动到sprint待办事项（详见图3.7）。用户故事被设计、实现、测试和集成到整个产品中。为了维护“潜在的可交付”产品，问题立即被修复。图3.10显示了团队成员如何处理产品待办事项。

图 3.10 待办事项和优先级

具有高优先级的工作项（因此将由团队成员选择）必须详细和定义良好，因为它们描述了开发人员即将完成的任务。另一方面，优先级较低的用户故事可能不那么详细。这些用户故事往往没有被业务用户很好地阐述，需要更多的定义。 典型的过程是删除这样一个用户故事，将其分割成多个故事，更详细地定义它们并将它们放置、优先排序、返回到产品待办事项中。 还可以在sprint冲刺之间重新排序现有用户故事，以使项目适应业务需求的变化。一个常见的实践是从产品所有者使用传统方法编写的需求规范中导出（至少是最初的）用户故事。

将Scrum与Data Vault 2.0方法相结合

为了成为一个敏捷的项目团队，并实现本文开头提出的目标，团队必须通过CMMI的不同级别进行进化。太多的团队和太多的组织只是决定“敏捷”，而没有正确地应用所选择的方法的原则。包括Scrum在内的所有敏捷方法都遵循一套让团队变敏捷的原则。

在没有正确遵循这些原则的情况下，团队加入了许多假装“做敏捷开发”，但决定放弃现实中大多数项目管理活动的团队。但是敏捷项目管理并不意味着“没有项目管理”，它是一种不同的项目管理方法，要求团队成员知道原则和如何执行它们。从来没有在敏捷项目上工作过的团队成员通常不知道这些原则。他们必须从培训或更有经验的团队成员中学习这些原则，才能成为成功的敏捷团队成员。

不仅如此——运行敏捷项目还需要一个敏捷组织。如果组织认为瀑布在部门之间（例如，从开发到测试到业务）抛出工件，并将更改放入生产需要至少3周，那么从敏捷的角度来看，您的团队将不会表现得很好。正如本文已经指出的，目标是将在一次迭代中开发的更改放入同一个sprint冲刺中生产。这一目标在任何时候都可能不成立，例如，如果不可能将更改范围缩小到易于管理并且可以在一个sprint中进行开发和部署的部分。在这种情况下，需要在多个sprint冲刺来完成开发的更改，直到可进行部署为止。但是，标准应该是在正在开发工件的sprint中部署。没有“敏捷的大爆炸”-也就是说，在多个sprint冲刺上开发数据仓库，并在两年内项目结束时进行部署。

CMMI可以帮助团队和组织进化以实现敏捷性。
当遵循《在Data Vault 2.0方法论中集成CMMI》的推进到成熟度等级5概述的建议时，组织会随着时间的推移发展这些技能，让团队成员有时间学习、使用和提高他们的敏捷技能。事实上，Scrum建立在CMMI5级（优化）的基础上，团队的目标是随着时间的推移提高他们的能力。我们将在后续文章中更详细地讨论这一点。

大多数敏捷项目都有一个共同的理解，即为了实现所提出的目标，商业智能(BI)团队必须承担以下几个责任：

• 客户满意：为了履行这一责任，团队必须迅速和持续地交付不仅是工作软件，而且是有用的软件。也就是说，增量应该为用户（和工作)提供价值。
• 频繁交付：为了向业务用户和其他利益相关者展示进展，BI团队有责任经常（以周而不是月为单位)交付可运行的软件。
• 衡量进度：开发团队通常用投入的时间来衡量他们的进度，并将其与初始计划或更新计划进行比较。在敏捷开发方法中，如Data Vault2.0方法论，在运行的软件中衡量进度，即衡量已经实现的特性。
• 欢迎更改：敏捷BI团队不应避免对初始需求的后期更改。为了满足业务需求并使业务用户对结果满意，需求收集是Data Vault 2.0中的一种持续方法。
• 密切合作：业务人员和开发人员应该每天致力于数据仓库的新功能。然而，目标不是快速解决生产中的任何问题。他们应该协作以实现这个冲刺计划中的新功能。快速定位问题应该由业务部门完成，这就是为什么数据仓库的开发应该使它能够由业务本身维护，而不需要将IT集成到这个过程中。
• 面对面交流：BI团队应该避免来回发送电子邮件，而不是面对面地见面，以解决任何当前的问题。
• 激励个体：激励往往来自信任，是一种双向关系。
• 技术卓越：为了使商业用户长期满意，需要一个技术优秀的产品。然而，IT应该避免在第一次尝试中实现这一点。相反，他们应该专注于一个好的设计，让他们最终以敏捷的方式实现优秀的产品。Data Vault2.0模型在这方面很有帮助，因为设计确保了模型的可扩展性，以便在以后的sprint中实现更多的特性。
• 简单：真正的工程师喜欢简单的解决方案。 避免添加业务不需要的功能。如果没有实际需要，避免通过系统属性修改Data Vault2.0模型。每当将复杂性添加到解决方案中时，必须有一个很好的理由。这使得维护最终解决方案更加容易。
• 自我组织团队：团队成员负责围绕相关任务自我组织。
• 定期适应：BI团队有责任回顾过去的决定，并确保它们在环境或其他情况发生变化时仍然有效。这种责任可能是最难的，因为人们不想承认错误。但在当时的情况下，六个月前做出决定并不是一个错误。如果情况改变了，继续下去是个错误。

所提出的责任直接来自Scrum原则，但适用于所有敏捷项目。因此，只有开发团队遵守这些职责，Data Vault2.0方法论才能成功。