当我们开始了解和采用「敏捷开发」的时候，时常会看到一个略显陌生的概念「史诗」。或许因为翻译的问题，这个概念在中文语境里有些难懂，在实际应用中，理解更是五花八门。为此，小编找到了这篇详细介绍“何为「史诗」”的文章，推荐给大家。
开始之前，我们先看看「史诗」的定义。「史诗」是与「用户故事/需求」密切相关的。
简单地说，「史诗」是一个更大的「用户故事」，或者说是一个「需求集」，它们通常表示了与产出物相关的原始想法；「用户故事」或称需求，代表着需要交付的解决方案的具体工作项。「史诗」是用于跟踪、管理这些待办事项中工作量较大事务的一种「工具」。一个「史诗」通常包含多个「用户故事/需求」。
在实际工作中，编写好用户故事并将其拆分为有意义的「史诗」的第一步，是先写好「用户故事」：
Good user stories
好的用户故事遵循 INVEST 规则：
Independent -独立的
Negotiable -可协商的
Valuable -有价值的
Estimable -可估计的
Small - 小颗粒的（指工作量）
Testable -可测试的
“小颗粒的”和“有价值的”是用户故事中最关键也最难做好的要素。其中，「有价值的」关系到另一个V，Vertical 垂直切分。
所谓垂直切分，是指将产品依照其对用户提供的功能点或价值场景，切为不同的模块进行研发进度的跟踪与管理。在很多团队实践中，或许将其称为「产品模块/功能组」。而这，正是「史诗」的雏形。
Epic Today
早在2004年，Mike Cohn就在他的开创性著作《用户故事应用》中介绍了史诗-epic. 在《用户故事、史诗和主题》中，他描述史诗为：用于描述「大故事」的一个标签。彼时，史诗和用户故事的区别主要在于工作量的大小。
然而，当我们在说“这个需求太大了”，“这条用户故事需要13点工作量”等问题时，根本上，我们是希望对这类故事作进一步细分的。因此，在后来的实践中，人们逐渐选择将「用户故事」和「史诗」分别使用。
如今，出于汇报工作的目的，产品负责人通常会将「用户故事」归纳为「史诗」，来做工作汇报。如此一来，我们很可能过度扩展了「史诗」的概念。
例如，我们可能会把故事归纳为以职能来区分的「史诗」。例如：服务端、前端、后端、测试等。但这种以横向职能为维度归纳法，只会让我们写出很糟糕的「史诗」。
如前文提到的，「史诗」应当是对用户故事的垂直切分：一个史诗中包含的众多用户故事都服务于同一个功能点或场景。这才是我们建议的使用史诗的方法。
事半功倍的「史诗」用法
我们来举个具体的例子：用户需要通过邮箱重置密码。
那么我们按照上述两种不同使用方法，会出现什么样的「史诗」呢？
A：预设 & 归纳
最常出现的情景是：
-
团队开始预设「史诗」，很可能是按照设计、前端、后端、安全等维度切片；
-
具体到“重置密码的页面”“更改密码的权限控制”之类的需求，更接近一项具体的任务，而无需用到史诗概念；
-
整个“重置密码”的任务工作量太大，于是团队分解出了一个“与邮件服务集成"的「史诗」；
-
截止到交付时，我们并没有能够完成整个功能，但在汇报中，我们似乎完成了一个「史诗」。
B：用于描述大型用户故事
最常出现的情景是：
-
团队并不预先设置「史诗」；
-
「用户故事」不会受到「史诗」的影响。它们依然保留了原定的编写逻辑和验收标准；
-
团队在快速识别出“规模过大”的故事后，将其列为史诗，并对它们作细分提取为新的故事；
-
即时交付时，我们未能完成整个功能，但此时已经拥有了依据功能要素切分的「故事集」，并可以重新决定优先级，以尽快处理积压。
结论
-
「史诗」并非敏捷开发的基本概念，应该按团队实际需求，决定是否使用「史诗」。
-
不要预设「史诗」。即使对用户故事有较清晰的理解，也很难预测「史诗」会否对需求描述及用户故事的编写产生影响。
-
通过用户故事的工作量大小发现史诗。
当一个用户故事过于庞大时，通过「史诗」可以快速区分其与其他用户故事的不同，便于沟通和工作。 -
识别积压项目的大小。
当「史诗」被用来管理一个积压事项时，可以快速识别出该积压项可否被分割成更小的组块。 -
如果由于某种原因需要对故事进行分组，思考是否可以采用更准确的术语来称呼，例如：模块、主题、里程碑。
-
如果「史诗」被用于汇报工作，需要更关注报告的理想状态；而避免过分关注「史诗」概念，导致的本末倒置。
-
选择更好的软件工具，帮助管理「史诗」或「用户故事」，以提升团队协作能力。
LigaAI 新一代智能研发协作平台 让 AI 为您的研发团队提供个性化、智能化的项目协作体验，化繁就简，帮助开发者专注、高效的创作！关注 LigaAI@csdn，后续我们还会分享更多与敏捷开发、项目管理相关的文章~
本文译自：https://www.thoughtworks.com/insights/blog/user-stories-tale-epic-confusion
原文作者: Matt Riley
标签：史诗,故事,到底,用户,工作量,敏捷,团队,我们 来源： https://blog.csdn.net/LigaAI/article/details/123042364
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。