2.3.2　敏捷宣言

应用任何一种敏捷方法，都需要清楚地理解敏捷宣言中所阐述的四个核心价值观。我们来看这些宣言：

□个体与交互高于流程和工具。流程和工具总是有助于完成项目。项目利益相关者作为项目的一部分，明白如何实施计划，以及如何在项目交付工具的帮助下交付成功的结果。但是项目交付的主要责任是人员及其协作。

□软件高于详尽的文档。对于产品的开发来说，文档始终是必不可少的过程。过去，许多团队只专注于收集和创建文档库，例如高层次设计、详细设计和设计变更等，这些文档以后会有助于实现对产品的定性和定量描述。

使用敏捷方法论，可以专注于可交付的产品。因此，根据这条宣言，我们需要文档。但是，还需要定义有多少文档对产品的持续交付至关重要。最主要的是，团队应该专注于在产品的整个生命周期中逐步交付软件。

□客户协作高于合同谈判。此前，当组织启动一个固定总价或工料合同项目时，客户总是在软件生命周期的第一个和最后一个阶段出现。他们是不参与产品开发的局外人，当他们在产品发布后终于有机会看到产品时，市场趋势已经发生了改变，因而也就失去了市场。

敏捷方法认为，客户对产品的发布负有同等责任，他们应该参与开发的每一步。他们也需要根据新的市场趋势或消费者需求给予反馈。由于业务现在是开发周期的一部分，因此可以通过敏捷和持续的客户协作来实现这些变化。

□响应变化高于遵循计划。在当前快节奏的市场中，客户的需求随着新的市场趋势而不断变化，业务也不断变化。由于迭代周期从1周到3周不等，所以确保在频繁改变需求与敏捷地拥抱变化之间取得平衡至关重要。响应变化意味着，如果规范有任何改变，开发团队将接受改变，并在迭代演示中展示可交付成果，以此不断赢得客户的信任。这条宣言有助于团队理解拥抱变化的价值。

敏捷宣言是一种工具，用来建立采用敏捷方法论的基本准则。这些宣言是所有敏捷技术的核心。下面我们来详细介绍敏捷流程。

1.敏捷流程和术语

我们来熟悉一下最常见的敏捷术语，以及它们是如何结合在一起的。首先是被广泛采用的敏捷Scrum流程。敏捷Scrum流程会有一个1～3周的小的迭代周期，具体取决于项目的稳定性，最常见的是2周的迭代周期，可以称之为开发周期。

这些迭代是开发周期，团队将分析、开发、测试和交付可工作的功能特性。团队采用迭代的方式，随着项目的推进，每个迭代都会创建产品可工作的基本构件。每个需求都会被写成用户故事，牢记客户角色，并使需求清晰可见。

敏捷Scrum团队有不同的角色。我们来了解一下最常见的角色，以及解决方案架构师如何与他们协作：

□Scrum团队：由产品负责人、敏捷专家Scrum Master和开发团队组成。分析师、技术架构师、软件工程师、软件测试人员和部署工程师都是开发团队的成员。

□Scrum Master：有助于所有的Scrum仪式的进行，保持团队的积极性，并为团队消除障碍。敏捷专家Scrum Master与解决方案架构师合作来消除技术障碍并获得业务需求的技术澄清。

□产品负责人：是一位业务人员，是客户的代言人。产品负责人了解市场趋势，并且能够定义业务内的优先级。解决方案架构师与产品负责人一起了解业务的愿景，并使其与技术观点保持一致。

□开发团队：负责产品实施和项目的交付。他们是一个跨职能的团队，致力于持续和增量交付。解决方案架构师需要与开发团队紧密合作，以保证产品实施和交付的顺利进行。

2.迭代仪式

迭代（Sprint）周期包括为管理开发而进行的多个活动，这些活动通常被称为Scrum仪式。这些Scrum仪式如下：

□待办事项梳理：一般是限定时间的会议形式，产品负责人、解决方案架构师和业务人员在会议上共同讨论待办用户故事，确定它们的优先级，并对迭代交付物达成共识。

□迭代计划：在迭代计划中，Scrum Master会根据团队的能力，将梳理好的故事分配给Scrum团队。

□迭代每日站会：每日站会是一种非常高效的协作方式，所有团队成员聚在一起开会，讨论前一天的工作，今天有什么计划，是否面临什么问题。这个会议要简短而直接，时间控制在15分钟左右。站会是解决方案架构师与开发团队协作的平台。

□迭代演示：在演示过程中，所有的利益相关者聚集在一起，检查团队在迭代阶段所做的工作。在此基础上，利益相关者接受或者拒绝这些故事。解决方案架构师确保功能性和非功能性需求已经得到满足。在这种会议中，团队会收集产品负责人和解决方案架构师的反馈，并查看做了哪些更改。

□迭代回顾：回顾在每个迭代周期结束时进行，是团队检查和采用最佳实践的方式。团队会确定哪些事情进展顺利，哪些应该继续实践，以及在下一个迭代中可以做得更好的事情。迭代回顾有助于组织在交付过程中进行持续改进。

