06 | 敏捷开发

一、什么是敏捷开发？

敏捷不是一种方法论，也不是一种软件开发的具体方法，更不是一个框架或过程，而是一套价值观和原则。

也就是说，当你开发做决策的时候，遵守了敏捷开发的价值观和原则，不管你是不是用 Scrum 或者极限编程，那么都可以算是敏捷开发。

敏捷开发就是快速迭代、持续集成、拥抱变化。

二、敏捷开发想解决什么问题？

如果你仔细读了敏捷宣言，你会发现，宣言中右边的内容其实都是瀑布模型核心的内容：流程和工具、详尽的文档、合同谈判、遵循计划。

虽然敏捷开发并未对瀑布模型的价值进行否定，但也表明了瀑布模型做的还不够好，同时提出了一套自己的价值观。

比如说，我们开始做一个新项目，需要从客户那里收集整理需求，如果按照传统的软件开发模式，我们需要在开发前获得所有需求，然后和客户签订合同，在发布前都不会轻易修改需求。

但是如果我们采用敏捷开发模式来开发项目，那这样做显然违背敏捷的价值观：“客户合作高于合同谈判”。所以如果是敏捷开发，在每个迭代后，都应该向客户收集反馈，然后在后面的迭代中，酌情加入客户反馈修改的内容。

结合敏捷开发提出的背景，你其实不难发现，敏捷开发就是想解决瀑布模型这样的重型软件开发方法存在的问题，用一种轻量的、敏捷的方法来改善甚至是替代它。这些年敏捷开发也是一直这么做的。

瀑布模型的典型问题就是周期长、发布烦、变更难，敏捷开发就是快速迭代、持续集成、拥抱变化。

三、如果用敏捷的方式盖房子

在讲瀑布模型的时候，我拿盖房子举了个例子，

如果改成用敏捷开发的模式盖房子，则会是这样子的：

• 客户想要盖一栋房子（初步的想法）。
• 产品经理和客户进行了初步的沟通，把用户的需求写成了一个个用户故事（用简单的用户故事代替繁重的需求文档），
• 例如：作为一个上班族，我想要一个卧室，以便于休息；作为一个家庭主妇，我想要一个厨房，以便于做饭。
• 施工人员根据用户故事和客户进一步沟通（客户合作高于合同谈判），然后对用户故事进行设计和实现；
• 每个用户故事开发时，还要给一个测试机器人编写测试脚本，让机器人可以自动测试（大量采用自动化测试），并且做好的用户故事可以随时被测试验收（随时发布，持续集成）；
• 每个 Sprint 四个星期时间（时间盒子，迭代时间固定）；
• 第一个 Sprint 搭了个草棚，一张床就是卧室，厕所就挖了一个坑，厨房还来不及搭建（每个 Sprint 会选择高优先级的用户故事），屋顶还在漏水（每个 Sprint 会定期发布，客户可以随时看到可用版本，即使还不完整）；
• 第二个 Sprint 有了简易厨房，同时修复了屋顶漏水的毛病（每个 Sprint 不仅完成用户故事，还会修复 Bug）；
• 第三个 Sprint 升级成了小木屋，但是忘记加上窗户（敏捷推崇自动化测试，但可能会测试不完备）；
• 第四个 Sprint 升级成了砖瓦房，窗户也开好了，客户可以入住。但是这时候客户发现一家三口的话，完全不够用，需要扩建到 3 个卧室。于是决定下个迭代改成 3 个卧室（响应变化高于遵循计划）；
• 第五个 Sprint，升级成了 3 个卧室，升级过程中把厨房下水道弄坏了（迭代过程中可能会导致质量不稳定）；
• 第六个 Sprint，修复了下水道的问题，房子也装修好了（迭代中不断完善）；
• 客户验收使用（上线）。

用敏捷开发的方式，不再像瀑布模型那样有严格的阶段划分，会在迭代中不断完善；不再写很多文档，而是和客户一起紧密合作；不再抵制需求变更，而是即时响应变更；不再等到测试阶段才发布，而是随时发布，客户随时可以看到东西。

当然，采用敏捷开发的模式也存在一些问题，例如全程需要客户参与，由于测试相对少一些 ，问题也会相应多一些。

四、敏捷开发和瀑布模型的差异

这些年敏捷开发，已经逐步发展出一套 “Scrum + 极限编程 + 看板” 的最佳实践，Scrum 主要用来管理项目过程，极限编程重点在工程实践，而看板将工作流可视化。

我将基于 Scrum 和极限编程的实践，来对比一下敏捷开发模型和瀑布模型的差异。

1. 敏捷开发是怎么做需求分析的？（用户故事）

瀑布模型要求产生详尽的需求分析文档，敏捷开发的需求来源于一个个的用户故事：

• 作为用户，我想登录网站
• 作为客人，我想有个卧室休息

在Sprint的开发中再去确认具体需求的细节。

好处：减少了大量需求文档的编写，可以早些进入开发；

但对开发人员在需求理解和沟通的能力上要求更高了。

2. 敏捷开发是怎么做架构设计的？（一部分需求，渐进式架构，会产生技术债务）

瀑布模型在需求分析完了以后，就需要根据需求做架构设计。

而在敏捷开发中，并不是基于完整的用户需求开发，每个 Sprint 只做一部分需求，所以是一种渐进式的架构设计，当前 Sprint 只做适合当前需求的架构设计。

这种渐进式的架构设计，迭代次数一多，就会出现架构满足不了需求的现象，产生不少冗余代码，通常我们叫它技术债务，需要定期对系统架构进行重构。

3. 敏捷开发怎么保证项目质量？（编写开发功能时编写单元测试和集成测试，自动化测试）

