关于用户故事

关于用户故事
用户故事，User Story，这个词儿来自于敏捷方法Scrum。到底什么是用户故事，因为近期重拾Redo一些项目方面和产品方面的工作，来整理整理相关知识。用户故事与另外几个概念，如用户故事切分、用户故事地图、用例、场景，都有啥关联或关系呢。

1、什么是用户故事
1.1 用户故事
用户故事，User Story。这是一个从属于产品设计的概念，它所指的，是从用户的角度来描述用户需求，要使用用户可以理解的业务预研来描述、切忌使用技术术语。

意即：

角色：谁
活动：需要做什么
价值：为什么
用一句常见格式来描述，即：

As a role, I want goal/desire so that benefit.

或

作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”

用户故事要点（Ron Jeffries，3C）：

简述：用卡片（Card）来简要描述故事。
细节：与Product Owner（或客户）交谈（Conversation）来明确细节。
确认：验收评审，确认（Confirmation）被正确完成。
1.2 用户故事切分
故事有大小、长度，如何编写一个用户故事、才算得上好的用户故事？ 
它应该遵循INVEST原则：

独立性（Independent）：尽可能让一个用户故事独立于其他用户故事，解除相互依赖性，便于确定优先级、评估工作量。可以通过组合、分解的方式来达到“独立性”的目的。
可协商性（Negotiable）：这个用户故事的内容可以协商，是一个简短的描述，而具体细节在沟通阶段产出，避免过多的细节限制了与用户的沟通。
有价值（Valuable）：这个用户故事，必须对客户具有价值，因此应该站在用户的角度去编写，描述的是一个一个的feature，而非一个一个的task。
可以估算性（Estimable）：这个用户故事，优先级、工作量、安排计划，都是可行的，以减少评估上的不确定性。
**短小（Small）：一个好的用户故事，可评估的工作量要尽量短小，确保在一个迭代周期内可完成。用户故事越大、风险越大。
可测试性（Testable）：这个用户故事可以测试以确认是可以完成的，所以必须在定义了验收测试通过的标准后才能认为故事划分完毕。
为了保证用户故事的颗粒度，上面说到了组合、分解的方法，我们也可以灵活应用，目标就是为了让产出的软件能够（Rachel Davies）：

能够工作
交付价值
能有效地得到用户的反馈
对于用户故事切分，不同的前辈也总结出一些更多的进一步的方法可供借鉴。

Richard Lawrence方法：

根据工作流程的步骤来切分故事
让业务规则中的每种变化都是其自身的故事
切分“实现第一个[x]”，然后“实现其他的[x]”
复杂故事中，将最简单的版本切分为单独的故事
通过故事所操作的数据类型来切分
通过简单数据输入方法和复杂方法之间的区别来切分故事
当前故事的性能转移到一个或多个新故事
按照CRUD（创建/读取/更新/删除）来切分
Bob Hartman方法：

根据角色来切分
将高风险和低风险的分离
在每个故事上工作的开发者数量最大化
Rachel Davies对于根据输入/输出的数据来切分故事的方式提供了一些细节处理方法：

可以为每个输入页面创建故事
可以为输入页面每个可用元素创建故事
可以创建简单的UI（简单≠漂亮）
可以创建一个命令行界面
1.3 用户故事地图
当我们开始进行一个产品或者项目规划的时候，首先需要梳理出一个backlog，在其中按照优先级列出所要实现的场景和具体功能。

而用户故事地图就有这么一种功效。 
 
 
用户故事地图，代表一个完整的用户故事。其核心是一条从左到右的时间线（横轴），以及其下的自上而下的必要程度线（纵轴）。

时间线（横轴，从左到右）

在时间线的上方防止最大粒度的内容（可理解为Epic 史诗，即比较大的User Story）；
在时间线的下方放置二级粒度的内容（可看做backlog item，即待办列表项）；
在二级粒度内容的下面放置三级粒度的内容（即切分好的用户故事，可作为User Story Task）。
以上形式可以灵活按照实际产品情况进行削减，去掉Epic、将backlog item移到时间线上面。

必要程度线（纵轴，自上而下）
用户故事地图的纵轴，而对于上述的Task（最小用户故事），按照必要程度、重要程度自上而下往下排列。

通过这种方式的划分，可以制定backlog及task用户故事的优先级，并安排迭代周期、迭代版本及对应任务。

大家一定多多少听过MVP，即Most Variable Product 最小化可用产品。这个概念，源于《精益创业》（埃里克·莱斯），有一定了解的朋友一定知道，MVP的目的是以最小的投入发布对用户有价值的产品，帮助我们快速试错，并通过不停的迭代最终找到产品的正确方向。

2、用户故事与其他相关概念
2.1 用例
Use Case

User Story关注的是业务场景和用户故事，更倾向于以用户角度描述响应业务功能的业务价值。用户故事会比较简单，重点是把业务需求和场景（或含业务价值/商业价值）说清楚即可。

而Use Case 用例，它包含了有业务用例和系统用例。其用例建模比较复杂，会涉及到业务流程、业务规则、输入、输出、界面和交互等等。

用户故事与用例里面的业务用例有点类似。但是，用户故事的粒度往往比用例的粒度更细化，如用例中的基本流、扩展流、业务规则都可能转化为用户故事（见上面“1.2用户故事切分”）。

还有一种比较明显的思维/角色/对象上的区别。用户故事从产品角度、业务场景看待，重在用户使用产品的目的/任务/流程/情节等等；而用例面向需求人员和开发人员，重在逻辑、次序。

2.2 场景
Scenario

Scenario 场景，有两拨人在用，当然，他们所指的含义也不一样。

交互设计师（如Alan Cooper） 
在RUP（Rational Unified Process）中已有辨析：“场景”在 RUP 内部指用例实例，即只是一个经过可能的基本流和备选流的特定“路径”（即Cockburn所说的“一个行为序列”）。
需求分析师（如Alistair Cockburn） 
在以用户为中心的设计方法和用户界面设计方法中常常将“场景”描述为使用经历（Cooper就这么做），这实际上包含了更多的细节，而不仅局限于事件流。虽然该附加信息可能与后来的设计阶段无关，但它对于了解用户、任务和环境却必不可少。
因此，场景可以在业务建模工作流程中广泛应用，但是在需求工作流中，重点则转移到用例上。

Alistair Cockburn：“用户故事”相当于“场景”的标题，而“用例”则是多个“场景”内容的集合。
--------------------- 
作者：山书生 
来源：优快云 
原文：https://blog.youkuaiyun.com/taizans/article/details/51698951?utm_source=copy