敏捷方法

新型软件开发方法

敏捷方法，是一种新型软件开发方法。不要求遵循传统的软件开发流程，强调快速开发和有效适应需求变化，典型代表如极限编程、测试驱动开发等。

简介

它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。

敏捷开发

敏捷开发（agile development）是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

敏捷开发是全新理论吗？答案莫衷一是。细心的人们可以发现，敏捷开发其实借鉴了大量软件工程中的方法。迭代与增量开发，这两种在任何一本软件工程教材中都会被提到的方法，在敏捷开发模式中扮演了很重要的角色。再向前追溯，我们还也可见到瀑布式与快速原型法的影子，也许还有更多。

改善，而非创新。敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华，去其糟粕。因此敏捷开发继承了不少原有方法的优势。“在敏捷软件开发的过程中，我们每两周都会得到一个可以工作的软件，”Fowler介绍，“这种非常短的循环，使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。”

也许是因为时间关系，Fowler只说出了这些优势中的一部分。允许开发过程中的需求变化、通过早期迭代可以较早发现风险、使代码重用变得可行、减少项目返工……借鉴了众多先进方法和丰富经验，拥有的众多优势使得敏捷开发看来已经成为解决软件危机的标准答案。

问题与思考

然而，我们不得不面对的现实却是，模式与方法的优化并不意味着问题的终结。作为一种开发模式，敏捷开发同样需要面对众多挑战。

大项目的拆分意味着更多子项目的出现，协调这些同步或异步推进的子项目，合理的资源调配都将变得更加复杂。另外，在当前项目和项目组普遍“增容”的情况下，遇到的问题同样成倍增长。人的重要性被提到了更高的高度，而缺乏有效协调手段，减少人员流动和项目变更对整个项目造成的影响也将成为一大挑战……新方法带来众多便利的同时，也相应引发了几乎同样多的问题。

业务部门

每个团队都有自己的敏捷指导（Bailar聘用了20个敏捷指导），他的工作是关注流程并提供建议和支持。最初提出的需求被归纳成一个目标、一堆记录详细需要的卡片及一些供参考的原型和模板。在整个项目阶段

开发阶段

在Bailar将其与传统的开发方式优先权大型项目或有特殊规则的需求的项目，更适宜采用传统的开发方式。尽管描述需求一直是件困难的事，但经过阵痛之后，需求处理流程会让CIO受益匪浅。

敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则，并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，他们认为：

并提出了以下遵循的原则：

一、敏捷开发方法

（一）说明

本文是阅读Alistair Cockburn的Agile Software Development和William C. Wake的XP Explored的一些笔记和想法，Agile Software Development是一组软件开发方法的总称，包括（Crystal , Extreme Programming , Adaptive software development等等）。敏捷开发方法又称为“轻量级”开发方法。

下面这段话摘自Martin Fowler的一篇文章：

从无到繁重再到敏捷

多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改” （code and fix）。设计过程充斥着短期的，即时的决定，而无完整的规划。这种模式对小系统开发其实很管用，但是当系统变得越大越复杂时，要想加入新的功能就越来越困难。同时错误故障越来越多，越来越难于排除。一个典型的标志就是当系统功能完成后有一个很长的测试阶段，有时甚至有遥遥无期之感，从而对项目的完成产生严重的影响。

我们使用这种开发模式已有很长时间了，不过我们实际上也有另外一种选择，那就是“正规方法”（methodology）。这些方法对开发过程有着严格而详尽的规定，以期使软件开发更有可预设性并提高效率，这种思路是借鉴了其他工程领域的实践。

这些正规方法已存在了很长时间了，但是并没有取得令人瞩目的成功，甚至就没怎么引起人们的注意。对这些方法最常听见的批评就是它们的官僚繁琐，要是按照它的要求来，那有做太多的事情需要做，而延缓整个开发进程。所以它们通常被认为是“繁琐滞重型”方法，或Jim HighSmith 所称的“巨型”（monumental）方法。

作为对这些方法的反叛，在过去几年中出现了一类新方法。尽管它们还没有正式的名称，但是一般被称为“敏捷型”方法。对许多人来说，这类方法的吸引之处在于对繁文缛节的官僚过程的反叛。它们在无过程和过于繁琐的过程中达到了一种平衡，使得能以不多的步骤过程获取较满意的结果。

敏捷型与滞重型方法有一些显著的区别。其中一个显而易见的不同反映在文档上。敏捷型不是很面向文档，对于一项任务，它们通常只要求尽可能少的文档。从许多方面来看，它们更象是“面向源码”（code-oriented）。事实上，它们认为最根本的文档应该是源码。

但是，我并不以为文档方面的特点是敏捷型方法的根本之点。文档减少仅仅是个表象，它其实反映的是更深层的特点：

? 敏捷型方法是“适配性”而非“预设性”。重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。

? 敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。

我认为以上两个特点很好的概括了敏捷开发方法的核心思想：适应变化和以人为中心

