瀑布模式把产品的开发过程分为多个阶段，如图（1）所示：
它有以下三个主要的特点：
1.强调预测性，期望在一开始预见大批量的需求。
2.文档驱动，前后阶段之间顺序工作，强调每个阶段的输入和输出，而这些输出主要都是中间产物，比如需求文档、设计文档、未经验收的代码等。
3.严格控制变更，因为变更的成本比较高。
除了交付周期比较长，瀑布主要的问题还在于每个阶段的团队通常在不同的职能部门，上下游之间的合作关系是契约关系，而不是共享责任的协作关系，上下游之间更多的责任的传递和信息传递，而不是围绕价值交付的沟通协作。
在一些实施Scrum的团队，特别是从瀑布模式转型到Scrum的团队，你会发现他们虽然也是在按照Scrum的形式开展工作，但却不能看到效果，非常的挣扎。迭代很难交付高质量的成果，迭代加班也是常态。为什么会是这样呢？
仔细观察这些团队的工作方式，你会发现，他们虽然使用了Scrum的各种仪式，把迭代也变短了，但是他们还是在按照瀑布的习惯和工作方式在工作，而没有去思考敏捷的核心价值。
图（2）是一个比较典型的小瀑布模式:
表面上看起来似乎没有什么问题，这个模式也是按照Scrum的方式在工作，2周一个迭代。Scrum相关的计划会议、每日站会、评审会议、回顾会议也都在按照Scrum的规定进行。这里最大的问题在于各个角色之间的协作方式仍然没有发生变化，仍然是契约式的。这势必会导致下游要求上游提供更加详细的文档，上下游之间也势必会期望保留证据以分清责任，带来的结果是仍然有大量的文档交接，增加了沟通壁垒。由于要求需求提供更多的文档，前期工作会更多，会导致开发启动太晚，测试介入时间更晚，因此这种模式下迭代最后加班的情况会非常普遍，导致Sprint交付质量很差。
在执行Scrum的时候，除了要看到Scrum外在的一些形式，更要理解它背后的思维模式。敏捷的核心思维在于通过价值驱动的方式，频繁地交付可见的工作成果，及早获得对市场、用户需求的正确认知，以更好地适应市场需要。 为了实现短平快的交付，团队成员共享责任、密切协作至关重要，共享责任、密切协作的目的是为了实现围绕目标交付的整体优化，而避免只是完成份内工作的局部优化。因此，实施Scrum，团队首先要在同一条船上，共享责任。图（3）是我个人比较建议的交付模式，即跨职能完整团队按照故事驱动的方式，集中优势兵力各个击破。
按照这样的方式交付，不论是PO还是团队内的任何一个成员，都以交付故事为目标，大家在一条船上。故事相关的所有工作不论分析、UE／UI、前端、后端、开发还是测试，必须都完成了，故事符合验收标准了才算完。只是单个职能、或者单项工作完成，并不带来实际的商业价值。
避免小瀑布的建议： 审视一下您的团队合作方式，如果还是契约式、顺序的合作模式，那么请尝试打破协作壁垒，尝试让各个角色共享责任、密切协作，按照故事驱动的方式交付， 实现价值驱动、频繁地交付可见的工作成果。
本文作者：
廖靖斌 Eric Liao， CSP，CSM，知名敏捷教练、顾问、培训师
