StatusPath Reports使用指南
如何在 Jira Time in Status 报表中创建状态分组
要创建有用的 Jira 状态分组，应先定义分析阶段，再配置报表。把每个纳入的 Jira 状态映射到命名分组，记录有意排除项，并在验收时保留基础状态列。Time in Status、Average Time in Status 和 Status Count 可以配置 Status Group；Status Entry Date 与 Transition Count 不显示 Status Group，Time in Assignee 则使用 Assignee Group。未映射状态不会自动进入任何分组。本 Time in Status 示例使用 Code Review + Peer Review = Review、QA + UAT = Validation。
Status Group 是分析映射，不是 Jira 工作流修改
Atlassian 把 Jira 工作流定义为工作项经过的一组状态和流转。这些 Jira 状态仍是历史数据来源。在 StatusPath Reports 中创建 Status Group 不会重命名 Jira 状态、增加流转或修改工作流。
对于 company-managed Board，Atlassian 还说明管理员可以把多个 Jira 状态映射到同一个 Board 列。Jira Board 列与 StatusPath Status Group 可以使用相似的阶段名称，但它们位于不同配置界面，是两份独立定义。StatusPath 创建 Status Group 时不会读取或继承 Board 列映射，也不会把分组写回 Jira。如果报表需要与 Board 对齐，应分别记录两份配置。
本文负责状态映射的设计与验算方法；当前 Columns Manager 控件说明见列和分组。
真实 Jira 场景：用一个映射维护两个工作流
一名 PMO 需要为 Platform 项目和 Storefront 项目维护一份共享的报表阶段定义。两个工作流使用不同的详细状态名称：
| 项目工作流 | Review 阶段状态 | Validation 阶段状态 |
|---|---|---|
| Platform | Code Review | QA |
| Storefront | Peer Review | UAT |
报表映射约定为：
| Status Group | 纳入的 Jira 状态 | 定义 | 有意排除 |
|---|---|---|---|
| Review | Code Review、Peer Review | 处于项目特定评审阶段的时间 | In Progress、Blocked |
| Validation | QA、UAT | 处于项目特定验证阶段的时间 | Waiting for QA、Done |
这些排除是有意为之。Review + Validation 并不等于完整工作流生命周期。 未映射状态不会自动进入其中任何一个分组。如果以后决定把 Waiting for QA 纳入 Validation，这是一项需要版本记录的定义变更，而不是无关紧要的标签编辑。
可以使用Jira 工作流报表完整指南把总体、选择窗口、历史窗口、指标、Calendar 和输出定义与这份映射保存在一起。
验收时全程使用同一份报表配置：
| 设置 | 值 |
|---|---|
| Report | Time in Status |
| 工作项范围 | key in (PLAT-201, PLAT-202, SHOP-301, SHOP-302) ORDER BY key ASC |
| Work item date range | 空 |
| Trim History | 关闭 |
| Calendar | Always / elapsed time |
| Format | Decimal Hours |
| 可见基础状态列 | Code Review、Peer Review、QA、UAT |
| Status Groups | Review；Validation |
本验收数据使用 elapsed time，因此每个显示小时都是时间戳差值。改用 Business Calendar 时，也应使用同样方法，只对纳入的工作时段进行验算。
用基础状态列逐项验算分组值
相关 Jira History 区间为：
PLAT-201：Code Review2026-07-20 09:00Z → 12:00Z；QA12:00Z → 14:00Z。PLAT-202：Code Review2026-07-20 09:00Z → 14:00Z；QA14:00Z → 15:00Z。SHOP-301：Peer Review2026-07-20 09:00Z → 13:00Z；UAT13:00Z → 16:00Z。SHOP-302：Peer Review2026-07-20 09:00Z → 11:00Z；UAT11:00Z → 15:00Z。
使用 elapsed time 时，预期表格为：
| 工作项 | Code Review | Peer Review | QA | UAT | Review 计算 | Validation 计算 |
|---|---|---|---|---|---|---|
PLAT-201 |
3h | — | 2h | — | 3h + 无贡献 = 3h | 2h + 无贡献 = 2h |
PLAT-202 |
5h | — | 1h | — | 5h + 无贡献 = 5h | 1h + 无贡献 = 1h |
SHOP-301 |
— | 4h | — | 3h | 无贡献 + 4h = 4h | 无贡献 + 3h = 3h |
SHOP-302 |
— | 2h | — | 4h | 无贡献 + 2h = 2h | 无贡献 + 4h = 4h |
| 列合计 | 8h | 6h | 3h | 7h | 14h | 10h |
横线保留“没有基础状态贡献”这一事实，并不能证明工作项记录过一次零时长访问。验算分组时，该成员只是没有可相加的时长。
列级验算如下：
Review 分组 = Code Review 合计 + Peer Review 合计
= 8h + 6h
= 14h
Validation 分组 = QA 合计 + UAT 合计
= 3h + 7h
= 10h
纳入的基础状态合计 = 8h + 6h + 3h + 7h = 24h
分组阶段合计 = 14h + 10h = 24h
最后一项相等，是因为这 4 个纳入的基础状态在两个分组中形成了完整且互斥的划分。未映射状态不贡献给任何分组。如果把同一个状态同时加入两个分组，其时长会分别出现在两个分组中，这两个分组合计不能相加。24h = 24h 并不代表分组覆盖 To Do、In Progress、Blocked、Done 或其他被排除的生命周期阶段。
创建可持续核查的状态映射
- 先写报表问题。 使用“选定工作流时间中有多少处于评审和验证阶段”这类有边界的问题，不能先从一个方便的分组名称出发。
- 盘点确切 Jira 状态。 记录状态名称、可获得的状态 ID、所属项目或工作流，以及目标分析阶段。如果标签曾重命名、本地化或重名，应先按状态身份核对指南确认身份，再进行分组。
- 确定纳入规则。 把每个来源状态标为“纳入一次”“有意排除”或“待评审”。不能仅因名称陌生就让一个状态从映射中消失。
- 固定计算输入。 验算期间保持工作项范围、Work item date range、Trim History、Calendar、Format 和报表时间不变。
- 创建两个 Status Group。 在 Columns Manager 中把 Code Review 和 Peer Review 加入 Review，再把 QA 和 UAT 加入 Validation；同时保留四个基础状态列。
- 核对行与合计。 至少从 Jira History 重新计算一个工作项，再对完整受控范围证明
8h + 6h = 14h与3h + 7h = 10h。 - 分别测试其他报表类型。 时长验算通过，并不自动证明平均值分母或进入次数正确。
- 把定义与报表一起保存。 记录映射负责人、版本、评审日期、来源工作流和验收行。Saved Reports可以保留支持的配置，但再次运行时查询当前 Jira 数据，并不会冻结本文结果。
明确当前已发布的报表边界
Status Group 目前有以下报表类型边界：
| 报表类型 | Status Group 行为 |
|---|---|
| Time in Status | 对每个工作项汇总所选成员状态的时长单元格 |
| Average Time in Status | 表格、时长筛选、排序和导出对成员状态已经显示的平均值求和；成员状态分母不同时，该值不是先按工作项合并阶段后得到的平均值 |
| Time in Assignee | 使用以 Jira 用户为成员的 Assignee Group，而不是 Status Group |
| Status Count | 汇总成员状态的 entryCount；不会把更宽泛业务阶段的访问去重 |
| Status Entry Date | 当前表格不显示 Status Group |
| Transition Count | 不显示 Status Group；应保留确切的 From → To 方向 |
对于 Average Time in Status，当前已发布的分组值是一项显示聚合：它对各成员状态已经计算并显示的平均值求和。当前表格、时长筛选、排序和导出都使用这一合计。如果 Code Review 与 Peer Review 的贡献工作项总体不同，它们的显示平均值之和就不是先按工作项合并 Review 阶段后得到的平均值。解释结果时，应同时保留成员状态的分母和基础值。可以使用报表类型把时长、平均值、进入次数、进入日期和流转问题分开。
在本例中，4 个工作项都分别一次进入一个 Review 成员和一个 Validation 成员：
Review Status Count = 2 次 Code Review 进入 + 2 次 Peer Review 进入 = 4
Validation Status Count = 2 次 QA 进入 + 2 次 UAT 进入 = 4
这些是状态进入事件，不是小时数，也不是去重后的阶段访问。重新进入 Code Review 会增加 Review Status Count。一个工作项先进入 Code Review，再直接流转到 Peer Review，会分别为两个成员各贡献一次进入，因此分组合计为 2；即使业务把这段过程视为一次连续的 Review 阶段访问，Status Count 也不会把它去重为 1。
常见错误
把 Jira Board 列当成报表定义
Board 列可以为了看板展示和完成规则映射多个状态，但仍应单独保存本报表使用的 StatusPath 映射。
验收前隐藏基础状态列
没有来源列的分组值难以质疑和复核。代表性行与合计完全对上之前，应保持成员列可见。
把 Average Status Group 当成按工作项合并的阶段平均值
当前分组单元格会把成员状态的显示平均值相加。成员状态的贡献工作项数不同时，这个合计并不等于按工作项合并后的 Review 平均值。应检查各成员分母，不能为该合计赋予“合并阶段平均值”的含义。
把同一个状态加入多个分析阶段
如果映射重叠，相加分组合计时可能重复计算同一段时长。需要做可加汇总时应使用互斥映射；如果确实需要重叠分组，应把它们标记为不能相加的不同问题。
把被排除的状态当成零
排除表示阶段定义不纳入该状态，并不能证明选定工作项在该状态停留了零时间。
用宽泛分组诊断具体延迟
Review 可用于宽泛的阶段汇总，但无法说明 Code Review 还是 Peer Review 推高了结果。提出工作流修改前，应返回基础状态列和 Jira History。
QA 与测试瓶颈指南说明了为什么诊断时应分开保留 Waiting for QA、实际 Testing 和重新测试路径，即使后续汇总适合使用更宽泛的分组。
期待 Status Entry Date 或 Transition Count 使用同一分组
当前表格不会在这两种报表中显示 Status Group。里程碑日期应保留确切状态身份，流转应保留确切方向。
常见问题
Status Group 与 Jira Board 列相同吗？
不同。两者都可以把多个状态组织到一个阶段名称下，但 Board 列属于 Jira Board，Status Group 属于 StatusPath 报表配置。StatusPath 不读取或继承 Board 映射，也不会把 Status Group 写回 Jira。如果需要两者对齐，应分别记录。
一个 Status Group 可以包含不同 Jira 工作流的状态吗？
它可以组合报表可用的选定状态，本例中的 Review 就是如此。应先核对每个状态的身份、工作流含义和基础列结果；名称相同或相似本身不能证明阶段边界等价。
Review 为 14 小时，是否表示评审人员实际工作了 14 小时？
不是。它表示在选定范围、历史窗口和 Calendar 下的状态停留时间，其中可能包含排队、等待、自动化、讨论，以及这些状态所代表的其他时间。
基础状态列需要永久显示吗？
验收和定期审计时应显示。验证完成后的例行汇总可以突出分组列，但映射与代表性基础证据仍应与报表定义一起保存。
同一个 Status Group 在所有报表中的含义都相同吗？
不同。Time in Status 对每个工作项汇总成员时长；当前 Average Time in Status 的分组显示对成员状态显示的平均值求和；Status Count 汇总成员 entryCount。Time in Assignee 使用 Assignee Group，不能复用状态成员。每种指标都必须分别验算。
相关指南
- 如何计算 Jira Cloud 中的状态停留时间
- 如何计算排除 On Hold 的 Jira 活跃流程时长
- Jira 状态重命名和本地化后如何核对工作流报表
- 为什么 Jira 状态列没有出现在 Time in Status 报表中
- 如何比较不同 Jira 团队的 Average Time in Status
让映射与指标一起发布
只有当 Status Group 的目的、成员、排除项、负责人、版本、报表类型和基础列验算与结果一起保存时，它才值得信任。即使 Review 与 Validation 适合作为汇总阶段，也要保留详细状态用于诊断；不能把 Average 分组合计解释为按工作项合并后的阶段平均值。
前往 Atlassian Marketplace 试用 StatusPath Reports，配置 Review 与 Validation 映射，用 Jira History 验算 Time in Status 成员，确认 Status Count 是成员进入次数合计，并保存经过评审的报表定义。Time in Assignee 应使用 Assignee Group，而不是 Status Group。