聊聊敏捷转型（上篇）︱敏捷软件开发

本文内容章节：

一、什么是敏捷?

1、敏捷宣言及其由来

1.1 个体和交互胜过过程和文档

1.2 可工作的软件胜过全面的文档

1.3 客户合作胜过合同谈判

1.4 相应变化胜过遵循计划

2、七种敏捷开发方法

2.1 XP（极限编程）

2.2 Scrum（迭代式增量软件开发过程）

2.3 Crystal Methods（水晶方法族）

2.4 FDD （特性驱动开发）

2.5 ASD（自适应软件开发）

2.6 DSDM（动态系统开发方法）

2.7 轻量型RUP

二、为什么要做敏捷?

1、敏捷和传统瀑布的特点和差别

1.1 瀑布开发模式的五大特点

1.2 敏捷开发模式的八大特点

2、敏捷能解决什么问题

2.1 版本发布的时间越来越长；

2.2 无法按时发布；

2.3 在版本发布的最后阶段让软件稳定的时间越来越长；

2.4 在发布期间很难进行改变；

2.5 质量持续恶化。

3、敏捷有哪些优缺点

3.1 敏捷的优点

(备注：后续内容请阅读下周发布的本文下篇)

一、什么是敏捷？

敏捷开发（Agile Development）是一种以人为核心、迭代、循序渐进的开发方法。

我们要想用好敏捷方式去管理项目就不得不去了解它，其中敏捷宣言就是重中之重。看似简单的四句话却蕴含了一系列的变革与创新。下面，我们就先来聊聊这四句话。

1、敏捷宣言及其由来

在2001年2月11日到13日，17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地Snowbird雪场。与会者包括XP、Scrum、DSDM、适应性软件开发和其他支持此类方法的方法学代表，它们都需要选择一种方法来替代文档驱动的、重量级的软件开发过程。经过两天的讨论，“Agile”这个词被全体与会者所接受，用以概括一套全新的软件开发价值观。Jim Highsmith认为，大部分敏捷原则都可以归结为“糊状材料”和“流星似的兴趣提升，有时对敏捷方法学的批判就是这种糊状材料蕴含的传统和价值”，这是这样的观点，形成了下面的敏捷宣言：

1.1个体和交互胜过过程和文档

通过第一条宣言的“Individuals”，我们就可以看到敏捷对于人是排在第一位的。这是因为敏捷方法着重强调有能力的、可以自我管理的团队并且是一只有自制能力的团队，而不需要日复一日的管理干预。而管理者要能够保护团队免受外界的干扰，让团队集中精力来消除项目中的各项障碍，让团队具有凝聚力和创造力。

对于团队而言，需要由跨职能的成员组成，在目标明确后做出承诺，自行考虑目标的实现过程，实现自组织和自管理。着重解决“How”的问题。对于管理者而言，则需要确立项目的目标，把过程的管理交付于团队，有团队成员自行解决。

在整个过程中，需要面对面的沟通，而不通过文档描述，着重解决“What”和“Why”的问题。

敏捷项目团队的成员能够彼此进行必要的协作，他们作为一个团队创建系统，而不像一群接力比赛的运动员那样按照顺序的过程创建系统。他们运用自身所学，同时集体的知识也得到了积累。最终，引起设计、质量和生产率都得到提高。

1.2可工作的软件胜过全面的文档

通过之前的文章提到过，敏捷是以价值来驱动工作的，那么可工作的软件就是我们的价值体现，在实现过程中的设计、编写的代码在不以软件形式让用户使用的话，那么它们就是一推假设而且还是没有价值的假设。这样的观点在传统项目管理上通过完成百分比来度量进度是截然不同的，考察可工作的软件让我们能够对项目的真实状态做出合适的响应。所有东西都是可见的，能够基于现有的产品做出决策，而不是只依据有关的文档形式的材料。

事实上，团队成员认为有些文档工作是不经济的。那是因为，通过文档来描述需求等问题，会造成信息夹杂噪音，使传递的信息失真，所以更愿意用基于可工作的产品来进行面对面的沟通和反馈。

1.3客户合作胜过合同谈判

从传统意义上来讲，合同识别和定义了客户想要的所有东西，规定了金额和完成日期。但对于软件项目来说，由于需求的不固定导致了我们往往会制造出无法满足客户要求的产品，因为我们往往做一些没有意义的工作，仅仅因为出于遵守合同的名义。用固定的方式去固定不稳定的假设，这本身就就充满矛盾。

客户合作意味着客户已经成为开发过程中的组成部分。敏捷项目团队重视客户能够学会如何让客户做出业务决策。反过来，客户也依赖项目团队提供的重要的技术信息来做出合适的决策。有时客户在没有看到东西之前并不知道自己想要的是什么。

1.4相应变化胜过遵循计划

