我猜一个功能可能类似于“信用卡授权”，而用户故事可能是“授权PayPal信用卡”。
那么，用户故事是一个功能的子集吗？
答案 0 :(得分：41)
是的，类似于子集。这篇文章读得很好：
Features vs Stories
摘录：
我今天意识到我没有做过 明确我的思想差异 功能和故事之间的关系 一个重要的区别。实质上， 一个特征是一组故事 相关并提供一揽子 最终用户的功能 一般都希望得到所有。 例如，内联表调整大小是 一个功能（注意：这是能力 拖动以调整表，行和 列 - 在Word中尝试。在里面 第一次通过，你可能有一个 内联调整大小的单一故事 桌子，但它太大了 估计。所以你把它分解成了 三个故事，调整列，调整大小 行并调整表本身的大小。
答案 1 :(得分：21)
根据Kent Beck and Martin Fowler 故事和功能是同义词：
用户故事是一大块 功能（有些人使用 单词 feature ）是有价值的 顾客。
您所谓的功能通常称为主题或史诗。主题和史诗用于将用户故事分组到更大的功能集，这些功能集本身就有意义。
从更加语义的角度来看：功能是您尝试构建的系统的一部分，用户故事是描述该部分的一种方式。
校正：
正如Pascal指出的那样 - 我可能错过了引用中“功能”的真正含义（“功能”显然指的是功能）除此之外，我仍然认为可以使用这些词（功能和用户故事）作为很多情境中的同义词（“我正在研究这个故事”与“我正在研究这个功能”），因为正如Pascal所说，用户故事是捕捉特征的一种方式。这意味着这两者之间存在1：1的关系。而且，从我对语义的评论中可以看出，这就是我真正理解它的方式。
答案 2 :(得分：9)
完全没有..
用户故事代表商业价值的一小部分。 因此，很难说当用户故事是功能的子集或功能是用户故事的子集时（同时请记住，用户故事通常由利益相关者编写，而这些利益相关者往往不知道具体是什么他们想...... :)）
因此，如果您遵循敏捷的建议来保持简短的故事，那么您将陷入“最佳”场景，即用户故事是该功能的一个子集。
然而，如果您的利益相关者撰写长篇故事，每个故事都会有一些功能（如果团队和利益相关者之间有良好的沟通，那么这将不会发生，因为团队会将故事分成小故事）
答案 3 :(得分：8)
功能是系统正在做的事情。用户故事只是捕获功能的一种方式。
答案 4 :(得分：2)
当我在寻找“为类似要求使用多个角色”的不同想法时，我刚刚遇到了这个话题。
我认为，作为相关故事的容器的功能有助于确定需求的优先级，因为利益相关者通常将他们的需求称为依赖故事。在最近的一个项目中，客户告诉我如下
会员可以向管理员发送消息 管理员可以向所有成员发送消息 会员可以互相发送消息
当我看到这些要求时，我知道，我们应该实施一个系统来让人们发送消息，我们应该添加检查以允许谁做什么。
我也知道这些要求可能还有一些其他的隐含要求，例如阅读邮件，安排邮件，可能设置为垃圾邮件等等。
所以我试着将这些要求改写为
作为会员或管理员，我可以向其他人发送消息。 作为会员或管理员，我可以阅读发送给我的邮件。
作为验收标准，我详细说明谁可以发送给谁。
然后我把所有这些事情“悄悄话”功能，这样，在一段时间后，如果客户决定，这是一个额外的费用，他可以说“刚落悄悄话的事”，我可以删除所有这些都来自积压。