第一章：概览
1.什么是用户故事
作者在文中给出了如下的定义：描述对用户、系统或软件购买者有价值的功能。我们不难看出，对于用户故事，他的立足点是用户，那么他就是对用户需求的描述。在BigMoneyJob网站的例子中：作者给出了几个事例故事：（1）用户可以搜索职位（2）公司可以发布新职位（3）用户可以限制浏览其简历的人。不难总结，用户，公司都是软件的用户。不理想的用户故事则是（1）这个软件将用C++语言来编写（2）程序将通过连接池连接数据库。如果是这样，则变成了开发者故事了。用户故事就是对用户有价值的需求。
2.细节在哪里
如何编写一个故事，像这样吗？（1）用户可以搜索职位（2）公司可以发布职位，显然这些需求比较庞大，甚至可以说没有用处，它没有细节之处，我们需要不断地分解故事，知道有一个故事能够覆盖到每一个细节，简单的一句“用户可以搜索职位”，我们首先需要分解为（1）用户可以通过地区，薪水范围，职位，公司名和发布日期之类的属性来进行搜索（2）用户可以查看搜索结果中每个工作的具体信息（3）用户可以查看发布工作的公司的信息。仅仅在第二点中，我们又可以继续划分（1）查看工作描述（2）查看薪水范围（3）查看工作地点，当然，这些不可能由开发者一人完成，需要与客户不断地交流讨论，毕竟他们才是真正的使用者。
3.必须多长时间完成？
显然我们需要知道用户对于软件完成时间的期望，这样有利于我们对软件完成的进度。
4.客户团队
这个类似于测试环节，但是又高于测试，建立一个客户团队，帮助开发者理解和完成所有的用户需求，这其中离不开测试人员，产品经理，实际用户和交互设计师。
5.使用故事的过程是怎么样的？
客户和用户不应该只在开始的时候参与进来写需求，而是在项目整个过程中全程参与。客户团队在迭代期间高度参与，与开发人员谈论正在开发的需求，不过我认为，这样做是否会有一个弊端，就是客户团队对于需求是否能够一直不改变，是否会一直变动需求？
6.规划发布和迭代
为发布中的所有迭代分配好需求之后，发布计划便“浮出水面”，开发人员需要估算出他们在议论迭代中能够完成多少个需求，客户团队则需要将这些需求按照优先级来分配到每轮迭代中。
7.什么是验收测试？
验收测试用来验证实现的用户需求是否符合客户团队的期望，而验收测试严需要尽早的编写并进行测试。
8.为什么要变？
需求集可以迭代，恰恰说明了需要，我们不必假装可以实现知道并写下所有东西，一客户团队和开发人员的讨论为基础，不断地今年我们的需求。