为了构造好的故事，我们关注六个特征。一个优秀的故事应该具备以下六个特点：
• 独立的（Independent)
• 可讨论的（Negotiable）
• 对用户或客户有价值的（Valuable to Purchasers or Users)
• 可估计的（ stimatable)
• 小的（Small）
• 可测试的 （Testable)
如何编写用户故事？
1、独立的
所谓独立，就是我们在编写故事的时候，要尽量避免故事间的相互依赖。在对故事排列优先级时，或者使用故事做计划时，故事间的相互依赖会导致一些问题：故事实现时间估算，优先级排序等等。
当用户故事之间出现这种依赖时，有两种方法可以绕过这种依赖：
（1）将相互依赖的故事合并成一个大的、独立的故事。
（2）用一个不同的方式去分割故事。
2、可讨论的
故事是可以讨论的。
用户故事不是签署好的合同或者软件必须实现的需求。故事卡是功能的简短描述，细节将在客户团队和开发团队的讨论中产生。故事卡只是用于提醒开发人员和客户进行必要的讨论。
若我们把故事卡用于提醒开发人员和客户进行关于需求的讨论，那么故事卡包含下面的信息就变得有意义。
（1）一两句短语，用来提醒开发人员和客户进行对话。
（2）一些注释，用以表明在对话中亟待解决的问题。
3、对用户或客户有价值的
“每个故事必须对用户有价值”，这话说起来很诱人，但那是不对的。在许多项目中包含对用户没有意义的故事。要记住用户（软件的使用者）和客户（购买软件的人）之间的区别：因为很多用户故事显示客户在购买时要考虑的价值有时候却不是用户所需要考虑的。
保证每个故事对客户或用户有价值的最好方法是让客户米编写故事。开始时客户般都会感觉不舒服，可能因为开发人员以前总是令他们觉得他们写下来的任何东西都有可能成为未来对他们不利的证据 （“好吧，需求文档并没有这样说… ”）故事卡只是提醒他们需要之后进行需求讨论，而不是 个正式的承诺或某个功能的具体描述。
4、可估计的
对开发人员来说，能估算故事的大小（至少猜一下），或者是把故事变为可用代码的时间量是很重要的。 一般有以3个原因会导致故事不可估计：
（1）开发入员缺少领域知识
（2） 开发人员缺少技术知识
（3）故事太大了
5、小的
故事的大小很关键，故事太大或太小，都无助子制订计划。使用史诗故事来开展工作会很困难，因为它们通常包含多个故事。史诗故事通常分为以下两种：
• 复合故事（compound story）：复合故事是由多个小的故事组成的史诗故事。
• 复杂故事（complex story)：复杂故事是其本身就很大且不容易分解的故事。
针对符合故事，简单的方式就是分割故事。复杂故事是其本身就很大且不容易分解的故事。如果一个故事因为不确定性而复杂，可以将它分成两个故事 一个做调研的故事和一个开发故事。所谓调研就是研究其可行性作为一个用户故事，所谓开发故事就是一般功能开发故事，但最好两个故事不要放在一个版本中同时进行。
有时候，故事太小了。对于太小的故事，开发人员会说她不想写下这个故事或者对它进行估计，因为那么做可能比实施该故事花的时间更长。那最直接的办法就是合并故事。
6、可测试的
故事必须是可测试的。成功通过测试可以证明开发入员正确地实现了故事。如果故事不能被测试， 开发人员怎么知道他们什么时候才算是完成了代码？
通常，不可测试的故事发生在一些非功能性的需求 ，这些需求和软件有关，但不直接与功能有关。比如软件的易用性，性能，数据库设计的合理性，开发框架的选型等等。
小结
（1）理想情况下，故事之间是独立的。有时很难做到这 点，但我们要尽量实现这一目标。故事之 间的交付顺序应该是无关的，可以任意拿一个故事来实现。
（2）故事细节由用户和开发人员共同讨论得出。
（3）故事应该很清晰地体现对用户或客户的价值。最好的做法是让客户编写故事。
（4）故事可以注释一些细节，但是过多的细节会使故事难以理解，也可能给人一种开发人员和客 户无需交谈的错觉。
（5）给故事加上注释的最好方法是给它编写测试用例。
（6）如果故事太大，复合故事和复杂故事可以分成几个小的故事。
（7）如果故事太小，几个小故事可以合并成一个较大的故事。
（8） 故事应该是可以测试的。
问题
2.1 以下故事中，哪些故事是好的故事，哪些是不好的故事。如果不是好故事说明理由？
a. 用户能快速掌握系统
b. 用户可以修改简 上的地址
c. 用户可以增加、修改和删除多份简历
d. 系统可以计算 型方程分布的鞍点近似值。
e. 行时错误都用同样的方法记录。
2.2 将这句史诗故事分解为大小合适的故事 “用户可以设置、更改职位自动搜索工具。
对于本书的电子版（PDF），可以通过链接：用户故事与敏捷开发.pdf获取，提取码：zmiz。谢谢
网友评论