Scrum&Kanban在移动开发团队的实践 (二)

Scrum&Kanban在移动开发团队的实践系列:

Scrum&Kanban在移动开发团队的实践 (一)

Scrum&Kanban在移动开发团队的实践 (二)

 

在第一篇分享文章中介绍了下Scrum的开发模式,介绍了Scrum中团员的角色、开发阶段、每个阶段中需要做的事情。在这篇分享我会介绍Kanban模式,相对于Scrum,Kanban比较轻量级。

首先分享些干货:

Kanban和Scrum对比的Mini书:Kanban and Scrum - making the most of both  中文

 

下面是一个非常经典的Kanban图

Scrum&Kanban在移动开发团队的实践 (二)_第1张图片

看板强调几点:

  1. 流程可视化
  2. 限制WIP (Work in Progress)
  3. 度量生产周期

流程的可视化 

想上图所示,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的作用,大家可以领会领会:

Scrum&Kanban在移动开发团队的实践 (二)_第2张图片

Scrum&Kanban在移动开发团队的实践 (二)_第3张图片

 

Scrum&Kanban在移动开发团队的实践 (二)_第4张图片

 

WIP的模式看起来很美,但实践起来并不容易,需要大家非常遵守WIP的限制严格执行。很多时候团队会迫于外部的压力,不断增加工作,于是kanban上面的小字条越来越多,这样其实是非常影响效率的。所以Kanban模式也是需要一个类似Scrum Master的角色来保护这些原则。

WIP的设置数量应该是多少呢?其实这个因团队而异,可以不断调整至到大家都觉得比较舒适的状态。一开始可以建议简单粗暴的设置,比如开发人员有多少人,就设置Development WIP的数量是多少。

 

度量生产周期 

Kanban的模式并没有固定的开发周期,也没有特定的计划、开发、发布的阶段,所有的事情都是想流水线性的一直持续下去。那么Kanban模式如何来评估生产的效率和周期呢?

一般会参考下图 - Cumulative flow diagram (堆积图?)

Scrum&Kanban在移动开发团队的实践 (二)_第5张图片

这个图统计了每一天,在每个状态中累计的任务数量。纵向可以表明WIP的作用,横向可以表明每个任务完成所需大概时间。

我一般会重点查看每个状态的趋势线的斜率情况,斜率越大说明任务开发所需的时间越少,团队效率越高。同时也要保证各个状态趋势线的平滑性,斜率要大体保持一致,这样说明任务没有在某个状态下积累太多而影响整体交付效率。

 

Kanban相对于Scrum的模式并没有太过于繁琐的条条框框,就只强调三件事:

  • 可视化的流程
  • 限制WIP
  • 度量生成周期

Kanban是个非常高效的管理工具,但因为缺少了很多Scrum的规范,实际操作起来并不容易,在现实世界Kanban往往和Scrum一起使用,相互吸取经验融合使用。

 

你可能感兴趣的:(Scrum&Kanban在移动开发团队的实践 (二))