如何使用 INVEST 原则编写有效的用户故事？ - IT 观察者随笔

Table of Contents hide

一个好的用户故事除了要有规范的格式和完整的元素外，还应该遵循INVEST原则： 1.我依赖；2.面议；3 、有价值的；4.E估计；5 、 S商城；6.可测试。

1.独立——让一个用户故事尽可能独立于其他用户故事是很重要的。保持用户故事之间的独立性不仅有利于优先级和对齐，使发布和迭代计划更容易，有利于独立理解、跟踪、实施、测试和频繁交付，而且使用户故事大小估计的范围更清晰，从而估计偏差更小。

2.可协商——用户故事的内容是可协商的；用户故事不是合同。用户故事只是对用户故事的简短描述，没有太多细节；具体细节是在沟通阶段产生的。太多细节的用户故事实际上限制了用户、团队的想法和沟通。

3.有价值——每个故事都必须对客户有价值（无论是用户、买家还是公司内部角色）。用户故事对最终用户很有价值，因此应该从用户的角度来编写，描述功能而不是任务。

此功能有助于团队的开发和测试成员从传统的基于指令的工作方式转变为以自我驱动的价值导向的工作方式，让团队中的每个人都知道他们每天所做工作的价值。

4.可估计（可评估）——计划会议中一个非常重要的部分是对故事点的估计。它实际上是对要开发的用户故事的粗略估计，以便团队可以了解此用户故事的复杂性（工作量）。

重点是根据该用户故事的接收条件和团队定义的DoD（completion criteria）是否可以在当前迭代中完成该用户故事，如果不能完成，给出原因和PO决定是拆分还是重新设计用户故事。

使开发人员难以估计故事的问题来自：缺乏对领域的了解（在这种情况下需要更多的沟通），或者故事太大（在这种情况下需要将其切割成更小的部分）。

5.小——一个好的故事在工作量上应该尽可能短，最好不超过10个理想人/天，至少要保证一次迭代完成。用户故事越大，调度、工作量估计等方面的风险就越大。

6.可测试（ testable）——一个用户故事应该是可测试的，以确认它可以完成。如果用户故事不可测试，那么您无法知道它何时会完成。不可测试的用户故事的一个例子：软件应该易于使用。

当遵循 INVEST 原则时，用户故事基本上就是一个好的用户故事。然后我们关注三个指导方针，以帮助在制作用户故事时更好地遵守这些原则。

这三个准则是：一个用户、完整的价值和无依赖关系。

1.一种类型的用户——只包括一种类型的用户，因为多个用户通常有细微差别。它通常是一个典型的用户，通常有某种共同的需求。

2.完整的价值——完整地交付客户价值。一个完整的用户故事意味着当这个故事完成时，用户可以达到一个明确而有意义的目标。

3.非依赖——三种常见的依赖类型是：重叠、顺序和包含。

一般来说，要避免故事之间的重叠功能点；顺序关系是现实的，在大多数情况下可以通过某种方式解决；和包含关系对复杂系统很有帮助，对需要注意的调度发布和迭代计划有影响。

重叠依赖

重叠依赖是最容易引起麻烦的依赖形式，尤其是当多个用户故事包含多个不同的重叠部分时。很难找到一组用户故事来代表该最小可行产品的一组功能，它应该包含并且只包含一次需要的功能。

解决方案

将重叠部分剥离为单独的用户故事。
合理拆分用户故事并将重叠部分保留在最具凝聚力的用户故事之一中。
使用 Scrum 开发模型。

顺序依赖

顺序依赖意味着为了完成一个用户故事，必须在它之前完成一个或多个其他用户故事。顺序依赖通常是无害的，并且有一些方法可以减轻这种依赖。

从敏捷开发的角度来看，整个系统从最初的最小可行产品逐渐演变为强大的产品，随后的每一步都建立在之前的产品之上。

但从另一个角度来看，不必要的顺序依赖使得排序和优先级变得更加困难，进而影响发布和迭代计划的制定，也使得估计用户故事的规模变得更加困难。

解决方案

使迭代中的用户故事尽可能地摆脱内在依赖。
在迭代之间只保留单向依赖关系，从后期迭代中的故事到早期迭代中的故事在时间上只有单向依赖关系（前向依赖关系）。
将核心依赖项剥离为单独的故事，而不是在一个故事中混合依赖和非依赖的需求。

包含依赖项

包含依赖是指在组织用户故事时使用分层管理，例如常见的两级特征故事管理，其中一个特征包含多个用户故事，从而构成该特征对其下级故事的包含依赖。

解决方案

用户故事级别用于迭代规划，避免了粗粒度迭代规划与特性级别，可用于发布规划。

功能级别也可以拆分，直到达到最低可销售功能的级别，并且它包含的用户故事可以单独分组到新拆分的功能中。

遵循最小可行产品概念，在多个用户故事的多次迭代中实现一个功能，每个用户故事都可以产生潜在的可交付成果或提供内部或外部反馈。

参考