软件需求是一个沟通的过程
如何规避风险
基本原则：
- 不要在项目开始阶段就做一套完善的，包罗万象的决策
- 把各个决策分散在项目过程中
什么是用户故事
用户故事描述了对用户、软件或软件购买者有价值的功能
由以下三个方面组成：
- 一份书面的故事描述，用于做计划和提示
- 有关故事的对话，用于具体化故事细节
- 测试，用来表达和编档故事细节并且可以用于确定故事何时完成
关键在于故事应该以对用户有价值的方式写下来。
细节在哪里
以用户搜索商品为例
- 用户可以搜索哪些商品
- 需要展示哪些与用户匹配的标签
- 搜索记录可以保存吗
多个小故事远胜于一个大故事
例如 用户搜索商品
- 用户可以通过商品名、商户名、分类来搜索商品
- 用户可以查看每个商品的详情和销量
- 用户可以查看每个商品相关的买家秀
我们需要不断的分解故事到一个合适的程度
与其写下这些故事细节，还不如让开发团队和客户讨论这些细节，即在这些细节变得重要时才讨论
讨论才是关键
故事并不具有契约性，达成的协议将由测试来记录，这些测试将演示故事是否被正确开发
必须多长时间完成
“必须多长时间完成？”这个问题能够从某种角度来了解项目用户的期望是什么
用户的期望最好以验收测试的形式记录下来
开发人员如果能够了解用户的期望，便能知道是什么时候算是完成了客户要求的功能
客户团队
在一个理想的项目中，一般有一个专职人员来为开发人员的工作排优先级，回答开发人员的所有问题，以及在软件完成时，写下所有故事。
这个客户团队中应该包括确保软件满足用户需求的所有人，这意味着这个客户团队应该包括产品经理、测试人员、实际用户和交互设计师
