小瀑布到敏捷的转型

敏捷 ：关注软件生产，是一种制作流程；

DevOps : 关注软件自动化流程化的送到客户手里，打通最后一公里；

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

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

表面上看起来似乎没有什么问题，这个模式也是按照Scrum的方式在工作，2周一个迭代。Scrum相关的计划会议、每日站会、评审会议、回顾会议也都在按照Scrum的规定进行。

这里最大的问题在于各个角色之间的协作方式仍然没有发生变化，仍然是契约式的。这势必会导致下游要求上游提供更加详细的文档，上下游之间也势必会期望保留证据以分清责任，带来的结果是仍然有大量的文档交接，增加了沟通壁垒。

由于要求需求提供更多的文档，前期工作会更多，会导致开发启动太晚，测试介入时间更晚，因此这种模式下迭代最后加班的情况会非常普遍，导致Sprint交付质量很差。

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

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

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