产品学习篇：用户故事原则

用户故事的原则

一、INVEST原则

INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable。

Independent 独立的

Negotiable 可讨论的

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

Estimable 可估计的

Small 小的

Testable 可测试的

Ø Independent：独立性
用户故事之间应该具有独立性，不应该依赖于其他的用户故事。如果用户故事存在依赖性那么就会导致用户故事之间存在着不同的优先级，只有被依赖的用户故事完成才能继续开发依赖的用户故事。用户故事之间的依赖使得制定计划、确定优先级、工作量估算都变得很困难。一般可以通过组合用户故事或者分割用户故事来减少用户故事间的相互依赖性。

Ø Negotiable：可协商
用户故事不是签订的商业合同contracts，它是由客户或者PO同开发小组的成员共同协商制定的，如果最开始像商业合同一样设定了太多的条条框框和限制就无法更好的沟通及协商，也就不可能划分出既让客户满意，也能让开发认同的好的用户故事。

Ø Valuable：有价值
用户故事必须对于最终的用户是有价值的，因此应该站在用户的角度去编写，描述的是一个一个的feature，而非一个一个的task。

Ø Estimable：可评估
开发团队需要去估计一个用户故事以便确定优先级、工作量、安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。

Ø Small：短小
故事应该尽量的短小，当然也不是说越小越好。短小的故事可以减少划分过程中估算的误差，最好的故事是能够在一个迭代周期之内完成的。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。如果太大就应该考虑将其拆分为多个粒度更小的用户故事。

Ø Testable：可测试
个人认为这一点在所有的特性中对于用户故事的重要程度最高。

首先，如果一个用户故事无法进行测试，那么也就无法判断该故事是否完成。除此之外，对应的验收测试也最好是自动运行的，这样在任何时候都能触发该用户故事的检验。最后，必须在定义了验收测试通过的标准后才能认为故事划分完毕。

二、二八原则

根据帕累托原则也就是二八原则，一个迭代80%的价值可能来自于其中20%的用户故事。假如有两种故事拆分方式，当第一种拆分方式将低价值部分拆分成独立的故事，而另一种拆分方式没有做到时，就意味着后一种方式把浪费隐藏到了每个小故事里。此时，应当选择前一种拆分方式，这样可以把低价值的故事直接作废或推迟实现。

二八原则的验证方法是：在拆分后的一系列故事中，高价值、中价值、低价值的故事要一目了然，要能很明显找到一个实现它可以得到高价值或能降低大部分风险的故事。

三、故事适中原则

故事太大不好。故事太大，里面内容庞杂，头绪太多，可能导致无处下手或在一个迭代内无法完成。“小”这一特性要求我们拆分大的故事。但拆分故事时依然要遵循INVEST原则。

故事太小也不好。比如有的敏捷团队太过细分故事：对于数据库建一个故事、对于UI建一个故事等，这样虽可以满足“小”这一特性，但它却不是“独立的”和“有价值的”。

故事应该要多小呢?建议每个迭代6~10个故事，当然故事拆分的颗粒度取决于项目团队的生产效率。对很多团队来讲，当一个用户故事庞大到8个甚至13个故事点的时候就需要进行拆分了。

建议每个迭代内的用户故事的故事点数差别不宜太大，拆分后得到的故事最好规模差不多大。把一个8点的故事拆分成4个2点的故事比拆分成5点和3点的故事更有用，因为PO能更自由地编排优先级。

参考文章：点击打开