1.2. 细节在哪里？
“用户可以搜索工作”，说起来容易，但仅以这句话为指南着手开发和测试确实另外一回事。
故事细节
那细节都在哪里？下面这些未解决的问题又该怎么办？
- 用户可以搜索哪些值？省份？城市？职位？关键字？
- 用户必须是网站的会员？
- 搜索参数可以保存吗？
- 要显示哪些与工作匹配的信息？
许多这样的细节可以用另外的用户故事来描述。
事实上，多个小故事远胜于一个庞大的故事。
例如，这个招聘网站大部分的功能可以描述成下面两个故事。
- 用户可以搜索工作
- 公司可以发布工作信息
但是这两个故事太庞大了，派不上用场。
史诗故事
如果一个故事很大，我们会称之为“史诗故事(
Epic)”.
史诗故事可以分成多个小故事。
例如，“用户可以搜索工作”可以分为下面几个小故事。
- 用户可以通过地区、薪水范围、职位、公司名和发布日期之类的属性来搜索工作
- 用户可以查看搜索结果中每个工作的信息
- 用户可以查看发布工作的公司的详细信息
然而，我们不需要不断的分解故事，知道有一个故事能够覆盖每一个细节。
例如，“用户可以查看搜索结果中每个工作的信息”，就是一个比较合理且实际的故事。我们不需要在进行下一步的分解成更小的故事。
- 用户可以查看工作范围
- 用户可以查看薪水范围
- 用户可以查看工作地点
与其写下这些故事细节，还不如让开发团队和客户讨论这些细节，即在这些细节变得重要时才讨论。
讨论才是关键，而不是故事卡上的注释。
故事并不具有契约性质，达成的协议将由测试来记录，这些测试将演示故事是否被正确开发。