第 2 章 编写故事
优秀的故事的特点：（INVEST）
- 独立性（Independent）
- 可讨论的（Negotiable）
- 对用户或客户有价值的（Valuable to Purchasers or Users）
- 可估计的（Estimatable）
- 小的（Small）
- 可测试的（Testable）
一、独立的
我们要尽量避免故事间的相互依赖。
假如客户团队已经选择了一个高优先级的故事，但它对一个低优先级的故事有依赖，这就会出现问题。
出现这种依赖时，有两种方法可以绕过这种依赖。
- 将相互依赖的故事合并成一个大的、独立的故事。
- 用一个不同的方式去分隔故事。
二、可讨论的
故事是可讨论的。
故事卡是功能的简短描述，不需要包含所有的相关细节，细节将在客户团队和开发团队的讨论中产生。
若我们把故事卡用于提醒开发人员和客户进行关于需求的讨论，那么故事卡包含下面的信息就变得有意义。
- 一两句短语，用来提醒开发人员和客户进行对话。
- 一些注释，用以表明在对话中亟待解决的问题。
三、对用户或客户有价值的
应当避免那些只对开发人员有价值的故事。
应该避免在故事中出现用户界面和技术方面的定义。
保证每个故事对客户或用户有价值的最好方法是让客户来编写故事。
四、可估计的
故事不可估算的3个原因：
开发人员缺少领域知识。
开发人员缺少技术知识。
故事太大了。
如何解决：如果开发人员不理解故事，他们应该和写故事的客户一起讨论。
如果开发人员缺乏所涉及的技术，可以让一个或多个开发人员去实施极限编程（XP）中所谓的探针实验（spike）。这是一个简短的试验，用于研究应用程序的某一方面。一个不可估计的故事就变成了两个故事：一个快速的探针故事（用来获得足够的信息）和一个故事（真正实现功能）。
如果故事太大了，那么可以将大故事拆分为多个小故事。
五、小的
故事的大小很关键，故事太大或太小，都无助于制定计划。
分割故事
大的故事通常分为以下两种。
- 复合故事（compound story）
- 复杂故事（complex story）
复合故事是由多个小的故事组成的史诗故事。
复杂故事是其本身就很大且不容易分解的故事。如果一个故事因为不确定性而复杂，可以将它分为两个故事：一个做调研的故事和一个开发故事。
合并故事
有时候，故事太小了，显得微不足道。
在极限编程的团队中，一个比较好的方法通常是将其合并到需要半天或几天完成的故事中。
可测试的
故事必须是可测试的。成功通过测试可以证明开发人员正确地实现了故事。
当产品是增量开发的，很多东西变化得很快，昨天能工作的代码，今天就会出现问题。这时需要自动化测试来帮助你尽早发现这些问题。
小结
- 理想情况下，故事之间是独立的。故事之间的交付顺序应该是无关的，可以任意拿一个故事来实现。
- 故事细节由用户和开发人员讨论得出。
- 故事应该很清晰地体现对用户或客户的价值。最好的做法是让客户编写故事。
- 故事可以注释一些细节，但是过多的细节会使故事难以理解。
- 给故事加上注释的最好方法是给它编写测试用例。
- 如果故事太大，复合故事和复杂故事可以分成几个小的故事。
- 如果故事太小，几个小故事可以合并成一个较大的故事。
- 故事应该是可以测试的。
开发人员职责
- 帮助客户编写故事，这些故事要能提醒你们同客户交谈，不是记录详细的需求定义，故事应该对用户或者客户有价值，它们是独立的、可测的、大小合适的。
- 使用对用户或客户有价值的术语来描述实现故事所用的技术或者基础架构信息。
客户团队职责
负责编写故事，这些故事要能提醒你们同开发人员交谈，而不是记录详细的需求定义，他们对用户或你们自己是有价值的，他们是独立的、可测的、大小合适的。
