敏捷开发用户故事系列之一：何为用户故事

全系列将涉及何为用户故事，面向客户价值编写故事，用户建模，产品待开发项的分类，故事颗粒度，故事的组织结构，等等若干问题，力求将此中问题尽量解决干净。

本系列文章假设正在编写一个“敏捷开发管理软件”，因为来阅读的都是做敏捷开发的，又都是做软件的，会更熟悉一些。

用户故事三要素：角色，功能，价值

按“作为一个……，可以……，以便……”样式和思路写成的用户需求，就是用户故事。

样式是技法层面的东西，它保证了无需太多思考，用户故事中即包含角色、功能、价值这三个要素。

角色

角色切记不要总是写“作为一个用户”，而是要把用户区别对待。这样才能更好地理解他们使用什么功能，如何使用，为何使用。

比如“作为一个开发人员，可以登录批量编辑页面，以便高效率地编辑多个故事”就是一个危险的举动，因为如果有多个程序员同时这么做，存储的时候会发生冲突（这个页面后来被删除了）。但“作为一个项目经理，可以登录迭代计划首页，同时编辑多个迭代的信息”则是可行的，因为项目经理一般就有一个，而且这个功能使用次数很少，即使有多个人有权限使用，偶然发生冲突的损害，与平时效率提高相比，也微乎其微。

所以把角色特化出来后，更容易理解功能的价值和风险。

日后另有文章详述如何识别角色，以及如何基于关键角色编写故事。

功能

功能即用户能亲自执行的操作。

应区分用户操作和产品功能之间的关系，因为产品功能可能也提供了用户所需的价值，但却极可能不便于操作。

一个例子是之前我使用一个XX手机，联系方式上在“拨出”之外，总是有一个“编辑拨出”，后来才知道是为了能在前面加拨17951之类的IP电话前缀。写成用户故事，差不多是：“作为一个用户，可以使用编辑拨出在拨打长途前输入IP前缀，以便节省话费。”不过这个功能从来没用过，因为太费劲。实际使用中要么我会把外地电话录入的时候就加上17951，要么一个电话就打出去了管它三七二十一。

后来又使用另外一款Android手机，因为别的原因安装了360，发现它有一个自动IP功能，写成用户故事，就是“作为一个用户，可以在拨打长途的时候自动使用IP拨出功能，以便节省话费。”这个功能每月可以给我节省不下20块钱，如果他有一天收费，我必会买。

价值

价值是完成操作后，客户所得到的价值。

价值里边，常常要带有一点褒义词，或有一些吸引人的内容，比如前面的“高效地”“节省话费”。

潘家宇老师当年提到何为“用例”的时候提到了类似的概念：“用例就是那个你能卖掉的东西。”用户故事也是用来被卖掉的东西，看不到价值的就不是用户故事。

比如上面的360的用户故事写得就比较好，估计如果有读者没装360，看完本文立刻就去。

底层的一些功能看不到直接的用户价值，怎么办？系列中另有一篇描述用户故事的分类。

敏捷开发用户故事系列之二：如何面向客户价值编写故事

敏捷开发中的用户故事采用的语法模式看似简单，却蕴含着深刻的思想。

“作为一个……，可以……，以（以便）……”不同于一般专注于功能的需求条目描述方法，三个……把角色、功能、价值跃然纸上。然而使用不当，却有可能形似而神不似。

下面就三个部分分别举出一个例子。

网络游戏的排行榜功能

“作为一个玩家，可以通过显示排名，以便让自己在服务器中的地位获得认可。”

这个功能可以激发玩家的“斗志”，鼓励购买道具，是个不错的想法，但实现起来却有技术问题：服务器中的玩家太多了，实时查看排名非常不现实。另一个问题是小虾米们其实对自己的排名不太关心，即使关心，也不会为了提升排名去购买道具，只有一批（也有上百个）顶级大佬才会真正受此蛊惑。

这个故事后来被改为：每周重新排名一次，而且只显示TopXXX（很像csdn的“排名两万以外”）。所以如果写成故事，就变成：

“作为一个排名靠前的付费玩家，可以通过显示排名，以便让自己在服务器中的地位获得认可（以刺激消费）。”

当然，对小虾米们也有刺激消费的方法，比如打怪掉落了一个很棒的道具，却要花钱买打孔材料和镶嵌宝石，即使用保健因素而非激励因素让他们消费，那是另外一个故事了。笔者曾经体验过的一个游戏中有帮派战争，大号会争当“连斩狂客”，小号则有“寻宝冠军”可得，且人人均有积分，因此各层人物都争相参加。

这个故事让我们理解到：“用户”这个词太笼统了，如果他们的“价值观”差别很大，就要分别为他们写故事，才能吸引他们使用功能，达成价值观。

权限查询功能

“作为管理员，可以查询所有用户的权限，以了解所有用户的权限”。

一种很常见的写之无味不写不行的故事，因为好像功能=价值。其实管理员不会平白无故地查看所有用户权限的，多半有其目的：有人反映自己访问不了某个文件，有个项目死活加不上新用户，有人刚刚离职，有三个外包团队的人需要在最近三个月在项目中作为成员一起工作……

知道这些就好多了，当点击“权限”这个tab后，多半不会出现“所有用户的权限”（倘若想想有10000人的企业），而是继续出现几个子链接：查询个人权限，项目成员，人员离职，限时权限（外包人员管理）……

