敏捷投 INVEST – 6 个很棒的用户故事指引

敏捷投 INVEST – 6 个很棒的用户故事指引

敏捷 使用用户故事来表达产品或系统应该解决的问题。Agile INVEST 指南是 Bill Wake 汇总的一组建议，用于测试可以帮助您进行敏捷项目管理的优质用户故事（或更一般的产品待办列表项）  。

根据 Agile INVEST 指南，高质量的用户故事很容易：

• 理解
• 实施
• 测试
• 向客户展示 – 演示
• 独立的

但是让我们看看 INVEST 中的首字母缩略词是什么意思。

敏捷投资 – 独立 (Independent)

这意味着它可以作为 PBI（产品待办事项项）按其优先级存在，独立评估，并且不依赖于任何其他故事。

分配的用户故事优先级应该是决定团队何时实施故事的唯一因素。如果它的优先级较低，用户故事在 backlog 中的位置较低，因此稍后实施；如果优先级较高，团队会将其在 backlog 中上移，以便更快地实施。如果用户故事相互依赖，那么依赖关系将决定团队何时实施用户故事，而不是优先级。

敏捷投资 – 可协商 (Negotiable)

一个好的用户故事能够捕捉到客户需求的本质。如果有问题，团队会与客户讨论以确定这个故事的正确价值，开发团队可以与产品所有者和利益相关者协商。通过这种方式，项目团队（供应商和客户团队）之间的协作可以相互联系，以创造出色的产品/服务。

敏捷团队没有什么可问的，敏捷用户故事中记录了所有内容？然后业务分析师编写需求。

会有一些不可转让的物品（通常是非功能性的），比如

– 与用户帐户相关的安全策略

– 性能要求，例如系统必须处理的并发用户数。

这很好，只要功能本身的细节是开放式的，邀请对话。

敏捷投资 – 有价值的 (Valuable)

通过引用敏捷原则，有价值的意思是我们可以展示客户在 sprint 审查会议上要求的功能或内容。

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

团队实施技术 PBI 总是更有趣，但是，它们并不总是为客户带来直接价值，这与敏捷原则之一相矛盾，  即 通过早期和持续交付有价值的软件来满足 客户.

敏捷投资 – 可估量 (Estimable)

一个良好的用户故事必须是可估量的。在敏捷中，估计是相对的；相对于待办事项中的其余用户故事。各种方法都很流行：斐波那契数列、T 恤尺寸（小、中、大）等。

这种围绕估算的讨论使整个团队对完成用户故事所需的条件达成共识。有时，故事不可估量，这是正常的，因为故事太大或在同一个故事中有多个特征。在这里，我们应该将故事拆分为多个故事。在其他情况下，故事有太多需要研究的未知数。

敏捷投资 – 小 (Small)

故事应该需要几个小时才能达到最大冲刺长度。否则会出现不同的问题，例如速度（团队如何对交付点负责），估计很难准确等。

敏捷投资 – 可测试 (Testable)

在这种情况下可测试是指在这种情况下分析定义的验收标准。

我们不能认为这个用户故事“完成”，除非它满足验收标准。我们知道的唯一方法，如果它满意，就是通过测试来验证它。

验收标准不是测试用例。回答这个问题：“我怎么知道我什么时候完成了这个用户故事？”

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

客户可以告诉您哪个是测试环境以及团队如何将用户故事视为 DONE 的测试条件。