在计划驱动的环境中，所有需求都是被现实规定的，成本和完成日期是根据这些颗粒较细的任务通过自下而上的计算得到的。因此，严格根据计划执行任务、控制范围蔓延在计划驱动的项目中非常重要，因为只有这样才能限制或消除成本超支或进度拖延。事实上，敏捷项目团队是非常训练有素的，并且专注于制定计划和在访问这些计划。敏捷方法中的计划更遵循波浪起伏式的方法，采用自上而下的策略。

左边的价值高于右边的价值但别忘了：

在考虑敏捷宣言的最后一条价值陈述时，重要的是强调价值陈述左边的条款，如果需要的话，在右边条款确实能够带来价值的情况下在强调右边的条款。这里只是考虑左边的价值大过右边的价值，但不代表右边没有价值。

2、七种敏捷开发方法

敏捷开发包括一系列的方法，主流的有如下七种：

2.1XP（极限编程）

XP（极限编程）的思想源自 Kent Beck和Ward Cunningham在软件项目中的合作经历。XP注重的核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化，XP无需开发人员在软件开始初期做 出很多的文档。XP提倡测试先行，为了将以后出现bug的几率降到最低。

2.2Scrum（迭代式增量软件开发过程）

Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。

SCRUM中发布产品的重要性高于一切。

该方法由Ken Schwaber和 Jeff Sutherland 提出，旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进。

2.3Crystal Methods（水晶方法族）

Crystal Methods（水晶方法族）由Alistair Cockburn在20实际90年代末提出。之所以是个系列，是因为他相信不同类型的项目需要不同的方法。虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵循它。

2.4FDD （特性驱动开发）

FDD （Feature-Driven Development，特性驱动开发）由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发，是一套针对中小型软件开发项目的开发模式。此外，FDD是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、 易于被开发团队接受，适用于需求经常变动的项目。

2.5ASD（自适应软件开发）

ASD（Adaptive Software Development，自适应软件开发）由Jim Highsmith在1999年正式提出。ASD强调开发方法的适应性（Adaptive），这一思想来源于复杂系统的混沌理论。ASD不象其他方法那样 有很多具体的实践做法，它更侧重为ASD的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。

2.6DSDM（动态系统开发方法）

DSDM（动态系统开发方法）是众多敏捷开发方法中的一种，它倡导以业务为核心，快速而有效地进行系统开发。实践证明DSDM是成功的敏捷开发方法之一。在英国，由于其在各种规模的软件组织中的成功，它已成为应用最为广泛的快速应用开发方法。

DSDM不但遵循了敏捷方法的原理，而且也适合那些成熟的传统开发方法有坚实基础的软件组织。

2.7轻量型RUP

RUP其实是个过程的框架，它可以包容许多不同类型的过程， Craig Larman 极力主张以敏捷型方式来使用RUP。他的观点是:目前如此众多的努力以推进敏捷型方法，只不过是在接受能被视为RUP 的主流OO开发方法而已。

2、 为什么要做敏捷？

敏捷开发只是一种用来应付需求快速变化的软件开发方法。

在当今互联网及一些企业认为敏捷是万能的，每当出现项目一团糟，不能及时给客户交付产品，或者交付的产品没有达到客户的预期等等问题时，就会想到敏捷。于是就着手进行敏捷转型，上来想知道怎么转，因为很多敏捷型转型失败的。失败的原因当然各不相同，但想转型成功还是有一些规律可循的，第一个规律就是正确地理解和选择敏捷开发。

很多企业想转型敏捷开发的原因是“开发人员的效率低下，这么多人还完不成老板要开发的功能和速度”。或者许多IT主管或是工程师，都把敏捷开发误以为是一种快速交付的方法，就因为它比传统开发方法快一些。

敏捷开发不是一种快速的开发方法，也不是用来解决所谓的“开发效率”问题的，如果真要提高开发效率可以从人的技能培养、流程优化、工具改进等方面来提升，而跟敏捷开发本身没太大关系，敏捷反而会降低所谓的效率。

它是一种用来应付需求快速变化的软件开发方法。

1、敏捷和传统瀑布的特点和差别

上图是敏捷迭代式和传统瀑布式在软件开发中的一些差异

1.1瀑布开发模式的五大特点

1、严格把软件项目的开发分隔成各个开发阶段：需求分析，要件定义，基本设计，详细设计，编码，单体测试，结合测试，系统测试等。使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开。

2、重视和强调过程文档，在开发的中后期才会看到软件原型，早起只能通过文档来了解系统的模样。在这种情况下，文档的重要性仿佛已经超过了代码的重要性。

3、瀑布模型把每个开发阶段都定义为黑盒，希望每个阶段的人员只关心自己阶段的工作，不需要关注其他阶段的工作。

4、既然叫做瀑布，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。

5、更适合需求相对稳定的大型项目。

1.2敏捷开发模式的八大特点

1、简单设计，避免过度设计。重复迭代、减少不必要的文档。

2、客户最关心的功能最先完成。要求客户有时间对每次迭代的成果进行确认，提出改进意见。

