第1章 概览
软件需求是一个沟通问题，一旦任何一方在沟通中把持绝对地位，项目就会遭受损失。我们需要一种协同工作的方式，让双方都不占绝对主导地位，共同面对感情用事和办公室政治化的资源分配问题。
当用户看到软件的早期版本时，他们总是会想出新的点子，导致我们无法勾勒出一个完美的蓝图来展示项目中所有必须完成的事情。那么我们怎么办？一般来说，不要在项目开始的时候试图做一套包罗万象的决策，我们要把各个决策分散到项目过程中去。为此，我们需要确保有一个获取信息的通道。用户故事由此而生。
什么是用户故事？
每个用户故事代表了一个独立的功能，即用户在一个单一环境中可能做的事情。用户故事描述了对用户有价值的功能，由以下3方面组成：
- card：一份书面的故事描述，用来做计划和提升。
- conversation：有关故事的对话，用于具体化故事细节。
- confirmation：验收测试，用于表达故事细节，可用于确定故事何时完成。
card可能是用户故事最明显的表现，但它并不是最重要的。card代表用户需求而不是记录需求！需求细节要在conversation中获得，并在confirmation部分得以记录。
什么是验收测试？
验收测试用来验证实现的用户故事是否符合客户团队的期望。测试工作可以包括从故事卡背面写下测试描述开始，到编写自动化测试脚本的所有工作。测试应该尽早的在迭代中编写，早期编写测试用例非常有用，不仅澄清了他们的预期，也提醒了程序员可能会忘记的情形。
由于用户故事的重点从文档转移到对话，所以重要的决策不会写在文档里，因为很可能没有人阅读那些文档。取而代之的是，在自动化验收测试中捕获用户故事的重要方面，频繁执行验证。
第2章 编写故事
一个优秀的故事应该具备以下特点：
- 独立的：应该尽量避免相互依赖，否则不利于排期。
- 可讨论的：故事是可以讨论的，他不是签署好的合同或者软件必须实现的需求。故事卡的作用只是提醒我们要对此需求进行讨论，它并不是具体的需求本身，因此他们不需要包含所有的相关细节。
- 对用户有价值的：保证每个故事对用户有价值的最好方法是让客户来编写故事。
- 可估计的：让开发人员能估算故事的大小，至少能猜一下。
- 小的：涉及复杂故事的拆分和简单故事的合并。拆分：沿用一种简单的方法，即“创建”“删除”“修改”“查询”这些动作来分解故事。
- 可测试的：只要有可能，就要把测试自动化。当产品是增量开发的，很多东西变化很快，这时就需要自动化测试来帮助你尽早的发现这些问题。
第3章 用户角色建模
显然，我们不能从单一的角度编写故事，让那些故事放映所有这些用户的经历、背景和目标是不现实的。我们将使用以下步骤来识别、选择有用的用户角色集合。
- 通过头脑风暴，列出初始的用户角色集合：直到大家再也想不出新的角色，这样的脑暴一般不会超过15分钟。例如：对于一个“使用工作搜索功能”的用户，我们收集到以下的角色。
- 整理最初的角色集合：在桌子或者墙上移动卡片的位置，以表明角色之间的关系。
- 整合角色：在角色分组完成后，试着整合、拆分、删除一些角色。
- 提炼角色：通过给每个角色定义一些特征来建立角色的模型。任何可以区分角色的信息都可以用来做角色的特征，例如：
- 用户使用软件的频率
- 用户在相关领域的知识水平
- 用户使用计算机和软件的总体水平
- 用户对当前正在开发的软件的熟悉程度
- 用户使用该软件的总体目标。有些关注便捷、有些关注体验等等。
至此，我们的团队可能已经花费了1小时的时间，在考虑他们的用户，大部分的团队可以到此为止了。但是还有2个额外的技术值得探讨：
虚构人物：对于更为重要的用户，再进一步为角色创建一个虚构人物是很值得的。虚构人物是假想的用户角色代表。选择虚构人物前，应做好充分的市场和目标用户群调查，要确保需求人物能够真正代表产品的目标用户。
极端人物：你可以饶有兴趣的花几分钟去考虑一下教皇如何使用你的软件，这可能会带来一两个灵感。
第4章 搜集故事
我们经常有一种错觉：“需求本来已经存在了，我们只是让客户给我们解释需求，然后把他们锁入一个笼子里就可以了。”事实上，用户并不知道所有的需求。让我们像捕鱼一样去捕获需求：
- 首先，不同大小的网捕获不同大小的需求。第一遍，用大网眼捞一遍需求池，通过这些大需求，形成对软件的整体感觉。接下来，再用稍小一些的渔网捕获中等大小的需求。这里的大小，可以是软件商业价值高地或者必要性。
- 其次，需求会像鱼一样成长或死亡！需求的重要性和复杂度可能会变化。
- 最后，正如不可能补到所有的鱼一样，我们也不可能捕获到所有的需求。但是，熟练的需求分析人员知道去哪里寻找需求。
够用就行，不是吗？
辨别传统过程和敏捷过程最简单的方法之一，是看他们搜集需求的方式。传统过程的特征是它过分强调在项目早期正确地获取并写出所有的需求。而敏捷则承认没有一个理想的方法可以在一个单一阶段获取到所有的用户故事。敏捷承认用户故事有一个时间维度：随着时间的推移，一个故事的相关性会有所变化。
方法
因为故事会随着项目的进展而演变，所以我们需要一些可以反复使用的方法来搜集故事。这些方法必须足够轻量，可持续地，以下是创建故事最有用的一些方法：
- 用户访谈：想要捕获用户的本质需求，最重要的技巧是学会提问。提开放性的问题，不要让用户简单的回答是或者否。比如"为了让我们下一代产品运行在浏览器里，你愿意放弃什么？"就比“你们想在浏览器上运行新的程序吗？”好的多。
- 问卷调查：在需要得到大量用户关于某些具体问题答案时，问卷是非常有用的。然而，问卷不适合作为捕获新需求的主要方法。
- 观察：每次我看到有人使用我的软件，我都会获得很多提高用户体验或生产力的想法。不幸的是，这样的机会并不多，所以如果有机会广场用户使用软件的情况，千万不要错过。
- 故事编写工作坊：我认为，故事编写工作坊是快速捕获故事最有效的方法。至少，在开始每个计划发布前举办故事编写工作坊。良好的故事编写工作坊结合了头脑风暴的最佳要素和简单原型法：可以把一个简单原型画在纸上，并画出软件内部高层级的交互。然后，对使用软件过程中可能要做的事情进行头脑风暴。这里并不需要确定实际界面和字段，只是为了从概念上确定工作流。接下来以一个招聘网站为例说明这个问题：
- 首先，我们要决定从哪个用户角色开始。
- 然后，从一个空的方框开始。对角色要做的每一件事情，画一条线指向一个新的方框，然后写一个故事。这里我们建议采用深度优先的方式：对于第一个组建A，写下主要的细节，然后是于A组建有关的组建B，接着是于B有关的组建C，而不要回到组建A去寻找与其相关的B2组建。
- 最后，需要用每个角色来重复以上的过程。
通过以上原型，我们得到了以下的故事：
- 求职者可以发布他的简历
- 雇主可以发布工作
- 雇主可以查看提交的简历
- 求职者可以搜索工作
- 求职者可以看到适合搜索条件的工作
- 求职者可以看到指定工作的详细信息
在画原型的过程中，问一些问题会有助于我们找到遗漏的故事：
- 用户接下来最有可能做什么？
- 用户会在这里犯什么错误？
- 用户在这里会有什么困惑？
- 用户需要什么额外的信息？