第四章 搜集故事
从前面几章我们可以了解到，要想做到尽可能完整的了解用户的需求，用户故事将会是一个不错的选择。在一些原来的书本上，我们了解到可以使用“引出”、“捕捉”这类方法来获取故事。但是这是明显错误的，因为需求本来是不存在的，或者说是，用户只知道一个大概，而不能详尽的想到每一处细节。所以这种单纯的引出是不可行的。于是在之后，“拖网”方法被开发，它包含着多重含义：需求分大小，需求的重要性会随时间推移而变化，发现需求需要技巧。
我们在项目开始之前，要对应用程序的结果有一个预判，这就需要我们在搜集故事这一阶段做到尽善尽美。我们可以通过许多方法来获取需求：用户访谈，问卷调查，观察，故事编写工坊。用户访谈使用最广，但是要注意，用户常常无法知道真正需求，应站在程序员的角度来看待问题。且要善用提问，尽可能使用开放式背景无关方式询问，这样才能给用户更大的发挥空间，得到的结果也更尽如人意。问卷调查是一种较有效的方法，但是也存在特有的局限：不利于后续问题的跟进，也不能与用户针对一个感兴趣的问题展开深入交谈。观察是一个上佳的办法，我们可以直观的了解到用户的需求。故事编写工作坊，这是作者最为推崇的办法，开发人员、用户、客户经理等等有关的人共同参加会议，快速搭建项目原型，头脑风暴，尽可能的提出可行的故事，并且采用深度优先的方法，可以大大拓展思维，将每一个用户的功能全面分析。
第五章 与用户代理合作
实际用户对项目的影响不可忽视，但是由于种种原因，我们很难邀请实际用户参与项目。这时我们常常会于用户代理合作。用户代理分为以下几种：用户经理、开发经理、销售人员、领域专家、市场营销团队、老用户、客户、培训师和技术支持、业务分析师或系统分析师。与这些人合作编写用户故事，结果往往不尽人意，由于个人所处职位关系或利益，他们都会将故事偏向自我，偏离那些真正用户的需求。所以最好的方法还是要寻求与实际用户的交流，这里一个顾问团队来寻求帮助；而是在不能的话，要从多个用户代理处获取信息，希冀正确的需求。
第六章 用户故事验收测试
验收测试可以记录故事细节，同时补充完善。较好的测试可分为两步流程：首先，将测试的要点记录在故事卡的背面，发现新的后，进行补充；其次，要将测试要点变为全面的测试，用于演示故事的正确性。验收程序可以用于确认故事是否被完整实现。同时验收测试从编写代码前，就应该进行，得到的信息有利于开发流程，同时贯穿于整个开发过程。而且重要的是，测试程序应该有客户定义，用户有自己的标准来判断软件是否适用。为了方便，我们还可以使用已经集成好的框架(自动测试化验收工具）测试结果的正确性。测试类型尽可能全面，追求软件性能的稳定。