1.2. 细节在哪里?

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

故事细节

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

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

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

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

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

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

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

史诗故事

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

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

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

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

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

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

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

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

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

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