《用户故事与敏捷方法》读书笔记 02 细节是什么

说“用户可以搜索岗位”是一回事，能够开始编码并作为测试的指导又是一回事。细节是什么？关于以下没有答案的问题又怎么办：

• 用户可以用什么进行搜索？州？城市？岗位名？关键词？
• 用户必须注册网站吗？
• 搜索参数可以保留吗？
• 匹配的岗位会展示什么信息？

这些细节可以表示为额外的故事。实际上，更多的故事比太大的故事更好。例如，整个BigMoneyJobs网站可以用以下两个故事形容：

• 用户可以搜索岗位
• 公司可以发布岗位

很明显，这俩个故事太大了以至于没有太大作用。第二章，“写故事”完全解决故事大小的问题，但是作为开始，故事能被一个或一组编程者在半天或两周编码并测试是比较好的。

当故事太大时可以分为两个或多个更小的故事。例如，“用户可以搜索岗位”可以分成这些故事：

• 用户可以通过地点、薪资水平、工作名、公司名以及发布时间这些属性来搜索岗位；
• 用户可以浏览搜索匹配的岗位的信息；
• 用户可以查看已发布岗位的公司的详情。

我们直到有了故事的最后的细节才会停止分解故事。例如，“用户可以查看每个搜索匹配岗位的信息”是一个非常合理并现实的故事。我们不需要进一步分解成：

• 用户可以查看岗位描述；
• 用户可以看每个岗位的薪资水平；
• 用户可以查看岗位的地点。

对比将这些细节都写成故事，有更好的对于开发团队和客户去讨论这些细节的方法。那就是，当细节变得重要的时候讨论这些细节。基于讨论对故事卡片做一些注释没毛病。例如：

用户可以通过地点、薪资水平、工作名、公司名以及发布时间这些属性来搜索岗位。

（note）Marco说展示描述、薪水和地点

但是，对话是关键，而不是故事卡片上的笔记。开发者和客户不可能在三个月后指着卡片说“瞧，我说的多对。”故事并不是合约的义务。我们会发现，协议是通过测试记录下的，这些测试证明故事被准确开发出来了。