3、showcase（就是开发团队把开发好的功能给客户的Product Owner（以下简称PO）等业务相关人员演示，以获取他们对所开发系统的反馈）。

4、沟通是非常重要的，所有的开发人员对项目活动的理解应该是一致的。加强团队之间和客户之间的沟通。

5、测试驱动开发（TDD）

6、需要更强的个人和团队能力。敏捷的管理是团队的自我管理和项目经理的服务式管理。

7、敏捷开发不能在一开始就给出项目完整的成本计划。在有技术问题还没有解决的情况下不适合展开迭代。

8、敏捷实践：晨会，deadline，负责人制等等。

TDD：测试驱动开发是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD的基本思路就是通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。TDD首先考虑使用需求（对象、功能、过程、接口等），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证。

传统开发与敏捷开发可以想象上图植物成长的过程

2、敏捷能解决什么问题

敏捷不是万能的，但相比瀑布开发模式，还是可以解决很多项目中现实存在的问题。传统瀑布开发模式中，下面的一些问题可以用敏捷很好的解决：

2.1版本发布的时间越来越长

在敏捷流程中，版本是由一系列增量集成在一起组成的，这些增量通过一个一个迭代按顺序开发。我们还可以在任意时间停止迭代。一旦发现产品的价值已经达到最大，尤其是发现软件里过半的功能很少被使用的时候，就可以停止迭代。

2.2无法按时发布

在敏捷流程中，版本的发布延迟最多不会超过30天，因为每个迭代的最长期限就只有30天。当到达交付期限的时候，就可以交付累积的增量。由于不会在迭代中开发低价值的功能，因此可以比以往更早地发布完整的系统。

2.3在版本发布的最后阶段让软件稳定的时间越来越长

在敏捷流程中，每个迭代所产生的增量都是完整和可用的，后续迭代所产生的增量都会包含之前所有迭代产生的增量，因此任何迭代产生的增量都是完成且可用的。也就是说，没有软件稳定化时期，因为软件一直保持稳定。

2.4在发布期间很难进行改变

版本发布中期的概念在迭代增量式项目中已经不复存在了。我们能够以最小的代价，在每个迭代开始前发现或者提出需求。

2.5质量持续恶化

在敏捷流程中，每个迭代产生的增量都是完整可用的。因此，增量必然已经通过质量测试。而后续迭代产生的增量同样要满足相同的质量要求，也就是说我们再也不必在项目的最后阶段为了赶上交付期限而牺牲质量，因为质量始终伴随着这个软件的整个开发过程。

3、敏捷有哪些优缺点

3.1敏捷的优点

敏捷的优点比较显著，主要有下面几点：

1、可以拥抱变化。可行的长期计划比较难制定并执行，在计划执行过程中会导致需求的变化，需求的变化必然导致开发工作不能按计划进行，而且“人”作为开发过程中最重要的因素时时刻刻都在变化，人员会有更替，人会有情绪，人会有私事，各种因素都会影响计划的执行，所以计划要短，及时调整才能响应一切变化导致的计划的不可行性，避免走弯路。

2、能够快速响应市场。市场环境的变化，越来越要求产品、服务的响应及时。比如按照传统方式，规划半年一个版本，一旦需要调整需求，后面所有的计划都得改变，会为项目管理带来极大的挑战，变化的成本奇高，多数情况下会因为多数人的反对而不了了之。

3、快速将功能推向市场变现。“成为第一，胜过做得最好”，在很多商业环境下是有效的，特别是在互联网行业，迅速占领市场更显得尤其重要，这是在向时间要效益。

4、在有限的资源条件下，做最值得做的事。因为Backlog的每一项都具有按唯一优先级顺序，都是已经排好序了，敏捷要求逐项完成用户故事，而不是全面开花，因为其评价结果是二值的，做完就是1，做不完就是0，没有75%一说，因为做完了才能交付，做完了才能投向市场变现。

3.2敏捷的局限性

敏捷也有它一定的局限性，个人认为主要有下面几点：

1、项目人数不能太多，一般在5~10人左右；

2、对团队成员要求比较高，要有很高的自主性；

3、不是很适合传统大型项目，如基建，大型工程等；

4、缺少过程资产积累，注重沟通轻文档。若人员流动性太大会给项目维护带来不少难度。

在现在管理项目过程中，各种开发模式都有其独特的地方和优缺点。并没有严格的按照完全的敏捷或者完全的瀑布模式，都是各自掺杂了其他的方式。

在实际项目过程中，过于强调模式并没有意义，重要的是能不能预防问题的发生，在问题发生之后能不能用最小的成本解决，模式更多起一个参考作用。

我们在选择敏捷之前，首先需要解决的是要多问自己几个为什么，找到项目或产品中需要敏捷解决的真正问题是什么，再来选择是不是采用敏捷方式。

文章来源：PMO之路 Mason