让用户故事真的像故事那样

早期用户故事写在卡片上，只需一个句子。随着越来越多的系统和产品采用敏捷开发，对于有些复杂长生命周期的系统和产品而言，用户故事的内容值得积累，以便后续追查和修改。另外一个情形是为了确保用户故事真的完成，需要在前期就明确其验收条件（也翻译为接收条件），因此曾几何时开始，用户故事的写法成了 用户故事经典句式+验收条件。
在https://blog.versionone.com/agile-acceptance-criteria/ 上提供了如下一个故事的样例。

As an executive, I want to be able to filter the dashboard by department so that I can isolate data by a specific department.【翻译：作为一个高层管理者，我想要根据部门来查看仪表板，这样我区分不同部门的表现。】

Acceptance Criteria:【验收条件】
● Given the Executive Dashboard default view, when I select the department drop-down, I have the ability to select a specific department to so only that data throughout the dashboard. 【给定：在高管仪表板缺省视图上，当：我选择部门下列列表时，然后：我可以选择一个指定的部门，这样只有这个部门的数据呈现到仪表板】
● Given the department drop-down, when I select a specific department, the entire dashboard filters to display only that department data.【给定：部门下拉列表，当：我选择一个部门，整个仪表板只显示这个部门数据】

遗留需讨论的问题有
1. “Hey Product Owner, does the Executive need to be able to Multi-select several departments?”
2. “How about grouping by division?”
3. “who can access the Executive Dashboard”

以上的故事正文就是故事经典句式所带来的一句话，加入了2个GWT。
利用上述格式，如果各类情况出现多的话，就会需要许多条GWT。

笔者综合用例规约写法，认为采用讲故事方法可以带来更好的故事表达方式。方法是把功能性验收条件采用正常步骤和异常步骤组合来表达，把非功能性验收条件作为非功能性要求来表达。具体而言，采用如下的故事格式。
故事标题：考虑卡片尺寸
故事简要说明：采用经典的故事一句话说明
故事起点：说明故事从哪里开始，其上下文
正常步骤：
1，采用流水号编号
2，此为示例
异常步骤：
1a，根据正常步骤编号来说明哪个正常步骤出现异常。
非功能性要求： 这里说明非功能性要求，功能性要求在上述步骤中说明

按照笔者的故事叙述方法（也称为讲故事方法，Story telling），试着来改写下以上故事，看看两个不同方法的比较。【此括号为说明，不是故事的内容】
Title标题： filter the dashboard by department
根据部门来查看仪表板
【简短的故事标题有利于看板展现和交流】
Brief 简介：
As an executive, I want to be able to filter the dashboard by department so that I can isolate data by a specific department.
作为一个高层管理者，我想要根据部门来查看仪表板，这样我区分不同部门的表现。

Start Point 故事起点： the dashboard is shown
仪表板已经得到展现。【明确整个故事的起点，有利于展开后续的故事情节】
Normal Steps 正常步骤：
【这下面的步骤是达成故事成功进行的，达成故事的目的】
1. executive select the department drop-down
2. system list all departments in drop-down
3. executive choose a specific department
4. the entire dashboard filters to display only that department data.
○ 4.1 department data is grouped by division(@furture，此标记意味着本次不包括，未来再考虑).
1，高管选择部门列表
2，系统列出所有部门名称
3，高管选择某个部门
4，仪表板只显示这个部门的数据
4.1 根据大区分组来查看部门数据（@未来）
Abnormal Steps：异常步骤：
【这下面的步骤是上述正常步骤中可能碰到的异常步骤，3a意味在是第3步正常步骤出现的第1个异常情况】
● 3a executive choose 2+ departments by shift click or multi-selection, only first department will be choosen
3a，高管通过shift click或者多选，选择了2+个部门，系统只处理被选中的第1个部门

对于who can access the Executive Dashboard这个问题，本用户故事的起点是dashboard is shown，因此这个问题不在这个用户故事的范围之内，应当是在show dashboard那个故事当中。

综上，新的故事写法就说明完成了。需要说明的是虽然模仿了用例规约的写法，但与用例规约最大的差别是故事叙述不强制要求全面完整，而是按照敏捷拥抱变化的思想，在过程中按需补充。
这样做法明显的好处有：
1，对比GWT写法，所用文字更加简练，而且按步骤阅读，可读性更好
2，在WIKI类工具支持下，可以非常方便的向下分解，可以容易地把大故事拆分成小故事。