识别一个好的用户故事-INVEST原则

敏捷团队在落地产品精益需求管理时，常常会引入用户故事这个实践，大家对于用户故事的概念应该都容易理解，实际上作为需求的一种表达方式，通过一张卡片来承载用户需求。那么这么样才能拆分出一个好的用户故事，却不是轻易就能够做到的，为此，极限编程的倡导者Bill Wake提出了用户故事的INVEST原则，指导我们去拆分和写出一个好的用户故事。

哪我们就来了解下，到底什么是INVEST原则？INVEST实际上六个英文的首字母缩写：

Independent

Independent，独立的，是指拆分后的用户故事相对独立，能够一个一个的进行单独开发，不具有强偶合性。比如，我们在拆分以下一个关于电子记事本的功能时，团队考虑拆分的故事中包括编辑和删除两个功能，实际上着2个功能就可以拆分成2个独立的故事，分别进行开发。但是切记不可能将同一个业务功能，基于开发技术栈的不同拆分成前后端来实现，这就不是一个独立的故事，也违反了故事可测试的原则，也是我们尽量要避免的。

Negotiable

Negotiable，可协商的，故事并不不在一开始锁定太多细节，从故事卡所隐藏的背后含义我们也容易了解，一张卡片中是无法包含太多的细节内容的。所以这就要求在用户故事沟通的过程中，第一，用户故事符合远粗近细的原则，避免在一开始就引入太多的细节设计，使得相关人员误以为这个需求已经是非常明确的，不需要再展开讨论；第二，故事卡本身就是一个沟通的工具，希望借此工具我们能够及时、面对面的沟通，从而避免细节遗漏；还有一点，很多故事是随着对业务需求对场景的理解而不断深化的，所以在迭代开始前，我们后希望能够获取到更多的细节，将用户故事不断完善，最终开发的功能是客户真正想要的。

Valuable

Valuable，有价值的，必须是有价值的。这条原则在整个INVEST原则中是最重要的一条，故事必须有价值，否则我们为什么要做它呢？这一点其实通过20/80原则就能得到验证。不知道到大家有没有尝试统计过我们自己手机的APP，试着将每天都用到的APP数量比上所有APP数量，看看能够得到一个什么结论，你会发现：我们每天常用的功能，竟然不到20%！实际上对于某一款具体的APP来说，其中的软件功能可能已经超出了你的预期，就能我们常用的微信来说，大大小小上百个功能肯定是有的，而我们每天用的有几个？文字、语音、视频、朋友圈等等，远远达不到20%，所以很多功能对于我们来说其实是没有太大作用，甚至有可能直到你卸载微信或者被其他通信软件替代时，也有80%、甚至超过80%的功能你从来没用过。所以这也是我们为什么在承接用户需求、拆分用户故事的时候，一定要明确这个故事是由价值，我们做的无意义的功能太多了，对于各种资源来说都是一种浪费。

Estimable

Estimable，可估算的，故事是可以估算大小的。为什么要是可估算的呢？有两方面原因，一是可估算的故事有助于我们进行迭代计划排期，团队有多少资源，我们能做多少故事，有估算的故事便于我们内外部协调资源、计划排期；二是可估算的故事其实可以帮助我们进一步澄清需求、降低风险，通过对故事工作量的评估，清楚这个故事的范围、识别要做的事情。如果估算不了，很可能有两方面的问题：一故事颗粒度太大，无法估算，比如说，产品经理告诉你，我们需要做一个线上购物平台，这个什么概念，一个购物平台，很可能就是另一个京东、拼多多、淘宝，你无法评估需要投入资源去完成；第二点，无法估算可能是含有未知信息，不足以支撑进行估算，如果我们缺少有效的信息，不知道需求的业务背景、不知道采用什么技术栈，是不是也很难做出估算。所以通过估算也是以另外一种方式帮助我们完成风险识别。

Small

Small，颗粒度小的（也有翻译成 Size appropriate，大小适中的），实际上都同样的要求，大小颗粒度是合适，以便于在一个Sprint里能够完成。对于为期2周一个迭代来讲，小于3~5天的颗粒度是合适的，尽量不要超过5天。这一点也很容易理解，合适的颗粒度大小有助于我们做好迭代计划，进行开发过程的风险管控。试想，如果故事的颗粒度比较大，一个故事的大小工作量需要5、6天，甚至超过一周，那就意味着测试的工作很可能都被推迟到迭代第二周才能开始启动，一方面造成测试资源不匹配，第一周无事可做，第二周忙到起飞；另一方面也不能尽早的展开测试验证，风险未能及时暴露出来。甚至有的故事大小需要跨迭代才能完成，很显然这样的颗粒度大小就是不合适的，需要进一步评估。

Testable

Testable，可测试的，故事是可以进行测试的，否则无法确认故事是否已经达成预期。对于一个独立的故事，如果没有办法进行测试，则意味着开发人员也不知道到底要就该故事开发到什么程度，而测试人员更是无法入手。比如说在一个需求要求对系统性能进行优化，如何没有清晰的测试范围，这个故事是无法进行验收的，这时候我们就需要考虑定义需求的范围、细化验收标准，如页面加载提升到2s以内，这就是我们对性能优化的最终结果，是具有可测试性的。当然可测试是有多种手段的，并不是纯粹的手工测试、界面测试等。有些技术性的故事卡，对于测试人员来说，确实没有办法进行手工测试，但是这并不意味着这个故事不具备可测试性，或许我们需要借助于其他的测试手段。

综合以上信息，我们对于故事的INVEST原则有个初步的了解，当然大家不要误以为所有的事情都必须100%的满足INVEST才算是一个好的故事，实际上除了强调故事必须有价值以外，其他的几个原则都是可以权衡的，不能因为一个故事必须拆成独立的而花费了2天的时间去研究如何去拆，这实际上是得不偿失的，所以我们在落地过程中尽量把握一个度，没有那个原则一直都是100%正确的，要批判的去看，当外界条件变化时，我们要基于当时的情况给出合理的判断，并采取措施。

最后，希望大家都能写出好的用户故事，高效的完成需求的开发，交付出客户满意的产品。