敏捷软件开发过程模型

敏捷联盟为希望达到敏捷的人们定义了12条原则：

1)最优先要做的是通过尽早、持续交付有价值的软件来使客户满意。

2)即使在开发的后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。

3)经常交付可工作软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

4)在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

5)围绕受激励的个人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

6)在团队内部，最富有效果和效率的信息传递方法是面对面交谈。

7)可工作软件是进度的首要度量标准。

8)敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该保持一种长期、稳定的开发速度。

9)不断地关注优秀的技能和好的设计，增强敏捷能力。

10)简单：使不需要的工作最大化。

11)好的架构、需求和设计出自于自组织团队。

12)每隔一定时间，团队会反省如何更有效地工作，并相应调整自己的行为。

敏捷可用于任何软件过程，实现要点是将软件过程设计为如下方式：允许项目团队调整并合理安排任务，理解敏捷开发方法的易变性并制定计划，精简并维持最基本的工作产品，强调增量交付策略，快速向客户提供适应产品类型和运行环境的可运行软件。

下面，我们以极限编程(eXtreme Programming，XP)为例，介绍敏捷过程模型。

XP使用面向对象方法作为推荐的开发范型。XP包含了策划、设计、编码和测试4个框架活动的规则和实践。图2-9描述了XP过程，并指出与各框架活动相关的关键概念和任务。

策划。策划活动开始于建立一系列描述待开发软件的必要特征与功能的"故事"。每个故事由客户书写并置于一张索引卡上，客户根据对应特征或功能的全局业务价值标明权值(即优先级)。XP团队成员评估每一个故事并给出以开发周数为度量单位的成本。如果某个故事的成本超过了3个开发周，将请客户把该故事进一步细分，重新赋予权值并计算成本。新故事可以在任何时刻书写。

客户和XP团队共同决定如何把故事分组，并置于XP团队将要开发的下一个发行版本中。一旦形成关于一个发布版本的基本承诺，XP团队将按以下三种方式之一对待开发的故事进行排序：(1)所有选定故事将在几周之内尽快实现；(2)具有最高价值的故事将移到进度表的前面并首先实现；(3)高风险故事将首先实现。

项目的第一个发行版本发布之后，XP团队计算项目的速度。简言之，项目速度是第一个发行版本中实现的用户故事个数。项目速度将用于帮助建立后续发行版本的发布日期和进度安排；确定是否对整个开发项目中的所有故事有过分承诺。一旦发生过分承诺，则调整软件发行版本的内容或者改变最终交付日期。

在开发过程中，客户可以增加故事、改变故事的权值、分解或者去掉故事。接下来由XP团队重新考虑所有剩余的发行版本，并相应修改计划。

设计。XP设计严格遵循保持简洁（Keep It Simple，KIS）原则，使用简单而不是复杂的表述。另外，设计为故事提供不多也不少的实现原则，不鼓励额外功能性设计。

XP鼓励使用类－责任－协作者（CRC）卡作为有效机制，在面向对象语境中考虑软件、CRC卡的确定，组织和当前软件增量相关的对象和类。CRC卡也是作为XP过程一部分的唯一的设计工作产品。

如果在某个故事设计中碰到困难，XP推荐立即建立这部分设计的可执行原型，实现并评估设计原型，目的是在真正的实现开始时降低风险，对可能存在设计问题的故事确认最初的估计。

编码。在故事开发和基本设计完成之后，团队不应直接开始编码，而是开发一系列用于检测本次（软件增量）发布的包括所有故事的单元测试。一旦建立起单元测试，开发者就可以更集中精力于必须实现的内容以通过单元测试。不需要加任何额外的东西（保持简洁）。一旦编码完成，就可以立即完成单元测试，可由此向开发者提供即时的反馈。

XP编码活动中的关键概念之一是结对编程。XP推荐两个人面对同一台计算机共同为一个故事开发代码。这一方案提供实时解决问题和实时质量保证的机制，同时也使开发者能集中精力于手头的问题。实施中不同成员担任的角色略有不同。例如，一名成员考虑特定设计的详细编码实现，而另一名成员确保编码遵循特定的标准，生成的代码符合该故事的接口设计。

结对的两人完成所开发代码和其他工作集成。在有些情况下，这种集成工作由集成团队按日实施。在另外一些情况下，结对者自己负责集成，这种"连续集成"策略有助于避免兼容性和接口问题，建立能及早发现错误的"冒烟测试"环境。

测试。在编码开始之前建立单元测试是XP方法的关键因素。所建立的单元测试应当使用一个可以自动实施的框架，这种方式支持代码修改之后即时的回归测试策略。

一旦将个人的单元测试组织到一个"通用测试集"，每天都可以进行系统的集成和确认测试。这可以为XP团队提供连续的进展指示，也可在一旦发生问题的时候及早提出预警。

XP验收测试也称为客户测试，由客户确定，将着眼于客户可见的、可评审的系统级的特征和功能，验收测试根据本次软件发布中所实现的用户故事而确定。