第2章 编写故事

第2章 编写故事
独立的
尽量避免故事间的相互依赖。
可讨论的
故事是可以讨论的，它们不是签署好的合同或者软件必须实现的需求。故事卡是功能的简短描述，细节将在客户团队和开发团队的讨论中产生。难点在于掌握如何恰如其分地包括必要的细节。
如果我们把故事卡用于提醒开发人员和客户进行关于需求的讨论，那么故事卡应包含以下信息：
1.一两句短语，用来提醒开发人员和客户进行对话。
2.一些注释，用以表明在对话中亟待解决的问题。
如果是纸质卡片，则测试可以被标注在卡片背面。
对用户或客户有价值的
应当避免那些只对开发人员有价值的故事，例如：
所有的数据库连接要通过一个连接池。
所有的错误处理和记录应在一系列公共类中完成。
下面是这两个故事更好的版本：
这个应用软件，最多50位用户能使用一个6用户的数据库许可。
所有的错误应以统一的方式呈现给用户并做记录。
同样，应当避免在故事中出现用户界面和技术方面的定义。
可估计的
一般有以下3个原因会导致故事不可估计：
1.开发人员缺少领域知识：需要和写故事的人一起讨论，没必要理解故事的所有细节，但是至少需要对故事有个大概的了解。
2.开发人员缺少 技术知识：可以让一个或多个开发人员去实施极限编程（XP）中所谓的探针实验（spike）。探针实验本身需要限定一个最大时间量（称为时间箱，timebox），用这个作为探针实验的估计。如此，一个不可估的故事就变成了两个故事：一个快速的探针故事（用来获取足够的信息）和一个故事（真正实现功能）。一般而言，会将这两个故事顺次放到两个迭代中。
3.故事太大：分解成更小的故事。
小的
史诗故事通常分为以下两种：
复合故事（compound story）：由多个小的故事组成。
复杂故事（complex story）：本身就很大且不容易分解的故事。一般采用探针实验。
对于太小的故事，不值得去写故事和评估，则可以将其合并到需要半天或几天完成的故事中。比如缺陷报表和用户界面变更。
可测试的
通常，不可测试的故事发生在一些非功能性的需求上。
只要有可能，就要把测试自动化。这意味着我们要争取99%都自动化，而不是10%。
开发人员职责
1.负责帮助客户编写故事，这些故事要能提醒你们同客户交谈，而不是记录详细的需求定义，故事应该对用户或者客户有价值，它们是独立的、可测的、大小合适的。
2.如果被问及实现故事所用的技术或者基础架构信息，应该使用对用户或客户有价值的术语来描述。
客户团队职责
1.负责编写故事，这些故事要能提醒你们同开发人员交谈，而不是记录详细的需求定义，他们对用户或你们自己是有价值的，它们是独立的、可测的、大小合适的。