用户故事的INVEST原则

用户故事的INVEST原则

Independent 独立的

Negotiable 可讨论的

Valuable to Purchasers or Users 对客户或用户有价值的

Estimable 可估计的

Small 小的

Testable 可测试的

Independent 独立的

尽可能避免故事间的相互依赖，因为这会影响到故事优先级和开发计划的编排。

可以通过以下两种方式去解决互相依赖的故事：

1. 将相互依赖的故事合并成一个大的、独立的故事

2. 用另外一种方式去分割故事

如果以上两种方式都不合适，那么可以退而求其次，给这个有依赖的故事卡做两个估计；即当这个故事所依赖的故事没有完成时，有一个较高的任务点估计；当这个故事所依赖的故事已经完成时，有一个较低的任务点估计。

Negotiable 可讨论的

故事不是合同，它是功能的简短描述，其细节会在客户团队和开发团队的讨论中产生。如果在编写故事的时候已经明确了一些细节，可以把它们写在注释里。

故事卡的注释

可是过多的故事细节会给人一种“这个故事的细节已经很明确了，不需要再讨论了”的错觉。为了避免这种情况，注释需要简化，只用一两句短记录最好，并且主要用来记录需要解决的问题，用来提醒开发团队和客户团队进行讨论，如下图：

修正后的故事卡备注，只有待讨论的问题

Valuable to Purchasers or Users 对客户或用户有价值的

首先需要明确一点，客户是软件购买者，而用户是软件使用者，二者关注的价值是有差异的。

尽量避免只对开发人员有价值的故事，如“所有的错局处理和记录应该在一系列公共类中完成”，如果改为“所有的错误应以统一的方式呈现给用户并做记录”更好。

保证每个故事对客户或用户有价值的最好方法是让客户自己来编写故事，但是需要记住，这些由客户自己编写的故事不是用来甩锅的，而是用来提醒后续需要进行讨论的话题。

Estimable 可估计的

对于开发人员而言，故事是需要能够估算大小的，否则很难把它们安排到开发计划当中。一般会有如下三个原因导致任务不可估计：

1. 开发人员缺乏领域知识

2. 开发人员缺少技术知识

3. 故事太大了

如果缺乏领域知识，开发人员需要和写故事的客户一起讨论，至少对故事有个大概的了解

如果缺乏技术知识，可以去做一个极限编程（XP）中的探针试验（spike），开发人员不需要做深入的研究，只需要在限定的时间内大体了解相关技术知识，做到可以对任务卡进行评估即可。这种情况下可以把任务卡拆成两个任务，一个快速的探针试验故事（来获取足够的信息）和一个需求故事（真正实现功能）

如果故事太大了，那么需要对这个大故事进行进一步拆分，以便对故事进行更好的估计。当然如果这个故事当前的优先级不高，也可以先保留其作为一个史诗故事（epic）来占位，并且提供一个比较虚的大致估值，等到后期准备开始这个故事的时候再来进行拆分。

Small 小的

正如上文提到，过大的故事需要被拆分成更小的故事以便于估计工作量，而与此同时，如果故事太小，也无助于故事的评估。对于过大的故事，我们需要进行故事的拆分与分割，而过小的故事则需要进行合并。

 - 故事分割

史诗故事通常分为两种，复合故事（compound story）和复杂故事（complex story）。

复合故事通常由多个小故事组成，在分割的时候可以按照CRUD（创建，查阅，更新，删除）等动作来分割故事，另一种方式是根据数据边界来进行分割（如把更新个人简历分割为更新工作经历，更新专业能力，更新求职目标等小故事）

复杂故事不同于复合故事，其通常是一个很大且不容易分解的故事。如果一个复杂故事是因为不确定性而复杂，那么可以将其分解为两个故事，一个做调研的故事（例如上文提到的探针试验）和一个开发故事。需要注意的是，一般建议把调研故事和开发故事放在不同的迭代里，因为在调研故事完成之前很难估计开发故事的工作量，从而导致不确定性增加。

 - 故事合并

当故事太小时，对故事的估计工作可能花的时间比实施故事的时间还多，这时候可以考虑把多个小故事合并到一个故事集合中，并把这个故事集合当成一个正常的故事来处理。

Testable 可测试的

故事必须是可测试的。只有成功通过测试才能说明该故事已经被开发完成。

例如“用户绝不需要花很长时间来等到新窗口的打开”就是一个不可测试的故事，其中“绝不”，“很长时间”都是没有明确定义的词汇，为了让这个故事可测试，可以将其改写为“在95%的情况下，新窗口的打开时间不会超过2秒”。如果能够写一个自动化测试脚本来验证这个测试标准就更好了。