简介
由敏捷开发署名者Ron Jeffries提出的观点，在软件开发需求阶段，使用用户故事的形式去描述需求，而非功能模块的形式去描述。保证每一个需求都有用户参与，是对用户有益的需求，且每一个用户故事的需求都可以落地，可以上线。
模板三要素
As a role，I want to …, so that …
“作为一个<用户角色>, 我想要<完成活动>, 以便于<实现价值>”
- 用户角色：谁要使用这个
- 完成活动：要实现什么
- 实现价值：获得的收益是什么
这就是用户故事最为经典的形式。我们可以看出，使用用户故事描述的需求，必然是对于用户有益，且可以落地的需求，否则通过用户故事的形式是无法将之描述清楚。
原则
用户故事有两个原则3C原则，INVEST原则
3C原则
1. 卡片（Card）
卡片形式的用户故事可以更加清楚的展示用户故事三要素
且同样可以通过简单的描述建立验收标准使每一个开发人员都能够通过用户故事即可了解到需要实现的目标
用户故事卡片Demo
| <卡片标题>（需求简介） |
|---|
| 作为<用户角色> |
| 我想要<完成的活动> |
| 以便于<实现价值> |
验收标准卡片Demo
| 验收标准 |
|---|
| 1.xxxxxx |
| 2.xxxxxx |
| 3.xxxxxx |
2. 交流（Conversation）
-
与客户交流：
用户故事主要实现的是确保每一个需求都是可上线可落地有价值的需求，其背后的细节来源于和客户或者产品负责人的交流沟通，也就是说用户故事描述的需求本身就是充分交流后的产物，而不是一个假大空，或者其价值要长远的未来才能体现一星半点好处的需求。
-
提高项目团队内部的沟通效果
如果一个企业，一个项目团队，要贯彻敏捷开发的精神，那么研发团队的成员会在需求评审的工程中，会出现对需求的质疑，因为大家的目标都是将产品做好，而不是当代码实现工具人。
“这个需求谁提的，为什么这么做，做了有什么价值？”
”老板就让这么做的，下周上线。“
如果我们在每一次需求评审中，都只能得出如上的结论，最终的结果一定会导致我们的项目实现走上弯曲的道路，而用户故事的形式可以极大程度的降低大家的沟通成本，大大减少”这个需求的意义是什么“的声音
3. 确认（Confirm）
完整的用户故事会有验收标准的体现，通过验收测试来保证用户故事被正确的实现
INVEST原则
独立的（Independent）
尽可能的保证用户故事的独立性，这样可以很好的去评估用户故事的优先级，也可以使用户故事被独立的测试，发布。
可商议的（Negotiable）
用户故事是可以商议的，商议的结果得到了团队中绝大多数（理想情况下是每一个成员）,整个团队的每一个成员都将对商议的结果负责，而不是妥协式办公。
有价值的（Valuable）：
用户故事的核心在于一定是有价值的，用户故事描述的东西是特性(Feature)而不是去要求xxx执行任务（Task）
例如优化类需求，如果是优化代码，对于用户是无感知的，不应当以用户故事形式体现，如果是优化系统操作流程，且该流程一定能为用户带来直接价值，才应当以用户故事体现。
可估量的（Estimable）：
用户故事需要可以被估算，这就要求用户故事不能太大，同时讨论人员需要具备一定的技术知识。
需要避免过大的用户故事出现，如果有此类用户故事，需要对用户故事进行细分
小规模的（Small）：
好的工作故事不能太大，最好能保证在一个迭代内可以完成。如果用户故事过大，则违反了上述可估量的，在后续开发安排上就会有较大风险。
「需要一个拉黑功能」看起来是一个需求，但其中还有很多细节没有说清楚：
- 用户如果不想拉黑对方了，是否可以解除拉黑？
- 拉黑有没有期限？
- 拉黑之后能不能给对方发消息，如果不能应该怎么提示？
- ……
可测试的（Testable）：
用户故事必须清晰地界定验收测试标准。
比如说「用户觉得很满意」「用户觉得系统好用」这样的抽象主观概念就是不可测试的
优点
1.敏捷开发
如果我们站在2020年去回顾互联网的发展历程，一定可以得到的结果就是敏捷开发更加的适合于需要及时响应客户的项目开发。
在许多互联网公司不惜花重金请敏捷团队为公司进行敏捷培训，甚至于我的上家公司，一家国资企业，也去请了敏捷团队进行敏捷培训。敏捷开发的好处，在于使整个项目团队在经历了磨合之后走向一个正向的循环。
关于敏捷开发可以参考我之前写的文档：
2.提升沟通效果
用户故事的在描写时需要产品团队评估用户故事的价值，以及用户故事的受益人，因此一个合格的用户故事提出，将会减少很多”这个功能有什么用？“的声音。可以大大的提升沟通效果。
例如我们在聊头疼的地址需求时，我们用户故事应该是，
”用户可以自己建模，且可以将建模挂载在国家标准5级地址“。
而不是”用户要把标准地址copy到自己租户下一份，然后在当前copy的地址下进行建模“
两种需求形式，第一种研发会在实现时给出解决方案，第二种只会让会议上的所有人去反问”为什么要copy一份？“然后马上去考量这样的坏处，好处，大大的降低了沟通效率
3.延迟细节
在研发过程中，许多细节，例如手机号码校验之类的，是属于细节，不应该放在用户故事中进行讨论，只需要在验收标准中明确即可
Step1：用户故事的描述，可以使大家对需要实现的需求有一个大的概念
Step2：大家会根据产品提供的原型，与用户故事对应，在确保原型逻辑没有错误的情况下，即可进行设计
Step3：最后根据验收标准，即可实现这个用户故事卡片
4.提升团队的产品意识
产品团队与客户，研发团队与产品团队的沟通会越来越密切，可以培养团队的产品意识，因为每一个需求都是对用户有益的，大家在思考问题时都会去想，这个用户故事/需求可以给用户带来怎样的收益，他的价值是怎样。而不是在需求评审的时候，大家去讨论，这样实现，那样实现，实现方式是否合理，这样的讨论应该是程序设计讨论，而不是需求评审讨论。
难点
1.无行业标准
对于不熟悉用户故事的人而言，用户故事的概念实在是过于模糊了，甚至会认为其没有意义，且用户故事需要与客户直接沟通，这对于产品而言是一个极大的考验，需要产品团队不断的去思考，用户有了这个功能，能有什么好处，这个好处的价值是否足够的有利，还是仅仅只满足了一些可有可无的需求
2. 用户故事不是万能的解药，需要界定
用户故事只能用于描述当前系统的用户，而不能跨平台（平台间用户打通除外），垮业务的进行用户故事描写，因为如果不是当前平台的用户，那么用户故事将无法找到其实现价值例如：
- 第三方端端对接
- 运维业务
