敏捷开发日常跟进系列之三:故事板,看板
这是敏捷开发日常跟进系列的第三篇。 (栏目目录)故事板和看板其实不是一个东西,前者是最初的敏捷开发里边的东西,受到了后者的启发产生的;而后者是制造业的东西,具体内容请参考末尾的百度百科。但是在敏捷开发里边提到这两样东西,可以认为大致相同。故事板简单说,故事板是展示迭代中的用户故事和任务的方法,在《硝烟中的Scrum和XP》的封面上就印着一个典型的故事板:一般故事板分为三列:To Do还没做的, D
这是敏捷开发日常跟进系列的第三篇。 (栏目目录)
故事板和看板其实不是一个东西,前者是最初的敏捷开发里边的东西,受到了后者的启发产生的;而后者是制造业的东西,具体内容请参考末尾的百度百科。但是在敏捷开发里边提到这两样东西,可以认为大致相同。
故事板
简单说,故事板是展示迭代中的用户故事和任务的方法,在《硝烟中的Scrum和XP》的封面上就印着一个典型的故事板:
一般故事板分为三列:
To Do还没做的, Doing正在做的, Done做完的(有各种各样的中英文写法,大同小异)
有些团队的分工比较多,会出现一些中间状态,比如“还没做的/正在开发的/等待测试的/正在测试的/等待评审的”是一种典型的开发与测试分离的故事板。
故事板的用法
要解决的问题
故事板可以帮助解决一些燃尽图解决不了的问题(见上篇):
1. 有哪些故事正在做,还没有做,已经开工了但没完成……?故事板的三列正好解决问题。
2. 最后剩下了哪些故事没完成?最左边剩下的就是。
3. 有没有人不是一个一个完成故事,而是同时开工了很多故事?(这个是最后很多故事都开工了但都差一点完成不了的主要原因)这个复杂一些,下面讲。
同时开工很多故事,很容易造成思绪散乱、最后全部完不成的情况,确切说瀑布模型就是同时开工所有故事的典范。
为了防止这一点,如果是手工做的故事板,,那么注意中间一个“正在做的”列一点要窄一些,这样当里边的故事挤不下的时候,就是一个危险的很多故事都在开工的信号。
还有一种做法,是每个人只准放一个故事在中间,做完一个,才能再做一个。这个严格坚持有难度,因为经常遇到被卡住的情况,但是作为一种思路和精神应该尽量坚持。
4. 如果有跟进人,谁负责跟进哪个?可以在卡片上写上当前负责人、跟进人的名字。
通常的做法有很多种,比如每个人用自己颜色的即时贴,可以比较容易地看出每个人有多少个故事,分别处于什么状态。不过,这样就需要在“尚未开始的”里边提前分配人员了,不太利于后期的互动和互相关注;当然还可以在开始的时候重新用有颜色的即时贴重新抄一个,看大家的习惯了。
介质
尽管有很多故事板/看板工具,使用纸质方法仍然是一个很好的选择,原因就是作为“迭代中的任务”这种东西,其生存期很短,基本上2个月后价值为0,人们也就用纸片来对付了。
不过如果想在未来做几件事情,那么及早采用电子故事板/看板还是有必要的,这些事情包括:
1. 希望统计和分析哪些故事容易完不成、每个月的完成情况等
2. 大型团队,分布式团队
3. 希望留下历史数据作为以后估算的参考值和参考故事
下面这个是免费工具火星人中的故事板,做了两个案例来说明一下情况。
上面这个图是不好的情况,开发中的故事一大堆,没几个完成的,很容易造成最后所有故事都差一点。
下面这个要好的多,每个人只开工了1个(每种底色是一个人,案例中只有cheny和yock两个人),剩下的要末完全做完了,要么一点没做,即使到期末不能全部完成,也不会把太多时间卡在半截的故事上。
2012-03-07补充:
昨天下午仔细调整了美术效果,现在的故事板外观如下:
更多推荐
所有评论(0)