用户故事101
内容列表
之所以以“用户故事101”作为系列的开头，是因为用户故事在当前敏捷开发如火如荼的情况下，用户故事的重要性也开始凸显。
然而在我们却观察到，很多PO，尤其是从产品经理转型或者BA转型的PO，对用户故事的理解依然是“PRD的变形”，这点让我们感觉有点痛心。
所以，让我们以这篇101作为系列的开头，让我们更好的在用户故事这项技术的呃加持下，一起更加敏捷吧。
前提
用户故事是一种需求描述的方式，常见于各种敏捷方法中。
它彻底改变了需求编写的方式。过去的需求编写，更多是来自于需求人员通过各种方式（包括但不限于用户访谈、问卷、数据分析等）获取需求后，编写成各种不同形式的文档。
需求文档是经过了需求人员分析、整理后的需求，具有一定的时效性和局限性，随着市场环境的变化，用户的需求是否可以通过需求文档进行满足，就被打上了一个问号。
而用户故事从用户角度来对用户“最终目的”进行描述，而不对“如何达到目的”进行描述，这就使得中间预留一些缓冲地带给研发团队，让研发团队可以就现状进行分析，并在开发时根据现状对用户“最终目的”进行满足。在这个过程中，可以将团队的智慧发挥到极致，让团队对“用户最终目的”进行分析，给出不同的方式，以集体的智慧完成需求。
什么是用户故事
用户故事是针对于用户有价值的功能进行的描述。一般情况下用户故事的格式如下
作为<角色>，我需要<功能>，以便于<商业价值>
在上述的格式中，包含了三个因素Who、What 和Why
- Who 描述了最终使用该功能并获得价值的角色，它帮助我们明确了功能使用人的边界，从而将当前用户故事集中在一个固定的范围内容；
- What 描述了需要达到的效果。注意此时是效果，而不是解决方案。换言之，关注点是你最终的目的，而不是解决方案（途径）。最简单的区别就是 “快速找到你需要的商品”是目的，而“使用搜索”是解决方案；
- updated 2020.1.15 有很多情况下，用户故事并不是都是“用户需要”的，而是用户被要求、被强迫执行。比如很多ERP系统中“单系统登录”，即同一时间，只能在一个浏览器登录，其他浏览器都会自动退出。这就很明显不是用户“需要”，而是“被迫执行”；
- Why 描述了What的合理性，着眼点是价值，即What 背后的商业逻辑。或者换一个更加粗暴的说法，就是“给Who 所带来的收益”。
对用户故事还有一种叫3C 原则，具体是：
Card，包含故事的文字说明
Conversation，包含了需求细节
Cofirmation，对上述内容进行记录
从上述对用户故事描述来看，当前我们至少知道用户故事至少有以下几种特点：
- 有价值，对用户故事中Who 来说，这个用户故事必须有价值，用户将会因此有所收益
- 用户故事所带来的价值，用户必须可感知——这点极度重要，这近似将所有的技术细节从用户故事中剔除，让我们可以更关注需求本身
史诗用户故事是什么
有些书或者论坛上，会将Epic （史诗）当作一种用户故事类型。
但我不认同用户故事有Epic（史诗）这种特定类型。
Epic 不是一种类型，而仅仅是一个标签（tag）而已。
用户故事就是用户故事，只是有些用户故事比较大，如果将这种用户故事完成，将会赋予用户某种能力（Capacity），那么这种用户故事我们就认为其具有Epic 这种标签，仅此而已。
而且这种认知直接让我对用户故事的INVEST原则（下一次我们会聊到）中某一项有了一些其他看法。
用户故事细节在哪里
用户故事如果写在看板上，内容是有限的，肯定是不能将各种讨论后的细节写明白的（微雕工艺者表示我不服），那么细节应该在哪里？
我的回答是：需要存在其他系统中。一般我们会将其存在Jira或者Trello中，存储的内容一般是讨论的最终结果（团队与PO 共同认可）。
最终结果包含两个部分：
- 讨论的细节，包括该用户故事涉及的流程、顺序、以及界面（UI）与交互（UX）等结果；
- 验收标准。肯定会有人告诉你，我们将验收测试写在用户故事卡片背后，但实际上由于用户故事的粒度问题，是不能保证100%都能写下的。而且有些验收标准也比较复杂，用户验收测试包含内容太多，这都不适合写在卡片背后。
验收测试是什么
验收测试是用来验证实现的用户故事是否满足客户需求的测试用例。
在迭代开始时，开发人员开始编码时，客户或者PO 就随时准备对产品进行验收。而帮助他们进行这个工作过程的工具，就是验收测试。
验收测试应该越早完成越好，这么做的最大好处是——让开发团队与客户可以尽可能早的，就功能开发做出相同的认知，避免开发人员对客户的要求理解不到位，导致开发的偏离，产生工作量的浪费。
下面是一个针对用户登录写的验收测试：
1. 用户可以使用正确的用户名、密码登录
2. 用户可使用手机验证码进行登录
3. 用户可使用微信扫码登录
4. 登录失败时，给用户错误提示
在这个过程中，细心的你可能会发现，我在验收测试中，并没有对“用户名密码错误”、“验证码输入错误”、“微信扫码后不点击授权”等场景进行描述，这是为何？
在实际验证过程中，验证的实施方是客户或者PO，他们更加关心是“正确的路径”，也就是所谓的Happy Path，而其他出错信息，他们无法穷举，所以该工作一定程度上就由研发团队来补上，从而让客户、PO将精力集中在有价值部分（非Happy Path 一般不产生价值）。
写在最后
用户故事是现在敏捷开发中常见的形式，如何用好用户故事将会直接对敏捷实施能否成功带来巨大影响，所以下面几篇文章中，我们将会从INVEST、用户角色建模、故事验收、故事收集、故事拆分等方面为大家详细讲解用户故事有关的内容，敬请期待。
