上两篇我们说到Agile框架中的角色(Role)和会议（Ceremonies），这篇我们深度聊一聊敏捷产物（Artefacts）的核心: 用户故事User Story！

概要

• 敏捷故事和需求和传统需求之间有什么区别？
• Design thinking: 什么时候可以开始讲故事？
• Theme, Epic, Story: 大故事，小故事，还有一些小小故事
• BDD: 故事编好了，测试还会远么？

用户故事一般由三句话组成，描述了一个用户渴望得到的功能。一个好的用户故事包括三个要素：

1.  角色：谁要使用这个功能。
2. 活动：需要完成什么样的功能。
3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达：

英文：

As a <Role>,
I want to <Activity>,
so that <Business Value>.

中文：

作为一个<角色>,
我想要<活动>,
以便于<商业价值>

我们以一个可供外星人和地球人订火箭订票网站举例：

作为一个“火箭订票网站”

我想要“统计每天有多少外星人访问了我的网站”

以便于“我的赞助商了解我的网站会给他们带来什么收益。”

在这寥寥三句话，它和传统需求描述有什么区别呢？

一、敏捷故事和传统需求之间的区别

出发点：客户vs需求

有价值（Valuable），是故事的核心要求。

每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们，而且需要让客户意识到这是一个用户故事并不是一个契约而且可以进行协商。

用户故事的每个故事，都会非常清晰的写明为什么目标客户做，帮助开发人员更好的站在客户的角度看问题。

传统需求会直接写明需要什么，对于开发人员来说，更像是知其然，未必知其所以然。

比如：以上火箭订票网站的故事，开发人员会清晰了解到是赞助商的需求，价值清晰可见，而非只是告诉客户一个简单的访问数字，假想哪些客户可以用到。

侧重点：问题vs方案

可协商性（Negotiable），是用户故事的另一个特质。用户故事不是合同，而是可以协商讨论。一个用户故事卡片上只是对用户故事的一个简短的描述，不会有太多的细节。为什么这么做呢？

用户故事侧重提出问题，但不一定要在一开始设置的时候提出解决方案。

比如说我们一开始看到统计多少外星人访问网站，目的是为了给赞助商提供信息，那么开发人员在数据分析过程中，很可能会发现，外星人星球的分布情况也可以轻松提供，为赞助商提供更准确信息。或者者有赞助商希望知道客户年龄，那么在统计数据前期，是不是可以调用其他地方的数据。等等。

所以，一个用户故事卡不会带有了太多的细节，来限制和用户的沟通。也就是说，用户故事的解决方案是需求方和开发人员不断沟通思维碰撞逐步产生的。

这与传统的方法往往由BA作为中间人来消化需求，喂给开发人员，有所不同。

沟通方式：逐步沟通 vs 一次到位

用户故事不是不会一步到位，会有一个雏形，然后慢慢形成方案和Acceptance Criteria。

传统方式当然也有沟通，但是需要什么菜基本上是一次性递给开发人员。

关于用户故事，Ron Jeffries用3个C来描述它：

1. 卡片（Card） ：用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。
2. 交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
3. 确认（Confirmation）：通过验收测试确认用户故事被正确完成。

经过交流一个好的故事加上AC很可能是这样的：

作为一个“火箭订票网站”，

我想要“统计每天有多少外星人访问了我的网站”，

以便于“我的赞助商了解我的网站会给他们带来什么收益。”

AC：

统计数据包括：

• 每日、每周、每月流量。
• 赞助商链接转化率。
• 购买赞助商产品的用户年龄、性别、星球所在地分布。

二、Design thinking: 什么时候可以开始讲故事

在敏捷的实践的时候，很多需求方都有一个困扰——抛弃了传统需求档案，我们还是需要做前期调研，那么我们什么时候可以开始写故事？

有一个非常有意思的方式——结合敏捷和设计思维。著名咨询公司Gartner把这个结合分成三个阶段：

1. Design Thinking 设计思维：分析客户的问题， 由具象到抽象
2. Lean StartUP 精益创业：提供客户问题解决方案，尝试开发模型
3. Agile 敏捷：迭代

（图片来源：Gartner）

敏捷是一种优化解决问题的方法，而设计思维是一种发现问题并找出解决方案的方法。它需要对最终用户的高度同情和理解，以及开发新想法，挑战假设和重新定义问题的迭代过程，目标是确定可能不一定明显的替代解决方案。

设计思维主要有5个阶段：

• 移情：了解人，他们的行为和动机。由于人们通常不明确地知道或无法清楚地表达这些事物，因此通过在上下文中查看用户及其行为来识别模式，提出问题和挑战假设，从而产生理解。
• 定义：根据组织，目标和最终用户的观点，创建可操作的问题陈述，以定义要解决的正确挑战，以及满足需求的一组需求。
• 构思：利用诸如头脑风暴，思维导图，素描或创建纸质原型等技术来退后一步，进行广泛应对，并提出最初未设想的更具创新性或影响力的解决方案。
• 原型：通过展示而不是说出来将想法变为现实;快速创建工作原型，将某些东西放入用户手中，并开始收集真实世界的反馈。
• 测试：从用户体验中学习，迭代并根据需要重复该过程，直到达到最小可行产品（MVP）。

在这个过程中，我们会慢慢形成解决问题的框架，继而帮助开发阶段拆分故事。

三、Theme, Epic, Story: 大故事，小故事，还有一些小小故事

有了设计思维，用户故事的产生是有故事地图Story mapping开始的，这个开发框架主要由三大类：

1. Themes：大故事.
2. Epics：可以细分到用户故事故事
3. Stories：用户故事

第一步：故事地图Story mapping

往往是团队和开发人员召集在一起的一个workshop. Epics可以按照client journey中每个阶段分类，然后团队一起在有哪些用户故事。

第二步：用户故事优先级

那么，如何确定每个阶段开发什么呢？

用户需求的优先级会被讨论出来，并结合团队开发能力，确定每个发布的主要内容；

(图片来源：一条翅膀)

后续：优化backlog中的故事

这些故事放在backlog中，你会发现，优先级高的故事，在开发前都已经经过了PO和开发人员的充分沟通，非常准确了。而优先级低的故事，可以是因为不紧急不重要，也可以是因为变化多端的外部环境导致不能很快确定需求，不需要在一开始就准备好。

四、BDD: 故事编好了，测试还会远么

故事必须是可测试的。成功通过测试可以证明开发人员正确地实现了故事。

因为如果一个用户故事不能够测试，你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：用户觉得软件很好用……

测试方法千千万，BDD已经成为了一个非常经典的测试方法。和用户故事的三句话相似，BDD也是三句话构成：

1. Given
2. When
3. Then

例子：

Given用户在根据星球搜索页面

When用户在出发星球填写飞地球之外的其他星球时，

Then返回星球自动填写为地球。

BDD具体怎么操作我们分一篇再聊。但是，用户故事只有理解以上这些来龙去脉前因后果，执行起来才有意义。

一条翅膀的其他敏捷相关文章：

老板提议我同时担任Scrum Master和产品负责人，有错吗？

自从用了敏捷，天天在开会？ 4大Scrum会议如何才能有意义？

从老板到项目成员，如何从燃尽图中洞悉团队工作？

本文由@一条翅膀 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash, 基于CC0协议