【在线研讨-现场文字】《敏捷开发用户故事分类与组织结构（一期-1）》2012-06-26

一期：活动描述，之一，之二，之三，之四，之五

二期：活动描述，之一，之二，之三，之四，之五，之六

三期：活动描述，之一，之二，之三，之四，之五

以下，是2012-06-26的现场交流文字及图片，请参考。

下一期时间，请关注本博客。

哪些用户故事是“主干故事”？

回复
谷雨霖(**58818) 13:00:09
今天我们非常有幸请到了敏捷实践大师，PMBar老朋友，PMBar专家顾问团资深专家@火星人陈勇

晋智红-PMO-广州(**1012665) 13:00:18
欢迎

谷雨霖(**58818) 13:00:09
来给大家分享
PMBar IT项目管理公益实践社区，6月26号周二中午13:00-14:00 MSN群第124期交流主题：《用户故事分类与组织结构》，面向产品经理和开发骨干，偏向需求管理和产品设计。关键词：敏捷开发 用户故事 史诗故事 重构 增强 缺陷 MVC FPA 功能点分析。分享者：敏捷专家@火星人陈勇，欢迎大家参与！

陈勇-创业-北京(**9107533) 13:00:53
好，谢谢大家，开始了。

谷雨霖(**58818) 13:00:09
他也是pmbar系列丛书敏捷实践的作者之一
下面交给火星人！
大家欢迎！

陈勇-创业-北京(**9107533) 13:01:28
好，我开始。先从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多个用户故事，多翻几次页面，并没有实质的困难。

所以，如何存放、展示PB成了一个关键问题。
先分析问题1： 有些故事，无法写成“作为一个……可以……”的句子
首先有个问题：这些故事是否都一样重要？我们发现不是，有些会更重要一些，比如用户实际需要的功能。
“作为一个系统管理员，可以批量添加用户，以便将已有用户数据导入进来”，这个重要，因为直接和用户相关。
但“添加的时候，保存按钮放在左上角比下面更方便操作”，就属于次要的功能。
尽管无法把所有“次要”的功能都归类到某一个“重要”的功能之下，我们还是希望他们能有所区别，并在某些时候，只显示“重要功能”。