敏捷开发用户故事系列之八：剖析用户故事描述语法兼谈不同种类故事的语法

1、敏捷开发用户故事系列之八：剖析用户故事描述语法（兼谈 不同种类故事的语法） 作者：cheny_com 发布时间：2012-07-30 13:44 用户故事中，最有名的就是三段式语法了： 作为一个（角色），可以（功能），以 便（客户价值）。” 然而这种语法用于描述用户的业务操作比较方便，但若用于描述非功能性需求（包含重构、 缺陷等），或用于描述对功能的增强，则有点力不从心。 让我们来剖析一下用户故事语法，并尝试写一下其他类型故事的语法。 分析 传统用户故事的语法为何得以成功流传 1010 年而没有发生变化？ 因为他们是大师发明的。” 错，因为发明了这个语法，他们才成为大师的，这是因果倒置。 真正

2、的原因是，这个语法很好地表明了需求的三个最重要的要素：角色，功能，客户价值。 角色 为什么要角色？ 1.1. 有利于开发人员理解场景。 普通用户/管理员，存款客户/银行职员，这些区别，令开发人员更容易理解产品的用途、 风格、操作人员的熟练程度、操作习惯等。 2.2. 有利于找特定的用户核实 无论是产品的潜在用户调研，还是项目中与客户核实需求，如果有一个 角色”字段，都令沟 通工作可以与适当的角色地进行，完成的产品自然也就令这些角色的人员满意。功能（标题） 功能是最好理解的，就是程序员原来写的那种功能的名字，或称为标题。 不过，要放到这种语法里边，还是要动点脑筋的。 1.1. 主语-谓语原则 比

3、如：（在某个用户管理系统中） 显示所有用户”，就不是一个好功能，为什么呢？把它套 到用户故事语法中： 作为一个系统管理员，可以显示所有用户，以便 。 是不是感觉有点别扭？对，应该用 查看所有用户”，会更好一些。 作为一个系统管理员，可以查看所有用户，以便 。好多了。 可是，难道所有用户故事的名字都要和语法中的功能相同吗？不能写一个名为 显示所有用 户”，但内容是 作为一个，可以查看所有用户，以便 。的故事？ 能，但不要这样写，因为这违反了 DRYDRY 原则。 DRYDRY 原则就是 Dont Repeat Yourself Dont Repeat Yourself 原则，一件事情不要做两遍，

4、尤其是这种本来就差 不多、很容易混淆的事情。 所以，好的功能是以用户为主语的一个谓语。 2.2. 动宾词组原则 如果连续有用户的新建、删除、编辑、查看，是否可以只写 ”新建“删除， 这是在一次培训中大家实际讨论到的问题。 理论上说在这种场景中可以（有一些小问题），但是在其他时候会遇到大问题。 小问题：查看往往分为”查看所有用户 IndexIndex 和”查看单个用户详情 DetailsDetails 两种，不写宾语 不容易区分。 大问题：在故事板、燃尽图、我的个人中心等地方，如果凑巧一个故事需要单独存在的时候， 失去了动作的宾语，会出现多个 ”新建“删除 故事，容易混淆，不如”新建用户“删除用

5、户 来 得好。 火星人在开发过程中尝试了各种方案，最后最佳结论是： 故事标题=功能；角色-功能是主语-谓语关系；功能本身是动宾词组。 用户价值 用户价值看似简单，其实很难写。 请看：作为一个管理员，可以查看所有用户，以便了解系统中有哪些用户。 看上去还不错，对吧？但是如果这个系统是 CSDNCSDN 博客，里边有 600600 万注册用户，这个管 理员为什么要查看所有用户？他怎么才能查看所有用户？如果这个系统是 QQ,QQ,又会如何？ 所以一个管理员，不会无缘无故查看所有用户。但是，也不能不查看用户（否则无法查看详 情、删除、申诉、找回密码、禁言 ），但是，要为管理员找到一个合理的理由，并以合

6、 理的方式查看某种用户，才是正确的故事。 实际案例剖析：火星人中新建用户 ”作为一个管理员，可以新建用户，以便在系统中新建一个用户。 “ 好像可以，但又有点像废话。怎么办？ 在亲自编写了 300300 个用户故事后，我们发现可以尝试这样： 1.1. 尝试找到功能的现实用意，然后写出不同于功能的用户价值。 ”作为一个管理员，可以新建用户，以便将特定用户添加到火星人系统中。 “ 不管汤、药如何，读起来顺嘴一些了。 但如果觉得还不够好，请尝试 2 2。 2.2. 对顽固的不好描述的用户故事，尝试添加一些形容词、副词、壮语，用以描述这种操作 的核心价值。 什么叫核心价值？有些操作希望 ”方便快捷，“另

