软件需求是一个沟通问题
不要在项目开始时就做一套包罗万象的决策，我们要把各个决策分散在项目过程中。为此，我们要确保有一个获取信息的过程，越早越好，越频繁越好。
什么是用户故事
描述了对用户、系统或软件购买者有价值的功能。包含：卡片（Card）、对话（Conversation）、确认（Confirmation）。
卡片代表客户需求而不是记录需求。卡片包含故事的文字描述，然而需求细节要在“对话”中获得，并在“确认”部分得意记录。
细节在哪里？
并不需要不断的分解故事，直到有一个故事能够覆盖每一个细节。与其写下这些故事细节，不如让开发团队和客户讨论这些细节，即在这些细节变得重要时讨论。
故事并不具有契约性质。达成的协议将有测试来记录，测试将演示故事是否被正确开发。
必须多长时间完成？
用户的期望做好以验收测试的形式被记录下来。
测试描述的目的是传递故事的额外信息，以便于开发人员指导故事于什么时候结束。
客户团队
使用故事的过程是怎么样的？
编写用户故事的过程最好从考虑系统的用户类别开始。
规划发布和迭代
什么是验收测试？
用来验证实现的用户故事是否符合客户团队的期望。
为什么要变？
对话》书面沟通
同时被你和开发理解
大小合适于做计划
适用于迭代开发
推迟考虑细节，知道非常清楚的了解自己的真正需求
用户故事的重点从文档转移到对话。
疑问
1. 交互文档、界面设计，与故事的关系
