敏捷用户故事的INVEST原则？

在本文中，我们将探讨什么是敏捷用户故事中的INVEST原则，因为尽管这个首字母缩写很简单，但很难具体理解它的含义。

敏捷用户故事的INVEST原则

INVEST首字母缩写代表：

现在，让我们深入了解，因为我发现仅凭这几行文字，不是每个人都能轻松理解什么是INVEST敏捷用户故事。

我经常听到人们说，在用户故事层面不可能完全独立。

如果仅从术语角度来看，这是完全正确的，但实际上我们谈论的是技术/功能上的依赖关系，而不是业务上的依赖关系。这个界限非常微妙，但绝对存在。

如果我正在开发一个电子商务网站，我可能会有一个用户故事用于身份验证，另一个用户故事用于创建账户。

很明显，从业务角度来看，身份验证必须伴随着账户创建，但从技术/功能角度来看并非如此。开发人员完全可以在没有创建账户的情况下执行身份验证。尽管从业务角度来看这没有多大意义，但在技术上是完全可行的。

因此，我们可以明确定义这两个用户故事是独立的，尽管在没有另一个的情况下发布产品是没有意义的。

我们通常通过简单的功能摘要开始用户故事。并不禁止包含一些管理规则等细节，但所有这些内容都应该以非常简单的方式编写，以便开发人员甚至客户能够迅速理解。

用户故事在精化阶段（产品待办事项的细化）中是可协商的，例如，如果所有开发人员都能够理解它，那么可以进行协商。因此，在编写用户故事的内容时，请始终使用简单的词语，以至于您自己都能确定一个10岁的孩子是否能理解用户故事的内容。

这一点有时被误解，但用户故事的概念仅用于具有应用程序中一个或多个用户类型的真实价值的功能请求。

我有时看到这样的用户故事：“作为开发人员，我希望数据库充满。”…对于任何用户类型都没有真正的价值，因此应该尽量避免。

在这种情况下，不要犹豫，可以创建不同类型的“故事原型”：参考文章“创建不同类型的故事原型”。所有对于用户类型没有真实价值的内容应该采用其他类型的任务。

仅将“作为….”用于真正的用户故事可以很好地区分具有业务价值和没有业务价值的任务。

开发人员将估算每个用户故事，除非您采用“#无估算”哲学；否则，开发人员通常会默认在心中有一个估算的概念。

我们已经讨论的所有标准以及下一个标准通常应该使开发人员能够轻松估算用户故事；实际上，如果他们无法估算，他们将要求产品负责人提供更多细节。

每个用户故事都应该在一个迭代内完成；如果有任何疑虑，它应该被切分成多个用户故事。通常情况下，建议产品负责人将每个用户故事切割到最小化（只要子用户故事仍然符合INVEST原则）。

这一点相对容易理解，每个用户故事都应该是可测试的。事实上，关于这一点，我们要求产品负责人在用户故事上明确可见的结束标志。

以下是一个例子，以便更好地理解。

作为客户，我希望在网站上浏览 -> 这个动作没有明确的结束，客户可以在不停止的情况下浏览多个页面。

作为客户，我希望将产品添加到购物车 -> 这个动作有一个明确且不可争议的结束。

现在，您已经掌握了制定真正的敏捷用户故事所需的一切，尤其是对INVEST首字母缩写的具体含义有了更清晰的理解。