《敏捷软件开发：用户故事实战》—可协商的

可协商的

故事是可协商的，它们不是签署好的书面合同或者是软件必须实现的需求。故事卡是对功能的简短描述，其细节是在客户和开发团队之间的对话中协商产生的。因为故事卡本身并不是详细的需求，而是用来提示客户和开发团队进行对话的，所以它们不需要包括所有相关的细节。然而，在编写故事的时候，如果一些重要的细节是已知的，那么就应该把它们包括在故事卡的注释中，如故事卡2.1所示。挑战在于如何掌握包含“足够”的细节。

故事卡2.1  一个注释了额外细节的故事卡

故事卡 2.1是一个不错的故事卡，因为它提供了适量的信息供开发人员和客户讨论。当一个开发人员开始编码实现这个故事时，故事卡会提示她必须支持三种主卡（Visa信用卡、万事达信用卡和美国运通卡），同时她也可以询问客户是否已经决定接受美国发现卡。卡片上的注释可以帮助开发人员和客户恢复之前中断的对话。理想的情况下，不管是原来对话的开发人员和客户，还是其他的开发人员和客户，对话都应该能够恢复。把细节加入故事时，应该以此为指导原则。

另一方面，让我们思考一个带有太多注释的故事，如故事卡2.2所示。这个故事有太多的细节（“收集卡片的过期月份和日期”），还结合了一个单独的故事（“系统可以存储一个卡号供将来备用”）。

故事卡2.2  细节过多的故事卡

处理故事卡2.2这样的故事是非常困难的。大多数读者在阅读这种故事时，会错误地关注本不应该关注的细节。然而，在许多情况下，过早指定细节只会产生更多的工作。例如，如果两个开发人员讨论和估算一个简单的故事“公司可以用信用卡支付发布职位的费用”，开发人员知道他们的讨论有点抽象，他们不会误以为他们的讨论是明确的，或者他们的估算是准确的，因为缺少太多的细节。然而，如果向故事卡中添加更多类似故事卡2.2中的细节，关于这个故事的讨论就有可能变得更加具体和真实。但这可能会导致错误的判断：故事卡反映了所有的细节，没有必要再与客户进一步讨论这个故事了。

如果我们把故事卡看作是开发人员和客户进行对话的一种提示，那么故事卡中包含如下信息就是很有价值的。

l   用来提示保持开发人员和客户对话的一两句话。

l   在整个对话期间待解决问题的注释。

已经通过对话确定的细节将变成测试。如果使用纸质故事卡，我们可以在故事卡背面注明测试内容，如果使用电子系统，可以标注在合适的地方。故事卡2.3和故事卡2.4展示了故事卡2.2中的过多细节如何变成测试，用于提示对话的注释可以留存在故事卡正面。这样，故事卡的正面包含故事本身和关于相关问题的注释，而卡片的背面则包含用于验证故事是否像预期的那样，以测试形式体现的故事细节。

故事卡2.3  修正后的故事卡正面（只有故事和需要讨论的问题）