《敏捷软件开发：用户故事实战》—细节在哪里？

细节在哪里？

说明“用户可以搜索工作”是一件事，把它作为指导用来开始编码和测试是另外一件事。细节在哪里？ 需要解答的问题可能如下。

l   用户可以搜索哪些值？州？城市？工作职位？关键字？

l   用户必须是网站的注册会员吗？

l   可以保存搜索参数吗？

l   匹配的工作要显示哪些信息？

这些细节可以用额外的故事来表达。事实上，更多的小故事要优于庞大的故事。例如，整个BigMoneyJobs网站可以描述成这两个故事。

l   用户可以搜索工作。

l   公司可以发布空缺职位。

很明显，这两个故事太大了，用处不大。第2章能够完全解决故事大小的问题。一个出发点是，好的故事可以在一天半到两周的时间里由一个或者两个程序员进行编码和测试实现。而前面的两个故事可以很容易地覆盖BigMoneyJobs网站的大部分功能，所以大多数程序员可能会花上一周多的时间。

当一个故事太大时，可以称为“史诗”。史诗可以拆分为两个或者更多个较小的故事。例如，史诗“用户可以搜索工作”可以拆分成以下几个故事。

l   用户可以通过诸如工作地点、薪资范围、职位名称、公司名称和工作发布日期等字段来搜索工作。

l   用户可以查看搜索到的相匹配的每个工作的信息。

l   用户可以查看已经发布的工作所属公司的详细信息。

然而，直到有了一个包括所有最终细节的故事，才不会继续拆分故事。例如，“用户可以查看搜索到的相匹配的每个工作的信息。”就是一个非常合理和真实的故事。

不需要进一步将其拆分为下面几项。

l   用户可以查看工作描述。

l   用户可以查看工作的薪资范围。

l   用户可以查看工作的地点。

与此类似，在典型的需求文档中不需要增加这种样式的用户故事。

4.6  用户可以查看搜索到的相匹配的每个工作的信息。

4.6.1  用户可以查看工作描述。

4.6.2  用户可以查看工作的薪资范围。

4.6.3  用户可以查看工作的地点。

与其将所有这些细节描述为故事，不如让开发团队和客户讨论这些细节。也就是说，在细节变得重要的时候，再对细节进行讨论。在一个基于对话的故事卡上做一些注释是没有错的，如故事卡1.2中所示。然而，相对故事卡上的注释，对话才是关键。三个月之后，开发人员和客户都不能指着卡片说：“但是，看，我说的就在这里。”故事不是合同义务。正如所看到的，记录的达成一致的内容通过了测试，这表明一个故事已经正确开发好。

故事卡1.2  带有注释的故事卡