什么是最佳的敏捷方法？

　　回答这个问题有点像解释在不知道什么工作的时候为这个工作选择什么样的工具。所有的敏捷方法都共享了一些相同的原则和实践。正确的问题应该是“哪一种最适合眼前的项目？”

　　无论你追随的是哪一种方法，敏捷方法的使用不只为软件开发者提供了一种承诺。业务专家和开发团队之间的紧密协作，以及频繁的面对面沟通都是任何敏捷项目成功的关键必不可少的部分。要想敏捷，就要积极主动并参与其中。但是我们如何实现这个目标呢？让我们来看一些流行的敏捷工具。

　　敏捷宣言

　　2011年二月，17为软件编程实践者聚在一起，就如何更有效地构建软件开发了一个宣言、他们并没有在大多数意见上达成一致，但是有四件事情是清楚的，这就是敏捷宣言，所有的敏捷方法都基于此：

• 　　个体与交互重于过程和工具
• 　　可用的软件重于完备的文档
• 　　客户协作重于合同谈判
• 　　响应变化重于遵循计划

　　可能由于思想派别的不同，这些原则对于你来说完全陌生。但是实际上它们是敏捷方法所需要的一套工具。其余的就是应用正确的敏捷方法进行这项工作。

　　极限编程（XP）

　　极限编程是一种敏捷方法，需要客户（谁来验收软件）和开发者之间高水平的参与。这里的客户通过优先用例中最重要的功能，从而驱动开发产出。开发团队通过持续编程、测试、计划和紧密协作迭代地交付用例。正常运转的软件频繁地被交付，典型的是一到三周。

　　优点：快速、积极的交付模式；高度协作；最低限度的预先文档化。

• 　　缺点：高度严格的纪律方法；要求IT部门之外的人员高度专注；要求团队中的每一个人精通XP知识才能成功；可移交文档少。
• 　　用途：适合由高级开发者组成的小型开发团队，团队成员具有出色的沟通技能，可以同非IT人员共事并对其进行管理。

　　SCRUM

　　SCRUM与XP相比，采取一种更加粗略的方法来构建软件。它是一种项目层管理和控制迭代工作的框架。在SCRUM中，“产品所有者”，我们称之为业务应用所有者，同时和业务和IT 团队共事，以“产品订单”的形式确定和优先系统端的功能。各种团队成员以短跑的形式，签名交付可装运的正常运作软件的增量，通常持续30天左右。

　　范围蠕变由开发团队控制，所以一旦交付没有任何功能可以再添加到这次短跑中来。一旦可装运增量被交付，产品订单就被分析，如果需要，重新优先化并再一次循环开始。

• 　　优点：范围蠕变的出色控制能力；鼓励团队协作和透明度；管理开发缺陷的良好可视性，因此适应性强；可以根据对团队和地理位置进行扩展。
• 　　缺点：关注粗粒度性能；有时导致“快餐式”编程；少量文档可交付。
• 　　用途：适用于关注于产品的IT 部门，主要聚焦在产品和项目管理者的协作中交付宽泛的性能。

　　特征驱动开发（FDD）

　　FDD是以开发者为中心的流程，以实现功能为目标。把系统分解成一个一个的功能集，每个功能集又习细分为具体的功能。不像SCRUM和XP，FDD关注具体的工作单元，这些工作单元通过严格流程审查，FDD的起点是起源于创建一个全局的模型轮廓（不要求很精确，大概模样就可以），然后是周期低于两周的一系列的“design by feature, build by feature”的迭代，逐渐丰富模型功能内容。

　　FDD及时且反复地促进了有形的，正常运转的软件的开发流程结果的严格控制。

• 　　优点：出色的文档化；高质量的设计和代码检验；可控制的创建流程；模型是面向类的，适用于面向对象编程语言，像Java；早期开发流程中，质量度量的良好洞察力；适合扩展到大型团队。
• 　　缺点：要求高度的设计和开发技能；如果最初的模型不正确很耗时；项目管理来跟踪项目很耗时；计划耗时。
• 　　用途：适用于法规驱动的环境下的团队开发者，像保险、金融、银行和政府，这些地方流程成熟，质量是最主要的需求。

　　结论

　　因此哪一种敏捷方法才是最佳的？谁都不是。每一个都对应具体的项目，没有一把万能钥匙。选取哪一种取决于IT环境和你所工作的内部流程。改变IT文化很难。但是敏捷方法的好处应该是让IT团队的生产率进入一个新水平的催化剂。