JIRA：Epics vs 标签 vs 组件
JIRA: Epics vs Labels vs Components
This blog 在 JIRA 中有 epics 的定义：
Epics are significantly larger bodies of work. Epics are feature-level work that encompasses many user stories. Using the above example, an epic might be the entire account management feature and the ability to see previous purchases.
因此，如果（作为产品所有者）我有一个我想要交付的大型功能，它将包含许多较小的任务并且可能跨越冲刺，那么史诗是一个不错的选择。
但是，我可以轻松地创建一个（使用博客中的示例）"Account Management" 组件，并且与该功能相关的任何任务都分配了该组件。
同样，我也可以轻松地使用 "Account_Management" 标签，任何属于账户管理功能的 stories/tickets 都可以简单地标记上该标签。
所以我的问题是：why/what 你会在什么情况下使用史诗？ why/what 你会在什么情况下使用组件？ Why/what 你会在什么情况下使用标签？即 - 所有这三个（epics、标签、组件）似乎都有非常相似的目的（将问题集合分组），有什么区别？
对于标签和组件，如果你想 select 一组，你需要使用问题搜索。如果您使用 epics，您也可以使用问题搜索，但您还可以在 JIRA Agile 中获得 built-in 功能。
在 JIRA Agile 面板的积压视图中，您有一个 Epic 选项卡。此选项卡允许您 select 与个人 epics 相关的问题。此外，它还具有使向史诗中添加新问题变得简单的功能。最后一个优点是史诗名称与列表中的问题一起显示为鲜艳的颜色。这在查看积压工作并了解接下来的工作时非常有用。
您可以在 Atlassian Working with Epics 页面上查看有关 epics 的更多信息。
组件对技术团队很有用，因为它们可以跨越许多 epics。典型的组件可能是 'database' 或 'UI'。 JIRA 提供了将特定组件的工作分配给特定 JIRA 用户的选项。例如，使用 'database' 的组件创建的所有问题都可以分配给 Jill Smith。
标签的适应性更强，并且具有允许多次分配的优势（因此一个问题可以关联多个标签）。使用标签完全取决于您如何使用它们。
Epics 是更大的故事，需要不止一个冲刺才能完成。一个 Epic 可能涉及多个用户故事。每个用户故事可能属于一个或多个组件。比如说，您有一个史诗般的航空公司可用性搜索。这可能有多个用户故事，如 OW 搜索、RT 搜索等，其中一些或全部可能涉及缓存、旅行政策和预订引擎等组件。
标签只是为了方便。它可能没有物理意义。
与整个项目相比，Epics 根据定义是 short-lived 问题。另一方面，Components 和 Labels 是永远的。而且，你应该坚持按照它们的真正含义使用它们，无论它有多诱人。
为 功能 创建 Epics，或者如@Sateesh 所述，用于更大的故事。他们应该解决他们的目的，一旦业务需求完成，他们就应该 closed/done.
组件不是功能。它们是系统的技术部分。它们还可以用于 分类 您的零件或...嗯，组件 :P... 您的产品。
标签可以是任何东西，如@barnaby 所述。通常，它们是关键字，catch-phrases，人们可能希望任务与之相关的词等。我主要使用它来使问题从 long-term 的角度更好地搜索。有一个 JIRA 插件可以给你一个 JIRA 标签云（我觉得纯粹是为了花哨的目的 :D）你可能也会感兴趣。
加法：
Atlasian 现在已经创建了一篇新文章，从他们的角度解释了这一点。
https://www.atlassian.com/agile/delivery-vehicles
我的看法/用法。
标签和组件几乎是直截了当的，并且已经得到很好的回答。
组件 示例
- Android 客户端应用
- 服务器API
- 数据库
等......
标签个例子。
- 业务逻辑部门（例如订单、发票、用户、产品）
- 代码质量改进
- 重构
- 可用性
- 用户request/complain
通常 随便 有助于分类。
但是让我给 Epics 我的两分钱，因为我觉得这个短语太笼统了。
Epics are significantly larger bodies of work
更大？ 10 冲刺？ 10个故事？ 20个故事？或者什么？
个人 我会将 Epics 分类为 目标。
在年度/季度回顾中，贵公司与所有成员和利益相关者举行会议，并得出以下结论
- 我们需要瞄准更多平台（史诗=平台扩展）
- 我们的支持人员需要更多工具来处理问题。 （丰富支持工具）
- 软件太难用了！ (重新设计UI用户体验)
这意味着 3 epics 有一组故事来涵盖每个通用要求
This blog 在 JIRA 中有 epics 的定义：
Epics are significantly larger bodies of work. Epics are feature-level work that encompasses many user stories. Using the above example, an epic might be the entire account management feature and the ability to see previous purchases.
因此，如果（作为产品所有者）我有一个我想要交付的大型功能，它将包含许多较小的任务并且可能跨越冲刺，那么史诗是一个不错的选择。
但是，我可以轻松地创建一个（使用博客中的示例）"Account Management" 组件，并且与该功能相关的任何任务都分配了该组件。
同样，我也可以轻松地使用 "Account_Management" 标签，任何属于账户管理功能的 stories/tickets 都可以简单地标记上该标签。
所以我的问题是：why/what 你会在什么情况下使用史诗？ why/what 你会在什么情况下使用组件？ Why/what 你会在什么情况下使用标签？即 - 所有这三个（epics、标签、组件）似乎都有非常相似的目的（将问题集合分组），有什么区别？
对于标签和组件，如果你想 select 一组，你需要使用问题搜索。如果您使用 epics，您也可以使用问题搜索，但您还可以在 JIRA Agile 中获得 built-in 功能。
在 JIRA Agile 面板的积压视图中，您有一个 Epic 选项卡。此选项卡允许您 select 与个人 epics 相关的问题。此外，它还具有使向史诗中添加新问题变得简单的功能。最后一个优点是史诗名称与列表中的问题一起显示为鲜艳的颜色。这在查看积压工作并了解接下来的工作时非常有用。
您可以在 Atlassian Working with Epics 页面上查看有关 epics 的更多信息。
组件对技术团队很有用，因为它们可以跨越许多 epics。典型的组件可能是 'database' 或 'UI'。 JIRA 提供了将特定组件的工作分配给特定 JIRA 用户的选项。例如，使用 'database' 的组件创建的所有问题都可以分配给 Jill Smith。
标签的适应性更强，并且具有允许多次分配的优势（因此一个问题可以关联多个标签）。使用标签完全取决于您如何使用它们。
Epics 是更大的故事，需要不止一个冲刺才能完成。一个 Epic 可能涉及多个用户故事。每个用户故事可能属于一个或多个组件。比如说，您有一个史诗般的航空公司可用性搜索。这可能有多个用户故事，如 OW 搜索、RT 搜索等，其中一些或全部可能涉及缓存、旅行政策和预订引擎等组件。
标签只是为了方便。它可能没有物理意义。
Epics 根据定义是 short-lived 问题。另一方面，Components 和 Labels 是永远的。而且，你应该坚持按照它们的真正含义使用它们，无论它有多诱人。
为 功能 创建 Epics，或者如@Sateesh 所述，用于更大的故事。他们应该解决他们的目的，一旦业务需求完成，他们就应该 closed/done.
组件不是功能。它们是系统的技术部分。它们还可以用于 分类 您的零件或...嗯，组件 :P... 您的产品。
标签可以是任何东西，如@barnaby 所述。通常，它们是关键字，catch-phrases，人们可能希望任务与之相关的词等。我主要使用它来使问题从 long-term 的角度更好地搜索。有一个 JIRA 插件可以给你一个 JIRA 标签云（我觉得纯粹是为了花哨的目的 :D）你可能也会感兴趣。
加法： Atlasian 现在已经创建了一篇新文章，从他们的角度解释了这一点。
https://www.atlassian.com/agile/delivery-vehicles
我的看法/用法。
标签和组件几乎是直截了当的，并且已经得到很好的回答。
组件 示例
- Android 客户端应用
- 服务器API
- 数据库 等......
标签个例子。
- 业务逻辑部门（例如订单、发票、用户、产品）
- 代码质量改进
- 重构
- 可用性
- 用户request/complain 通常 随便 有助于分类。
但是让我给 Epics 我的两分钱，因为我觉得这个短语太笼统了。
Epics are significantly larger bodies of work
更大？ 10 冲刺？ 10个故事？ 20个故事？或者什么？
个人 我会将 Epics 分类为 目标。
在年度/季度回顾中，贵公司与所有成员和利益相关者举行会议，并得出以下结论
- 我们需要瞄准更多平台（史诗=平台扩展）
- 我们的支持人员需要更多工具来处理问题。 （丰富支持工具）
- 软件太难用了！ (重新设计UI用户体验)
这意味着 3 epics 有一组故事来涵盖每个通用要求