3.1.2　常见的敏捷开发方法

敏捷开发是基于敏捷宣言定义的价值观和原则的一系列方法和实践的总称，尤其适合那些需求和功能迭代需要跨业务团队支撑，且团队又是偏自组织管理的情况。敏捷开发不是一种范式，而是各团队基于敏捷价值观实践产生的解决方案。

敏捷宣言诞生多年以来，敏捷思维已经从一个小众活动转变为被广泛使用的方法，全世界都有大量的公司在践行敏捷开发理念，在这些实践过程中，诞生出了不少优秀的方法和案例。这里，我们将介绍一些被广泛采用的敏捷开发方法。

Scrum

Scrum一词，源于橄榄球运动，中文一般会翻译为“争球”。双方的前锋各自排成一队，在中间形成一个通道，当球被抛入这个通道后，双方球员要用脚去争夺球权。很显然，单靠一名队员是无法赢得球权的。日本教授竹内弘高和野中郁次在1986年《哈佛商业评论》中发表的一篇论文The New New Product Development Game，首次将这一概念与产品开发结合在一起，提出了Scrum方法，他认为一个敏捷团队也应该像橄榄球比赛一样，大家通力协作，达成最终目标。

Scrum的标准模式如图3.1所示，产品负责人（PO/PM）的工作是整理需求，并将其汇总为待办事项（Backlog），同时确定优先级。之后，团队从这个待办事项池子中取出一部分任务，形成当次迭代（Sprint）的计划，并明确完成时间点。在每次迭代中，团队需要有每日站会（Daily Standup Meeting）对进度和风险进行追踪。每次迭代结束后，召开迭代评审会（Sprint Review）和迭代回顾会（Sprint Retrospective），对当次迭代的问题和经验进行整理和反思。整个过程通常由敏捷教练（Scrum Master）进行把控和指导。

图3.1　Scrum的标准模式

极限编程

极限编程的思想最早出自1996年克莱斯勒汽车公司的一个称为克莱斯勒综合报酬系统（下面简称为C3）的工资单项目，当时的项目负责人Kent Beck对项目的开发流程做了一些突破性的尝试，并将这些实践记录在一本名为Extreme Programming Explained（《极限编程解析》）的书中。尽管最终C3项目失败了，但这些项目流程的改进却实实在在地积累了下来，从此极限编程进入了大众视野。

极限编程的主要目标是降低因需求变更而带来的成本，体现在实际工作中，最大的变化就是更短和更频繁的开发周期。伴随着这一变化，诞生了测试驱动开发（TDD）和结对编程等方法，其本质都是希望在更快的节奏下，用最轻量级的方式，保证产品的交付质量。

动态系统开发方法

动态系统开发方法（Dynamic Systems Development Method，DSDM）是一个敏捷项目开发交付框架，如图3.2所示，其核心思想是：开发时间固定，而功能规划和资源配置是可变的。这一点有别于传统的软件开发方法，它强调需要实现的功能是预先确定的，而人力资源和时间是可变的。

图3.2　DSDM框架

具体来解读一下动态系统开发方法的实践过程，假设我们定义一个迭代周期为两周，这个周期是固定的。如果发生了一些变化导致人力资源不足，那么就需要增加人员；如果插入了一些新的需求，导致原先的开发时间不够用，那么就根据优先级放弃部分需求，排入下一个迭代周期。这样可以保证项目交付的准时性，避免一拖再拖，最终演变成一个长期交付的传统开发模式。

特性驱动开发

特性驱动开发（Feature Driven Development，FDD）方法由Jeff de Luca、Eric Lefebvre和Peter Coad共同提出。它创造性地将“特性”作为开发工作的第一公民，所有工作围绕特性展开，而不是任务。项目不需要冗长的设计过程，而是边设计、边开发、边完善。特别地，特性被设计为是可理解的、可衡量的、可实现的功能，可以直接拿出来展示给客户，提供富有价值的信息。