1.2. 细节在哪里？

“用户可以搜索工作”，说起来容易，但仅以这句话为指南着手开发和测试确实另外一回事。

故事细节

那细节都在哪里？下面这些未解决的问题又该怎么办？

• 用户可以搜索哪些值？省份？城市？职位？关键字？
• 用户必须是网站的会员？
• 搜索参数可以保存吗？
• 要显示哪些与工作匹配的信息？

许多这样的细节可以用另外的用户故事来描述。

事实上，多个小故事远胜于一个庞大的故事。

例如，这个招聘网站大部分的功能可以描述成下面两个故事。

1. 用户可以搜索工作
2. 公司可以发布工作信息

但是这两个故事太庞大了，派不上用场。

史诗故事

如果一个故事很大，我们会称之为“史诗故事(Epic)”.

史诗故事可以分成多个小故事。

例如，“用户可以搜索工作”可以分为下面几个小故事。

• 用户可以通过地区、薪水范围、职位、公司名和发布日期之类的属性来搜索工作
• 用户可以查看搜索结果中每个工作的信息
• 用户可以查看发布工作的公司的详细信息

然而，我们不需要不断的分解故事，知道有一个故事能够覆盖每一个细节。

例如，“用户可以查看搜索结果中每个工作的信息”，就是一个比较合理且实际的故事。我们不需要在进行下一步的分解成更小的故事。

• 用户可以查看工作范围
• 用户可以查看薪水范围
• 用户可以查看工作地点

与其写下这些故事细节，还不如让开发团队和客户讨论这些细节，即在这些细节变得重要时才讨论。

讨论才是关键，而不是故事卡上的注释。

故事并不具有契约性质，达成的协议将由测试来记录，这些测试将演示故事是否被正确开发。