3.敏捷工具和术语

我们来了解一些有助于推动团队指标和项目进度的敏捷工具：

□规划卡牌：规划卡牌是敏捷方法论中最流行的评估技巧之一，当迭代开始时，Scrum Master会用卡牌游戏来评估用户故事。在此活动中，将根据每个用户故事的复杂性进行评估。团队成员通过对比分析来给出每个用户故事的故事点，这有助于团队了解完成用户故事需要做多少工作。

□燃尽图：燃尽图用于监控迭代进度，并帮助团队了解有多少工作有待完成。Scrum Master和团队始终遵循燃尽图，以确保迭代中没有风险，并再次使用这些信息以改进下一次的评估。

□产品待办列表：产品待办列表包含了用户故事和史诗故事形式的需求集合。在迭代梳理过程中，产品负责人会持续更新待办列表，并对需求进行优先级排序。史诗故事是一种高层次的需求，产品负责人编写用户故事来完善它们。开发团队将用户故事分解成一个个任务，也就是一个个可执行的行动项。

□迭代看板：迭代看板包含了当前迭代的用户故事集合。迭代看板提供了透明度，因为任何人都可以查看该特定迭代周期的项目进度。团队每天都会参考看板来确定整体的工作进度，并消除障碍。

□完成标准：这意味着所有的用户故事都应该通过解决方案架构师和产品负责人与利益相关者合作制定的完成标准。其中一些标准如下：

●代码必须经过同行评审。

●代码应该进行单元测试。

●足够的文档。

●代码质量。

●代码编写标准。

4.敏捷方法与瀑布式方法

瀑布式开发是组织过去遵循的最古老、最传统的软件开发方法论之一。接下来将介绍瀑布和敏捷之间的区别，以及为什么组织需要转向敏捷。这里不会讨论瀑布过程的细节，仅指出关键的区别：

□敏捷方法论有助于将思维方式从传统思维方式转变为敏捷思维方式。这样做的动机是为了从瀑布式方法转向敏捷方法，从而实现最大的业务价值并赢得客户的信任。这使得敏捷方法在每一步都倡导客户协作，并提供透明度。瀑布式方法往往更多的是以项目和文档为中心，客户在最后阶段才参与进来。

□瀑布式方法对所有需求都非常明确并且其可交付成果顺序已知的项目更有帮助，这有助于消除不可预测性，因为需求非常明确。敏捷方法论对于那些想要紧跟市场趋势、并且来自客户的压力越来越大的公司很有帮助。他们需要尽早发布产品，并且必须适应需求的变化。

□敏捷项目以小规模迭代的方式交付，具有最高的质量且实现了业务价值。许多敏捷团队在整个迭代期间并行工作，在每一个迭代周期结束时为产品提供可交付的解决方案。由于每个迭代都有一个小的可交付成果，并在此基础上不断构建，因此客户能不断地看到产品的工作模型。瀑布项目的周期很长，利益相关者直到最后才能看到最终产品，这意味着没有太多的空间来适应变化。

□敏捷过程通过在每个迭代周期设置检查点，确保团队朝着目标前进，并且项目能够按时完成。在传统的瀑布式方法中，没有频繁的检查点来确保团队走在正确的道路上，也不能验证项目是否可以按时完成，这就可能会造成不确定性。

□在敏捷方法中，客户始终与产品负责人和团队合作。这种合作确保他们对小的、可交付的产品进行观察及审查。敏捷还确保工作正在进行，并向利益相关者展示进度。然而，在瀑布式方法中，在项目结束之前都不会有这样的客户交互。

敏捷是最具适应性的方法论，因为快速发展的技术和业务变得如此不可预测，需要更高的速度。敏捷方法支持检查和适应周期，这样就在需求和控制之间建立了平衡。

5.敏捷架构

在说起敏捷模型中的解决方案架构师时，你会想到什么？人们有很多误解，比如认为解决方案架构是一项非常复杂的活动，而使用敏捷会被要求立即或在下一个迭代周期提交设计。另外还有误解认为，敏捷架构无法应用于这样的架构设计和开发，无法进行测试，等等。

敏捷架构就是设计可解耦和可扩展的接口。敏捷环境下的解决方案架构师需要通过检查和调整来遵循迭代的重新架构理念。这涉及选择适合企业的解决方案，进行良好沟通，获得持续反馈，以及以敏捷的方式进行建模。开发团队需要一个坚实的基础和适应不断变化的需求的能力，他们需要来自解决方案架构的引领和指导。

敏捷架构的基础应该是降低变更的成本，通过质疑来减少不必要的需求，并创建可以快速扭转不正确需求的框架。敏捷架构师构建原型来将风险降到最低，并通过对变化的了解来制订变更计划。他们在设计原型的同时平衡所有利益相关者的需求，并创建一个可以轻松与其他模块集成的松耦合架构。更多关于松耦合的架构模式见第6章。