故事板和看板其实不是一个东西,前者是最初的敏捷开发里边的东西,受到了后者的启发产生的;而后者是制造业的东西,具体内容请参考末尾的百度百科。但是在敏捷开发里边提到这两样东西,可以认为大致相同。

故事板

简单说,故事板是展示迭代中的用户故事和任务的方法,在《硝烟中的Scrum和XP》的封面上就印着一个典型的故事板:

敏捷开发日常跟进系列之三:故事板,看板_第1张图片

一般故事板分为三列:

To Do还没做的, Doing正在做的, Done做完的(有各种各样的中英文写法,大同小异)

有些团队的分工比较多,会出现一些中间状态,比如“还没做的/正在开发的/等待测试的/正在测试的/等待评审的”是一种典型的开发与测试分离的故事板。

故事板的用法

要解决的问题

故事板可以帮助解决一些燃尽图解决不了的问题(见上篇):

1. 有哪些故事正在做,还没有做,已经开工了但没完成……?故事板的三列正好解决问题。

2. 最后剩下了哪些故事没完成?最左边剩下的就是。

3. 有没有人不是一个一个完成故事,而是同时开工了很多故事?(这个是最后很多故事都开工了但都差一点完成不了的主要原因)这个复杂一些,下面讲。

同时开工很多故事,很容易造成思绪散乱、最后全部完不成的情况,确切说瀑布模型就是同时开工所有故事的典范。

为了防止这一点,如果是手工做的故事板,,那么注意中间一个“正在做的”列一点要窄一些,这样当里边的故事挤不下的时候,就是一个危险的很多故事都在开工的信号。

还有一种做法,是每个人只准放一个故事在中间,做完一个,才能再做一个。这个严格坚持有难度,因为经常遇到被卡住的情况,但是作为一种思路和精神应该尽量坚持。

4. 如果有跟进人,谁负责跟进哪个?可以在卡片上写上当前负责人、跟进人的名字。

通常的做法有很多种,比如每个人用自己颜色的即时贴,可以比较容易地看出每个人有多少个故事,分别处于什么状态。不过,这样就需要在“尚未开始的”里边提前分配人员了,不太利于后期的互动和互相关注;当然还可以在开始的时候重新用有颜色的即时贴重新抄一个,看大家的习惯了。

介质

尽管有很多故事板/看板工具,使用纸质方法仍然是一个很好的选择,原因就是作为“迭代中的任务”这种东西,其生存期很短,基本上2个月后价值为0,人们也就用纸片来对付了。

不过如果想在未来做几件事情,那么及早采用电子故事板/看板还是有必要的,这些事情包括:

1. 希望统计和分析哪些故事容易完不成、每个月的完成情况等

2. 大型团队,分布式团队

3. 希望留下历史数据作为以后估算的参考值和参考故事

 

下面这个是免费工具火星人中的故事板,做了两个案例来说明一下情况。

敏捷开发日常跟进系列之三:故事板,看板_第2张图片

上面这个图是不好的情况,开发中的故事一大堆,没几个完成的,很容易造成最后所有故事都差一点。

下面这个要好的多,每个人只开工了1个(每种底色是一个人,案例中只有cheny和yock两个人),剩下的要末完全做完了,要么一点没做,即使到期末不能全部完成,也不会把太多时间卡在半截的故事上。

敏捷开发日常跟进系列之三:故事板,看板_第3张图片

2012-03-07补充:

昨天下午仔细调整了美术效果,现在的故事板外观如下:

敏捷开发日常跟进系列之三:故事板,看板_第4张图片