用户故事，功能和史诗之间的关系？

作为尚不熟悉敏捷的人，我不确定我是否完全了解用户故事，功能和史诗之间的关系或差异。

根据这个问题，特征是故事的集合。答案之一表明某个功能实际上是史诗。那么功能和史诗是否被认为是同一件事，基本上就是相关用户故事的集合？

我们的项目经理坚持要有一个层次结构：

史诗->功能->用户故事

基本上所有用户故事都必须属于此结构。因此，所有用户故事都必须属于保护伞功能，而所有功能都必须属于史诗级功能。

对我来说，这听起来很尴尬。有人可以说明用户故事，功能和史诗之间的关系吗？还是有一篇文章清楚地概述了这些差异？

实际上，它们是非常通用的术语。解释它们的方式很多，在文献和人们如何看待它们方面都有所不同。把我所说的一切都撒上一大盐。

通常，Epic在您的软件中包含非常全局且定义不明确的功能。它非常广泛。当您尝试理解它并使它们适合敏捷迭代时，通常会将其分解为较小的用户故事或功能。范例：

史诗
-允许客户通过网络管理自己的帐户

功能和用户故事是更特定的功能，您可以轻松地通过验收测试进行测试。通常建议它们具有足够的粒度以适合单个迭代。

功能通常会描述您的软件做什么：

功能
-通过Web门户编辑客户信息

用户故事倾向于表达用户想要做的事情：

用户故事
作为银行业务员，
我希望能够修改客户信息，
以便使其保持最新状态。

我认为这两者之间并没有真正的层次结构，但是如果您愿意或者适合您的工作方式，则可以有一个层次结构。用户故事可以是功能的特定依据，也可以是特定的实现方式。或相反。功能可以是实现用户故事的一种方式。或者它们可以表示同一件事。您可以同时使用：用户故事来定义带来业务价值的内容和描述软件约束的功能。

用户故事：作为客户，我想用最受欢迎的信用卡付款。
功能支持政府的GOV-TAX-02 XML API。

还有一个场景问题，通常是功能/用户故事的执行方式。他们通常清晰地映射到特定的验收测试。例如

场景：提款
假设我的银行帐户中有2000 $，
当我提取100 $时
，我会收到100 $现金，
而我的余额是1900 $

这就是我们定义工作地点的方式。这些定义远非数学定义或标准化术语。就像右翼政客或左翼政客之间的区别一样。这取决于你住在哪里。在加拿大，所谓的右翼在美国可能被视为左翼。这是非常可变的。

认真地说，我不会对此太担心。重要的是团队中的每个人都同意一个定义，以便您可以互相理解。一些诸如scrum的方法倾向于更正式地定义它们，但是选择适合您的方法，其余的留给其他人。毕竟，对于流程，工具上的个人和交互以及对综合文档上的工作软件，敏捷不是很敏捷吗？

史诗：很大的用户故事，最终分解为较小的故事。

用户故事：需求的非常高级的定义，仅包含足够的信息，以便开发人员可以对实现需求的工作做出合理的估计。

http://www.telerik.com/agile-project-management-tools/agile-resources/vocabulary.aspx

功能：软件应用程序或库的独特特征或功能（例如，性能，可移植性或功能）。

http://en.wikipedia.org/wiki/Software_feature

我告诫您不要对这些术语使用过于严格的层次结构。我们在上一份工作中试图做到这一点。两次。两次尝试都不相同，而且两次都发现我们不必要地限制了自己。唯一的常数是用户故事的定义。从计划的角度来看，故事是项目的基本组成部分。较大的术语（史诗，特征等）实际上只是标签。标签是一种允许故事同时作为多个史诗和多个功能的一部分存在的简便方法。没有比这更严格的精神努力了。

标签适用于Stack Exchange，它们也可以为您服务。

我们使用史诗，故事和功能的方式如下

在项目周期的早期，我们提出了Epics。这些是非常高级的功能，几乎都是以市场为中心的。您可以在执行摘要中使用的某种内容，例如，

我们的新网站将允许客户浏览产品，查看可用性和价格，下订单并查看他们过去的订单历史记录

这导致诸如

• 浏览产品目录
• 查看空房
• 查看定价
• 下订单
• 查看订单历史

这些都是作为用户故事写的（例如，作为客户，我想浏览产品目录，以便做出明智的购买决定），但只能作为十个入门书来实际开发和发布。

然后将这些史诗进一步细分为“ 用户故事”。这些是实际的端到端用户旅程，范围非常有限，并且以可以独立估计和计划，开发，测试和发布的方式定义。

