Intro: 简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷 开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试， 具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但 也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有 快速工作、响应变化能力的价值观和原则，并于 2001初成立了敏捷联盟。他们 正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。

敏捷开发(agile development)概念从2004年初开始广为流行。Bailar非 常支持这一理论，他采取了 "敏捷方式"组建团队：Capital One的"敏捷团队" 包括3名业务人员、两名操作人员和5〜7名IT人员，其中包括1个业务信息 指导(实际上是业务部门和IT部门之间的"翻译者");另夕卜，还有一个由项目经 理和至少80名开发人员组成的团

队。这些开发人员都曾被 Bailar送去参加过" 敏捷开发"的培训，具备相关的技能。

每个团队都有自己的敏捷指导(Bailar聘用了 20个敏捷指导)，他的工作 是关注流程并提供建议和支持。最初提出的需求被归 纳成一个目标、一 堆记 录详细需要的卡片及一些供参考的原型和模板。在整个项目阶段，团队人员密 切合作，开发有规律地停顿--在9周开发过程中停顿3〜4次，以评估过程及决 定需求变更是否必要。在Capital One大的IT项目会被拆分成多个子项目， 安排给各"敏捷团队"，这种方式在"敏捷开发"中叫"蜂巢式(swarming)"，所有 过程由一名项目经理控制。

为了检验这个系统的效果，Bailar将项目拆分，从旧的"瀑布式"开发转变 为"并列式"开发，形成了 "敏捷开发"所倡导的精 干而灵活的开发团队，并将开 发阶段分成30天一个周期，进行"冲刺"--每个冲刺始于一个启动会议，到下个 冲刺前结束。

在Bailar将其与传统的开发方式做了对比后，他感到非常兴奋 --"敏捷开 发"使开发时间减少了 30%-40%有时甚至接 近50%提高了交付产品的质量 "不过，有些需求不能用敏捷开发来处理。"Bailar承认，"敏捷开发"也有局 限性，比如对那些不明确、优先权不清楚的需求或处于 "较快、较便宜、较优" 的三角架构中却不能排列出三者优先级的需 求。此外，他觉得大型项目或有特 殊规则的需求的项目，更适宜采用传统的开发方式。尽管描述需求一直是件困 难的事，但经过阵痛之后，需求处理流程会让 CIO受益匪浅。

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

・ 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判

个体和交互 胜过过程和工具 * 响应变化 胜过遵循计划 并提出了以下遵循的原则： 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客 户满意。 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客 户创造竞争优势。 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个 月，交付的时间间隔越短越好。 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持, 并且信任他们能够完成工作。 在团队内部，最具有效果并富有效率的传递信息的方法，就是面对 面的交谈。 工作的软件是首要的进度度量标准。 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够 保持一个长期的、恒定的开发速度。 • 不断地关注优秀的技能和好的设计会增强敏捷能力。 • 简单是最根本的。 ・ 最好的构架、需求和设计出于自组织团队。

每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然 后相应地对自己的行为进行调整。

MatainFlow: 从无到繁重再到敏捷 多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改” (code and fix)。设计过程充斥着短期的，即时的决定，而无完整的规划。这种模式 对小系统

开发其实很管用，但是当系统变得越大越复杂时，要想加入新的功能 就越来越 困难。同时错误故障越来越多，越来越难于排除。一个典型的标志就 是当系统功能完成后有一个很长的测试阶段，有时甚至有遥遥无期之感，从而 对项目的完成产生严重的影响。

我们使用这种开发模式已有很长时间了，不过我们实际上也有另外一种选择， 那就是“正规方法” (methodology)。这些方法对开发过程有着严格而详尽的 规定，以期使软件开发更有可预设性并提高效率，这种思路是借鉴了其他工程 领域的实践。 这些正规方法已存在了很长时间了，但是并没有取得令人瞩目的成功，甚 至就没怎么引起人们的注意。对这些方法最常听见的批评就是 它们的官僚繁琐， 要是按照它的要求来，那有做太多的事情需要做，而延缓整个开发进程。所以 它们通常被认为是“繁琐滞重型”方法，或 Jim HighSmith 所称的“巨型” (monumental) 方法。

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

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

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

