共计 1874 个字符，预计需要花费 5 分钟才能阅读完成。
当咱们开始理解和采纳「麻利开发」的时候，会看到一个略显生疏的概念「史诗」。或者因为翻译的问题，这个概念在中文语境里有些难懂，在理论利用中，了解更是形形色色。为此，小编找到了这篇具体介绍“何为「史诗」”的文章，举荐给大家。
开始之前，咱们先看看「史诗」的定义。「史诗」是与「用户故事 / 需要」密切相关的。
简略地说，「史诗」是一个更大的「用户故事」，或者说是一个「需要集」，它们通常示意了与产出物相干的原始想法；「用户故事」或称需要，代表着须要交付的解决方案的具体工作项。「史诗」是用于跟踪、治理这些待办事项中工作量较大事务的一种「工具」。一个「史诗」通常蕴含多个「用户故事 / 需要」。
在理论工作中，编写好用户故事并将其拆分为有意义的「史诗」的第一步，是先写好「用户故事」：
Good user stories
好的用户故事遵循 INVEST 规定：
Independent - 独立的
Negotiable - 可协商的
Valuable - 有价值的
Estimable - 可预计的
Small – 小颗粒的（指工作量）
Testable - 可测试的
“小颗粒的”和“有价值的”是用户故事中最要害也最难做好的因素。其中，「有价值的」关系到另一个 V，Vertical 垂直切分。
所谓垂直切分，是指将产品按照其对用户提供的性能点或价值场景，切为不同的模块进行研发进度的跟踪与治理。在很多团队实际中，或者将其称为「产品模块 / 性能组」。而这，正是「史诗」的雏形。
Epic Today
早在 2004 年，Mike Cohn 就在他的开创性著述《用户故事利用》中介绍了史诗 -epic. 在《用户故事、史诗和主题》中，他形容史诗为：用于形容「大故事」的一个标签。彼时，史诗和用户故事的区别次要在于工作量的大小。
然而，当咱们在说“这个需要太大了”，“这条用户故事须要 13 点工作量”等问题时，基本上，咱们是心愿对这类故事作进一步细分的。因而，在起初的实际中，人们逐步抉择将「用户故事」和「史诗」别离应用。
现在，出于汇报工作的目标，产品负责人通常会将「用户故事」演绎为「史诗」，来做工作汇报。如此一来，咱们很可能适度扩大了「史诗」的概念。
例如，咱们可能会把故事演绎为以职能来辨别的「史诗」。例如：服务端、前端、后端、测试等。但这种以横向职能为维度归纳法，只会让咱们写出很蹩脚的「史诗」。
如前文提到的，「史诗」该当是对用户故事的垂直切分：一个史诗中蕴含的泛滥用户故事都服务于同一个性能点或场景。这才是咱们倡议的应用史诗的办法。
事倍功半的「史诗」用法
咱们来举个具体的例子：用户须要通过邮箱重置明码。
那么咱们依照上述两种不同应用办法，会呈现什么样的「史诗」呢？
A：预设 & 演绎
最常呈现的情景是：
- 团队开始预设「史诗」，很可能是依照设计、前端、后端、平安等维度切片；
- 具体到“重置明码的页面”“更改明码的权限管制”之类的需要，更靠近一项具体的工作，而无需用到史诗概念；
- 整个“重置明码”的工作工作量太大，于是团队合成出了一个“与邮件服务集成 ” 的「史诗」；
- 截止到交付时，咱们并没有可能实现整个性能，但在汇报中，咱们仿佛实现了一个「史诗」。
B： 用于形容大型用户故事
最常呈现的情景是：
- 团队并不事后设置「史诗」；
- 「用户故事」不会受到「史诗」的影响。它们仍然保留了原定的编写逻辑和验收规范；
- 团队在疾速辨认出“规模过大”的故事后，将其列为史诗，并对它们作细分提取为新的故事；
- 即时交付时，咱们未能实现整个性能，但此时曾经领有了根据性能因素切分的「故事集」，并能够从新决定优先级，以尽快解决积压。
论断
- 「史诗」并非麻利开发的基本概念，应该按团队理论需要，决定是否应用「史诗」。
- 不要预设「史诗」。即便对用户故事有较清晰的了解，也很难预测「史诗」会否对需要形容及用户故事的编写产生影响。
- 通过用户故事的工作量大小发现史诗。当一个用户故事过于宏大时，通过「史诗」能够疾速辨别其与其余用户故事的不同，便于沟通和工作。
- 辨认积压我的项目的大小。当「史诗」被用来治理一个积压事项时，能够疾速辨认出该积压项可否被宰割成更小的组块。
- 如果因为某种原因须要对故事进行分组，思考是否能够 采纳更精确的术语来称说，例如：模块、主题、里程碑。
- 如果「史诗」被用于汇报工作，须要更关注报告的现实状态；而防止过分关注「史诗」概念，导致的轻重倒置。
- 抉择更好的软件工具，帮忙治理「史诗」或「用户故事」，以晋升团队合作能力。
LigaAI 会继续分享你须要的内容，点击 LigaAI- 新一代智能研发治理平台 在线申请体验咱们的产品，专一灵感 回归价值 享受成绩~
文章起源：thoughtworks
原文作者：Matt Riley