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

#1 楼

实际上，它们是非常通用的术语。解释它们的方式很多，在文献和人们如何看待它们方面都有所不同。用我所说的话来解释一下。
通常，Epic在您的软件中包含非常全局且定义不明确的功能。它非常广泛。当您尝试理解它并使它们适合敏捷迭代时，通常会将其分解为较小的用户故事或功能。示例：
Epic

允许客户通过Web管理自己的帐户

功能和用户故事是更特定的功能，您可以轻松接受测试测试。通常建议它们具有足够的粒度以适合单个迭代。
功能通常倾向于描述您的软件的工作：
功能

通过网络编辑客户信息门户网站

用户故事倾向于表达用户想要做的事情：
用户故事
作为银行业务员，
我希望能够修改客户信息
，以便我可以保持最新状态。
我认为这两者之间并没有真正的层次结构，但是如果您愿意或者它适合您的工作方式，则可以有一个层次结构。用户故事可以是功能的特定依据，也可以是特定的实现方式。或者也可以相反。功能可以是实现用户故事的一种方式。或者它们可以表示同一件事。您可以同时使用：用户故事来定义带来业务价值的要素和描述软件约束的功能。
用户故事：作为客户，我想使用最受欢迎的信用卡付款功能支持GOV-TAX-02政府的XML API。
还有场景问题，这通常是功能/用户故事的执行方式。他们通常清晰地映射到特定的验收测试。例如
场景：提款
我的银行帐户中有2000 $
当我提款100 $
然后我会收到100 $现金
是1900 $
这就是我们在工作时定义这些术语的方式。这些定义远非数学定义或标准化术语。就像右翼政客或左翼政客之间的区别一样。这取决于你住在哪里。在加拿大，所谓的右翼在美国可能被视为左翼。这是非常可变的。
我真的不会为此担心太多。重要的是团队中的每个人都同意一个定义，以便彼此了解。一些诸如scrum的方法倾向于更正式地定义它们，但是选择适合您的方法，其余的留给其他人。毕竟，对于流程，工具上的个人和交互以及对综合文档上的工作软件，敏捷不是很敏捷吗？

#2 楼

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

用户故事：需求的非常高级定义，其中包含足够的信息，以便开发人员可以进行合理的估算实现它的努力。

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

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

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

#3 楼

我们使用Epics，故事和功能的方式如下所述。

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


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


这会导致史诗般的发布，例如


浏览产品目录
查看库存状况
查看定价
下订单
查看订单历史记录

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

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

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

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

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


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

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

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

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

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

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

，似乎有“用信用卡下订单”故事，“处理退货退款到信用卡上”的故事，以及“允许客户在他们的帐户上管理保存的信用卡”的故事。属于彼此。它们都将被标记有“信用卡”功能标签。即它们都属于“信用卡”功能。如果无法处理退货退款到PayPal，或者无法管理帐户中保存的信用卡，则释放信用卡下订单的功能不是很有帮助。

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

因此，《史诗》可以分解为（相关但独立的）故事，可以独立开发，而功能可以将应该一起发布的故事组合在一起。

您可以说，Epics分解为用户故事，而用户故事则组合为功能。属于某个功能的故事通常遍及史诗。因此，史诗和特征是正交的，而不是严格的层次结构。我们不估计或计划史诗。我们不会跟踪Epics的进度。我们不发布史诗。我们估计，计划和跟踪用户故事。并且我们发布功能。

#4 楼

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

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

#5 楼

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

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

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


Epic只是一个大故事（分层）
Theme只是一组故事（非常类似于tag）

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

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

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

#6 楼

功能和史诗不是一回事。

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

在计划阶段，讨论导致用户故事通常被标识为史诗，因为为他们实施解决方案的工作量太大，几天之内就无法完成。在此阶段确定产品功能。但这只是讨论的副产品。然后使用功能来规划产品路线图，这是一个单独的讨论。
将进一步讨论和讨论史诗，并为每个史诗生成用户故事。功能和史诗用于推动积压细化和Sprint计划会话中的讨论。那时，对这些讨论中的用户故事进行了完善，确定优先级，并在Sprint计划中被接受为Sprint以进行实施。

#7 楼

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

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

#8 楼

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

将这些不同的级别分别称为“工作项”。一些组织（包括上面的一些答复者）将不同的级别称为“故事”或“用户故事”（并且过去也是如此），但是我们发现这太含糊，因此我们现在将它们统称为工作项。 >
到目前为止，我们“要做的最好的工作”是遵循Dean Leffingwell的SAFe投资主题和业务史诗结构，将其置于层次结构的顶部（从顶部开始，第二从顶部开始），然后是该层次结构下的功能，最后功能下的故事。根据敏捷的说法，任务始终处于“故事”之下，因此，我们小心不要再使用此术语。我们选择遵循SAFe，以使我们所有团队至少保持一定的一致性。

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

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

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

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

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

最重要的是，对于我们来说，这仍在进行中，而我们仍在努力。但是，坚持SAFe对主题，史诗，专题和故事的定义使我们朝着正确的方向前进！

#9 楼

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

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

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

定义积压的比例时，请记住以下几点：1。故事：a）在一次冲刺中始终可行； b）并非始终可对最终用户进行测试2。史诗/功能：a）不适合一个冲刺持续时间，需要分解； b）始终应对最终用户进行测试； c）始终可发货，可以货币化-获取为其计算的ROI3。在考虑添加或不添加Epic> Feature部分或坚持使用Epic> Story时：仅在以下情况下才建议在Feature Epic和Story之间插入Feature：Epic甚至不适合1 Release，因此您需要定义适合的史诗元素1释放持续时间。

希望有帮助。

#10 楼

在我们的组织中，我们具有以下内容：

主题=用于将故事的集合归类到

Epic =描述需要处理的大型用户故事（实际上是要求）被分解为用户故事

功能=锡上写着什么，描述了所需产品的功能

用户故事=这是最低级别的详细信息哪些任务是派生的。