（二）方法背后的思想

Alistair Cockburn在Agile Software Development中讲述了敏捷开发方法背后的思想

人们掌握过程（process）可以分为3个阶段：

1 following 遵循一个定义好的process

2 detaching 知道不同process的适用范围，在不同的场合使用不同的process

3 fluent 不关心是否遵循特定的process，知道在什么情况下采用什么动作

软件开发是一个充满发明和交流的协作性游戏(cooperative game of invertion and communication)。软件开发的首要目标是生产出软件，遵循特定的过程和模型只是手段，只要传递了足够的信息，手段是次要的。交流的效果要远远重于交流的形式（Effect of communication is more important than the form of communication）。

一般软件开发有两个目标：1 尽快的生产出软件2 为下一个team或项目做准备，有时这两个目标是矛盾的，我们要在这两个目标之间寻求平衡

在软件开发中，人的因素要远远大于过程和技术。人是有缺陷的：

1 容易犯错误，因此必须在错误扩散之前找到并改正错误

2 当觉得可能失去较多的时候，不愿意冒险

3 重新构造而不愿意重复使用已有的东西

4 难于坚持一个习惯

针对个人因素的几个建议：

1 具体的模型较抽象的模型更容易理解

2 从一个例子开始是容易的

3 通过观察他人的成果学习

4 要有足够的不受打扰的时间

5 分配的工作要与个人意向，能力匹配

6 不正确的奖励会有坏作用，从长期看个人兴趣比奖励更重要，培养在工作中的自豪感：

(1) pride in work参与工作的自豪感，通常参与一个重要的工作会有自豪感

(2) pride in accomplishment 完成工作的自豪感，长期未完的工作会使士气低落

(3)pride in contribution 为他人贡献的自豪感

7 鼓励关心其他人的工作和整体的工作

在一个团队之间，交流是最重要的，实践证明面对面的实时的交流是最有效的，对交流的延误会损失信息，白板是最好的交流工具，交流工具的先进并不能提高交流效果。文档的作用是记录和备忘，不能通过文档交流。

敏捷开发方法要避免的过程设计的几个常见错误

1 对所有的项目使用同一种过程

2 没有弹性

3 过于沉重

4 增加不必要的“必须完成”（“should do” is really should？）

5 没有经过实践检验

敏捷开发方法过程设计的几个原理：

1 交互的面对面的交流是代价最小，最迅速的交换信息的方法

2 超过实际需要的过程是浪费的

3 大的团队需要重量级方法

4 处理重大问题的项目需要重量级方法强调

5 增加反馈和交流可以减少中间产品和文档的需求

6 轻量级方法更强调理解（understanding）,自律（discipline）和技能(skill)，重量级方法更强调文档（documentation），过程（process）和正式（formality）

understanding指整个团队关于项目的全部知识，包括讨论的过程，documentation只能记录其中的一部分

discipline是指个人主动的完成工作，process指个人根据指令完成工作

skill指具有良好技能的人可以省略中间的产品，formality指必须按照规定步骤完成工作

7 确定开发中间的瓶径，提高它的效率

对于瓶径处的工作应该尽量加快，减少重复，（使用更熟练的人，使用更多的人，使用更好的工具，使瓶径处的工作的深入尽量稳定）对于非瓶径处的工作可以多一些重复，在输入还不确定的情况下也可以尽早开始。

这些原理的几个结论：

1 向一个项目增加人员要花费较大代价（constly），因为原有人员和新人员之间的交流要花费大量时间

2 团队的规模经常是跳跃的，例子：需要6个熟练的程序员，但是只有4个，于是增加不熟练的程序员，结果团队的大量时间花费在培训不熟练的程序员上面，最后增加到了20个不熟练的程序员。

3 应该侧重于提高团队的技能而不是扩充团队

4 对不同的项目使用不同的过程

5 在适用的条件下，轻量级的方法优于重量级的方法

6 对不同的项目要裁减过程

敏捷开发方法的原则是“刚刚好”（Light and Sufficient）

开发重点

敏捷宣言四个价值中的两个都强调的敏捷方法对协作有重要性。“整个流程和工具中涉及到的人和交互”提醒着我们相到尊重的交流的重要性。例如，与其让测试和开发人员使用缺陷跟踪工具来记录bug，还不如鼓励他们坐下来，一起使用重要创建并解决问题。“根据合同指示的客户协作”提醒我们开发团队给予的灵活性更重要，更能令客户满意，找到协作解决方案来解决产品开发中可能会出现的问题，远远比只是固守着严格的合同好的多。

虽然协作并不是局限在使用敏捷方法团队的中，但与控制命令型企业文化相比，敏捷开发实践可以通过培养交流的企业文化帮助企业更好地发展。敏捷心态与交流文化中的价值实践类似——鼓励共享驱动决策，自我管理跨功能团队和服务型领导。

开发安全

在敏捷产品开发中，提高安全性的一些建议如下：