编写一个优秀的用户故事

独立的（Independent）

尽量避免故事之间的依赖。因为在对故事排列优先级或者做计划的时候，故事之间的依赖会导致一些问题。

如“图片放大”与“图片缩小”有依赖，“放大”的优先级高于“缩小”的优先级，当客户团队选择了“放大”后，而不能缩小，就会有问题。

可讨论的（Negotiable）

故事是可以讨论的。它不是签署好的合同或者软件必须实现的需求。故事卡是功能的简短描述，细节将在客户团队和开发团队的讨论中产生。

如果在编写故事的时候已经知道一些重要细节，可以在故事卡上注释，但不能有太多注释和细节，这会导致一种错觉：故事卡反应了所有细节，没必要再讨论了。

故事卡包含信息：①一两句短语，用来提醒开发人员和客户进行对话；②一些注释，用以表明在对话中亟待解决的问题。

对用户或客户有价值

Valuable to Purchasers or Users

假设一个开发团队正在构建一个支持大量用户的软件，可能在公司5000台电脑上实施。

对开发有价值的故事：①所有的错误处理和记录赢在一些列公共类中完成。

以上关注技术和实现细节，并不能体现对客户或用户的价值，很难排列优先级。做如下转换会更好：

①所有的错误应以统一的方式呈现给用户并作记录。

保证每个故事对客户或用户有价值的最好方法是让客户来编写故事。

可估计的（Estimatable）

对开发人员来说，能估算故事大小，或者能把故事变为可用代码的时间量是很重要的。

一般有3个原因导致故事不可估计：

1.开发人员缺少领域知识。——可以和写故事的人一起讨论。

2.开发人员缺少技术知识。——可以实施极限编程中的探针实验。

3.故事太大了。——分解成更多的小故事。

小的（Small）

故事大小很关键，太大或太小都无助于制定计划。

对于太大的故事，进行分割。史诗故事通常分为两种：复合故事和复杂故事。

复合故事，由多个小故事组成，可以对较小的故事进行整合分解。

复杂故事，如果因为不确定性而复杂，可以分成两个故事，一个做调研的故事和一个开发故事。

对于太小的故事，可以进行合并。

可测试的（Testable）

故事必须是可测的，成功通过测试，说明开发人员正确的实现了故事。

通常不可测的故事发生在一些非功能性需求上，如：

①用户绝不需要花很长时间等待窗口出现。

可以改为：

在95%的情况下，新窗口会在2秒内打开。

来源 | 网络 侵删