在敏捷软件开发中，史诗＆故事都是常用的术语。对于管理敏捷软件开发来说，Choerodon猪齿鱼是一个很好的工具，为敏捷术语和功能提供了非常广泛的实践方法，例如：史诗，故事、任务、子任务和缺陷，这些都是Choerodon中的问题类型。
- 史诗：是一个功能集或是一个大的用户故事，但因为颗粒度太大而无法适应冲刺，它可以分解为许多较小的故事；
- 故事：是简短的用户需求，足够小以适合冲刺；
- 任务：是完成用户需求的过程性的工作，表示用户故事开发任务的完成；
- 子任务：子任务通常是故事或任务的具体拆分，由单人承接，而且通常能在短时间内完成；
- 缺陷：主要针对测试中的缺陷或者已发布版本的缺陷；
本文将详细为大家介绍敏捷中史诗和故事以及它们在敏捷中的具体使用规范。
什么是史诗？
史诗是一个大的故事，当一个功能具有多个场景时，该功能则需要在史诗层面进行多种实现。史诗代表的通常是与特定结果密切相关的原始想法，与该史诗相关联的用户故事则代表需要交付的解决方案的各个方面。总的来说，通过史诗可以跟踪待办事项中比较大的用户需求，史诗中包含多个小的产品功能的用户故事，这让用户需求更加具有层次结构。
如何编写史诗？
对于史诗的编写，目前还没有标准格式，一些团队会使用熟悉的用户故事格式，也有一些团队则用简短的短语表示史诗。
在命名史诗时，请牢记以下两点：
1.它是开发或需求的核心内容；
2.编写时使用组织中的每个人都可以理解的语音文字，以免产生歧义；
因为史诗是编写用户故事时要参考的内容，并且在编写用户故事时还要参考所有团队成员的意见，所以正确的编写史诗并将详细信息在史诗中体现非常重要，这有助于避免团队中的许多冲突和对产品功能的误解。
用史诗介绍开发的新功能时，需要包括开发此功能的原因、需要解决的用户需求以及新功能的度验收量标准。此外，该功能的任何文档或早期的思路，可以向团队简单介绍，或者提供清晰的图片和信息。注意：团队对功能达成共识和目标是成功交付的关键。
Choerodon中的史诗示例：
- 史诗01：向用户提供排序和优先级选项，以轻松管理需求
- 用户故事01：作为发布经理，我希望将发布映射到不同的sprint，并看到每个故事的优先级。
- 用户故事02：作为系统管理员，我拥有优先处理产品需求的权限。
- 用户故事03：作为用户，我可以标注需求的优先级，并实现简单的拖放操作重新排序需求。
编写史诗时需要注意的是：
谨慎思考 在编写史诗时，可以先撰写项目构想的草稿，并需要思考最有必要的内容以及在以后的开发中包含的内容。这些都需要仔细考虑。
逻辑清晰 在编写后续的史诗时，应该根据先前的主题来创建史诗，前后的史诗需要合乎逻辑且一致。
结合测试 史诗不只是从大的故事进行思考，它分解的每个功能还需要在测试中可用。
参考专家人士的意见 在编写过程中不应仅依靠个人或团队成员的眼光和思路，还需要参考专家人士的意见，阅读专业人士的的博客或他们推荐的书籍。他们的工作经验和意见能使史诗更加客观，也能让团队成员获得专业的经验和技能。
史诗是项目计划过程中重要的组成部分，有了史诗，团队成员和利益相关者可以看到产品真正的目的和用户需求。正确的史诗是进一步项目开发甚至产品研发的好帮手。
什么是用户故事？
用户故事是基于史诗进行分解的，反映的是用户需求和用户可以得到的价值。它们从用户的角度描述功能的各个部分。在敏捷开发过程中，当我们开始站在用户的角度上思考时，即使这个功能不是当前解决方案的范畴，我们仍需要建立用户可以操作的行为场景。例如，我们正在针对共享照片和视频的特定问题制定解决方案，根据经验我们按照预期的方式执行所有操作，但是用户第一次使用并且不了解产品，可能查找不到特定角色对应的照片。为了避免这种情况，在用户故事中从用户角度清楚地说明所需的功能非常关键。
如何编写用户故事
在敏捷方法论中，团队构建的所有内容都应围绕用户，这里的团队指的是产品经理、客户、利益相关者还有产品的最终用户。为了深度了解用户的需求和痛点，在开始编写用户故事之前，需要确定好产品的角色。以下是编写用户故事时广泛使用的模板：
“ 作为一名 <角色或角色>，我可以 <目标/需要> 这样说 <为什么>”
或者，在另一种情况下：
“作为 <特定的用户类别>，我希望 <能够执行/执行某项操作>， 以便 <获得某种形式的价值或收益>”
上面的描述为产品用户制定了业务价值。除此之外，用户故事的魅力在于，它不仅制定了业务价值，而且还制定了开发和测试的要求。通过简单的描述，添加产品功能的验收标准等描述，以总结需要完成的所有任务。
以下Choerodon中某个项目的用户故事的简短形式：
作为夜晚驾驶的驾驶员，我想迅速找到最近的优质加油站，以补充高品质的汽油。
验收标准：
- 作为开灯的司机，我可以看到所有即将到来的加油站。
- 点击“Ctrl+T”，我可以选择适合我的加油站品牌的加油站。
- 到达加油站，我可以看到即将到来的选定品牌的加油清单。
- 点击“M”键，我可以看到最近在地图上选择的加油站。
用户故事的重点是从用户的角度清楚地说明所需的功能，需要正确的理解用户需求并详细的表达出来。编写用户故事时需要注意：
用户故事≠任务 用户故事不是任务。在实际开发中，一个故事可能需要数百个任务才能成功交付，任务与执行有关，而用户故事是根据用户需求定义的。在编写故事时，应着重于提供有关产品功能的信息。
故事简明扼要 故事必须简单而准确。只需使用简单准确的语言即可，有助于团队成员和利益相关者深入了解用户需求，避免花时间澄清用户故事中不清楚的地方，比如术语和首字母缩写词等。
了解用户 在开始编写用户故事之前，都需要收集一组关键用户（理想情况下是产品的角色用户），了解他们的个人资料、观点、对产品的期望以及相关的“痛点”，以帮助更好地了解用户及其需求。
大胆思考 当将产品描述为用户故事放到待办事项中时，“没有预算，时间周期不允许，可行性低或成本高等”会限制产品的思维。正确的做法是大胆思考 ，将用户故事维护到待办事项列表，从产品的清晰度、用户愿景方面获得的价值。
用户故事提供了一种快速而准确地描述软件产品或系统功能的好方法，在产品规划会、产品迭代会中具有主导和输出作用。在这些会议过程中，用户故事需要以紧凑、结构化的方式阐明思想的提要。
故事地图
根据敏捷的定义，在Choerodon中我们使用故事地图的形式来体现史诗和用户故事的价值。
故事地图的优势：
- 将史诗用作业务价值的容器；
- 根据产品版本得到横向流程；
- 快速制定出产品的蓝图，得到mvp版本的制作周期；（关于MVP的介绍可以参考《MVP：平衡“可行性”和“最小化”》）；
- 以故事为中心，使开发人员的精力全部集中到重点功能上；
- 使用增量来定期检查并调整项目进度；
总结
敏捷开发关注于快速且持续地交付给用户高价值、高质量、可用的产品功能。通过史诗和用户故事梳理用户需求、识别用户角色、梳理用户故事逐步完善更多细节，使执行的故事足够短小、简单，能在单个迭代期内完成，达到快速交付的目的。