敏捷术语中，“用户故事”和“特性”有什么区别？

Question

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

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

- Chakra

---

敏捷的用户商店必须以个人为中心。例如：“作为账户所有者，我可以为Paypal授权我的信用卡。”之后，您需要获取详细的成功标准。 - Jay

在http://scalingsoftwareagility.files.wordpress.com/2007/03/a-lean-and-scalable-requirements-information-model-for-agile-enterprises-pdf.pdf中，有UML模型用于解释故事、待办事项等之间的关系。 - Fuhrmanator

Answer 1

是的，就像一个子集一样。这篇文章是一篇好文章：
特性 vs 用户故事

摘录：

我今天意识到，我在心中没有明确区分特性和用户故事之间的区别，而这是一个很重要的区别。实质上，特性是一组相关的用户故事，它们提供一整套功能，最终用户通常希望一次性获得。例如，行内表格调整大小是一个特性（注意：这是拖动调整表格、行和列的能力——在 Word 中尝试一下）。首先，你可能只有一个关于行内调整表格大小的故事，但它太大了无法估算。所以你把它分成三个故事，调整列、调整行和调整表格本身。

- o.k.w

---

请看一下这个页面上Diego的帖子，非常新颖的观点。 - o.k.w

谢谢...你发布的链接很好。每当我阅读到某个人重新思考自己所做事情的经历时，都会让我以不同的方式思考这个话题。这也是我认为这个网站令人惊叹的原因之一..你可以不断地学习。 - Diego Dias

我认为这种思维方式只会增加混乱。多年来，我们在敏捷软件开发中创造了许多术语，并且有时使用不够严谨。我认为这个答案不应该是正确的答案，而是下面那个。Epic = 大故事。Feature = 用户故事。Theme = 一组特性。因此，epic、feature 和 story 是同义词；而 theme 则是它们的一个组合。 - Josh Bruce

Answer 2

根据Kent Beck和Martin Fowler的说法，“故事”和“特性”是同义词：

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

你所称之为“特性”的东西通常被称为“主题”或“史诗”。主题和史诗用于将用户故事分组到更大的特性集中，这些集合本身就有意义。

从更语义化的角度来看：特性是您正在构建的系统的一部分，而用户故事是描述该部分的一种方式。

---

更正：

正如Pascal所指出的那样，我可能错过了该引文中“feature”的真正含义（显然，“feature”指的是功能）。除此之外，我仍认为在许多情况下可以将这些词（feature和user story）视为同义词（“我正在处理这个story”与“我正在处理这个feature”），因为正如Pascal所说，用户故事是捕获功能的一种方式。这意味着两者之间存在1:1的关系。而且，正如我的语义备注所示，这就是我真正理解它的方式。

- Milan Novota

---

你所说的“feature”通常被称为“主题”或“史诗”，我喜欢这个类比。 :) - o.k.w

我不小心删掉了我的评论，为了清晰起见，我重新发一遍：你确定有些人使用“特性”这个词并不适用于“功能”吗？ - Pascal Thivent

顺便提一下，尽管我有不同的观点（个人认为，我将关系视为“用户故事= >功能”，而没有严格的等价性），但我真的很喜欢这个补充。 - Pascal Thivent

Answer 3

完全不是这样的情况...

用户故事代表业务价值的小部分。因此，很难说一个用户故事是一个特性的子集还是一个特性是一个用户故事的子集（也要记住，用户故事通常是由利益相关者编写的，他们往往不知道自己究竟想要什么... :)）

因此，如果按照敏捷推荐的保持故事简短的建议，您会得到“最好”的情况，即用户故事是特性的子集。

然而，如果您的利益相关者编写了长篇故事，每个故事都会有几个特性（如果团队和利益相关者之间有良好的沟通，这种情况不会发生，因为团队会将故事分解成小的故事）。

- Diego Dias

Answer 4

特性是系统正在执行的功能。用户故事只是其中一种捕捉特性的方式。

- Pascal Thivent

Answer 5

在我搜索“使用多个角色满足相似需求”的不同想法时，我偶然发现了这个主题。

我认为，将特性作为相关故事的容器有助于优先考虑需求，因为利益相关者通常会提出他们的需求作为依赖故事。在最近的一个项目中，客户告诉我如下：

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

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

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

所以我试图重新表述这些要求：

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

并且作为验收标准，我详细说明了谁可以向谁发送消息。

然后我把所有这些东西称为“私信”功能，这样，如果客户在以后某个时候决定这是额外的费用，他可以说“删掉私信功能”，我就可以把它们全部从待办事项中删除。

- Cagatay Kalan