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

Posted zhangmike

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了让用户故事真的像故事那样相关的知识,希望对你有一定的参考价值。

早期用户故事写在卡片上,只需一个句子。随着越来越多的系统和产品采用敏捷开发,对于有些复杂长生命周期的系统和产品而言,用户故事的内容值得积累,以便后续追查和修改。另外一个情形是为了确保用户故事真的完成,需要在前期就明确其验收条件(也翻译为接收条件),因此曾几何时开始,用户故事的写法成了 用户故事经典句式+验收条件。
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类工具支持下,可以非常方便的向下分解,可以容易地把大故事拆分成小故事。

以上是关于让用户故事真的像故事那样的主要内容,如果未能解决你的问题,请参考以下文章

无法将组件导入故事书

故事板静态表视图太多行

故事板静态表视图太多行

我的保研故事

我的保研故事

我的保研故事