瀑布模型在编码完成后，会有专门的阶段进行测试，以保证质量。

在敏捷开发的 Sprint 中，并没有专门的测试阶段，这就依赖于开发功能的同时，要编写单元测试和集成测试代码，用自动化的方式辅助完成测试。

相对来说，这种以自动化测试为主的方式，质量确实是要有些影响的。

4. 敏捷开发是怎么发布部署的？（持续集成，每完成一个任务构建部署，测试）

瀑布：编码–>测试环境–>生产环境

瀑布模型通常在编码结束后，开始部署测试环境，然后在测试阶段定期部署测试环境。测试验收通过后，发布部署到生产环境。

敏捷开发：持续集成

在敏捷开发中，这种持续构建、持续发布的概念叫持续集成，因为整个过程都是全自动化的，每次完成一个任务，提交代码后都可以触发一次构建部署操作，脚本会拿最新的代码做一次全新的构建，然后运行所有的单元测试和集成测试代码，测试通过后部署到测试环境。

持续集成是一个非常好的实践，极大的缩短和简化了部署的流程，而且自动化测试的加入也很好的保证了部署产品的质量。前期搭建整个持续集成环境需要一定技术要求。

5. 敏捷开发的 Sprint 和迭代模型的迭代有什么区别？

增量模型和迭代模型，这两种也是一种快速迭代的方式，那么敏捷开发和 迭代模型的区别是什么？

迭代模型本质上是一个小瀑布模型，所以在一个迭代里面，需要完整的经历从需求分析，到设计、编码、测试这几个完整的阶段。

所以像瀑布模型一样，刚开始测试的时候是不稳定的，到测试后期才逐步稳定下来，一般迭代前期也会相对轻松一点，而后期测试阶段可能会时间很紧张。

敏捷开发的 Sprint 中，没有像瀑布模型那样严格的开发阶段划分，而是一个个循环迭代的 Sprint。

举例来说，一个瀑布模型的项目，可能会按照阶段分成：2 周需求分析，2 周设计，4 周编码，2 周测试，然后上线发布，一共 10 周。如果用敏捷开发的方式来进行，那么可能会是每 2 周一个 Sprint，每个 Sprint 结束后，都会发布上线，每次发布的可能只是完整功能的一部分，但是每次发布的都是一个可用的版本，通过多个 Sprint 的迭代，最终完成项目开发。具体到每一个 Sprint 的开发周期中，在一个 Sprint 中会有多个小的开发任务，这些开发任务主要是新功能的开发和 Bug 的修复。

由于每个 Sprint 周期很短，所以不能像瀑布模型那样有充足的时间去做需求分析、设计和测试，那么敏捷开发中怎么保证质量呢？在敏捷开发中，通常用“用户故事”这样的方式来代替传统的需求分析，也就是以用户故事的形式，对一个需求进行简单的描述，配合关键的测试用例，并且和需求方的紧密沟通，让开发人员可以理清楚需求；通过“只做刚刚好的设计”来节约设计上的时间；通过“自动化测试”、“持续集成”来提升测试效率。

相对来说，敏捷开发中，整个 Sprint 的节奏是比较恒定，产品也是相对稳定的，即使用户故事没有完成，也不影响版本的发布。因此，敏捷开发更注重软件开发中人的作用，需要团队成员以及客户之间的紧密协作。

五、什么时候选择敏捷开发？

条件：

• 团队要小，人数超过一定规模就要分拆；
• 团队成员之间要紧密协作，客户也要自始至终深度配合；
• 领导们的支持。敏捷需要扁平化的组织结构，更少的控制，更多的发挥项目组成员的主动性；
• 写代码时要有一定比例的自动化测试代码，要花时间搭建好源码管理和持续集成环境。

因为敏捷开发对项目成员综合素质要求更高，做计划要相对难一些。如果团队大、客户不配合、领导不支持，再好的敏捷方法也很难有效实践起来。

如果你要实践敏捷开发，建议先找个小项目进行试点，能证明可行了，再进一步推广。

有条件的话，可以和一些顾问公司合作，请人做专门的培训和指导。如果不具备条件，应该考虑先把其中一些好的实践用起来，比如说持续集成、每日站会、自动化测试等。

六、总结

流程、工具、文档、合同、计划都是工业化的标志。它们带来了稳定的质量、惊人的效率、超大规模的协作，对于软件工业也是如此。

然而软件工业具备轻资产、知识密集型、从业人员素质高等特点，充分发挥人的创造力和价值，是其相较传统工业更高阶的要求。加之软件工程面对的不确定性与复杂度更显著。于是“个体和互动高于流程和工具，工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划”的敏捷思想应运而生。

通过用户故事，理解用户需求。在迭代中采用渐进的架构设计。定期重构解决技术债务。功能开发的同时编写自动测试代码。自动化持续构建。

由于淡化了部分工业思维中兼顾稳定、质量、效率、成本的传统手段，敏捷思想的最终落地，需要素质极高的从业人员参与其中，且数量不宜过多，以此来弥补流程上的缺失。同时要团队与客户紧密协作，上级的充分信任，才能够有效发挥其灵活应变，又万变不离其宗的优势。这是大胆的返璞归真，好似回到了瀑布模型前的蛮荒时代，实则是更高级的打法，就像独孤九剑一般。所以，敏捷开发“道”的属性更浓。

敏捷开发具有快速迭代、持续集成、拥抱变化等诱人的特点，但也有苛刻的条件要求。不过，即使无法推行完整的敏捷开发，依旧可以在传统模式下，有针对性的应用敏捷开发的实践方法。