1 敏捷型方法是“适配性”而非“预设性”。 重型方法试图对一个软件开 发项目在

很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法 在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其 实，它们的目的就 是成为适应变化的过程，甚至能允许改变自身来适应变化。

2 敏捷型方法是“面向人”的 (people-oriented) 而非“面向过程”的

(process-oriented) 。 它们试图使软件开发工作顺应人的天性而非逆之。它们 强调软

件开发应当是一项愉快的活动。

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

Ation：

Adaptive Planning Pair Automated Programming Testing 枳 . Continuous Integration

Customer Engagement f Test Driven St^nd up

Development j ；

Frequent Refactoring Releases

Collaboratrve Focus Minimal Documentation

这两个圆圈表示不同的视角上的敏捷实践，包括开发者视角和项目管理的视 角。接下来从里向外进行介绍。 Test-Driven Development，测试驱动开发，它是敏捷开发的最重要的部分。 在

ThoughtWorks,我们实现任何一个功能都是从测试开始，首先对业务需求 进行分析，分解

为一个一个的 Story，记录在Story Card上。然后两个人同时 坐在电脑前面，一个人依照Story，从业务需求的角度来编写测试代码，另一 个人看着他并且进行思考，如果有不同的意见就会提 出来进行讨论，直到达成 共识，这样写出来的测试代码就真实反映了业务功能需求。接着由另一个人控 制键盘，编写该测试代码的实现。如果没有测试代码，就不能 编写功能的实现 代码。先写测试代码，能够让开发人员明确目标，就是让测试通过。

Continuous Integration ，持续集成。在以往的软件开发过程中，集成是一 件很痛

苦的事情，通常很长时间才会做一次集成，这样的话，会引发很多问题， 比如build未通过或者单元测试失败。敏捷开发中提倡持续集成，一天之内集 成十几次甚至几十次，如此频繁的集成能尽量减少冲突，由于集成很频繁，每 一次集成的改变也很少，即使集成失败也容易定位错误。一次集成要做哪些事 情呢？它至少包括：获得所有源代码；编译源代码；运行所有测试，包括单元 测试、功能测试等；确认编译和测试是否通过，最后发送报告。当然也会做一 些其它的任务，比如说代码分析、测试覆盖率分析等等。 在我们公司里，开发 人员的桌上有一个火山灯用来标志集成的状态，如果是黄灯，表示正在集成；

如果是绿灯，表示上一次集成通过，开发人员在这时候获得的代码 是可用而可 靠的；如果显示为红灯，就要小心了，上一次集成未通过，需要尽快定位失败 原因从而让灯变绿。在持续集成上，我们公司使用的是自己开发的产品 CruiseC on trol

Refactoring，重构。相信大家对它都很熟悉了，有很多很多的书用来介绍重 构，最

著名的是Martin的《重构》，Joshua的《从重构到模式》等。重构是 在不改变系统外部行为下，对内部结构进行整理优化，使得代码尽量简单、优 美、可扩展。在以往开发中，通常是在有需求过来，现在的系统架构不 容易实 现，从而对原有系统进行重构；或者在开发过程中有剩余时间了，对现在代码 进行重构整理。但是在敏捷开发中，重构贯穿于整个开发流程，每一次开发者 check in代码之前，都要对所写代码进行重构，让代码达到 clean code that works。值得注意的是，在重构时，每一次改变要尽可能小，用单元测试来保证 重构是否

引起冲突，并且不只是对实现代码进行重构，如果测试代码中有重复， 也要对它进行重构。

Pair-Programming，结对编程。在敏捷开发中，做任何事情都是 Pair的，包

括分析、写测试、写实现代码或者重构。Pair做事有很多好处，两个人在一 起探讨很容易产生思想的火花，也不容易走上偏路。在我们公司，还有很多事 都是Pair来做，比如Pair学习，Pair翻译，Pair做PPT关于这个话题，钱 钱同学有一篇很有名的文章对它

进行介绍，名为 Pair Programming （结对编程）。

Stand up，站立会议。每天早上，项目组的所有成员都会站立进行一次会议， 由于是