Being Agile！用户故事要妙在价值而非骨感-京东云开发者社区

#### 随着敏捷的推进，重点会倾向于PO们的领域，我们先讨论第一个话题：用户故事。

可能会有朋友说，好好的不叫需求，为啥叫用户故事？用户故事最早由Kent Beck在《极限编程》里提出，仔细琢磨这个词，我认为它更是一个隐喻。**当你听到“需求”你想到的往往是工作量，而当你听到“故事”这个词，会不会勾起你的好奇和探索欲呢？**

#### 用户故事的格式
敏捷中，产品经理有个很重要的“家伙式”是产品代办列表PB，PB里面放的就是“用户故事”。用户故事是业务的一种表达方法，它应该是独立的、有价值的。格式很简单，简单到骨感：
**“作为一个  [用户] ，我想要  [功能] ，以便我可以 [获得的价值]” 。**
**同时，一个用户故事，对应一组验收条件。**

**它的价值在于：**
- 强制同理用户：统一了业务、研发的视角站在用户的视角沟通。
- 强制思考价值：就是第三部分 why。一个用户故事一定要有价值。（往往这部分是最难写的）

#### 用户故事属于哪个环节
用户故事的格式很简单，研发同学拿着用户故事是无法有效开发的。所以**用户故事不等于PRD。**

用户故事是在业务目标确定后，在讨论产品解决方案时开始产生的，或者说用户故事组成了产品解决方案。

#### 用户故事的颗粒度
###### 用户故事从粗到细：
- EPIC 史诗级故事，一般大于一个版本
作为一个女白领，我想要上门取干洗衣物的服务，以便我及时没有时间去干洗店也能保持衣服整洁。
- Theme 主题故事   一般大于等于一个迭代
由一组相关联的故事，用主题来表明故事与故事之间的关联性。
- Story                      一般几天可以完成
作为一个快递员，我想要默认显示我当前定位附近上门取件单，以便我及时、省力地上门取件。

#### 讲故事贯穿全过程
故事是讲出来的，而不是写出来的。所以用户故事最重要的一个点是激发讨论、达成共识！讲故事贯穿整个交付的过程：
1. **需求获取阶段：**理解用户需求与痛点【业务、产品】
2. **需求分析阶段：**梳理、分析功能需求、隐含需求，提炼抽象，整理解决方案【业务、产品】
3. **需求定义阶段：**沟通需求，探索非功能需求，验收条件【产品、研发】
4. **需求评审阶段：**估算需求，细化澄清，确认验收条件 【业务、产品、研发】
5. **迭代计划会：**确认交付范围与目标【产品、研发】
6. **迭代：**实现、调整、跟进、测试【产品、研发】
7. **迭代评审会：**产品验收【产品、研发】
8. **线上验证：**验证故事价值【业务、产品】

#### 用户故事要有价值才够漂亮
**PO有个很重要的职责是要通过输入有价值的需求，让团队不断收获成就感。**
用户故事挖掘的够不够有价值，就很重要！
如果你的用户故事针对的是核心干系人的问题、痛点或是期待一路梳理过来的，那背后的Why应该不会偏差太大。你可以从以下几个点去澄清一个故事的价值：
- 谁最关心这个Story？对谁影响最大？
- Story所针对的这个**客户/用户的具体问题和期待**，是当前产品发展的**优先级**吗？与我们的目标对齐的吗？
- Story是这个解决方案中**必须的组成**吗？
- Story已经是最优解了么？在当前约束内，是否还有**性价比更高的解决方案**？

#### 用户故事要有验收条件（AC）
验收条件来验证用户故事是否真正实现了，验证条件应该是测试用例的一部分，只不过是在用户故事定义阶段定义的。一个用户故事对应的AC小于8个，目前有的团队把这个当成冒烟测试，也是不错的做法。
验收条件也有一个格式：
**Given<前置条件>, When<输入>，Then<输出>**

**例如：**作为家长，我希望能有多个账号登录APP，以方便我不在场时，其他人也可以使用APP管理小朋友学习。

**AC1  登录成功**
- Given：未登录
- When：输入关联手机号
- Then：登录成功

**AC2 登录失败**
- Given：未登录
- When：输入未关联手机号
- Then：登录失败

#### 最后抛一个问题：用户故事与UML里的用例的区别是什么？

------------
###### Being Agile 京东物流技术发展部效能提升部
###### 作者：效能提升部 宋宁
![](//img1.jcloudcs.com/developer.jdcloud.com/a0f979a8-94a7-4b37-93c0-bb7b687f072620210108180341.png)