最近在阅读《用户故事与敏捷方法》，一边读一边回忆最近项目遇到的问题。通过重新整理思路，理解了很多概念和环节设置背后原因和使用技巧，同时很多问题似乎也得到了解决。
每个环节我打算从Why，What，How，Who，When去理解。
用户故事
Why：为什么是用户故事？（产品篇，流程篇）
用户故事这个主题全部围绕着“软件需求”
软件需求是用户需求到软件产品之间的桥梁，核心在于沟通
用户需求->软件需求->软件设计->软件开发->软件产品
（大家都玩儿过千里传音的游戏，经过这么多环节，如何保证用户需求，最终成为软件产品的时候，还是用户想要的那个）
用户故事，解决在VUCA的环境下，软件需求的沟通任务
业务语言，用户语言《===》技术实现，在用户语言和技术实现之间搭建桥梁
让用户和开发团队之间进行协同工作的工具
通过3C原则，实现用户故事的这一沟通职能。Card、Conversation、Confirmation
用户故事如何可以替代详尽的文档
Why：为什么用户故事要替代详尽的文档？
How：如何正确的使用用户故事，让我们可以脱离详尽的文档？
(让我们带着这两个问题来看后面的内容)
敏捷开发宣言之二，工作的软件高于详尽的文档
为什么要专门说这一点，很重要，因为传统模式下，是文档沟通。
如果我们没有系统性的理解用户故事的内涵和作用，用户故事形同摆设，我们会发现开发团队没办法离开文档进行有效的开发。因此，产品经理会抱怨，周期缩短了，文档工作却一点没少。
头脑风暴一下：
文档的好处？
文档的坏处？
好处：
1、隔离情绪，避免争论，避免沟通产生冲突。
2、达成一致。文档一般就是定论，单方面决定，大家遵照文档进行工作，带有强制性。
3、便于随时查阅。
坏处：（针对敏捷模式）
1、不利于面对面沟通，更倾向于单独阅读。复杂一点的，面对面沟通理解费力。人的记忆力有限。
2、不是团队沟通的结果，因此需要写文档的人（产品经理）反复的推敲，仍然很多细节难以确定，若没有细节，又会造成最终做出来的不是产品所设想的那样。
比如，看下面的例子：
由此可以明了，文档做为需求载体的问题，就是产品必须要准确无误的阐述产品需求细节，并且让开发团队准确无误的接收和理解。
应对市场的模糊性
即便产品准确的描述了开发团队完全能够理解的产品需求，你又如何保证产品完全理解了客户的需求。
在敏捷模式下，大部分情况是，市场是变化的，市场数据是不清晰的不完整的，客户自己都不能够清晰的阐述自己的需求，经常会变化。
产品头脑里面的设计有可能只是闭门造车。
随着市场的变化，产品经理会改变最初的市场判断，进行需求变更
（心理学原理，人类的本能，是会自动脑补数据缺失和模糊的部分，以保持其完整性和可定义。）
更糟糕的事情发生了，这样的情况如果发生多次，开发团队和产品经理之间的沟通和信任会存在危机。
用户故事的作用（总结）
1、前提---不确定性，数据不全，市场需求模糊的情况下的：
2、软件需求的载体
3、沟通的工具
4、用户语言、业务语言到技术实现的桥梁
为什么是用户故事，而不是详尽的文档就阐释到这里，下一篇继续介绍，What，How，Who。
