上两篇我们说到Agile框架中的角色（Role）和会议（Ceremonies）这篇我们深度聊一聊敏捷产物（Artefacts）的核心： 用户故事User Story！
概要
敏捷故事和需求和传统需求之间有什么区别？
Design thinking： 什么时候可以开始讲故事？
Theme， Epic， Story： 大故事，小故事，还有一些小小故事
BDD： 故事编好了，还会远么？
用户故事一般由三句话组成，描述了一个用户渴望得到的功能。一个好的用户故事包括三个要素：
角色：谁要使用这个功能。
活动：需要完成什么样的功能。
商业价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达：
As a 。
I want to 。
so that .
作为一个。
我想要。
以便于
我们以一个可供外星人和地球人订火箭订票网站举例：
作为一个“火箭订票网站”
我想要“统计每天有多少外星人访问了我的网站”
以便于“我的赞助商了解我的网站会给他们带来什么收益。”
在这寥寥三句话，它和传统需求描述有什么区别呢？
一、敏捷故事和传统需求之间的区别 出发点：客户vs需求
有价值（Valuable）是故事的核心要求。
每个故事必须对客户具有价值（无论是用户还是购买方）一个让用户故事有价值的好方法是让客户来写下它们，而且需要让客户意识到这是一个用户故事并不是一个契约而且可以进行协商。
用户故事的每个故事，都会非常清晰的写明为什么目标客户做，帮助人员更好的站在客户的角度看问题。
传统需求会直接写明需要什么，对于人员来说，更像是知其然，未必知其所以然。
比如：以上火箭订票网站的故事，人员会清晰了解到是赞助商的需求，价值清晰可见，而非只是告诉客户一个简单的访问数字，假想哪些客户可以用到。
侧重点：问题vs方案
可协商性（Negotiable）是用户故事的另一个特质。用户故事不是合同，而是可以协商讨论。一个用户故事卡片上只是对用户故事的一个简短的描述，不会有太多的细节。为什么这么做呢？
用户故事侧重提出问题，但不一定要在一开始设置的时候提出解决方案。
比如说我们一开始看到统计多少外星人访问网站，目的是为了给赞助商信息，那么人员在数据分析过程中，很可能会发现，外星人星球的分布情况也可以轻松，为赞助商更准确信息。或者者有赞助商希望知道客户年龄，那么在统计数据前期，是不是可以调用其他地方的数据。等等。
所以，一个用户故事卡不会带有了太多的细节，来限制和用户的沟通。也就是说，用户故事的解决方案是需求方和人员不断沟通思维碰撞逐步产生的。
这与传统的方法往往由BA作为中间人来消化需求，喂给人员，有所不同。
沟通方式：逐步沟通 vs 一次到位
用户故事不是不会一步到位，会有一个雏形，慢慢形成方案和Acceptance Criteria。
传统方式当然也有沟通，但是需要什么菜基本上是一次性递给人员。
关于用户故事，Ron Jeffries用3个C来描述它：
卡片（Card）：用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。
确认（Confirmation）：通过验收确认用户故事被正确完成。
经过交流一个好的故事加上AC很可能是这样的：
作为一个“火箭订票网站”
我想要“统计每天有多少外星人访问了我的网站”
以便于“我的赞助商了解我的网站会给他们带来什么收益。”
AC：
统计数据包括：
每日、每周、每月流量。
购买赞助商产品的用户年龄、性别、星球所在地分布。二、Design thinking： 什么时候可以开始讲故事
在敏捷的实践的时候，很多需求方都有一个困扰—抛弃了传统需求档案，我们还是需要做前期调研，那么我们什么时候可以开始写故事？
Design Thinking 设计思维：分析客户的问题， 由具象到抽象
Lean StartUP 精益创业：客户问题解决方案，尝试模型
Agile 敏捷：迭代
敏捷是一种优化解决问题的方法，而设计思维是一种发现问题并找出解决方案的方法。它需要对最终用户的高度同情和理解，以及新想法，假设和重新定义问题的迭代过程，目标是确定可能不一定明显的替代解决方案。
设计思维主要有5个阶段：
移情：了解人，他们的行为和动机。由于人们通常不明确地知道或无法清楚地表达这些事物，因此通过在上下文中查看用户及其行为来识别模式，提出问题和假设，从而产生理解。
定义：根据组织，目标和最终用户的观点，创建可操作的问题陈述，以定义要解决的正确，以及满足需求的一组需求。
构思：利用诸如头脑风暴，思维导图，素描或创建纸质原型等技术来退后一步，进行广泛应对，并提出最初未设想的更具创新性或影响力的解决方案。
原型：通过展示而不是说出来将想法变为现实；快速创建工作原型，将某些东西放入用户手中，并开始收集真实世界的反馈。
从用户体验中学习，迭代并根据需要重复该过程，直到达到最小可行产品（MVP）
在这个过程中，我们会慢慢形成解决问题的框架，继而帮助阶段拆分故事。
三、Theme， Epic， Story： 大故事，小故事，还有一些小小故事
有了设计思维，用户故事的产生是有故事地图Story mapping开始的，这个框架主要由三大类：
Themes：大故事.
Epics：可以细分到用户故事故事
Stories：用户故事第一步：故事地图Story mapping
往往是团队和人员召集在一起的一个workshop. Epics可以按照client journey中每个阶段分类，团队一起在有哪些用户故事。
第二步：用户故事优先级
那么，如何确定每个阶段什么呢？
用户需求的优先级会被讨论出来，并结合团队能力，确定每个发布的主要内容。
后续：优化backlog中的故事
这些故事放在backlog中，你会发现，优先级高的故事，在前都已经经过了PO和人员的充分沟通，非常准确了。而优先级低的故事，可以是因为不紧急不重要，也可以是因为变化多端的外部环境导致不能很快确定需求，不需要在一开始就准备好。
四、BDD： 故事编好了，还会远么
故事必须是可的。成功通过可以证明人员正确地实现了故事。
因为如果一个用户故事不能够，你就无法知道它什么时候可以完成。一个不可的用户故事例子：用户觉得软件很好用…
方法千千万，BDD已经成为了一个非常经典的方法。和用户故事的三句话相似，BDD也是三句话构成：
Given
When
Then
例子：
Given用户在根据星球搜索页面
When用户在出发星球填写飞地球之外的其他星球时。
Then返回星球自动填写为地球。
BDD具体怎么操作我们分一篇再聊。但是，用户故事只有理解以上这些来龙去脉前因后果，执行起来才有意义。
本文相关词条概念解析：
故事
故事：文学体裁的一种，侧重于事件过程的描述。强调情节的生动性和连贯性，较适于口头讲述。已经发生事。或者想象故事。故事通过对过去的事的记忆和讲述，描述某个范围社会的文化形态，也有说法认为，故事并不是一种文体，它是通过叙述的方式讲一个带有寓意的事件。诸如此类的自然现象，都和原始人类的生产、生活有密切关系，他们迫切地希望认识自然，于是便以自身为依据，想象天地万物都和人一样，有着生命、意志的；对于自然现象的过程和因果关系，也加以人间形式的假设和幻想，并以为自然界的一切都受有灵感的神的主宰。