Scrum_tupian3

Scrum反模式之 —— 小瀑布

瀑布模式把产品的开发过程分为多个阶段,如图(1)所示:

Scrum_tupian2

它有以下三个主要的特点:
1.强调预测性,期望在一开始预见大批量的需求。
2.文档驱动,前后阶段之间顺序工作,强调每个阶段的输入和输出,而这些输出主要都是中间产物,比如需求文档、设计文档、未经验收的代码等。
3.严格控制变更,因为变更的成本比较高。

除了交付周期比较长,瀑布主要的问题还在于每个阶段的团队通常在不同的职能部门,上下游之间的合作关系是契约关系,而不是共享责任的协作关系,上下游之间更多的责任的传递和信息传递,而不是围绕价值交付的沟通协作。

在一些实施Scrum的团队,特别是从瀑布模式转型到Scrum的团队,你会发现他们虽然也是在按照Scrum的形式开展工作,但却不能看到效果,非常的挣扎。迭代很难交付高质量的成果,迭代加班也是常态。为什么会是这样呢?

仔细观察这些团队的工作方式,你会发现,他们虽然使用了Scrum的各种仪式,把迭代也变短了,但是他们还是在按照瀑布的习惯和工作方式在工作,而没有去思考敏捷的核心价值。

图(2)是一个比较典型的小瀑布模式:

Scrum_tupian1

表面上看起来似乎没有什么问题,这个模式也是按照Scrum的方式在工作,2周一个迭代。Scrum相关的计划会议、每日站会、评审会议、回顾会议也都在按照Scrum的规定进行。这里最大的问题在于各个角色之间的协作方式仍然没有发生变化,仍然是契约式的。这势必会导致下游要求上游提供更加详细的文档,上下游之间也势必会期望保留证据以分清责任,带来的结果是仍然有大量的文档交接,增加了沟通壁垒。由于要求需求提供更多的文档,前期工作会更多,会导致开发启动太晚,测试介入时间更晚,因此这种模式下迭代最后加班的情况会非常普遍,导致Sprint交付质量很差。

在执行Scrum的时候,除了要看到Scrum外在的一些形式,更要理解它背后的思维模式。敏捷的核心思维在于通过价值驱动的方式,频繁地交付可见的工作成果,及早获得对市场、用户需求的正确认知,以更好地适应市场需要。 为了实现短平快的交付,团队成员共享责任、密切协作至关重要,共享责任、密切协作的目的是为了实现围绕目标交付的整体优化,而避免只是完成份内工作的局部优化。因此,实施Scrum,团队首先要在同一条船上,共享责任。图(3)是我个人比较建议的交付模式,即跨职能完整团队按照故事驱动的方式,集中优势兵力各个击破。

Scrum_tupian

按照这样的方式交付,不论是PO还是团队内的任何一个成员,都以交付故事为目标,大家在一条船上。故事相关的所有工作不论分析、UE/UI、前端、后端、开发还是测试,必须都完成了,故事符合验收标准了才算完。只是单个职能、或者单项工作完成,并不带来实际的商业价值。

避免小瀑布的建议: 审视一下您的团队合作方式,如果还是契约式、顺序的合作模式,那么请尝试打破协作壁垒,尝试让各个角色共享责任、密切协作,按照故事驱动的方式交付, 实现价值驱动、频繁地交付可见的工作成果。

 

本文作者:

廖靖斌 Eric Liao, CSP,CSM,知名敏捷教练、顾问、培训师