阅读用户故事与敏捷开发的后边几章，搜集故事这一章，我们经常有一种错觉：“需求本来已经存在了，我们只是让客户给我们解释需求，然后把他们锁入一个笼子里就可以了。”事实上，用户并不知道所有的需求。让我们像捕鱼一样去捕获需求：
首先，不同大小的网捕获不同大小的需求。第一遍，用大网眼捞一遍需求池，通过这些大需求，形成对软件的整体感觉。接下来，再用稍小一些的渔网捕获中等大小的需求。这里的大小，可以是软件商业价值高地或者必要性。
其次，需求会像鱼一样成长或死亡！需求的重要性和复杂度可能会变化。
最后，正如不可能补到所有的鱼一样，我们也不可能捕获到所有的需求。但是，熟练的需求分析人员知道去哪里寻找需求。
辨别传统过程和敏捷过程最简单的方法之一，是看他们搜集需求的方式。传统过程的特征是它过分强调在项目早期正确地获取并写出所有的需求。而敏捷则承认没有一个理想的方法可以在一个单一阶段获取到所有的用户故事。敏捷承认用户故事有一个时间维度：随着时间的推移，一个故事的相关性会有所变化。
方法
因为故事会随着项目的进展而演变，所以我们需要一些可以反复使用的方法来搜集故事。这些方法必须足够轻量，可持续地，以下是创建故事最有用的一些方法：
- 用户访谈：想要捕获用户的本质需求，最重要的技巧是学会提问。提开放性的问题，不要让用户简单的回答是或者否。比如"为了让我们下一代产品运行在浏览器里，你愿意放弃什么？"就比“你们想在浏览器上运行新的程序吗？”好的多。
- 问卷调查：在需要得到大量用户关于某些具体问题答案时，问卷是非常有用的。然而，问卷不适合作为捕获新需求的主要方法。
- 观察：每次我看到有人使用我的软件，我都会获得很多提高用户体验或生产力的想法。不幸的是，这样的机会并不多，所以如果有机会广场用户使用软件的情况，千万不要错过。
- 故事编写工作坊：我认为，故事编写工作坊是快速捕获故事最有效的方法。至少，在开始每个计划发布前举办故事编写工作坊。良好的故事编写工作坊结合了头脑风暴的最佳要素和简单原型法：可以把一个简单原型画在纸上，并画出软件内部高层级的交互。然后，对使用软件过程中可能要做的事情进行头脑风暴。这里并不需要确定实际界面和字段，只是为了从概念上确定工作流。