用户故事和功能之间有什么区别？

在玩icescrum时，我意识到我不了解用户故事和用户功能之间的区别。

有人可以解释差异吗？

功能是可以为企业提供功能的功能的独特元素。

故事是功能的一小部分，您可以使用它来获取利益相关者的反馈，并确定您做错了什么。

例如，一个功能可能是“允许用户评论文章”。与该功能相关的故事可能是：

• 保存评论
• 过滤不礼貌用语的注释
• 将评论限制为400个字符并反馈给用户
• 添加验证码以阻止漫游器向网站发送垃圾邮件
• 允许用户通过Google ID登录

等等

然后，在每个阶段，我们都可以获取有关我们所采取的方向是否有用的反馈。

有些团队不会费心将功能拆分为故事。没关系。

功能==用户故事。

语气由所采用的给定敏捷方法决定。

不同的方法使用不同的术语来指代功能。由团队决定使用哪种方法或术语。极限编程（XP）使用用户故事或故事来表示功能；Scrum使用Product Backlog来描述功能列表。功能驱动开发使用功能；而DSDM使用需求。同样，存在各种轻量级的Unified Process或Agile UP，它们使用需求和/或用例来定义可交付的增量功能。最终，目标是相同的-定期以小增量定期交付业务价值，而不是早于后来。

一个用户故事是在客户捕捉意图的一些客户希望实现语言的非正式说法。您可以将用户案例视为非正式要求声明。

一个软件功能是软件的一个显着特点，有助于软件的整体设计和功能。

几个关键注意事项：

• 一个故事可以描述一个功能，但功能从来没有描述一个故事。
• 一个故事可能没有直接描述一个特征。
• 一个故事可能意味着一些列入特点。
• 一个功能部件（单独或作为功能部件集合的成员）可以捕获故事的意图。

考虑到所有这些，我倾向于将故事视为描述。基本上非正式的要求可以告诉我客户的需求。另一方面，我倾向于将功能更多地看作是一个规范，该规范告诉我系统如何工作才能满足客户需求。

这两个术语密切相关，但是有一些区别。

首先，它们来自不同的领域。术语“功能”是软件功能某些部分的通用术语，而“用户故事”是发明的，实际上仅在敏捷软件开发的上下文中使用。

实际上，它们经常是一致的，因为一个用户故事包含实现某种功能。

但是，在某些情况下它们可能有所不同：

• 通常，对于单个用户而言，功能太多了。用户故事不应太大（通常不超过几天，最多工作1-2周）。显然，许多功能要大得多。在这种情况下，将在许多用户案例中实现功能。有些人使用“史诗”将用户故事分组在一起，在这种情况下，您可以说该功能是史诗般的。
• 非功能性要求（性能，安全性，兼容性等）也可以作为用户案例处理（尽管这不是普遍接受的）。在那种情况下，用户故事的结果通常不会被称为功能（除非您称“我们的应用程序很少崩溃”功能）。