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一起使用，相互吸取经验融合使用。