以下,是2012-06-26的现场交流文字及图片,请参考。
下一期时间,请关注本博客。
哪些用户故事是“主干故事”?
谷雨霖(**58818) 13:00:09
今天我们非常有幸请到了敏捷实践大师,PMBar老朋友,PMBar专家顾问团资深专家@火星人陈勇
欢迎
来给大家分享
PMBar IT项目管理公益实践社区,6月26号周二中午13:00-14:00 MSN群第124期交流主题:《用户故事分类与组织结构》,面向产品经理和开发骨干,偏向需求管理和产品设计。关键词:敏捷开发 用户故事 史诗故事 重构 增强 缺陷 MVC FPA 功能点分析。分享者:敏捷专家@火星人陈勇,欢迎大家参与!
好,谢谢大家,开始了。
他也是pmbar系列丛书敏捷实践的作者之一
下面交给火星人!
大家欢迎!
好,我开始。先从Product Backlog讲起。
一年多以前,我们开始做火星人,是第一次完整地实践敏捷项目。
既然是敏捷,就少不了对两个重要的内容也就是Product Backlog(PB)和Sprint Backlog(SB)的管理。
SB相对简单一些,尤其是业界已经有很多的管理思路了,比如燃尽图,故事板,看板,乃至MoSCoW方法,都是关于SB的。
但是关于PB,好久就说了几句话:高层需求,面向用户价值,优先级排序……
所以在我们开发开始的时候,我们想象中PB就这样子:每行一个用户故事,每个故事都写成“作为……可以……以便……”
每个用户故事都有一个优先级(或者拆解成紧急-重要两个),每个月挑选最优先的放到SB里边,进行开发就是了。
但结果,与我们最初的想法有很大很大的不同,几乎颠覆了我对PB的认识。下面,就是分享整个过程和最后的结果。
大约做到2个月的时候,开始出现一些新的问题,我先把所有问题都写出来,再一个一个解决。
1. 有些故事,无法写成“作为一个……可以……”的句子,比如多数的Bug,比如重构(因为多数是技术层面的),比如增强(“把保存按钮挪到左上角”之类)
2. 故事越来越多,开始显得很乱,很难一眼看清楚产品结构。
我们在第二个月,差不多就有50个用户故事了,如果把描述都写出来,每个屏幕只能放10个,要5屏幕。而一年下来,最后我们做了大约300个用户故事。
而这不过只是1人年的结果,如果是稍微大一些的团队和长一些的周期,肯定会面临更加严峻的情景。
即使只写出故事的名字,比如“添加用户”,一个屏幕也只能列出50个,10人年有3000用户故事之多,需要60页。
不过,SB倒没什么问题,因为一个人月,也就完成10多个用户故事,多翻几次页面,并没有实质的困难。
![](file:///C:/Users/CY/AppData/Local/Temp/WML%60ZUS$8NCVU(%257M%255VUJI.gif)
首先有个问题:这些故事是否都一样重要?我们发现不是,有些会更重要一些,比如用户实际需要的功能。
“作为一个系统管理员,可以批量添加用户,以便将已有用户数据导入进来”,这个重要,因为直接和用户相关。
但“添加的时候,保存按钮放在左上角比下面更方便操作”,就属于次要的功能。
尽管无法把所有“次要”的功能都归类到某一个“重要”的功能之下,我们还是希望他们能有所区别,并在某些时候,只显示“重要功能”。