在敏捷开发实践中，团队常面临工作项分类的挑战。本文基于行业实践探讨 Epic（史诗）、User Story（用户故事）、Task（任务）、Sub-Task（子任务）及 Engineering Task（工程任务）的界定标准与协作逻辑，并结合 Jira 工具应用场景展开分析。
一、工作项定义体系
1.史诗（Epic）
史诗是一个大型工作项，通常代表一个重要的功能或项目阶段。作为最高层级的用户用例集合，它可以被拆解为多个用户故事，以便在多个迭代中逐步完成。史诗的核心价值在于为产品路线图提供战略视角。典型示例包括”用户认证系统”等跨功能模块。
2.用户故事（User Story）
用户故事是从最终用户角度描述的功能需求，通常是团队在一个迭代中可以完成的工作单位，保持独立可交付特性。它们可以帮助团队理解用户的需求和期望。例如在”用户认证系统”史诗下，可拆解为以下用户故事：
- 用户登录界面
- 密码找回流程
- 多次尝试失败后锁定帐户
- 第三方登录支持
3.子任务（Sub-Task）
子任务是更小的工作单位，用于将较大的工作项拆解为可管理的部分。它们通常没有故事点估算，且一般不超过一天的工作量。在回顾会议中，团队可以通过统计子任务的数量或时间估算，评估用户故事的故事点估算是否准确，并进行相应调整。
以上面提到的其中一个用户故事“用户登录界面”为例，子任务可拆解为：
- 设计登录页面。
- 切割 SVG 图标和图像。
- 实现登录页面 HTML/CSS/JS。
- 创建 SQL 脚本来创建表。
- 为存储过程创建 SQL 脚本。
- 为用户资源创建 web 服务 REST API。
- 将登录页面连接到 web 服务 REST API
4.工程任务（Engineering Task）
区别于用户导向的工作项，这类任务聚焦技术基础设施建设，例如：
- 创建 GitHub 代码仓库
- 配置云服务平台（GCP/AWS）
- 建立 Jenkins 持续集成管道
- 系统架构设计评审等
二、工具层面的协作逻辑
在 Jira 项目管理系统中，用户故事与工程任务作为同级工作项存在，均可关联至特定史诗。这种设计允许团队明确区分用户需求与技术债务：
- 用户故事反映外部价值交付
- 工程任务体现内部技术需求
二者共享子任务分解机制，但在看板视图中的呈现方式存在差异——子任务在工作模式和报表模式可见，而计划模式仅显示父级工作项。
三、实践争议与解决方案
关于工程任务的归类问题存在两种观点碰撞：
- 价值驱动派主张：
所有工作项都应体现用户价值，建议将工程任务转化为用户故事形式，通过子任务分解并与相关史诗关联。 - 技术现实派认为：
部分技术工作（如架构重构、数据库迁移、API 版本控制）难以直接对应具体用户故事，需保持独立任务形态。这种做法既能确保技术负债可视化，又可帮助产品负责人全面评估里程碑进度。
四、最佳实践建议
- 跨团队协作时，可将复杂故事升级为史诗，拆解为多个子故事分配给不同团队
- 单团队开发场景下，优先采用子任务机制保持工作项简洁
- 工程任务应尽早列入产品待办列表，采用斐波那契数列估算以提高计划可见性
- 通过迭代回顾会议持续校准估算模型，结合速率指标优化故事点分配
该分级体系的价值在于建立统一的工作语言，既保证业务价值的可追溯性，又为技术复杂性提供管理空间。团队可根据项目特征灵活调整分类粒度，关键是在价值交付与技术卓越之间保持动态平衡。
五、ONES 提供 Jira & Confluence 迁移解决方案
作为国内领先的企业级研发管理平台，ONES 同样提供了多层级任务拆分功能，不仅可以将大任务拆分成小任务，还可以将需求拆解成具体的研发、测试任务，帮助团队做好需求收集和任务拆分。
如果您有 Jira & Confluence 迁移需求，可点击下方链接免费获取《企业级研发管理系统迁移指南》，希望这份指南能够帮助您评估和选择最适合您团队的迁移方式。
>>> 免费获取《企业级研发管理系统迁移指南》：https://ones.cn/migration/guide
阅读指南还可获取：
Jira 和 ONES Project 功能对比表
Confluence 和 ONES Wiki 功能对比表
从 Jira 到 ONES Project 的数据迁移效果图
从 Confluence 到 ONES Wiki 的数据迁移效果图
