Waterfall

Waterfall 把一个项目作为一连串有序的阶段来执行：先收集所有需求，然后设计整个系统，然后构建它，然后测试它，然后部署它。每个阶段产出一份签署确认的文档，并在下一个阶段开始之前完成。它的吸引力显而易见：你预先就知道计划、成本和日期，而且所有人在写下一行代码之前都达成一致。

它对某些工作仍然有正当的适用之处。当范围真正固定且被充分理解时，当监管方要求预先的文档和可追溯性时，或当你在构建硬件、金属切下后无法廉价迭代时，顺序式阶段就是诚实的模型。把这样的项目假装成「敏捷」，只是把计划藏了起来，而不是把它去掉。

合同这一面，是 Waterfall 与敏捷碰撞得最具体的地方。在奥地利和德国法律下，一份固定价格的 Werkvertrag 需要一个明确的交付物来绑定供应商，这会自然地把项目推向一个瀑布式、被完整规格化的范围。真正迭代的工作，也就是你预期需求会随学习而变化的那种，更适合 Dienstvertrag 或 Retainer。当创始人既想要固定价格的法律确定性、又想要敏捷的灵活性时，麻烦就来了：这两者朝相反方向拉扯。诚实的解法通常是先做一段固定价格的发现，把范围钉到足以定价的程度，然后用剩余不确定性实际所需的那种边界渗透度去跑构建。

它在产品探索上失败得很惨。致命的假设是，你能在任何用户接触它之前就预先把正确的产品规范定下来。你几乎永远做不到。等到构建阶段结束时，几个月前收集的需求已经有一部分是错的，而 Waterfall 没有廉价的办法在测试阶段之前发现这一点，那时改动任何东西都很昂贵。你得到的是一个符合规范却错失需求的产品。

与敏捷诚实的区分：Waterfall 把所有决策前置，并赌它们是对的。敏捷（无论是以 Scrum 还是一种更轻量的流动来跑）把决策分散到整个工作过程中，并赌早期反馈会抓住错误的决策。无论哪种，两者都只是对同一组底层 SDLC 阶段所做的排序选择。对于任何你还不确切知道该构建什么的事情，这个赌注偏向敏捷。对于任何答案真正已知且固定的事情，Waterfall 的可预测性是一个优点，而不是缺陷。