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

这是敏捷开发用户故事系列的第三篇。（栏目目录）

 

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

用户建模四部曲

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

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

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

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

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

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

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

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

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

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

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

总结

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

 

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

第2步：识别关键用户

第3步：合并次要用户

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

 

灵活应变

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

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

 

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

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

本系列乃至本博客其他所有文章所描述的方法，都是即是非法，又是非非法，要本着对开发团队是否有价值，如何更有价值的心法来加以采纳或调整。

 

 

点击下载免费的敏捷开发教材：《火星人敏捷开发手册》