ScrumVSKanban,如何选择?


ScrumVSKanban,如何选择?
文章图片
两大方法
虽然敏捷诞生只有20年的时间 , 但却帮助了很多企业取得了成功 , 在这期间也出现了各种敏捷方法论和思想体系 , 这篇文章 , 我们试图去讨论一个问题:对于准备实施敏捷的团队 , 在Scrum和Kanban两种方法之间如何选择?(特别说明:有人会说Kanban其实是一套思想体系 , 不是方法论 , 这里我们不想陷入概念之争 , 只想解释他们适用的场景 , 所以下文中都会称呼他们为方法 , 而不会刻意加以区分) 。
Scrum和Kanban两者都作为符合精益思想和敏捷的思考结果 , 他们之间必然会有一些相似点:
两者都限制开发中工作数目
两者都是通过透明度来驱动过程改进
两者都提倡提及时且稳定的交付价值
两者都基于自组织型团队
两者都要求把工作细分
两者都是基于经验数据持续优化
再来看看两者之间的一些区别:
ScrumVSKanban,如何选择?
文章图片
Scrum
在标准的Scrum流程定义中 , 有两个关键的产物:ProductBacklog和SprintBacklog , 以及四个关键的会议:计划会议、每日立会、评审会议和回顾会议 。 在WorktileAgile产品中 , 我们把ProductBacklog分为需求和缺陷 , 其中需求部分使用Epic-Feature-UserStory三级体系来表示 。
Epic:史诗 , 表示比较大的特性 , 开发周期一般是1-3月 , 用于产品路线图的规划
Feature:特性 , 表示相对小一些的特性 , 开发周期一般是1-3周 , 用于产品版本的规划
UserStory:用户故事 , 表示最小的用户场景 , 开发周期一般是1-3天 , 用于迭代规划 。
ScrumVSKanban,如何选择?
文章图片
(图1WorktileAgile中的需求管理)
在每个迭代开始时会召开计划会议 , 全员都会参加 , 这个会议最重要的事情就是确定SprintBacklog , 由ProductOwner按照优先级介绍ProductBacklog , 然后团队决定是否把某一个条目放入当前迭代 。
ScrumVSKanban,如何选择?
文章图片
(图2WorktileAgile中的迭代规划)
迭代进行的时间内 , 每天都会有10-15分钟的站立会议 , 团队中每个成员基于Worktile中的迭代任务板介绍前一个工作日所做的事情 , 以及遇到的问题 。
ScrumVSKanban,如何选择?
文章图片
(图3WorktileAgile中的迭代任务板)
迭代结束时召开评审会议 , 在评审会议上每个人基于产品演示自己在这个迭代中所完成的成果 , 团队成员可以针对完成的事项提一些建议 。 在评审会议结束后 , 团队成员会一起召开迭代回顾会 , 回顾会是Scrum迭代实践中的最后一环 , 也是最重要的一环 , 迭代回顾会将整个迭代形成了闭环 。 回顾会上大家提出的问题通过迭代回顾面板记录 。
ScrumVSKanban,如何选择?
文章图片
(图4WorktileAgile中的迭代回顾面板)
在Scrum实践中 , 大部分团队都会忽视版本管理 , 迭代是针对Scrum团队的活动行为 , 而版本管理是针对产品的 , 它定义的是一个批量的概念 , 用于版本进度管理和交付风险管理 , 明确在一个版本中的最终交付物 , WorktileAgile中你可以创建版本并把它与迭代关联 , 或者只是单纯的设置某个用户故事/缺陷属于某个版本

ScrumVSKanban,如何选择?
文章图片
(图5WorktileAgile中的版本管理)
迭代管理是针对Scrum团队的 , 它定义的是一个时间盒的概念 , 用于团队容量管理和进度管理 , 对于不同的团队来说 , 明确在一个迭代的时间盒内的产出 , 这个产出最终以迭代Review为标准 , 通过了Review并不意味着一定发布出去 。

经验总结扩展阅读