Scrum&Kanban在移动开发团队的实践系列:
Scrum&Kanban在移动开发团队的实践 (一)
Scrum&Kanban在移动开发团队的实践 (二)
在第一篇分享文章中介绍了下Scrum的开发模式,介绍了Scrum中团员的角色、开发阶段、每个阶段中需要做的事情。在这篇分享我会介绍Kanban模式,相对于Scrum,Kanban比较轻量级。
首先分享些干货:
Kanban和Scrum对比的Mini书:Kanban and Scrum - making the most of both 中文
下面是一个非常经典的Kanban图
看板强调几点:
- 流程可视化
- 限制WIP (Work in Progress)
- 度量生产周期
流程的可视化
想上图所示,Kanban强调的可视化流程,通常团队可以把需求分解成小任务,一个小卡片写一件任务,把卡片放到墙上。其实现在有很多敏捷开发工具都可以支持可视化管理,不过我还是建议贴在墙上这种“原始”做法。这样可以“强制”所有的成员非常容易的看到整个Kanban,有什么问题、更新都能一目了然。
- 每个任务都会有不同的状态,所以在墙上每列需要定义状态。我们的做法是分成Next、Analysis、Development、QA四个阶段,每个阶段都有Ongoing和Done两个子阶段。
- 每个阶段都有Ongoing和Done的状态,每个阶段的"Definition of Done"需要精确定义,保证所有团队成员对完成的定义达成一致。以下是一些定义的例子:
- Analysis - Definition of Done: Backlog建立好了,提供需求描述,提供MockUI
- Development - Definition of Done: 功能实现,程序员自己进行过测试,通过Unit Test,进行过Code Review,代码合并到Develop分支
- QA - Definition of Done: 完成功能测试,修复所有高优先级的bug
- 每个任务尽量细化,保证不超过一个星期的工作量。
- 每个任务都是分配给特定的一个人。如果是多个平台一起合作,比如iOS/Android/Server,可以把任务拷贝几份分配给不同的人,这样可以保证开发者对这个任务具有Ownership。
下面是我们团队实践的Kanban墙:
- 四个阶段(列):Next, Analysis, Development, QA。每个阶段都有Onging和Done。
- 四个小团队(行):Android, iOS, Web, Server
看到字条在最终状态越积越多还是很有成就感的!
限制WIP(Work in Progress)
在看板里面一个核心的概念就是限制WIP,简单的说就是每个状态下面的Ongoing的任务数目是有上限的。这样做可以带来不少好处
- 可以让团队成员更加专注
- 一旦发生任务阻塞,团队会第一时间知道,并且很容易发现问题,这时团队可以集中精力解决阻塞的问题
- 每次计划任务的时候都会考虑首先做最重要的事情,避免后期随便加塞任务
下面的漫画很好的描述了WIP的作用,大家可以领会领会:
WIP的模式看起来很美,但实践起来并不容易,需要大家非常遵守WIP的限制严格执行。很多时候团队会迫于外部的压力,不断增加工作,于是kanban上面的小字条越来越多,这样其实是非常影响效率的。所以Kanban模式也是需要一个类似Scrum Master的角色来保护这些原则。
WIP的设置数量应该是多少呢?其实这个因团队而异,可以不断调整至到大家都觉得比较舒适的状态。一开始可以建议简单粗暴的设置,比如开发人员有多少人,就设置Development WIP的数量是多少。
度量生产周期
Kanban的模式并没有固定的开发周期,也没有特定的计划、开发、发布的阶段,所有的事情都是想流水线性的一直持续下去。那么Kanban模式如何来评估生产的效率和周期呢?
一般会参考下图 - Cumulative flow diagram (堆积图?)
这个图统计了每一天,在每个状态中累计的任务数量。纵向可以表明WIP的作用,横向可以表明每个任务完成所需大概时间。
我一般会重点查看每个状态的趋势线的斜率情况,斜率越大说明任务开发所需的时间越少,团队效率越高。同时也要保证各个状态趋势线的平滑性,斜率要大体保持一致,这样说明任务没有在某个状态下积累太多而影响整体交付效率。
Kanban相对于Scrum的模式并没有太过于繁琐的条条框框,就只强调三件事:
- 可视化的流程
- 限制WIP
- 度量生成周期
Kanban是个非常高效的管理工具,但因为缺少了很多Scrum的规范,实际操作起来并不容易,在现实世界Kanban往往和Scrum一起使用,相互吸取经验融合使用。