软件需求是一个沟通问题

不要在项目开始时就做一套包罗万象的决策，我们要把各个决策分散在项目过程中。为此，我们要确保有一个获取信息的过程，越早越好，越频繁越好。

什么是用户故事

描述了对用户、系统或软件购买者有价值的功能。包含：卡片（Card）、对话（Conversation）、确认（Confirmation）。

卡片代表客户需求而不是记录需求。卡片包含故事的文字描述，然而需求细节要在“对话”中获得，并在“确认”部分得意记录。

细节在哪里？

并不需要不断的分解故事，直到有一个故事能够覆盖每一个细节。与其写下这些故事细节，不如让开发团队和客户讨论这些细节，即在这些细节变得重要时讨论。

故事并不具有契约性质。达成的协议将有测试来记录，测试将演示故事是否被正确开发。

必须多长时间完成？

用户的期望做好以验收测试的形式被记录下来。

测试描述的目的是传递故事的额外信息，以便于开发人员指导故事于什么时候结束。

客户团队

使用故事的过程是怎么样的？

编写用户故事的过程最好从考虑系统的用户类别开始。

规划发布和迭代

什么是验收测试？

用来验证实现的用户故事是否符合客户团队的期望。

为什么要变？

---

对话》书面沟通

同时被你和开发理解

大小合适于做计划

适用于迭代开发

推迟考虑细节，知道非常清楚的了解自己的真正需求

---

用户故事的重点从文档转移到对话。

疑问

1. 交互文档、界面设计，与故事的关系