00.软件需求是一个沟通问题。需要新软件的人（使用或销售软件的人）必须与开发新软件的人进行交流。一个项目的成功，依赖于很多不同的信息，这些信息来自各有不同的人员：一方是客户和用户，有时还有分析人员、领域专家和其他从业务或组织视角来审视软件的人；另一方面是技术团队。
01.一旦任何一方在沟通中把持绝对地位，项目就会遭受损失。
如果业务方把持绝对地位，他们就会关注软件功能和交付日期，却很少关注开发人员是否能够同时满足这两个目标，或者开发人员是否确切地了解需求。
如果开发人员把持绝对地位，技术属于就会代替业务语言，从而导致开发人员无法倾听业务方的实际需求。
02.用户故事描述了对用户、系统或软件购买者有价值的功能。
*一份书面的故事描述，用来做计划和作为提示
*有关故事的对话，用于具体化故事细节
*测试，用于表达和编挡故事细节且可用于确定故事合适完成。
03.如果一个故事很大，我们有时候就称为之为史诗故事（Epic）。史诗故事可以分为两个或更多的小故事。用户的期望最好以验收测试的形式被记录下来。
04.客户团队中包括确保软件满足用户需求的所有人。这意味着客户团队可以包括测试人员、产品经理、实际用户和交互设计师。
05.面向瀑布模型的过程会有书写所有需求、分析需求、设计方案、编码、最终测试的周期。
06.软件的客户和最终用户应该在编写用户故事时承担着非常活跃的角色，尤其是在团队使用基线编程进行软件开发时。编写用户故事的过程最好从考虑系统的用户类别开始。
07.由客户团队而不是开发人员来编写用户故事主要基于两个原因。首先，每个故事必须用商业语言来写，不是用技术术语，这样一来，客户团队可以排列故事的优先级，放入迭代和发布。其次，作为主要的作品构想者，客户团队所处的位置最适合描述产品行为。
08.与其写这些故事细节，还不如让开发团队和客户讨论这些细节。
09. 发布规划指的是确定项目时间表和预期功能集合之间达到平衡。迭代规划设计选择迭代包含的故事。客户团队和开发人员在发布和迭代规划中都要参与
10.当程序员开始编程前，故事卡被卖你就写下测试描述时，可以节省程序员的时间。更多关于编写故事验收测试的内容。
11.为什么要变？
a.用户故事强调对话交流而不是书面沟通。
b.用户故事可以同时被你和开发人员理解
c.用户故事的大小适合于做计划
d.用户故事适用于迭代开发
e.用户故事鼓励推迟考虑细节，知道你非常清楚地了解自己的真正需求。
12.迭代过程是一个逐步求精的过程。开发团队首先开发系统的一小部分，知道它在某些方面是不完整的或者不完善的。然后他们呢逐步加以相应的改进，知道产品让人满意。通过每轮迭代中增加的更多细节，软件被逐步改进。
13.推迟细节很重要，因为这样一来，我们在不确定是否真正需要某个新特性时，可以不花过多时间来考虑它。使用故事，我们不必假装可以事先知道并写下所有东西。一客户团队和开发人员的讨论为基础，不断地精炼我们的需求。
14.客户团队包括那些确保软件符合潜在用户需求的人，可以包括测试人员、产品经理、实际用户和交互设计师。故事卡由客户团队编写，因为他们最了解如何表达需要实现的需求，也因为他们会在后期与开发人员共同确定故事细节并安排故事的优先级顺序。