下载掌阅APP，畅读海量书库
立即打开
在20世纪90年代，软件开发行业被认为处于危机之中，人们称之为“软件危机”。根据“CHAOS报告” [Standish1994] ，当时很多软件项目超预算、延迟交付、不符合需求，有近三分之一的项目被直接取消。
敏捷并不是针对这场危机的回应，而是对其回应的回应。
为了将软件开发置于管控之下，大型组织创建了非常详细的流程，准确定义了软件的生产方式。一切都被严格控制，以免出错（至少理论上是这样）。
首先，业务分析师将采访利益相关者并记录系统需求。接下来，软件架构师将阅读需求文件并创建详细的设计文件，指定系统的每一个组成部分以及它们之间的关系。然后，程序员会将设计文件转换成代码。在一些组织中，这被认为是低技能的工作，只是一种机械性的翻译练习。同时，测试负责人将使用相同的文件来生成测试计划，当编码完成后，大量的测试人员将手动执行这些测试计划，并将差异报告为缺陷。在每个阶段结束后，一切都将被仔细记录、审查和签署。
这些基于阶段的方法后来被称为“瀑布 [1] 式开发”或“阶段门开发”。如果这些听起来像一个危言耸听的笑话，那么请相信你是幸运的——你避开了软件工程领域的蛮荒时代。在20世纪90年代，并不是每家公司都使用大量的文档、基于阶段的流程，但当时这被看作一种合乎逻辑的、合理的工作方式。在当时，大家被要求去定义需求，然后设计、实施、测试，并记录每个阶段，这就是所谓的纪律和工程。否则你怎么可能成功？
[1] 瀑布模型通常被误认为源于Winston Royce 在1970年发表的一篇论文，但基于阶段的方法可以追溯到20世纪50年代，而Royce 的论文直到20世纪80年代末才被广泛关注，当时人们用它来描述他们已经在做的事情。 [Bossavit2013]（第7章）