敏捷方法是从20世纪90年代发展起来的一种方法学的总称，包括极限编程等。这些方法学之间有些差异，但是差异不是很大。每种方法学的领导者一起起草了《敏捷软件开发宣言》，总结了方法之间的共同点，就是价值，并且用敏捷方法统称这些方法学。
5.1 建立敏捷思维
敏捷开发（agile development）是一种以人为核心、迭代、循序渐进的开发方法。采用用户故事等轻量级的需求描述，不断扩展、编码和测试。
5.1.1 传统管理面临的挑战
长期以来，软件开发过程一直在两种开发方式之间摇摆不定，即正规的软件开发方式和随性的边写边改的方式。
传统方法虽然以预测性为原则，以文档驱动开发过程，以过程为核心，但传统的开发模式无法严格执行，大多停留在理想状态。
一方面，大多数软件开发仍然是典型的“边写边改”的过程。尤其是在创业型企业，其需求需要根据市场要求及时调整，计划也会不断变化，设计过程充斥着短期的、即时的决定，而无完整的规划，已经开发的功能需要根据以上这些调整重新开发，而且最终产品与用户的最终期望差距较大，容易造成项目的失败。当系统变得越来越复杂时，想要加入新的功能就会越来越困难；同时当错误越来越多时，越来越难以排除。典型的就是当系统功能完成后会有一个很长的测试阶段，甚至遥遥无期，从而对项目产生严重的影响。造成这种状况的原因是客户会慢慢发现他们的需要，开发人员会在开发过程中会慢慢发现如何更好地开发客户需要的系统，在整个过程中很多事情是慢慢演进的。
另一方面，正规的软件研发过程经过瀑布模型到螺旋迭代等不断的优化，已日趋完善，但是并没有取得太大成功，甚至没怎么引起人们的注意。对于这些方法，常听到的批评就是过程繁杂，对文档的要求严格，这在很大程度上造成了效率下降，即人们所说的“重型化危机”。如果按照其要求，就有太多的事情需要做，而延缓整个开发进程。所以通常认为它们是“烦琐滞重型”方法，或Jim Highsmith所称的“巨型”（monumental）方法。
瀑布模型造成了诸多问题，包括版本发布的周期越来越长，版本无法按时发布，在版本发布的最后阶段让软件稳定的时间越来越长，制订计划的时间越来越长且不准确，在版本发布期间很难进行改变从而使员工士气受挫。
5.1.2 敏捷思维的引入
作为这些方法的对立方法，一类新方法出现了，一般称为“敏捷型”方法。对许多人来说，这类方法的吸引力在于对繁文缛节的简化。它们在无过程化和过于烦琐的过程之间达到了一种平衡，能以简单的过程获取较满意的结果。
“敏捷”一词产生于2001年2月11日～13日召开的一次会议上，Martin Fowler、Jim Highsmith等17位软件开发领域的领军人物聚集在美国犹他州，经过3天的讨论，总结出了全新的软件开发价值观，并且一致同意以“敏捷”（agile）这个词加以概括。该价值观体现在《敏捷宣言》中，从此宣告敏捷开发运动的开始。之后，敏捷联盟成立，敏捷开发作为一种新的方法正式诞生。
敏捷宣言包括4个价值观以及12条准则，这12条准则是4个价值观在实际工作中的体现。
5.1.3 敏捷的定义
简单来说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。不再把开发者当作一个物化的、投入多少时间完成相应数量代码的开发机器；而更注重开发者之间的交互以及开发者和用户之间的交互，同时因为增加了交流和协作，使得开发的项目更加灵活和易于修改。在敏捷开发中，把软件项目切分成多个子项目，各子项目都要测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系但又可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
敏捷方法与传统的烦琐滞重型方法有一些显著的区别。
其中一个显而易见的区别在于文档。敏捷型方法使用轻文档，对于一项任务，它们通常只要求尽可能少的文档。从许多方面来看，敏捷型方法更像是“面向源码的”（code-oriented）。事实上，敏捷型方法最根本的文档应该是源码。
文档减少仅仅是一个表象，它反映的是更深层的准则—敏捷型方法是“适配性”的而非“预设性”的。烦琐滞重型方法是指对软件开发项目在很长的时间跨度内制订出详细的计划，然后依计划进行开发，这类方法在计划制订完成后拒绝变化。而敏捷型方法则欢迎变化，目的就是成为适应变化的过程，甚至允许改变自身来适应变化。
另一个区别则是敏捷型方法是“面向人的”（people-oriented），而非“面向过程的”（process-oriented），它试图使软件开发工作顺应人的天性而非逆之，强调软件开发应当是一项愉快的活动。
以上两个特点很好地概括了敏捷开发方法的核心思想—适应变化和以人为中心。
5.1.4 敏捷宣言的价值观和准则
《敏捷宣言》中包含4个价值观和12条准则。下面介绍其具体内容。
通过身体力行和帮助他人来揭示更好的软件开发方式。通过这项工作，我们形成了如下价值观。
个体与交互重于过程和工具。
可用的软件重于完备的文档。
客户协作重于合同谈判。
响应变化重于遵循计划。
在每一项比对中，后者并非全无价值，但我们更看重前者。
《敏捷宣言》中隐含的12条准则如下。
我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
在项目开发过程中，业务人员与开发人员必须一起工作。
要善于激励项目人员，给他们需要的环境和支持，并相信他们能够完成任务。
无论是团队内还是团队间，最有效的沟通方式是面对面交谈。
可用的软件是衡量进度的主要指标。
敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进度。
对技术的精益求精以及对设计的不断完善将提升敏捷性。
要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
最佳的架构、需求和设计出自自组织的团队。
团队要定期反省如何能够更有效地工作，并相应地调整团队的行为。
敏捷开发过程中使用的技术和开展的活动都必须满足这12条准则。
5.1.5 敏捷的四大核心支柱
敏捷的四大核心支柱也是其价值观的集中体现。
迭代开发：在敏捷开发模式下，我们将开发周期分成多个1～4周的迭代，每个迭代都交付一些增量的可用的功能。迭代的长度是固定的，如果我们选择了1周的迭代，那么要保持它在整个产品开发周期内每个迭代都是1周的长度。这里要强调的是，每个迭代必须产出可用的增量功能，而不是第1个迭代用于满足需求，第2个迭代用于进行设计，第3个迭代用于编写代码。
增量交付：增量是一个迭代中完成的所有产品待开发功能列表（product backlog）的总和。在迭代的结尾，新的增量必须“完成”，这意味着它必须可用并且达到了敏捷团队中“完成”定义的标准。无论产品负责人是否决定真正发布它，增量必须可用。增量是从用户的角度来描述的，它意味着从用户的角度可工作。
自组织团队：Scrum团队是一个自组织的团队。传统的命令与控制式的团队只有执行任务的权利；而自组织团队有权进行设计、计划和执行任务，自组织团队还需要自己监督与管理其工程过程和进度，自组织团队自己决定团队内如何开展工作，决定谁来做什么，即分工协作的方式。
高优先级的需求驱动：在敏捷开发中，我们使用产品待开发功能列表来管理需求，产品待开发功能列表是一个需求的清单，产品待开发功能列表中的需求是逐渐细化的，待开发功能列表当中的条目必须按照商业价值的高低排序。Scrum团队在开发需求的时候，从待开发功能列表最上层的高优先级的需求开始开发。在Scrum中，只要有1～2个迭代（sprint）开发细化了高优先级的需求，就可以启动迭代，而不必等到所有的需求都细化之后。我们可以在开发期间通过梳理待开发功能列表来逐步细化需求。
版权声明：51Testing软件测试网获得人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
