2.2. 可讨论的

故事应该是可以讨论的

故事不是签署好的合同或软件必须要实现的需求。故事是功能的简短描述，细节在客户团队和开发团队的讨论中产生。因为故的作用是提醒客户团队和开发团队在以后要进行关于需求的对话，它并不是具体的需求本身，因而，他们不需要包含所有的相关细节。

如果，我们在编写故事的时候已经知道了一些重要的细节，那么应该在故事上以注释的形式记录这些细节。

一张提供有额外细节的故事卡

公司可以用信用卡支付发布工作信息的费用。

备注：接受Visa、万事达和运通卡，考虑支持发现卡。

这是一个非常好的故事，因为它提供了适量的信息给开发人员和客户团队进行交流。当一个开发人员开始编码和实现这个故事时，这张故事卡可以提醒他也能根据故事上的注释去询问客户团队是否已经做了决定。

理想情况下，不论对话的双方无论是开发人员还是客户人员是否与原来相同，这种对话一般都很容易继续进行。

把细节加入故事时，请参考上面这个故事卡。

细节太多的故事卡

公司可以用信用卡支付发布工作信息的费用。

备注：接受Visa、万事达和运通卡，考虑支持发现卡。
当支付金额超过100美元时，需要提供信用卡背面的ID号。
系统可以根据卡号的前两位数字识别客户使用的是何种类型的信用卡。
系统可以保存卡号以备用将来使用。
搜集信用卡的过期月份和日子。

这个故事有太多的细节（“搜集信用卡过期月份和日期”），同时也合并了本该成为单独故事的部分(“系统可以保存卡号以备将来使用”)

处理这个故事是很困难的。大部分人阅读到这种类型的故事时，会过多的关注本不应该关注的细节。在许多的案例中，过早的制定细节只会带来更多的工作量。

另外，这样的故事会更容易让人觉得确定和真实。这会导致一种错觉：这个故事反映了所有细节，没有必要跟用户进行下一步的讨论。

如果我们将故事永远提醒开发人员与客户团队进行关于需求的讨论，那么故事包含下面的信息就变的有意义了。

• 一两句短语，用于提醒开发人员和客户团队进行对话
• 一些注释，用以表明在对会中等待解决的问题

讨论中确定的细节将变成测试，这些测试可以留在故事中。

修正后的故事，只有故事和将要讨论的内容

公司可以用信用卡支付发布工作信息的费用。

备注： 我们将支持发现信用卡吗？
用户界面备注：不需要专门的字段来输入信用卡的类别卡片种类（可以从卡号的前两位数组获得该信息）。