第二章 编写故事
优秀故事的六大特性：
# 独立的
# 可讨论的
# 对用户或客户有价值的
# 可估计的
# 小的
# 可测试的

独立的（Independent）：
避免故事与故事之间相互依赖，比如一个较高优先级的故事对一个较低优先级的故事有依赖，就会出现问题。（对于互补情况，算不算是一种故事之间的相互依赖，比如开优先级较高的“放大”功能，与其形成互补的“缩小”功能，这两种算不算一种故事依赖？如何处理相互依赖的故事？）
对于相互依赖的故事，有两种方法进行处理：
#将相互依赖的故事合并成一个大的、独立的故事（对于“放大”、“缩小”功能的实现，个人想法可以将其合并成一个大的故事，例如“缩放功能”）
#用一个不同的方式去分割故事
如果你不想合并两个故事并且找不到很好的方法对其进行分割的时候，还可以使用一个简单的方法，在故事卡上加上两个估计：当该故事将早于另一个故事实现时，一个较高的估计；当该故事将晚于另一个故事实现时，一个较低的估计。（？？？不是特别理解？？？）

可讨论的（Negotiable）：
故事卡仅仅是对软件功能很简短的描述，具体细节还是由客户团队和开发团队讨论产生。同时故事卡的作用在于提醒客户团队和开发人员在以后要进行关于需求的对话。（细节不应该太多太具体，见书P17信用卡的例子）

对用户或客户有价值的（Valuable to Purchasers or Users）：
注意区分客户和用户的差异（客户是购买软件的人，用户是使用软件的人），对客户有价值的故事不一定对用户有价值。
保证故事对用户或客户有价值的最好办法就是由客户来编写故事。

可估计的（Estimatable）：
对于开发人员来讲，能估算故事的大小，或者将故事变为可用代码的时间量是很重要的。一般有三个原因会导致故事不可估计：1.开发人员缺少领域知识 2.开发人员缺少技术知识 3.故事太大

小的（Small）：
故事的大小很关键，故事太大或太小都不利于制定计划。
#分割故事
史诗故事：1.复合故事（由多个小故事组成的） 2.复杂故事
##分解复合史诗故事可以有不同的方法（见书P21求职者发布简历的例子）
##复杂故事属于本身就很庞大且不易分割的故事。如果因为不确定性而复杂，可以将它分成两个故事：一个做调研的故事（进行探针实验）和一个开发的故事（见书P22信用卡支付的例子）并将这两个故事放在不同的迭代中
#合并故事
对于太小的故事，开发人员会不想写下它或者对它进行估计（如缺陷报表和用户界面变更），对于这样的故事，一般会将其合并到需要半天或者几天完成的故事中。（见书P23例）

可测试的（Testable）：
故事必须是可测试的。成功的通过了测试证明开发人员正确的实现了故事。当然，也会有不可测试的故事，这些故事一般发生在一些非功能需求上，这些与软件有关但是与软件的功能无关（见书P23不可测试故事例子）。作为开发人员，无论什么时候，只要有可能就需要把测试自动化。实际情况中，总有小部分的测试是不能进行自动化测试的（如：一个新用户不经过培训就能完成一般的工作流程）。

小结：
#故事之间相互独立，故事的交付顺序应该是无关的，这种情况很难实现，但是我们需要尽量做到。
#故事细节需要由客户和开发人员讨论得出
#故事应很好的体现对客户的价值，最好的办法是由客户编写故事
#故事可以加一些注解，但是过多的细节会使故事难以理解，也可能给开发人员和客户无需交谈的错觉
#给故事加注解的最好的方法是给它编写测试用例
#如果故事太大，可以将复合故事与复杂故事进行分解
#如果故事太小，可以将几个小故事合并成一个大故事
#故事应该是可测试的

问题：
1.以下故事中，哪些是好故事，哪些是不好的故事。如果是不好的故事请说明理由。
a.用户能快速掌握系统。
b.用户可以修改简历上的地址。
c.用户可以增加、修改和删除多份简历
d.系统可以计算n元二次型方程分布的鞍点近似值
e.运行时错误都用同样的方法记录
#b是一个好故事，其他的都是不好的故事。a是不可讨论的，用户能否快速掌握系统与开发无关；c故事不够小，可以进一步进行分解；d故事是不可估计的；e故事对用户或客户是无价值的
a故事中，“快速”、“掌握”没有定义，这不是一个好故事；b故事可能太小了，实际上取决于开发人员实现它需要花多长时间；c故事不够小，可以进一步分解更小的故事；d故事如果是客户写的，那么她可能知道这是什么意思。但是，如果开发人员不理解这个故事，客户应该重新考虑这个故事，起码开发人员应该可以对他进行一个估计；e故事没有问题

2.将这句史诗故事分解为大小合适的故事：“用户可以设置、更改职位自动搜索的工具”
#“用户可以设置职位自动搜索的工具”、“用户可以更改职位自动搜索的工具”
还有许多其他不同的分解方式