1. 课程导入
在研发团队规模逐渐扩大之后，管理者最常遇到的困境并不是“没有数据”，而是“数据散落在各处，无法回答一个具体问题”。需求在 Jira 里流转，代码在 Git 仓库里提交，构建在 CI 流水线上执行，缺陷在测试环节被记录，但当我们想回答“这个迭代的交付速度是否健康”“哪个环节正在成为瓶颈”“团队承诺的 40 个故事点最终完成了多少”时，往往需要手工导出多张表、拼接多个字段，才能勉强拼出一个答案。Jira 仪表盘与研发效能度量的价值，正是把这种“事后拼凑”变成“随时可读”的持续观测能力。
一、为什么需要仪表盘与效能度量
Jira 本身已经记录了研发过程的原始事实：每个 Issue 的类型、状态、经办人、创建时间、解决时间、故事点、Sprint 归属、优先级等。这些字段单独看只是记录，组合起来就是度量。仪表盘的作用是把这些字段按特定视角聚合，形成可重复查看的视图；效能度量的作用则是从这些视图中提炼出能够指导决策的指标，例如交付周期、吞吐量、在制品数量、缺陷逃逸率、承诺完成率等。
需要强调的是，度量本身不是目的。一个团队如果只盯着“故事点完成数”，很容易出现拆分任务、虚报点数的行为；如果只看“缺陷数量”，也可能导致缺陷被降级或延后记录。因此本课程会反复强调一个原则：指标必须与团队的真实目标对齐，并且要成组观察，而不是孤立地看单一数字。例如，交付周期缩短的同时，如果缺陷逃逸率上升，说明速度的提升可能以质量为代价；吞吐量提高但在制品持续堆积，说明瓶颈可能被推到了下游。
二、本课程的学习目标
完成本课程后，你应该能够独立完成以下几类任务：
- 理解 Jira 中与度量相关的核心字段（状态、状态类别、故事点、Sprint、Resolution、Created/Resolved 时间等）及其语义差异；
- 根据一个具体的研发问题，选择合适的仪表盘图表类型（如累积流图、控制图、燃尽图、筛选结果统计等），而不是随意堆砌 Gadget；
- 使用 JQL 精确筛选数据，并理解筛选器、仪表盘、看板之间的数据关系；
- 计算并解读交付周期、周期时间、吞吐量、在制品、承诺完成率等常用效能指标；
- 识别常见的数据陷阱，例如状态回退、跨 Sprint 遗留、时区与工作日差异、故事点缺失等；
- 把度量结果转化为可执行的改进假设，而不是停留在“看板很好看”的层面。
三、整体框架：从数据到决策的四层结构
本课程的内容组织遵循一条从原始数据到决策动作的链路。理解这条链路，有助于你在后续章节中把每个工具和指标放到正确的位置上。
上图展示了本课程的核心逻辑：数据层是 Jira 中客观存在的字段与历史记录；筛选层决定我们“看哪些数据”，JQL 和筛选器在这里起关键作用；度量层把筛选结果转化为指标；决策层则把指标放回业务语境中，形成改进动作。四层之间不是单向的，决策结果会反过来修正筛选口径和指标定义，这也是为什么度量体系需要持续迭代，而不是一次配置完成就固定不变。
四、一个贯穿课程的示例场景
为了让后续章节的讨论有共同语境，本课程会使用一个假想的研发团队“DEMO 项目组”作为示例。该团队使用 Scrum，Sprint 长度为两周，Jira 中主要 Issue 类型包括 Story、Bug、Task，状态流转为“待办 → 进行中 → 待测试 → 已完成”。假设某个 Sprint 计划承诺 40 个故事点，实际完成 32 个，Sprint 结束时仍有 5 个故事点处于“待测试”状态，另外 3 个故事点未开始。
仅凭这组数字，我们只能得出“完成率 80%”这一个结论。但如果结合状态流转历史，可能会发现：这 5 个“待测试”的故事点平均已经在测试环节停留了 4 天，而团队只有 1 名测试人员；同时，已完成的故事点中，有 3 个曾在“进行中”和“待测试”之间来回跳转。这些信息指向的就不是“团队不努力”，而是测试环节容量不足和状态定义不清导致的返工。后续章节会逐步演示如何用 Jira 仪表盘和 JQL 把这些线索可视化出来。
五、学习建议
本课程不是 Jira 操作手册，也不会停留在“点击哪个按钮”的层面。建议你在学习过程中始终带着一个真实问题，例如“我们团队的交付周期为什么变长了”或“为什么 Sprint 后期总是集中爆发缺陷”。每学完一个指标或图表，就尝试用它回答你的问题，并记录下数据暴露出的异常。度量能力的提升，本质上来自“提问—取数—解读—验证”的循环，而不是记住所有 Gadget 的名称。
下一部分内容将从 Jira 的数据模型开始，帮助你理解仪表盘和度量指标究竟建立在哪些字段之上。