所有敏捷项目的开端都源于同一项工作——简洁的用户故事。

一、文档的症结所在

对于软件项目来说，作为一种捕捉软件需求的手段，重型文档从来就没起过什么实际作用。这样做开发，客户很难得到真正想要的东西，团队也很难开发出客户真正需要的东西。大量的时间和精力都浪费在争论文档上写了什么，而不是必须做些什么。

对变化束手无策，他们按照文档而不是客户的需求来开发，他们做出了错误的预测和假定，他们浪费了大量的时间。

敏捷原则：无论是团队内还是团队间，传递信息最有效的方法就是面对面的交流。

二、进入用户故事

敏捷用户故事是对特性的简短描述，我们的客户希望软件具有这些特性。用小卡片不是为了获取所有细节，只需要写下少许关键词，收集特性的要求义，然后将其存档以备日后之需。

三、优秀的用户故事要素

用户故事模板：作为<用户类别>   我希望达成<某个目标>  以便于<一些原因>

本故事是关于谁的   他们想要做什么    为什么他们要这样做。

还有重要的一点，这里团队人员要转化思维方式，不能站在软件的角度记录故事，要站在用户的角度。比如：不能记录“优化数据库连接池”，要记录成“用户请求速度要小于2s ”。

四、如何主持收集故事研讨会

1、要有一个开放的大空间

2、要画很多图画

3、编写大量的用户故事

4、将一切考虑周全（一定要标注事件优先级）

5、整理清单，使其闪亮。