用户故事是交付的单位。是完整的或未完成的，上线或下线的用户故事。

史诗可能会导致大量的用户故事，并非所有故事都会同时开发或发布。

例如，“浏览产品目录”史诗可能细分为

• 导航类别层次结构
• 按关键字搜索
• 按产品属性（例如价格范围，品牌，颜色，尺寸等）过滤

同样，每一个都将以这种格式写成，例如，作为客户，我想浏览类别层次结构，以便浏览产品并向下钻取最适合自己需求的产品。

通常，对于我们的大多数项目，我们都有几十个史诗和数百个故事。

现在，当我们经历故事的生命周期时，我们将这些故事标记为Feature。例如，所有浏览和搜索以及库存和定价故事都将标记为“产品目录”。与信用卡付款有关的下订单故事可能带有“信用卡”标签，而与PayPal付款有关的那些则带有“ paypal”标签。

这些标签用于将属于同一故事的故事组合在一起，这不是因为它们是执行同一活动的不同类型（例如，所有下订单的故事），而是因为它们应该一起发布。

例如，“通过信用卡下订单”故事与“通过PayPal下订单”故事属于同一史诗，但是它们不必一起发布。

而“下订单用信用卡付款”，“处理退货退款到信用卡上”的故事和“允许客户在其帐户上管理已保存的信用卡”的故事似乎确实是相互关联的。 。它们都将被标记为“信用卡”功能标签。即它们都属于“信用卡”功能。如果无法处理退货退款到PayPal，或者无法管理帐户中保存的信用卡，则释放信用卡下订单的功能不是很有帮助。

注意：通常，就是这样。最终，这是一个商业决策。如果上市时间很重要，则可能有正当理由选择其中之一而不是另一个。

因此，Epic可以分解为可以独立开发的（相关但独立的）故事，而Features可以将应该一起发布的故事分组在一起。

您可以说Epics分解为用户故事，而用户故事则组合为功能。属于某个功能的故事通常遍及史诗。因此，Epic和Feature是正交的，而不是严格的层次结构。

在我们的工作方式中，史诗一旦分解成故事，他们就会失去目标。我们不估计或计划史诗。我们不会跟踪Epics的进度。我们不发布史诗。我们估算，计划和跟踪用户故事。并且我们发布功能。

我同意许多回答，但实际上并没有正确的答案，因为这些只是术语，可以根据您所基于的敏捷阵营而有所不同，只要您团队中的每个人（包括外部利益相关者），您都可以确定自己的阵营了解他们的意思。这只是组织需求的一种方式。

我喜欢的答案来自Mike Cohn的阵营，这很简单。

http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes

• 史诗只是一个大故事（分层）
• 主题只是一组故事（非常类似于标签）

他实际上避免使用“功能”一词。我认为这主要是因为它是传统瀑布世界中的一个常用术语。许多敏捷阵营倾向于使用不同的术语来强调差异。

因此，按照您的PM的定义，Feature位于Epic-Story层次结构的中间。

这是我的InfoQ文章http://www.infoq.com/articles/visualize-big-picture-agile ;-)中有关此定义的信息图

功能和史诗不是一回事。

• 功能不是用户故事。
• 史诗是用户故事。
• 用户故事可能是史诗。
• 用户故事可以包含许多功能。
• 一个功能可以实现1到许多用​​户故事。

在计划阶段，讨论的结果是通常被标识为Epics的用户故事，因为为他们实施解决方案的工作量太大，几天之内就无法完成。在此阶段确定产品功能。但这只是讨论的副产品。特点然后用于规划产品路线图，这是一个单独的讨论。

进一步讨论了这些史诗，并为每个史诗生成了用户故事。的特点和史诗用于驱动讨论积压细化和Sprint计划会议。到那时，来自这些讨论的用户故事将得到完善，确定优先级，并在Sprint计划中被接受为Sprint以进行实施。

只是问题分解。它们只是故事，只是大小不同。

我个人不希望标注其尺寸，但是如果您这样做也可以。问您项目经理您的工作区中的定义是什么。

我们的组织有2000多名开发人员，因此，对于我们共同开发通用产品的数百个敏捷团队之间的流畅和清晰的沟通，此问题的答案非常重要。对于一个非常小的组织，您可以拥有一个非常简单的结构，该结构甚至不需要分层（就像其他人回答的那样）。但是，对于大型组织而言，绝对需要一些组织化，规模化，一致的层次结构-这就存在着一个问题，即努力从严格的层次结构中构建出层次结构。

