敏捷开发日常跟进系列之三：故事板，看板

这是敏捷开发日常跟进系列的第三篇。 （栏目目录）

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

故事板

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

一般故事板分为三列：

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

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

故事板的用法

要解决的问题

故事板可以帮助解决一些燃尽图解决不了的问题（见上篇）：

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

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

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

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

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

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

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

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

介质

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

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

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

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

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

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

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

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

2012-03-07补充：

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