StatusPath Reports使用指南
Jira 状态流转方向报表模板
Jira 状态流转方向报表应从可编辑矩阵开始，而不是从“返工”这类宽泛标签开始。为每个 From → To 路径命名，决定它是否计入指标，指定负责人，并保留一个 Jira 历史记录（History）样本。然后对同一工作项范围和历史窗口运行流转次数（Transition Count），使矩阵中的每一行都能与一个流转方向列核对。
可编辑的状态流转方向矩阵
把下表复制到团队评审文档中，并在运行报表前替换所有方括号字段：
| From → To 路径 | 业务含义 | 是否计入指标 | 计数规则 | 负责人 | 核验样本 | 后续行动 |
|---|---|---|---|---|---|---|
[来源状态] → [目标状态] |
[该流转为何重要] |
[是 / 否 / 对照] |
[每次事件 / 首次事件 / 受影响工作项] |
[角色或团队] |
[Jira Key] |
[评审、修复或监控] |
[来源状态] → [目标状态] |
[该流转为何重要] |
[是 / 否 / 对照] |
[每次事件 / 首次事件 / 受影响工作项] |
[角色或团队] |
[Jira Key] |
[评审、修复或监控] |
[来源状态] → [目标状态] |
[该流转为何重要] |
[是 / 否 / 对照] |
[每次事件 / 首次事件 / 受影响工作项] |
[角色或团队] |
[Jira Key] |
[评审、修复或监控] |
状态名称应保持可编辑，并以实际工作流为准。Atlassian 将 Jira 工作流描述为由状态和流转连接起来的过程，其工作流管理指南说明，Transition 是状态之间的单向路径。因此，In Progress → In Review 与 In Review → In Progress 是两个不同的流转，即使它们涉及相同的状态。
如需先筛选重复阶段，再诊断具体方向，请阅读如何用状态进入次数（Status Count）和流转次数分析 Jira 返工。
Jira 示例：12 个 Bug 和 6 条已命名路径
受控的 SR 项目包含 SR-4601 到 SR-4612 这 12 个 Bug。本例计算完整历史，关闭裁剪历史（Trim History）。8 个 Bug 遵循标准路径，2 个各从 In Review 返回一次，1 个从 QA 返回两次，另 1 个在 Done 后被重新打开。
团队矩阵如下：
| From → To 路径 | 业务含义 | 是否计入 | 计数规则 | 负责人 | 核验样本 | 后续行动 |
|---|---|---|---|---|---|---|
In Review → In Progress |
Bug 从 In Review 退回 In Progress 继续实现 | 是 | 计算每次匹配事件 | 工程负责人 | SR-4609 |
评审退回原因 |
QA → In Progress |
Bug 从 QA 退回 In Progress | 是 | 计算每次匹配事件 | QA 负责人 | SR-4611 |
评审两次 QA 退回 |
Done → Reopened |
已完成工作被重新打开 | 是 | 计算每次匹配事件 | 交付负责人 | SR-4612 |
确认重新打开分类 |
In Progress → In Review |
进入 In Review 的正向对照路径 | 对照 | 不计入返工总数 | 工程负责人 | SR-4601 |
与退回量对比 |
In Review → QA |
进入 QA 的正向对照路径 | 对照 | 不计入返工总数 | Review 负责人 | SR-4601 |
检查预期后续流转 |
QA → Done |
进入 Done 的正向对照路径 | 对照 | 不计入返工总数 | QA 负责人 | SR-4601 |
检查完成路径 |
这 12 个 Bug 的流转历史数量不大，可以逐项审计：
| Bug | 工作流路径 | Bug 数量 |
|---|---|---|
SR-4601–SR-4608 |
In Progress → In Review → QA → Done |
8 |
SR-4609、SR-4610 |
In Progress → In Review → In Progress → In Review → QA → Done |
2 |
SR-4611 |
In Progress → In Review → QA → In Progress → In Review → QA → In Progress → In Review → QA → Done |
1 |
SR-4612 |
In Progress → In Review → QA → Done → Reopened → In Progress → In Review → QA → Done |
1 |
核对每个 Bug 的报表行
受控工作项范围的流转次数表格应生成以下 6 列：
| Bug | In Review → In Progress | QA → In Progress | Done → Reopened | In Progress → In Review | In Review → QA | QA → Done |
|---|---|---|---|---|---|---|
SR-4601 |
0 | 0 | 0 | 1 | 1 | 1 |
SR-4602 |
0 | 0 | 0 | 1 | 1 | 1 |
SR-4603 |
0 | 0 | 0 | 1 | 1 | 1 |
SR-4604 |
0 | 0 | 0 | 1 | 1 | 1 |
SR-4605 |
0 | 0 | 0 | 1 | 1 | 1 |
SR-4606 |
0 | 0 | 0 | 1 | 1 | 1 |
SR-4607 |
0 | 0 | 0 | 1 | 1 | 1 |
SR-4608 |
0 | 0 | 0 | 1 | 1 | 1 |
SR-4609 |
1 | 0 | 0 | 2 | 1 | 1 |
SR-4610 |
1 | 0 | 0 | 2 | 1 | 1 |
SR-4611 |
0 | 2 | 0 | 3 | 3 | 1 |
SR-4612 |
0 | 0 | 1 | 2 | 2 | 2 |
| 列合计 | 2 | 2 | 1 | 17 | 15 | 13 |
验算如下：
已定义的返工/重新打开事件 = 2 + 2 + 1 = 5 次事件
受影响 Bug = SR-4609、SR-4610、SR-4611、SR-4612 = 4 个 Bug
In Progress → In Review = 8 + 2 + 2 + 3 + 2 = 17
In Review → QA = 8 + 1 + 1 + 3 + 2 = 15
QA → Done = 8 + 1 + 1 + 1 + 2 = 13
5 次事件并不等于 5 个受影响 Bug：SR-4611 贡献了 2 次 QA → In Progress。当决策同时需要频率和覆盖范围时，应同时保留事件总数和不同工作项数量。
在 StatusPath Reports 中配置报表
1. 固定问题和矩阵
先决定指标计算事件数、受影响工作项数，还是同时计算两者。把正向路径标记为对照，不要悄悄把它们加入“返工”总数。记录准确的 Jira 状态名称；不要假定 Review、In Review、Code Review 和 Waiting for Review 可以互换。
2. 选择 12 个 Bug 的工作项范围
可以使用 Project、已保存 Filter 或 JQL 数据源。本例使用：
project = SR
AND issuetype = Bug
AND issuekey IN (
SR-4601, SR-4602, SR-4603, SR-4604, SR-4605, SR-4606,
SR-4607, SR-4608, SR-4609, SR-4610, SR-4611, SR-4612
)
ORDER BY issuekey ASC
Atlassian 的 JQL 运算符参考说明了 CHANGED、FROM、TO、BEFORE、AFTER 和 DURING 等历史条件。Atlassian 文档说明 JQL 用于筛选匹配的工作项；文档未说明 JQL 会输出逐行发生次数。评审需要逐工作项次数时，应使用流转次数。
3. 明确历史窗口
这个完整历史示例关闭裁剪历史。如果评审只覆盖某个时期，应在运行前记录准确的起止边界。改变已选工作项范围与改变计算历史窗口回答的是不同问题；报表设置与范围说明了两者的区别。
4. 运行流转次数并选择明确列
选择 流转次数，切换到 Table 视图，并保留 6 个已命名的流转方向列。Transition 列来自所选工作项范围的计算历史中实际存在的流转，因此完全没有匹配事件的路径可能不会作为动态列出现。
本任务不要使用 Status Group。当前流转次数使用明确的 来源状态 → 目标状态 列；流转次数不支持 Status Group。准确行为见列与分组。
5. 核对各列与受影响 Bug
对每个方向列求和并与矩阵对比。然后分别把 3 个计入指标的列筛选为大于 0，收集匹配的 Bug Key，再对它们的并集去重。列筛选之间使用 AND，因此同时应用三列筛选会在本例中错误地得到 0 行。受控结果是 4 个受影响 Bug 中发生 5 次计入事件，正向对照分别为 17、15 和 13。
6. 核验代表性的 Jira 历史
至少检查一条正常路径（SR-4601）、一次 Review 退回（SR-4609）、两次 QA 退回（SR-4611）以及一条重新打开路径（SR-4612）。Atlassian 说明，工作项的 Activity → Jira 历史记录会记录字段变更和工作流流转。StatusPath 的 Issue Activity可以提供当前工作项的聚焦流转次数视图，而 Jira 历史记录仍是需要检查的源记录。
7. 保存定义并导出证据
把矩阵与已命名的报表配置放在一起。审核人需要计数明细时，可导出 CSV 或 XLSX；导出文档说明当前表格导出行为。已保存配置可以针对持续变化的 Jira 数据重新运行，因此应为导出的证据单独记录日期。
常见错误
把每个非正向流转都叫作返工
流转方向本身不能说明原因。应通过矩阵区分有效例外、自动化、取消、已批准的重新打开和团队定义的返工。
把 5 次事件报告成 5 个 Bug
SR-4611 有两次 QA 退回。事件数是 5，但只有 4 个不同 Bug 存在计入指标的流转。
使用状态进入次数推断方向
重复进入 In Progress 不能说明此前处于哪个状态。应使用对应的 From → To 流转次数列。
期望 JQL 输出包含发生次数列
Atlassian 文档说明 JQL 用于筛选匹配的工作项；文档未说明 JQL 会提供逐行发生次数列。该评审应使用流转次数取得计数输出。
使用 Status Group 合并流转列
当前流转次数不支持 Status Group。每个 From → To 流转都应保持明确，只在书面评审计算中组合选定列。
在核对之间改变范围或裁剪历史
矩阵、汇总表和 Jira 历史记录样本应使用相同的工作项范围与历史边界。
常见问题
每个 Jira 反向流转都是返工事件吗？
不是。团队必须定义哪些路径计入指标，并核验代表性工作项。看似反向的流转也可能是有效工作流路径，不一定代表缺陷或失败。
为什么有 5 次事件，却只有 4 个受影响 Bug？
因为 SR-4611 发生了两次 QA → In Progress 流转。事件总数计算发生次数；受影响 Bug 总数计算至少存在一次计入事件的不同工作项。
JQL 可以计算每个 Bug 的流转次数吗？
Atlassian 文档说明 JQL 可筛选历史满足 CHANGED FROM 和 TO 等条件的 Bug；文档未说明 JQL 会提供可复用的逐行发生次数输出。该评审应运行流转次数，并在 Jira 历史记录中核验。
为什么缺少某个 Transition 列？
已选工作项范围或计算历史窗口中可能没有匹配流转。修改指标定义前，应先确认准确状态名称、工作项范围和裁剪历史边界。
流转次数可以使用 Status Group 吗？
当前报表不支持。流转次数提供明确的方向列。要让矩阵适配不同工作流，应编辑状态名称，而不是声称产品存在分组后的 Transition 列。
相关指南
- 如何用状态进入次数和流转次数分析 Jira 返工
- Jira 工作流报表指南：从范围到导出
- Jira Sprint 工作流分析：状态停留时间（Time in Status）、返工和趋势
- 如何分析 Jira 中的 QA 或测试阶段瓶颈
把状态流转标签变成可审计指标
在 Atlassian Marketplace 试用 StatusPath Reports，对受控 Jira 工作项范围运行流转次数，核对明确的 From → To 路径，并保留团队可编辑矩阵背后的证据。