1.1 敏捷的起源

在20世纪90年代，软件开发行业被认为处于危机之中，人们称之为“软件危机”。根据“CHAOS报告”[Standish1994]，当时很多软件项目超预算、延迟交付、不符合需求，有近三分之一的项目被直接取消。

敏捷并不是针对这场危机的回应，而是对其回应的回应。

为了将软件开发置于管控之下，大型组织创建了非常详细的流程，准确定义了软件的生产方式。一切都被严格控制，以免出错（至少理论上是这样）。

首先，业务分析师将采访利益相关者并记录系统需求。接下来，软件架构师将阅读需求文件并创建详细的设计文件，指定系统的每一个组成部分以及它们之间的关系。然后，程序员会将设计文件转换成代码。在一些组织中，这被认为是低技能的工作，只是一种机械性的翻译练习。同时，测试负责人将使用相同的文件来生成测试计划，当编码完成后，大量的测试人员将手动执行这些测试计划，并将差异报告为缺陷。在每个阶段结束后，一切都将被仔细记录、审查和签署。

这些基于阶段的方法后来被称为“瀑布[1]式开发”或“阶段门开发”。如果这些听起来像一个危言耸听的笑话，那么请相信你是幸运的——你避开了软件工程领域的蛮荒时代。在20世纪90年代，并不是每家公司都使用大量的文档、基于阶段的流程，但当时这被看作一种合乎逻辑的、合理的工作方式。在当时，大家被要求去定义需求，然后设计、实施、测试，并记录每个阶段，这就是所谓的纪律和工程。否则你怎么可能成功？