敏捷 INVEST — 用户故事的6个优秀指南

敏捷使用用户故事来表达产品或系统应解决的问题。敏捷 INVEST 指南是由比尔·韦克整理的一套建议，旨在帮助测试和创建高质量的用户故事（或更广泛地说，产品待办事项），以支持有效的敏捷项目管理.

根据敏捷 INVEST指南，高质量的用户故事应易于：

• 理解
• 实现
• 测试
• 向客户展示
• 保持独立

但让我们来分解一下，INVEST 这个缩写实际上代表什么。

敏捷 INVEST — 独立

这意味着该故事可以作为一个具有自身优先级的产品待办事项（PBI）独立存在，能够独立估算，并且不依赖于其他任何故事。

用户故事的分配优先级应是决定团队何时实施它的唯一因素。如果优先级较低，该故事在待办事项列表中的位置就靠后，实施时间也更晚；如果优先级较高，团队会将其提前到待办事项列表中以实现更快交付。当用户故事相互依赖时，是依赖关系而非优先级决定了团队实施它们的时间。

敏捷 INVEST — 可协商

一个好的用户故事应捕捉客户需求的本质。如果有疑问，团队会与客户讨论以确定该故事的正确价值。开发团队可以与产品负责人和利益相关者进行协商。这样，项目团队（供应商与客户）之间的协作能够创造出卓越的产品或服务。

敏捷团队难道因为所有内容都已记录在敏捷用户故事中而无需提问吗？那其实是业务分析师撰写了需求。

会有一些不可协商的事项（通常是非功能性需求），例如：

• 与用户账户相关的安全策略
• 性能要求，例如系统必须处理的并发用户数量

这没问题——只要功能本身的具体细节保持开放并鼓励讨论即可。

敏捷 INVEST — 有价值

根据敏捷原则，“有价值”意味着我们可以在冲刺评审会议中向客户展示所请求的功能或特性。

在拆分用户故事时，团队必须进行垂直拆分（也代表“V”），而不是水平拆分。这样可以在冲刺结束时交付完整功能，从而增加潜在可交付的产品增量。

团队可能更倾向于实现技术型待办事项，但它们并不总是能直接为客户带来价值——这违背了敏捷原则：通过尽早且持续交付有价值软件来满足客户。

敏捷 INVEST – 可估算

一个好的用户故事必须是可估算的。在敏捷开发中，估算是一种相对评估——与其他待办事项列表中的用户故事进行比较。常用的方法包括斐波那契数列，T恤尺码法（S、M、L 等），以及其他方法。

关于估算的讨论有助于整个团队就完成该故事所需的条件达成一致。有时一个故事无法估算，如果故事过大或在同一项中包含多个功能，这是正常的。在这种情况下，应将该故事拆分为多个较小的故事。在其他情况下，存在太多未知因素，需要进行研究。

敏捷 INVEST – 小型化

故事的完成时间应从几小时到最多一个完整冲刺周期。否则，会出现各种问题——例如速度（团队对交付点的责任感）、准确估算的困难等。

敏捷 INVEST – 可测试

在此语境下，“可测试”指的是在分析阶段定义的验收标准。

除非满足验收标准，否则我们不能认为一个用户故事“已完成”。我们唯一能确认其满足的方式是通过测试和验证。

验收标准不是测试用例。它们回答的问题是：“我如何知道我已经完成了这个用户故事？”

测试用例列出了测试功能所需的步骤。

客户可以告诉你测试环境是什么样子，以及团队认为用户故事达到何种测试条件时可视为完成.