agile - 敏捷术语中的用户故事和功能有什么区别？

Question

我想一个功能可能是“信用卡授权”，而用户故事可能是“为贝宝授权信用卡”。

那么，用户故事是功能的子集吗？

Answer 1

是的，像一个子集。这篇文章很好读：
功能与故事

摘抄：

今天我意识到，我并没有在脑海中明确区分特征和故事之间的区别，这是一个重要的区别。从本质上讲，功能是一组相关的故事，并提供最终用户通常希望一次获得所有功能的包。例如，内联表格调整大小是一项功能（注意：这是通过拖动来调整表格、行和列大小的能力——在 Word 中尝试）。在第一遍中，您可能只有一个用于内联调整表格大小的故事，但它太大而无法估计。所以你把它分成三层，调整列的大小，调整行的大小和调整表格本身的大小。

Answer 2

根据Kent Beck 和 Martin Fowler的 故事和特征是同义词：

用户故事是对客户有价值的一大块功能（有些人使用“功能”一词）。

您所说的功能通常称为主题或史诗。主题和史诗用于将用户故事分组为更大的功能集，这些功能集本身就有意义。

从更语义的角度来看：功能是您尝试构建的系统的一部分，用户故事是描述该部分的一种方式。

---

更正：

正如 Pascal 指出的那样——我可能错过了引用中“功能”的真正含义（“功能”显然是指功能）除此之外，我仍然认为可以将这些词（功能和用户故事）用作同义词很多上下文（“我正在研究这个故事”与“我正在研究这个功能”），因为正如 Pascal 所说，用户故事是捕捉功能的一种方式。这意味着这两者之间存在1：1的关系。而且，从我对语义的评论中可以看出，这就是我真正理解它的方式。

Answer 3

一点也不..

用户故事代表业务价值的一小部分。所以很难说用户故事是功能的子集还是功能是用户故事的子集（还要记住，用户故事通常是由利益相关者编写的，他们往往不知道具体是什么他们要 ... ：） ）

因此，如果您遵循敏捷的建议以保持故事简短，您将陷入“最佳”场景，即用户故事是功能的子集。

但是，如果您的利益相关者写长故事，每个故事都会有几个特点（如果团队和利益相关者之间有良好的沟通，这不会发生，因为团队会将故事分成小故事）

Answer 4

功能是系统正在做的事情。用户故事只是捕捉功能的一种方式。

Answer 5

当我在寻找关于“针对类似需求使用多个角色”的不同想法时，我刚刚遇到了这个话题。

我认为，作为相关故事容器的功能有助于确定需求的优先级，因为利益相关者通常将他们的需求作为依赖故事来讲述。在最近的一个项目中，客户告诉我如下

成员可以向管理员发送消息 管理员可以向所有成员发送消息 成员可以相互发送消息

当我看到这些要求时，我知道，我们应该实施一个系统，使人们能够发送消息，我们应该添加检查以允许谁做什么。

而且我知道这些要求可能还有其他一些隐含的要求，例如阅读收到的消息，安排它们，可能设置为垃圾邮件等。

所以我尝试将这些要求改写为

作为会员或管理员，我可以向其他人发送消息。作为会员或管理员，我可以阅读发送给我的消息。

作为验收标准，我详细说明了谁可以发送给谁。

然后我将所有这些东西称为“私人消息”功能，这样，在某个时间之后，如果客户认为这是额外费用，他可以说“放弃私人消息”，我可以将它们全部删除从积压。