用户故事的INVEST

发布时间:2020-03-08

用户故事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 排序之后,会是怎样的场景?这里看一下用户故事的冰山模型。

1.jpg

用户故事冰山模型

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

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

T——Testable,可测试的

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

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

1、客观性。所谓客观性,从某个测试结果可以得到唯一的结论,即测试通过或者不通过,不存在不同人、不同时间用测试结果可以得到不同的结论;

2、可重复性。即这种测试不是一过性的,可以重复验证与测试的。

好的用户故事

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


Copyright © 2020 All Rights Reseverd Designed by 5thspace.net      备案号:沪ICP备15017019号-1