用户故事的INVEST

用户故事INVEST原则，本质上是用来形容“好的用户故事”，而不是“用户故事”，这点请一定要谨记，因此不用怀疑，如果不满足INVEST也可以是用户故事。

下面简单介绍一下各个部分。有一些很好懂我就快速掠过，有一些比较有争议我也会努力讲出我自己的理解。

I——Independent，独立的

这点算是INVEST中最难懂，且最有可能出错的部分。同时也是PO或者研发觉得最困难的一个部分。

所谓独立性，说的是各个用户故事之间不存在依赖性。原先我们对独立性的理解是，在实现功能先后上不能有依赖性，即A的实现不依赖于B，这样子我们就可以更好的根据价值来进行优先级排序。

但是实际工作中，我们遇到过这种需求。看起来是独立的，但实际上依赖性很重。

假设我们有一个Epic，要求我们支持信用卡支付。信用卡包括Visa、MasterCard和银联。

我们根据习惯将这个Epic拆分为支持Visa、MasterCard和银联。

此时三个用户故事是否有依赖？

从功能角度来看没有，但估算用户故事大小的时候，就有非常明显的影响。支付底层逻辑是三个用户故事共同依赖的，无论你优先完成哪个需求，你都需要完成底层逻辑。因此就会出现，第一个完成的用户故事（假设为A），一定会比另外两个故事增加了一些底层逻辑实现的功能。但如果你说先实现用户故事B，那么这部分底层逻辑功能就需要加到B上面去。

这种情况下，拆分出来的用户故事是有依赖性的。

因此，我们对依赖性的定义就要包含两方面：

1. 功能实现之间没有依赖性，即任意顺序实现用户故事都可以，不用可以考虑技术底层；
2. 功能之间不要出现共同依赖的底层逻辑，这会让底层逻辑必然在某个拆分的用户故事中实现，这对用户故事的尺寸估算带来一定的麻烦，这也是一定意义上的依赖性。

那针对上面的示例，我们怎么做比较合适呢？这里给出一个我个人常用的方法，我一般称其为“模糊细节”。针对于信用卡支付的用户故事，我们拆分成下面的两个，或者三个用户故事，这里以两个为例。为了简化，不再严格按照用户故事模板。

1. 优先支持一种支付方式

2. 再支持另外两种支付方式

通过这种方式，我们将用户故事主体中关于信用卡类型的部分隐藏掉，不会过早的将细节暴露，方便优先级排序与工作量估算，然后借助验收标准来完善用户故事（在正式开发之前完善结束），再进入正式的开发阶段即可。

N——Negotiable，可协商的

可协商体现在需求实现程度可协商。

以登录功能为例，假设有这么一个用户故事。

作为商家，我需要可以登录我的后台。

这里的登录到底是什么意思？用户名密码？手机验证码？OpenID？扫码登陆？还是其他？

都有可能，这一切并没有在我们写下上面的用户故事的时候就确定了，而是需要PO 与研发团队共同协商后得出结论。可能我们当前只需要实现用户名密码，但是下一个迭代中，我们需要支持微信扫码登陆。

当时这里请注意，Negotiable仅仅是可协商，并不代表PO 一定要接受研发的意见。毕竟PO 才是最终决定用户故事的人。

V——Valuable，有价值的

这个不用谈了，只需要严格按照用户故事模板来写，必然是有价值的，否则在编写阶段就已经被拍死了。

这里有一点要注意：在编写用户故事的时候，一般我们都会紧紧抓住价值，但是在对用户故事进行解聚（Split）时，可能会发生根据模块（Module）而不是功能（Feature）来进行拆分。

E——Estimable，可估算的

所谓可估算的，背后的逻辑是：编写用户故事的人，应具备该用户故事的行业背景。

研发团队是自组织团队，他们负责对用户故事进行估算、拆分、完成等工作。其工作输入主要是来自于PO 与客户/用户，因此作为输入方的PO 是否靠谱就成了最后自组织团队输出是否靠谱的重要判断标准之一。因此，如果PO 自身都不掌握该用户故事的行业背景与知识，我们又怎能相信PO 可以为研发做澄清工作，并让研发通过自组织团队的方式完成交付呢？

举例来说就是，你让一个做电商的PO ，从淘宝去有赞，这个问题不太大。毕竟都是相同行业，模式有差别而已，稍微学习学习还能搞定。但是你是否敢让一个电商PO 去商飞做C919的PO？或者说，如果C919的PO 是淘宝网的PO，这种飞机你还敢不敢坐？

当然，上面的例子比较极端，但放到不同领域或者垂直领域都是适用的。

具备行业知识是写出好的用户故事基础条件之一。

S——Small/Size Appropriate，小的/大小适当的

这个S是当前争议比较多的。

传统的INVEST中，对S的解释就是Small，即认为只有小的用户故事才是好的用户故事，来源见此。

之所以认为小的用户故事是好的用户故事，有以下几个原因：

1. 小的用户故事可以放入短迭代中完成；
2. 小的用户故事更容易被研发所理解，帮助更好的开发；
3. 小的用户故事更容易被估算

如果我们将用户故事放在“即将开发”的用户故事中的话，Small 是毫无疑问非常正确的。

但是，如果我们将用户故事当作Product Backlog的组成元素的话，那么Small可能就不那么合适。

我们考虑一下PBL 排序之后，会是怎样的场景？这里看一下用户故事的冰山模型。

如果我们针对的用户故事是在冰山底层的用户故事，鉴于其优先级较低，我们也不需要在一开始就将这些用户故事细化与拆分，因此这类用户故事不可能是Small的，只能是Size Appropriate。

所以综合来看，我个人是比较接受Size Appropriate这种说法。这种说法可以包含Small的场景，也考虑那些不需要很早就拆分的、较大的用户故事。

T——Testable，可测试的

可测试的重要性毋庸多言，这是用户故事验收标准的重要组成部分之一。

在我的经验中，可测试至少要包含两个要素：

1. 客观性。所谓客观性，从某个测试结果可以得到唯一的结论，即测试通过或者不通过，不存在不同人、不同时间的测试结果可以得到不同的结论；
2. 可重复性。即这种测试不是一过性的，可以重复验证与测试的。

好的用户故事

好的用户故事是帮助我们实现敏捷的重要的一步。如何写好用户故事是个技术活，没有太多的捷径。只能通过不断的训练才可以将用户故事写好，而INVEST 就是我们在练习写好的用户故事过程中，重要的尺子。不断的利用这项工具，对自己的用户故事进行反复的改写与练习，才能最终得心应手的写好用户故事。