顺便提及，我们将这些不同的级别称为“工作项”。一些组织（包括上面的一些答复者）将不同级别称为“故事”或“用户故事”（并且我们过去也是如此），但是我们发现这太含糊，因此现在将它们统称为工作项。

到目前为止，我们在“官方”上所做的最好的工作是遵循Dean Leffingwell的SAFe结构，即“投资主题和业务史诗”位于层次结构的顶部（从上至下），然后是该结构下的Feature，最后是Feature下的Stories。根据敏捷的说法，任务始终处于“故事”之下，因此，我们小心不要重复使用该术语。我们选择遵循SAFe，以便在我们所有团队中至少保持一定的一致性。

但这仍然不足以满足我们的需求。我们将功能定义为对我们的软件产品的消费者而言具有明显价值的交付物（即，我们在即将发布的公告中列出了这些功能）。而且，我们将故事定义为可以由一个敏捷开发团队在一个Sprint中交付的较小范围和工作。我们现在也开始在投资组合级别（且不低于此级别）遵循SAFe关于投资主题和业务史诗的定义。而且我们开始不使用“主题”和“史诗”的旧定义。

我们现在正朝着这个方向缓慢发展，但是进步的轮子缓慢地磨。我们仍在努力将工作分成几小块，以便我们可以定义工作并使多个团队顺利完成工作。为此，我们认为需要一个“子功能”，该“子功能”小于功能，但大于故事。子功能可用于由每个个人团队在功能上完成的工作，或由单个团队在不同时间（在不同的Sprint甚至不同的发行版中）完成的工作。

我们还需要在Feature和Business Epic之间建立多个层次级别，但是我们还没有解决这个问题，只是将它们称为“主题”-我们知道这不是正确的术语，因为它很容易与SAFe投资主题混淆。对于某些大型项目（发行版），我们有多达5-8个不同的层次级别，每个层次将工作分解为越来越小的块。您可以将这些主题视为“功能组”，但这也不一定是正确的术语。

我认为，重要的是尝试使用提供清晰而非歧义的术语。因此，任何引用故事的人都意味着可以在单个Sprint中完成的最小工作单元（故事下的任务除外），而子功能意味着可以在单个Sprint中完成的最小工作单元。球队。同样，功能组是功能之上的一个层次级别。除此之外，它还有些模糊，因此我们通常将它们称为“主题”，并且允许“主题”作为其他“主题”的父项和子项。我们尝试将功能，子功能和故事级别分别限制为一个级别（功能不应是其他功能的子级），但我们尚不能100％成功地限制此功能。

我知道我们可以使用“标签”来组织其中的一些，但是标签不能为我们提供组织工作分解结构，而我们需要对这些结构进行分类以对所有团队之间的工作进行分类。根据定义，标签是模棱两可的（多对多关系），但是层次结构严格是一对多的。

最重要的是，对于我们来说，这仍然是一个未完成的工作，我们仍在为此而努力。但是，坚持SAFe主题，史诗，专题和故事的定义可以使我们朝着正确的方向前进！

产品积压层次结构在很大程度上取决于产品大小及其模块化（定义的产品区域数量）。

对于小型项目：Epic> Story绰绰有余；然后您将其称为“功能”。
大型项目可能类似于：小说>主题>史诗>专题>故事

最好的示例如下：
小说 = MS Office
主题 = MS Word / MS Excel ...
史诗 =表/字体目录...
功能 =基本表/表配色方案/带单元的操作...
故事（对于' '表格'史诗中的基本表格功能）=添加表格/绘制表格/插入原始/插入列...

我认为在定义自己的积压规模时要记住的好处是：
1.故事： a）在一个冲刺中总是可行的；b）并非总是能对最终用户进行测试
2.史诗 /功能：a）不适合一个冲刺持续时间，需要分解；b）始终应对最终用户进行测试；C）总是可交付的，可货币化-得到的投资回报率计算它
3.当考虑添加或不史诗> 功能部分或坚守史诗>故事：我建议在史诗和故事只有当之间插入功能：史诗没有按”甚至无法容纳1 Release，因此您需要定义适合1 Release duration的可运输元素。

希望这会有所帮助。

在我们的组织中，我们具有以下优势：

主题=用于将故事集合在一起

史诗=描述需要分解为用户故事的大型用户故事（实际上是一项要求）

功能=锡罐上的文字说明了所需产品的功能

用户故事=这是从中派生任务的最低详细级别。