最近在阅读《用户故事与敏捷方法》，一边读一边回忆最近项目遇到的问题。通过重新整理思路，理解了很多概念和环节设置背后原因和使用技巧，同时很多问题似乎也得到了解决。

每个环节我打算从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。