7、外一些则需要”安全口致；这就是核心价 值。 ”作为一个管理员，可以新建用户，以便快捷地将特定用户添加到火星人系统中。 “ 恩，好像可以了。但是 如果一个管理员，要一个一个在弹出窗口中新建用户，保存，再 新建，再保存 这个功能可能挺快捷，但对最终业务而言，如果有 10001000 个用户要添加， 实在谈不上快捷。 所以，请看 3 3。 3.3. 如果感觉用户故事无法满足核心价值，请尝试改进故事，乃至换一个新故事。 ”作为一个管理员，可以批量创建用户，以便快捷地导入已经有的用户数据。 “ 批量创建比创建快多了， 每行一个用户，用逗号分隔用户名、 邮箱可是出了错怎么办？ 弹出输入的数据不符合要求，请

8、检查格式是否正确。 “ 但如果有 10001000 行，该怎么办？额 请看 4 4。 4.4. 请验证改进后的用户故事能达成核心价值。 既然要快捷，除了错也应该迅速定位。 这样吧：所有识别成功的用户先暂存起来，所有不成功的行， 则留在屏幕上（最多也就是几 行），修改后再次识别，直到全部成功；确认后开始批量创建。 这个过程不用写在故事语法里边，因为没地方放。但要写在需求详情 /测试用例里边。 好了，这就是火星人产品中”批量创建用户的辗转经历。 不同种类故事的语法 让我们来尝试为其他种类的故事（非功能性需求）分别编制一套语法。首先解决两个问题： 1.1. 这种故事有哪些最重要的要素？ 2.2. 如

9、何编写才能突出这些要素？ 在编写了 300300 多个用户故事后，火星人团队摸索到了一套自己的编写语法，并预置在火星 人产品中（请在 8 8 月中旬关注本博客，了解在线体验系统的信息 ）。 在看具体示例之前，先写一下最后的总结，方便大家理解我们为何识别了这些要素。 语法总结： 1.1. 角色多数时候是必需的 增强、重构、BugBug都有其受益者或受害者，若没有角色字段，很难站在真实位置上猜想 其真实需求，也很难找人核实、询问优先程度。 2.2. 客户价值（或潜在损失）多数时候是必须的 若不能识别客户价值（或潜在损失），就不能知道增强、重构后是否达到了商业效果，或 BugBug 修正后是否避免了

10、潜在损失。 3.3. 原来 功能”的位置各不相同。 火星人中的几个实例 由于未必了解这些故事的背景， 读者可能不会很清晰地判断故事的好坏， 但请重点留意语法 格式的作用。 增强：突出显示本次/上次/下次意向表（增强一个操作） 须现后，作为一个产品经理，可以在查看意向表 时，突出地看到本次和上次迭代的意向表， 以便连贯地思考本次迭代的需求规划。 在这个实例中，实现后，作为一个（角色），可以在（原功能）时，（超 出的功能），以便（超出的价值）。”这一语法突出了实现前后的功能差异。 （仅限丁对功能的增强描述） 增强类型中，一般会暗含一个被增强的功能，但描述内容则是超出的功能和超出的价值。 重构：重构

11、界面及 ViewModelViewModel 须现前，原来的中间为树两侧为迭代的展示方式较为占用空间，树的高度太大导致难以完 整看到；实现后，以故事树为主体配合左侧的当前迭代故事，查看和操作更加快捷。 在这个实例中， 重构前，;重构后， . 的语法对比了重构前后的差异，这 种差异必须面向用户进行描述，以便产品经理能正确理解和排序。 缺陷：在加入故事时产品按钮不刷新 一作为一个产品经理，在加入或挪出故事时，顶端的产品按钮上人大数据不刷新， 导致计划 时对各产品的总量和比重的错误判断。 在这个实例中， 作为一个（角色），在（功能）时，（现象），导致 （潜在损失）”的语法表达了在何时，会出现何种现象，导致何种业务问题。有 些缺陷发生时 现象”很不明显 （比如数据不刷新） ，因此必须描述导致的业务问 题以