当然，这需要一大堆故事了，但如果一个给客户带来明确价值操作友好的产品正是我们所追求的，我们极有可能选择开发其中最高价值的几个，然后再留下之前那个“万能”但又什么都干不太好的。

这个故事让我们理解到：功能不等于价值，要理解用户操作功能的业务目的，不要随意抛出万能的功能。

杀毒软件的防打扰功能

“作为一个用户，可以选择‘认可所有相似操作’，以便同意或禁止连续的相似操作。”

这看起来也是个很不错的功能，但笔者曾经在安装软件的时候用到这个功能，尽管选择了“认可所有相似操作”，窗口仍然跳个不停，直到后来仔细查看弹出的信息，原来在软件安装过程中要进行很多“不相似”的操作：修改注册表，创建C盘目录，向system32中拷贝dll……而这个杀毒软件在处理的时候，连注册表不同位置的修改都认为是“不同的操作”。

要改好这个故事，就要从最后的客户价值入手。比如如果安装软件是最常见的需要“认可所有相似操作”的过程，就可以写一个这样的故事：

“作为一个用户，可以在安装软件时选择‘认可本次安装操作’，以便一键完成正常的安装操作。”当然何为“正常”的操作需要额外说明，但整体客户价值却更精准地表达出来了。

这个故事让我们理解到：“客户价值”是要从客户的角度来理解的，否则极可能跑偏。

敏捷开发用户故事系列之三：用户建模

用户建模的目的，是为了更好地分析用户行为和用户价值，并因此获得商机。

用户建模四部曲

有一次培训中，分组建模的时候，一位学员就自言自语地说了一句话：“真的啊……我好像不知道谁会使用我的产品……”这其实是一种常见的现象。

比如前文所说的敏捷开发管理软件，如果想把一个用户故事描述为“作为一个用户，可以登录“我的空间”，以查看我我在的所有项目的进展以及自己的任务”，就会遇到这个麻烦。所谓领导，肯定想浅层次低能看到多少项目，就看到多少项目，而且最好能汇总一下显示；作为普通程序员，则肯定不止是想知道自己在哪些项目中有任务，而是想知道自己有哪几个任务是急需完成的（领导肯定也有着急的事情比如要审批，但肯定不如把控大局更重要）；作为项目经理，又介于其间。

分析到这一步，就已经做了用户建模的第1步：列出尽可能多的用户。

第2步则是：识别关键用户。

按刚才的划分，还是很难确定谁是关键用户，因为“项目进展”的关键用户是领导和项目经理，而“我的任务”的关键用户则是普通程序员更常用。

这说明这个故事太大了，应该予以分拆，直到能识别出关键用户为止。后面还会提到另外一种更科学的判断故事颗粒度过大是否应该分拆的方法，这里先用这个方法。

第3步则是：面向关键用户，描述故事

假设我们先研究普通程序员的“我的任务”的功能，那么问题就简单一些了。故事可以描述为：“作为一个程序员，可以登录“我的空间”，以查看自己的开发任务中有哪些需要处理。”

为何要写上“那些需要处理”这句话？因为一般没有人会无缘无故面对自己的任务列表发呆的，他肯定来了就有它的目的。比如我们描述了这个“哪些需要处理”的价值观，眼前就能浮现出这些任务肯定不是一视同仁地列在那里，至于要突出“延期的任务”还是“亟待解决的任务”还是“领导关注的任务”，都是具体需求了，不难实现。

可惜经常不是这么简单的三种角色，而是上来一堆程序员、脚本设计师、测试人员、黑盒测试人员等等，不可能给他们每人写一个故事，这时候要做的是第2.5步：合并次要用户。

在上面的例子里边，我们发现刚才列举的几种人可能在使用其他功能上有所不同，但在“我的空间”里边，还是基本相同的，所以把它们合并为一个“开发人员”，并把故事描述为：“作为一个开发人员，可以登录“我的空间”，以查看自己的任务中有哪些需要处理。”

总结

重新排序总结一下用户建模四部曲：

第1步：列出尽可能多的用户

第2步：识别关键用户

第3步：合并次要用户

第4步：面向关键用户，描述故事

灵活应变

本来写到这里就万事大吉了，国外书上也是这么说的，之前有几次课也是这么讲的，大家也听得挺开心的。

但自己在项目中实践了一段时间后，发现自己经常有一些“过度合并”的倾向。比如在那个敏捷开发管理系统中，角色设置是非常自由的，“添加用户”这个操作，任何授权的用户都可以做，而不一定是“系统管理员”，所以开始就写成“作为被授权的用户，可以添加用户，以便……”。但这种“授权的用户”越来越多了，就感觉其实逐渐坠入最开始的一股脑“作为一个用户”的情况，又都改成“作为一个系统管理员，……”。宁可放弃实际功能，而模拟用户可能的使用场景。

一会说要分清用户，一会又说太多了要合并，一会又说合并过头了不行，到底应该怎样？

这里借用《金刚经》里边的一句话，来稳定心法：“菩萨为利益一切众生故，不着于法。”就是菩萨的出发点是众生的利益，因此怎样做好他们就会怎样做，而不会纠缠于方法（比如韦陀菩萨经常杀生）。在如何用户建模这件事情上，出发点是“更清晰更有价值地描述故事”，而不是符合什么建模方法，因此实际使用时，应固守心法，而灵活掌握技法。