3. 需求工作项类型体系
在 Jira 中，工作项类型（Issue Type）不是简单的标签，而是决定字段布局、工作流、权限方案、看板列映射和报表统计口径的“第一层骨架”。如果类型体系设计混乱，后续的版本管理、跨团队依赖跟踪和度量都会失去可靠的数据基础。本节从标准类型出发，逐步扩展到跨团队场景下的自定义类型，并给出可落地的使用规范。
一、标准工作项类型的职责边界
Jira 默认提供的类型中，最常用的是史诗（Epic）、故事（Story）、任务（Task）、缺陷（Bug）和子任务（Sub-task）。它们之间不是简单的层级关系，而是各自承担不同的管理粒度：
- 史诗（Epic）：一个较大的、可独立交付的价值单元，通常跨越多个迭代，包含若干故事或任务。史诗是版本规划中的“容器”，用于回答“这个版本要交付哪些能力”。
- 故事（Story）：以用户价值为中心的可交付增量，通常能在一个迭代内完成。故事是需求澄清和验收标准的主要载体。
- 任务（Task）：不直接面向最终用户、但必须完成的技术性或事务性工作，例如环境搭建、数据迁移、文档编写。
- 缺陷（Bug）：与预期行为不一致的问题。缺陷需要独立跟踪，因为它涉及复现步骤、严重程度、影响版本和修复版本等专属字段。
- 子任务（Sub-task）：从属于某个父工作项的细分执行项，不能独立存在于版本中，通常用于拆分故事或任务的具体执行步骤。
这里有一个容易被忽视的原则：故事和任务的区别不在于“大小”，而在于“是否直接交付用户价值”。一个需要三天完成的技术重构，如果用户不可见，应建为任务；一个半天就能完成的界面文案调整，如果用户可见，应建为故事。类型选错会直接导致速率（Velocity）统计失真。
二、跨团队场景下的自定义工作项类型
当需求需要多个团队协作时，标准类型往往不够用。典型痛点是：A 团队的故事需要 B 团队提供接口，但 B 团队的工作无法挂在 A 团队的故事下，导致依赖关系只能写在评论里，版本发布时无法自动检查。为此，建议扩展以下自定义类型：
- 跨团队需求（Cross-team Requirement）：用于描述需要两个及以上团队共同交付的需求。它不直接进入某个团队的迭代，而是作为协调层存在，关联各团队的交付故事。
- 接口契约（Interface Contract）：当团队间通过 API、消息或数据文件交互时，用该类型固化接口字段、协议、错误码和版本兼容策略。接口契约的完成是下游团队开始联调的前置条件。
- 依赖项（Dependency）：用于标记“我方的完成依赖于他方的某个交付物”。依赖项应关联到具体的上游工作项，并设置期望交付日期。
- 发布单元（Release Unit）：当多个团队需要同步发布时，用该类型聚合各团队的发布内容，统一记录发布窗口、回滚方案和验证结果。
自定义类型的命名要避免歧义。例如“跨团队需求”不要简写成“需求”，否则会和故事混淆；建议在类型名称前加统一前缀，如“XT-需求”“XT-接口契约”，便于在 JQL 中快速过滤。
三、类型使用规范与配置要点
类型体系建立后，必须配套明确的选用规则，否则团队成员仍会凭习惯随意选择。以下规范可直接作为团队约定使用：
| 判断场景 | 应选类型 | 关键判断依据 |
|---|---|---|
| 用户可见的功能增量，一个迭代内可完成 | 故事 | 有明确用户价值，可写验收标准 |
| 技术重构、环境搭建、文档编写 | 任务 | 用户不可见，但必须完成 |
| 测试发现与预期不符的行为 | 缺陷 | 有复现步骤，需记录影响版本 |
| 需要两个及以上团队共同交付 | 跨团队需求 | 存在跨团队接口或联合发布 |
| 团队间 API/消息/文件交互约定 | 接口契约 | 需要固化字段、协议、错误码 |
| 我方完成依赖他方交付物 | 依赖项 | 有明确上游工作项和期望日期 |
| 多团队同步发布 | 发布单元 | 需要统一发布窗口和回滚方案 |
在 Jira 管理后台配置时，需要注意三个技术要点。第一，工作项类型方案（Issue Type Scheme）要按项目绑定，跨团队项目应包含自定义类型，而普通团队项目可以只保留标准类型，避免选择过载。第二，字段配置（Field Configuration）要按类型区分：缺陷必须显示“影响版本”和“修复版本”，接口契约必须显示“接口版本”和“联调日期”，这些字段不应出现在故事或任务上。第三，工作流（Workflow）可以按类型绑定不同流程，例如缺陷需要“重新打开”状态，而故事通常不需要。
四、类型与版本管理的衔接
类型体系最终要服务于版本管理。在版本（Version）视图中，史诗和跨团队需求通常作为版本范围的顶层条目；故事和任务挂在史诗下，构成可交付内容；缺陷单独统计，用于判断版本质量是否达标；依赖项和接口契约则作为发布前的检查项。一个可操作的版本发布检查规则是：版本下所有“接口契约”必须处于“已确认”状态，所有“依赖项”必须处于“已交付”状态，否则版本不允许进入发布评审。
此外，建议在 JQL 中建立常用过滤器，例如：
project = "XT-Platform" AND issuetype = "跨团队需求" AND fixVersion = "R2024.06" ORDER BY priority DESC
project = "XT-Platform" AND issuetype = "依赖项" AND status != "已交付" AND "期望交付日" < endOfWeek()第一条用于查看某版本下的全部跨团队需求，第二条用于在每周例会上快速暴露即将逾期且未交付的依赖项。通过类型与字段的配合，跨团队协作中的“口头承诺”被转化为可查询、可预警的结构化数据，这正是工作项类型体系设计的最终目的。