1. 课程导入与全景认知
在开始学习具体操作之前，我们需要先建立一张“全景地图”。很多团队使用 Jira 多年，却始终停留在“建任务、拖状态、看板子”的层面，根本原因不是工具不熟，而是没有把 Jira 放进敏捷研发与交付治理的整体框架中去理解。本课程的目标，是让你不仅会用 Jira，更能用 Jira 支撑一条从需求到交付、可度量、可治理的研发链路。
一、Jira 在敏捷研发中的真实定位
Jira 本质上是一个工作项（Issue）驱动的协作与流程管理系统。它的核心抽象只有三层：工作项、工作流、看板/报表。所有敏捷实践——需求管理、迭代规划、缺陷跟踪、发布管理——最终都落在“工作项如何流动”这件事上。
因此，Jira 在敏捷研发中的定位可以概括为三点：
- 协作中枢：产品、开发、测试、运维围绕同一批工作项对齐信息，减少口头传递和文档割裂。
- 流程载体：把团队约定的研发流程固化为工作流状态与流转规则，让流程可执行、可追溯。
- 度量底座：通过状态变更、时间戳、字段数据，产出燃尽图、累积流图、周期时间等治理指标。
需要强调的是，Jira 不是敏捷本身。敏捷是一种以迭代、反馈、持续改进为核心的工作方式，Jira 只是承载这种方式的工具。工具用得好，流程会更透明；流程本身不合理，工具只会把混乱放大。这是本课程反复强调的判断原则。
二、核心价值：从“记录工具”到“交付治理平台”
如果把 Jira 只当作任务记录本，它的价值非常有限。真正的价值在于它能把研发过程中的状态、时间、责任人、依赖关系沉淀为可分析的数据。下面这张图展示了 Jira 从工作项输入到治理输出的整体数据链路，也是本课程后续章节的结构主线。
这张图说明了本课程的组织逻辑：底层是项目、权限、字段、工作流、自动化、报表等配置能力；中层是工作项在流程中的流转；上层是数据沉淀与治理决策；而治理结果又会反向调整输入与流程，形成闭环。学习 Jira，本质上就是逐层打通这条链路。
三、学习路径：从会用走向会治理
基于上述链路，本课程的学习路径分为四个阶段，建议按顺序推进：
- 基础认知与项目搭建：理解 Jira 的产品体系（Jira Software、Jira Service Management 等），掌握项目创建、项目类型选择、成员与角色配置。这一阶段的目标是“能建起来”。
- 工作项与工作流设计：掌握 Issue 类型、字段方案、工作流状态与转换、看板列映射。这一阶段的目标是“流程能跑通”。
- 敏捷执行与度量：掌握 Backlog 管理、Sprint 规划、故事点估算、燃尽图与累积流图解读。这一阶段的目标是“数据能说话”。
- 交付治理与持续改进：掌握 JQL 查询、仪表盘设计、自动化规则、发布管理与复盘机制。这一阶段的目标是“问题能闭环”。
四、交付治理框架总览
交付治理不是额外增加的管理动作，而是把研发过程中本来就存在的信息，用统一的口径呈现出来，并据此做决策。一个可落地的交付治理框架通常包含四个维度：
| 治理维度 | 关注问题 | Jira 中的主要载体 |
|---|---|---|
| 流动效率 | 工作项是否顺畅流动，哪里堆积 | 累积流图、周期时间、WIP 限制 |
| 迭代节奏 | 每个 Sprint 是否按承诺交付 | 燃尽图、Sprint 报告、速度 |
| 质量与缺陷 | 缺陷产生与修复的趋势如何 | 缺陷密度、重开率、Bug 分布 |
| 可预测性 | 交付时间是否可预估 | 历史速度、吞吐量、发布燃尽 |
以“流动效率”为例，假设某团队一个 Sprint 内 12 个工作项的平均周期时间为 6.5 天，其中“进行中”状态平均停留 4.2 天，“测试”状态平均停留 1.8 天。通过累积流图可以观察到“测试”列在 Sprint 后半段明显变宽，说明测试环节成为瓶颈。此时治理动作不是催测试人员加班，而是检查：测试环境是否排队、验收标准是否在开发前明确、是否存在大量返工。这就是从数据到判断再到改进的完整治理逻辑。
五、本课程的学习方法建议
最后给出三条贯穿全课程的学习建议：
- 先理解概念，再动手配置：Jira 的配置项很多，但核心概念只有工作项、工作流、方案绑定三类。概念清晰后，配置只是选择。
- 用真实项目练手：建议用一个模拟项目（例如“移动端订单系统迭代”）贯穿全课程，从建项目到出报表完整走一遍。
- 始终追问“这个配置解决什么问题”：任何字段、状态、自动化规则，都应该能回答它服务于哪个治理目标。无法回答的配置，往往是冗余的。
当你完成本课程后，应该能够独立完成：为一个 5～9 人的敏捷团队搭建 Jira 项目、设计符合其研发流程的工作流、规划并执行 Sprint、通过 JQL 与仪表盘输出治理视图，并在复盘中基于数据提出可执行的改进项。这就是本课程希望达成的能力目标。