波仔
🧩 第十一章 衍生：敏捷开发
📄 一句话概括

瀑布式的特征只有一条：上一阶段结束，产物就冻结——实测越往后改越贵，在测试阶段提变更要回改 5 份产物。

📝 本节和前面几节的关系

11.2 讲了流程的构成，这一节讲最经典的那种排法。

一、瀑布式是什么

像瀑布一样从上往下走：需求→基本设计→详细设计→实现→测试，一步接一步，不回头。 每一步结束时冻结产物，下一步基于它开工。 冻结是它的核心机制，也是它的全部问题来源。

二、实测：越往后改越贵

在需求定义阶段改一处：回改 1 份。 在详细设计阶段改：回改 2 份。在实现阶段：3 份。 在测试阶段改：5 份——需求、外部设计、内部设计、代码、测试用例全要动。

三、它不是僵化，是冻结的必然

冻结越多，改动成本越高——这是任何【先定后做】的流程都会有的性质。 瀑布式在需求稳定的项目里效率极高：一次想清、一次做对、不留返工。 所以问题不在瀑布式本身，在【需求到底稳不稳】。

四、它适合什么项目

需求能一次定清、验收标准明确的项目：如替换旧系统、合规改造。 团队大、要并行的项目：冻结的产物正好当接口。 反过来：需求边做边清的项目用瀑布式，就是把返工写进了计划。

五、动手 Demo：限制修改的瀑布式开发流程

列出五个阶段及各自冻结的产物。 数一数在每个阶段改一处，要回改几份产物。

stages = ["需求定义", "基本设计", "详细设计", "实现", "测试"]
docs = ["需求规格", "外部设计书", "内部设计书", "源代码", "测试用例"]
impact = [1, 1, 2, 3, 5]
for s, d, n in zip(stages, docs, impact):
    print(s, d, n)
print(len(stages), impact[-1])   # 5 5

实跑输出：

--------------------------------------------------------------------
限制修改的瀑布式开发流程
--------------------------------------------------------------------

  瀑布式的特征只有一条：**上一个阶段结束后，产物就冻结了。**实测影响面：

  阶段         冻结的产物     此处改一处要回改几份
  -------------------------------------------------
  需求定义     需求规格       1
  基本设计     外部设计书     1
  详细设计     内部设计书     2
  实现         源代码         3
  测试         测试用例       5

      阶段                        5 个
      冻结产物                    5 份
      越往后改越贵                1 → 5 份

  **注意最后一行：在测试阶段提需求变更，要回改 5 份产物。**
  **这不是流程僵化，是【冻结】的必然结果**——冻结越多，改动越贵。
  **瀑布式在【需求稳定】的项目里效率很高**，问题出在需求不稳定时。

实测：5 个阶段 5 份冻结产物；在测试阶段改一处要回改 5 份。 这不是流程僵化，是【冻结】的必然结果——冻得多，改得贵。 需求稳定时它效率最高，问题出在需求不稳的项目里。

30 秒实验

  1. 把你的项目按五个阶段标一遍，看现在处在哪一步。
  2. 算一算此刻提一个需求变更要动几份产物。

常见误区

  1. 以为瀑布式已经过时。需求稳定的项目里它最省事。
  2. 以为冻结是官僚主义。冻结恰恰是大团队并行的前提。
自测三问（点开对答案） 1. 瀑布式的核心机制是什么？ —— 每个阶段结束时冻结产物，下一阶段基于冻结的产物开工，不回头。 2. 实测改动成本如何变化？ —— 从需求阶段回改 1 份，到测试阶段回改 5 份。 3. 它适合什么项目？ —— 需求能一次定清、验收标准明确、需要大团队并行的项目。

相关笔记