3.2　敏捷

3.2.1　敏捷的理念

软件工程有很大的进步意义，但是慢慢地，人们觉得好像哪里不太对劲。软件开发跟别的技术领域还是有一些区别的：它是富有创造性的活动，它不是那么可预测和可计划的，并且它的成果往往是等用户用起来才能切身体会到。所以工程化的方法不是100%适用。似乎开发过程、角色分工有点儿太复杂、太僵化了，好像各种中间产物特别是文档有点儿太多了，特别是对于小产品、小团队来说，过犹不及！在这样的背景下，敏捷运动兴起了。

在2001年提出的“敏捷软件开发宣言”[1]中说，“我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

• 个体和互动　高于　流程和工具。

• 工作的软件　高于　详尽的文档。

• 客户合作　高于　合同谈判。

• 响应变化　高于　遵循计划。

也就是说，尽管右项有其价值，但我们更重视左项的价值。”

所以它的核心意思就是，你们引入软件工程，用工程化的思想做软件开发，挺好，上面每句话中的后半句都是有道理的。但是不要太过了，还是要灵活一点、务实一点，这就是上面每句话中的前半句高于后半句的含义。

“敏捷软件开发宣言”遵循的原则[2]有12条，这也是它的核心思路。具体如下：

• 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

• 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

• 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

• 业务人员和开发人员必须相互合作，项目中的每一天都不例外。

• 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

• 不论团队内外，传递信息效果最好、效率也最高的方式是面对面的交谈。

• 可工作的软件是进度的首要度量标准。

• 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

• 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

• 以简洁为本，它是极力减少不必要工作量的艺术。

• 最好的架构、需求和设计出自自组织团队。

• 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

总体来说，敏捷是在纠正软件工程过于强调工程化的倾向。当然，如果把敏捷片面地理解成不要流程、不写文档、不做计划，那就矫枉过正了。说到底，是要找一个对特定业务、特定团队来说合适的“姿势”。

3.2.2　敏捷的实践

敏捷的落地，包括管理实践和工程实践两个方面。在管理实践中，接受度最高的是Scrum，相信读者大多耳熟能详。大体上，Scrum团队以每两到四周的时间作为一个冲刺（Sprint）周期，也就是做一次迭代。在一个冲刺之初，确定好要实现哪些用户故事（User Story），迭代中一般不会再改变。当迭代结束时，这些用户故事应该已经被集成并且可以演示。可以看出，与瀑布模型、V模型、RUP（Rational Unified Process，Rational统一过程）相比，Scrum是一个相当轻量的开发计划和管理的框架。对于小团队来说，它好上手，招人喜欢。

敏捷的工程实践包括不少内容，其中被普遍采用的有单元测试、持续集成等。相对来说，结对编程、测试驱动开发等还没有被广泛地采用。

其中的持续集成，在3.4节中会稍微详细地介绍一下。尽管从敏捷的角度来看，它是敏捷的工程实践之一，但它已经重要和独立到我们应该单独介绍了。