敏捷开发用户故事系列之八：剖析用户故事描述语法（兼谈不同种类故事的语法）
分析
传统用户故事的语法为何得以成功流传10年而没有发生变化？
“因为他们是大师发明的。”
错，因为发明了这个语法，他们才成为大师的，这是因果倒置。
真正的原因是，这个语法很好地表明了需求的三个最重要的要素：角色，功能，客户价值。
角色
为什么要角色？
1. 有利于开发人员理解场景。
普通用户/管理员，存款客户/银行职员，……这些区别，令开发人员更容易理解产品的用途、风格、操作人员的熟练程度、操作习惯等。
2. 有利于找特定的用户核实
无论是产品的潜在用户调研，还是项目中与客户核实需求，如果有一个“角色”字段，都令沟通工作可以与适当的角色地进行，完成的产品自然也就令这些角色的人员满意。
功能（标题）
功能是最好理解的，就是程序员原来写的那种功能的名字，或称为标题。
不过，要放到这种语法里边，还是要动点脑筋的。
1. 主语-谓语原则
比如：（在某个用户管理系统中）“显示所有用户”，就不是一个好功能，为什么呢？把它套到用户故事语法中：
作为一个系统管理员，可以显示所有用户，以便……。
是不是感觉有点别扭？对，应该用“查看所有用户”，会更好一些。
作为一个系统管理员，可以查看所有用户，以便……。好多了。
可是，难道所有用户故事的名字都要和语法中的功能相同吗？不能写一个名为“显示所有用户”，但内容是“作为一个……，可以查看所有用户，以便……。“的故事？
能，但不要这样写，因为这违反了DRY原则。
DRY原则就是Don't Repeat Yourself原则，一件事情不要做两遍，尤其是这种本来就差不多、很容易混淆的事情。
所以，好的功能是以用户为主语的一个谓语。
2. 动宾词组原则
如果连续有用户的新建、删除、编辑、查看，是否可以只写”新建“”删除“？
这是在一次培训中大家实际讨论到的问题。
理论上说在这种场景中可以（有一些小问题），但是在其他时候会遇到大问题。
小问题：”查看“往往分为”查看所有用户Index“和”查看单个用户详情Details“两种，不写宾语不容易区分。
大问题：在故事板、燃尽图、我的个人中心等地方，如果凑巧一个故事需要单独存在的时候，失去了动作的宾语，会出现多个”新建“”删除“故事，容易混淆，不如”新建用户“”删除用户“来得好。
火星人在开发过程中尝试了各种方案，最后最佳结论是：
故事标题=功能；角色-功能是主语-谓语关系；功能本身是动宾词组。
用户价值
用户价值看似简单，其实很难写。
请看：作为一个管理员，可以查看所有用户，以便了解系统中有哪些用户。
看上去还不错，对吧？但是如果这个系统是CSDN博客，里边有600万注册用户，这个管理员为什么要查看所有用户？他怎么才能查看所有用户？如果这个系统是QQ，又会如何？
所以一个管理员，不会无缘无故查看所有用户。但是，也不能不查看用户（否则无法查看详情、删除、申诉、找回密码、禁言……），但是，要为管理员找到一个合理的理由，并以合理的方式查看某种用户，才是正确的故事。
实际案例剖析：火星人中新建用户
”作为一个管理员，可以新建用户，以便在系统中新建一个用户。“
好像可以，但又有点像废话。怎么办？
在亲自编写了300个用户故事后，我们发现可以尝试这样：
1. 尝试找到功能的现实用意，然后写出不同于功能的用户价值。
”作为一个管理员，可以新建用户，以便将特定用户添加到火星人系统中。“
不管汤、药如何，读起来顺嘴一些了。
但如果觉得还不够好，请尝试2。
2. 对顽固的不好描述的用户故事，尝试添加一些形容词、副词、壮语，用以描述这种操作的核心价值。
什么叫核心价值？有些操作希望”方便“”快捷“，另外一些则需要”安全“”一致“，这就是核心价值。
”作为一个管理员，可以新建用户，以便快捷地将特定用户添加到火星人系统中。“
恩，好像可以了。但是……如果一个管理员，要一个一个在弹出窗口中新建用户，保存，再新建，再保存……这个功能可能挺快捷，但对最终业务而言，如果有1000个用户要添加，实在谈不上快捷。
所以，请看3。
3. 如果感觉用户故事无法满足核心价值，请尝试改进故事，乃至换一个新故事。
”作为一个管理员，可以批量创建用户，以便快捷地导入已经有的用户数据。“
批量创建比创建快多了，每行一个用户，用逗号分隔用户名、邮箱……可是出了错怎么办？
弹出”输入的数据不符合要求，请检查格式是否正确。“
但如果有1000行，该怎么办？额……请看4。
4. 请验证改进后的用户故事能达成核心价值。
既然要快捷，除了错也应该迅速定位。
这样吧：所有识别成功的用户先暂存起来，所有不成功的行，则留在屏幕上（最多也就是几行），修改后再次识别，直到全部成功；确认后开始批量创建。
这个过程不用写在故事语法里边，因为没地方放。但要写在需求详情/测试用例里边。
好了，这就是火星人产品中”批量创建用户“的辗转经历。
不同种类故事的语法
让我们来尝试为其他种类的故事（非功能性需求）分别编制一套语法。首先解决两个问题：
1. 这种故事有哪些最重要的要素？
2. 如何编写才能突出这些要素？
在编写了300多个用户故事后，火星人团队摸索到了一套自己的编写语法，并预置在火星人产品中（请在8月中旬关注本博客，了解在线体验系统的信息）。
在看具体示例之前，先写一下最后的总结，方便大家理解我们为何识别了这些要素。
语法总结：
1. 角色多数时候是必需的
增强、重构、Bug……都有其受益者或受害者，若没有角色字段，很难站在真是位置上猜想其真实需求，也很难找人核实、询问优先程度。
2. 客户价值（或潜在损失）多数时候是必须的
若不能识别客户价值（或潜在损失），就不能知道增强、重构后是否达到了商业效果，或Bug修正后是否避免了潜在损失。
3. 原来“功能”的位置各不相同。
火星人中的几个实例
由于未必了解这些故事的背景，读者可能不会很清晰地判断故事的好坏，但请重点留意语法格式的作用。
在这个实例中，“实现后，作为一个……（角色），可以在……（原功能）时，……（超出的功能），以便……（超出的价值）。”这一语法突出了实现前后的功能差异。（仅限于对功能的增强描述）
在这个实例中，“重构前，……；重构后，……”的语法对比了重构前后的差异，这种差异必须面向用户进行描述，以便产品经理能正确理解和排序。
在这个实例中，“作为一个……（角色），在……（功能）时，……（现象），导致……（潜在损失）”的语法表达了在何时，会出现何种现象，导致何种业务问题。有些缺陷发生时“现象”很不明显（比如数据不刷新），因此必须描述导致的业务问题以便理解问题的实质。
在这个实例中，“当前……（当前的临时实现方法），在……（未来某种情况下）时，将……（可能出现的现象），导致……（潜在的损失）。”的语法表达了当前的何种技术原因，在何时，将会发生何种问题，并导致何种潜在的损失。