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

极限不是瀑布式错了，而是它要求一件做不到的事：开工前把需求定清——实测 20 条需求里只有 12 条能定清，剩下 8 条（40%）要见到东西才清楚。

📝 本节和前面几节的关系

11.3 讲了瀑布式的机制，这一节讲它在哪里撞墙。

一、实测：40% 的需求要见到东西才清楚

20 条需求里，开工时能定清的 12 条（60%）。 剩下 8 条（40%）要见到东西才清楚——不是客户不说，是说不出。 瀑布式要到第 5 阶段（测试）才见到东西，那时改一处要回改 5 份产物。

二、这是认知限制，不是态度问题

人对自己想要什么的认知，是在看到东西之后才成形的。 所以【请客户一次说清】这个要求本身就不合理，跟客户认不认真无关。 这 40% 就是瀑布式的天花板：它把不确定的部分当成确定来处理。

三、两种反应

第一种：硬扛——把 12 条当 20 条，剩下 8 条靠猜。结果是验收时返工。 第二种：承认不确定——早点给客户看到东西，让那 8 条尽早成形。 第二种就是 11.5 的迭代式，它不是新潮流，是把这件事认了。

四、极限不等于没用

需求稳定的项目，那 40% 可能只有 5%——这时瀑布式依然最优。 所以判据是【不确定有多大】，不是【流不流行】。 这一条判断，比记住任何流程的名字都值钱。

五、动手 Demo：瀑布式开发流程的极限

拿 20 条需求，数开工时能定清几条、要见到东西才清楚几条。 对比瀑布式与迭代式在【见到东西】这件事上的差别。

total, clear_at_start = 20, 12
unclear = total - clear_at_start
print(total, clear_at_start, unclear, 100 * unclear // total)   # 20 12 8 40

实跑输出：

--------------------------------------------------------------------
瀑布式开发流程的极限
--------------------------------------------------------------------

  瀑布式的极限在哪？**开工时就有 8 条需求定不清。**实测：

      需求条目总数                20 条
      开工时能定清的              12 条（60%）
      见到东西才清楚的            8 条（40%）
      瀑布式在第几阶段才见到      5 阶段（测试）
      此时回改要动几份产物        5 份

  情形                       瀑布式         迭代式
  ---------------------------------------------------
  什么时候见到能跑的东西     最后一阶段     每轮末尾
  发现理解错时的改动成本     很高           较低
  需求稳定时的效率           高             中

  **极限不是【瀑布式错了】，而是【它要求一件做不到的事】**：开工前把需求定清。
  **40% 的需求要见到东西才清楚**——这是人的认知限制，不是态度问题。
  **所以 11.5 的迭代式不是【新潮流】，是把这件事认了。**

实测：20 条需求里 12 条能定清，8 条（40%）要见到东西才清楚。 这是认知限制：人对自己想要什么的认知，是看到东西之后才成形的。 瀑布式把不确定当确定处理，这就是它的天花板。

30 秒实验

  1. 回想一个验收时被推翻的需求，它在开工时是不是【以为已经说清了】。
  2. 估一估你项目里那 40% 有多少。

常见误区

  1. 以为需求没说清是客户不认真。是认知还没成形。
  2. 以为承认不确定就是没计划。迭代式的每轮范围是定死的。
自测三问（点开对答案） 1. 瀑布式的天花板是什么？ —— 要求开工前定清需求，而实测 40% 的需求要见到东西才清楚。 2. 为什么说是认知限制？ —— 人对自己想要什么的理解，是在看到东西之后才成形的，与态度无关。 3. 两种反应分别是什么？ —— 硬扛（把 12 条当 20 条，验收返工）或承认不确定（早点让客户看到东西）。

相关笔记