4.2. 够用就行，不是吗？

辨别传统规范过程和敏捷过程最简单的方法之一，是看它们收集需求的方式。

传统规范过程的特征是它过分强调在项目早期正确的获取并写出所有的需求。与此不同的是，敏捷项目则承认没有一种理想的方法可以在一个单一阶段获取到所有的用户故事。

敏捷过程也承认用户故事有一个时间维度： 随着时间的推移以及先前迭代中加入产品的故事，一个故事的相关性(relevance)会有变化。

然而，即使我们承认无法为一个项目编写出所有的故事，我们还是应该在早期尝试编写我们可以编写的故事，即使许多故事还只能停留在十分笼统的阶段。

使用故事的好处之一就是可以用不同的详尽程度来编写。我们可以写下“用户可以搜索故事”这样的故事，无论是作为一个占位符，亦或此时我们只是了解到这个程度，这个故事都是恰当的(placeholder)。我们可以在今后将它演进为更小的、更有用的多个故事。

因此，对应用程序的大部分功能编写故事是非常容易的，其工作量少于用其他方法收集故事。

这并不是鼓励大家在开始一个新项目时花3个月时间来编写用户故事。相反，它要求大家展望未来的一个发布（大概3-6个月）的时间，故事发布的时间越往后，我们越不需要编写的那么详细。

例如，如果客户或用户说过他们“很可能在此次发布中想要报表功能”，那么简单的在一张卡片上写下“用户可以运行报表”。但是可以就此打住：先不用决定他们是否需要配置自己的报表，报表是否以HTML格式输出，或者是否可以保存报表。

在项目启动之前，对应用程序的大小有一个大致的了解是很重要的。通常在对项目拨款以及批准启动它之前，有必要粗略的了解一下项目的成本和它能够带来的效益。为了获知这些问题的答案，需要对项目包含的故事进行初步的深谋远虑。