详谈Scrum和看板的区别

上次我们用一张图给大家展示了Scrum和看板的区别，今天我们通过案例再来详细的说一说。

我认为从宏观层面，两者的区别如下（图1）：

图1 Scrum对比看板方法

1.变革方式不同

从组织变革的角度，Scrum需要拆分组织，成立跨职能小团队，任命新的角色。比如，原来做一个需求需要跨越多个部门的交接，包括产品部门、设计部门、开发部门、测试部门、运维部门，Scrum Guide对跨职能团队的定义是：“拥有完成工作所需要的全部技能，不需要依赖团队以外的人。”因此，Scrum需要打破各个部门的壁垒，涉及到产品交付的每个部门抽出人员，组建能够不依赖于外部，可以独立交付产品增量的团队。

Scrum团队里只有三个角色：Scrum Master, 产品负责人（PO）, 开发团队。因此，每个组织初次尝试Scrum的时候都有这样的困惑：我们组织现有的角色怎么办？必须对组织原有的角色做转型，才能加入到Scrum团队里承担新的角色职责。

因此，Scrum需要对组织做手术，属于剧烈变革方式。

而看板方法不规定团队的组成、角色和责任分工。这并不是说你不能或是不应该在看板里有产品负责人等角色，只是说不是必须有。此外，看板方法本身不规定具体的流程，几乎对任何工作方式都是开放的，它仅有的规范就是将流程可视化和限制在制品。虽然规范少，但仍有令人惊异的力量。从理解和分析现有的工作方式起步，应用看板的六个实践，持续渐进地改进工作方式。因此，看板方法属于温和的渐进式变革方式。

由于这个差异，那些组织文化属于求稳不求变、不敢承担变革风险的企业更拥抱看板方法。

案例：

某银行科技网络集团，产品研发分布在三个城市：开发中心在珠海、测试中心在杭州、运维中心在深圳。2014年该企业选择了一个团队试点了Scrum，发现对组织现有的冲击很大，组建Scrum团队需要打破三个地域的研发中心，困难很大，结果没有继续进行下去。于是该企业开始尝试看板方法，广受欢迎，没有受到大的抵触，于2016年全面应用，依托看板暴露出的组织问题，逐步牵引组织缓慢转型。

2.基本流程不同

Scrum的工作单位是固定时间箱的迭代周期。即，每个迭代周期“Sprint”有个明确的交付目标和需求范围，Sprint结束时要交付一个产品增量。固定时长的迭代是Scrum的基础之一。团队可以自己选择迭代长度，但一般都会在一定时间内让迭代长度固定不变，继而形成固定节奏。

基于这个差异，维护类项目天然适合用看板方法。因为，团队无法给维护类项目设置一个迭代周期，并且固定这个周期的范围。即使团队做了Sprint计划，第二天会有一堆更紧急的线上问题打断，导致原来的Sprint的计划作废。

此外，除了维护类项目，一些互联网团队为了快速响应业务变化，也开始打破时间箱的周期，转向看板方法。

案例：

中国电商网站1号店在2014年之前一直应用Scrum，所有团队一刀切地采用两周的迭代周期。后来，很多团队发现即使才两周的周期内，业务上仍有大量的需求变化导致原来的Sprint计划无法执行。于是，1号店开始打破迭代周期，向看板方法转型，每周一次计划，每周两次上线。

3.规则的显示化程度不同

Scrum的规则主Scrum流程上的规则，即：三个角色，五个事件和三个工件。除此之外，Scrum还有DoD（DOD: Definition Of Done: “完成的定义”），用来评估产品增量是否完成。Scrum Guide对DoD的定义是：当产品待办列表项或者增量被描述为“完成”的时候，每个人都必须理解“完成”意味着什么。虽然DoD在不同的Scrum团队之间会有巨大的差别，但是团队成员必须对完成意味着什么有相同的理解。但是，至于怎么达到这个DoD, 没有进一步的约定。

此外，Scrum对任务板的设计没有规定，团队自己设计，但是一般都是三列: To Do（Not Started), Doing（In progress), Done。

图2 Scrum 任务板示例

像图2这样的任务板设计，对于Doing（In progress)这一列，Story到底处于什么阶段不是一目了然，无法判断Story是在设计、开发，还是在测试阶段。

而在看板方法里，价值流动的每个环节都可视化在看板上，Story是处于什么阶段一目了然。一个工作项从上游步骤流转到下游需要达到什么条件有明确的规则，这个条件在看板方法里成为“拉动条件”，如图5-4所示。这个拉动条件相当于分解的DoD（完成的定义）。价值流动的每个环节达到了拉动条件，最终保证整个产品增量达到了DoD。因此，看板方法对流程规则的显示化程度更高。

** 图3看板方法里的拉动条件**

4．运作单位不同

Scrum流程规则中的三个角色、五个事件和三个工件都是围绕团队来设计和运作。Scrum的运作单位是单个Scrum团队。因此，Scrum是以团队为中心的工作方式。

看板方法是以价值流为中心的工作方式。看板方法里没有团队的概念，以价值流为单位建立看板。使用看板的单位可以是一个团队，也可以是多个团队共同使用，这取决于价值流的范围。

5.领导力不同

Scrum强调团队自组织、自管理，不期望管理层从上向下对团队施加管理。由于这个基本理念，Scrum流程里没有设置管理者这一角色，并且取缔了传统项目管理方式里的“项目经理”角色。定义了Scrum Master，作为服务型领导，对团队没有管理职权，引导团队自管理。Scrum 联盟在敏捷价值观的基础上，定义了Scrum的五个价值观，它们是：聚焦、勇气、开放、承诺和尊重。Scrum Master引导团队聚焦Sprint目标，保持开放的心态，开诚布公地跟团队分享当前的工作进展、困难；引导团队互相尊重、彼此互助、迎接挑战，兑现Sprint目标的承诺。

看板方法本着尊重已有的角色、职称和工作职责的原则，对现有的角色给予极大的保护。因此，看板方法没有过多地强调团队自组织。相反，看板方法鼓励实施各级领导力。这里的各级领导力体现在以下方面：

1. 团队每个成员的领导力

也许你会觉得诧异，普通的团队成员有什么领导力，不是只有领导才有领导力吗？这是对管理和领导的误解。一个人不是一定要在管理者的位置上，才能实施领导力。在看板方法里，个人的领导力体现在以下几个方面：

1. 鼓励每个团队成员可视化自己名下工作项的真实状态，敢于暴露有问题的工作项，在每日站会上主动反馈工作项的风险，敢于求助；

2. 当其他成员遇到困难时，不依赖管理者，主动想办法，集思广益，帮助同事解决问题；

3. 每个人的行为都影响其他人，建立这种透明、负责、互助的团队文化。

4. 每个管理者的领导力

管理者的领导力体现在以下几个方面：

1. 引导团队建立价值流；
2. 团队成员提出遇到障碍时，管理者需要及时引导团队，或帮助团队解决；
3. 对于团队反馈的困难，管理者不搪塞，积极帮助团队解决；
4. 设立鼓励透明、负责、互助、创新的考核机制；
5. 引导团队持续优化价值流，打造持续改进的文化。

总的来说，Scrum对团队的自组织能力要求比较高。在团队从命令控制的管理方式转型到Scrum的初始阶段，需要Scrum Master行使较强的服务型领导力，训练团队逐渐向自组织团队转变。