使用技巧

Scrum vs Kanban,如何选择?


两大方法

虽然敏捷诞生只有20年的时间,但却帮助了很多企业取得了成功,在这期间也出现了各种敏捷方法论和思想体系,这篇文章,我们试图去讨论一个问题:对于准备实施敏捷的团队,在Scrum和Kanban两种方法之间如何选择?(特别说明:有人会说Kanban其实是一套思想体系,不是方法论,这里我们不想陷入概念之争,只想解释他们适用的场景,所以下文中都会称呼他们为方法,而不会刻意加以区分)。

Scrum和Kanban两者都作为符合精益思想和敏捷的思考结果,他们之间必然会有一些相似点:

  • 两者都限制开发中工作数目

  • 两者都是通过透明度来驱动过程改进

  • 两者都提倡提及时且稳定的交付价值

  • 两者都基于自组织型团队

  • 两者都要求把工作细分

  • 两者都是基于经验数据持续优化

再来看看两者之间的一些区别:

[Terry] 粘贴上传 -2020-04-08 18_14 03.png

下面结合实例来演示Scrum和Kanban这两种方法如何在Worktile Agile中体现。

Scrum

在标准的Scrum流程定义中,有两个关键的产物:Product Backlog和Sprint Backlog,以及四个关键的会议:计划会议、每日立会、评审会议和回顾会议。
在Worktile Agile产品中,我们把Product Backlog分为需求和缺陷,其中需求部分使用Epic-Feature-User Story三级体系来表示。

  • Epic:史诗,表示比较大的特性,开发周期一般是1-3月,用于产品路线图的规划

  • Feature:特性,表示相对小一些的特性,开发周期一般是1-3周,用于产品版本的规划

  • User Story:用户故事,表示最小的用户场景,开发周期一般是1-3天,用于迭代规划。

image.png

图1 Worktile Agile中需求管理

在每个迭代开始时会召开计划会议,全员都会参加,这个会议最重要的事情就是确定Sprint Backlog,由Product Owner按照优先级介绍Product Backlog,然后团队决定是否把某一个条目放入当前迭代。

image.png

图2 Worktile Agile中迭代规划

迭代进行的时间内,每天都会有10-15分钟的站立会议,团队中每个成员基于Worktile中的迭代任务板介绍前一个工作日所做的事情,以及遇到的问题。

image.png

图3 Worktile Agile中的迭代任务板

迭代结束时召开评审会议,在评审会议上每个人基于产品演示自己在这个迭代中所完成的成果,团队成员可以针对完成的事项提一些建议。在评审会议结束后,团队成员会一起召开迭代回顾会,回顾会是Scrum迭代实践中的最后一环,也是最重要的一环,迭代回顾会将整个迭代形成了闭环。回顾会上大家提出的问题通过迭代回顾面板记录。

image.png

图4 Worktile Agile中的迭代回顾面板

在Scrum实践中,大部分团队都会忽视版本管理,迭代是针对Scrum团队的活动行为,而版本管理是针对产品的,它定义的是一个批量的概念,用于版本进度管理和交付风险管理,明确在一个版本中的最终交付物,Worktile Agile中你可以创建版本并把它与迭代关联,或者只是单纯的设置某个用户故事/缺陷属于某个版本

image.png

图5 Worktile Agile中的版本管理

Kanban

对于一个团队采用Kanban方法来管理是否能够成功,取决于使用Kanban后能否为你的团队带来以下几点改进:

  • 帮助团队可视化整个链条的价值流动

  • 帮助团队识别价值流动中的风险点

  • 帮助团队度量价值流动中的各种浪费,并加以消除

基于这些考虑,在Worktile Agile中的Kanban项目类型,目前支持以下的能力:

  • 能够清晰定义在制品WIP

  • 能够清晰定义在制品限制WIP Limit

  • 明确定义DoD

  • 支持多泳道分割

image.png

图6 Worktile Agile中的Kanban项目

在Worktile Agile中的同一个项目中,支持同时创建多个看板,便于你根据业务场景的不同,或者团队角色的不同定义多个看板,并且可以针对每个看板的需要进行个性化的配置。

image.png

图7 根据团队的需要个性化你的看板

因地制宜

讲完了Scrum和Kanban的基础知识,以及在Worktile Agile中对于Scrum和Kanban的支持,我们来看看在实际团队落地时,如何结合实际情况在二者之间选择。

  1. 如果你的团队是产品导向型的,推荐使用Scrum;如果是研究导向型的,比如性能优化、编码优化等不确定性非常大的,推荐使用Kanban。
  2. 团队规模适中,5-9人左右,并且有跨功能团队成员,推荐使用Scrum;相反如果你的团队规模比较小,只有2-5人左右,推荐使用Kanban,相对效率较高。
  3. 产品或者项目交付是按照一定的周期来计算,比如每2周或每个月要求有一个新的版本,推荐使用Scrum;如果产品或者项目的交付不是按周期来计算,而是按照某个特定的事件为标志,比如性能提升了10%发布一个新版,推荐使用Kanban。
    当然这些只不过是一点经验之谈,具体还要看团队的实际情况,因地制宜,来推动敏捷在团队的真正落地,而不是流于形式。