敏捷词汇表 -- 敏捷联盟
# 史诗故事 Epic
## 定义
史诗是一个大型用户故事，无法按一次迭代中的定义进行传递，或者足够大，可以分解为较小的用户故事。
没有标准格式可以代表史诗。有些团队使用熟悉的用户故事格式（作为A，我想要，以便于或为了），而其他团队则用简短的短语表示史诗。
## 预期收益
通过Epics，您可以跟踪积压的未定义大型想法，而无需在积压的项目中添加多个项目。您可以记住一个积压的模糊想法，直到您的团队确定需要提供史诗般的结果。到那时，您的团队可以在积压的提炼过程中将史诗分成较小的用户故事。
通过史诗，您可以为积压的项目建立层次结构，其中史诗表示通常与特定结果密切相关的原始想法。与该史诗相关联的用户案例代表了您需要交付的解决方案的各个方面，或者满足这些需求的选项。
您可能还会看到用于将处理同一主题的用户故事分组的主题概念。主题概念通常用于将单独识别的用户故事分组在一起，并且可以用作各种决策过滤器，以决定将哪些故事分组到特定的冲刺或交付中。主题通常不用作积压层次结构中的级别。
## 常见陷阱
团队不仅仅可以将大型史诗视为大型用户故事，还可以使史诗般的使用变得过于复杂。当团队创建复杂的机制以区分史诗和用户故事（以及其他潜在的待办事项层次结构），并创建用于跟踪史诗与其他待办事项分开的广泛工具时，这一点显而易见。
这两种操作都会导致浪费精力，无论是史诗般的事件还是用户的故事，以及花费的时间跟踪有关待办事项的信息，这些信息打算用作以后的讨论的占位符，从而导致粒度更细的待办事项。
团队也可能尝试估算史诗，即使这些物品通常性质上非常模糊并且容易产生很大的不确定性，从而降低了可靠或有用估算的可能性。
## 当适用
当您遵循诸如Scrum之类的框架时，史诗的概念特别有用，该框架具有明确的时间盒式迭代（即Sprint）。由于您将工作组织成2到4周的冲刺，因此可能会发现占位符代表无法在该时间段内完成的工作。
当在您的产品待办事项列表中具有简单的层次结构很有价值时，Epic也有用。
## 起源
2004年：Mike Cohn在他的《为敏捷软件开发应用的用户故事》一书中将史诗的概念介绍为大型用户故事。
## 进一步阅读
Mike Cohn《用户故事与敏捷方法》
点击看敏捷名词地铁线路全图