Jira 报表指南

如何计算排除 On Hold 的 Jira 活跃流程时长

通过明确的状态分组计算排除每次 On Hold 区间的 Jira 流程小计，并核对重复进入和工作日历结果。

作者： BlueGrove Labs发布于 2026年8月5日更新于 2026年8月5日

要计算排除 On Hold 的 Jira 流程时长，应先明确哪些状态需要计入，把这些状态加入 Status Group，并保留被排除的 On Hold 列用于验算。StatusPath Reports 会累加所有纳入状态的每段区间，包括重复进入同一状态的情况。结果是一个按状态定义的流程小计，不是秒表、实际劳动时间，也不是 Jira Service Management SLA。

先判断 Jira 原生报表是否已经负责这个问题

对于 company-managed Jira Software 空间，Atlassian 的 Control Chart可以选择代表 Cycle Time 的工作流列。如果它的工作项总体、状态边界、自然时间口径和图表输出已经满足问题，应先使用原生报表。

如果问题是 Jira Service Management 服务目标，应使用原生 SLA 条件。Atlassian 文档提供独立的开始、暂停和完成条件，例如等待客户回复时暂停。报表小计不能替代 SLA 目标、breach 状态或暂停时钟。

当你需要逐工作项查看纳入和排除的状态时长、应用 StatusPath 工作日历、按小计排序或筛选，并导出当前报表依据时，可以使用 StatusPath 的 Time in Status 表格。

使用明确的 allowlist，而不是自动排除规则

Status Group 是明确的 allowlist。本例创建 Counted lifecycle，成员和排除项如下：

纳入 Counted lifecycle	有意排除
In Progress	On Hold
Code Review	To Do
QA	Done

公式为：


Counted lifecycle
  = 所有 In Progress 区间
  + 所有 Code Review 区间
  + 所有 QA 区间

这里不存在隐藏的“除 On Hold 外全部计入”规则。工作流新增状态不会自动进入分组；每次工作流变更后都应复核映射。

用自然时间验算两次 On Hold

使用一个受控工作项，Jira 状态历史如下：

区间	状态	时长	是否计入
2026-08-03 09:00–13:00 UTC	In Progress	4h	是
2026-08-03 13:00–19:00 UTC	On Hold	6h	否
2026-08-03 19:00–22:00 UTC	Code Review	3h	是
2026-08-03 22:00–2026-08-04 11:00 UTC	On Hold	13h	否
2026-08-04 11:00–13:00 UTC	QA	2h	是

使用 Always / elapsed-time Calendar 时：


完整区间             = 28h
Counted lifecycle    = 4h + 3h + 2h = 9h
On Hold 证据         = 6h + 13h = 19h
验算                 = 9h + 19h = 28h

两次 On Hold 都保留在 Jira History 中。分组只是不把这 19 小时加入小计，不会删除或改写源历史。

配置并核对报表

打开 StatusPath Reports → Report Center，选择 Time in Status。
选择边界明确的 Project、Filter、JQL、Sprint 或 Epic。第一次验算只使用一个已知工作项，并保持 Work item date range 为空。
除非问题明确需要裁剪历史窗口，否则关闭 Trim History。
第一次验算选择 Always / elapsed time 和 Decimal Hours。
打开 Columns Manager，保留 In Progress、Code Review、QA 和 On Hold 基础列。
创建 Counted lifecycle Status Group，只加入 In Progress、Code Review 和 QA。
信任分组前先核对基础列：4h + 3h + 2h = 9h，并确认两段 On Hold 合计 19h。
按 Counted lifecycle 排序或筛选，导出当前表格证据为 CSV 或 XLSX，并另外记录 Counted lifecycle 成员清单、Calendar、Format 和历史边界。

StatusPath Reports Columns Manager 和 Time in Status 表格，其中显示基础状态列与已配置的 Status Group — 这张已发布的 Status Group 示例展示了配置方式。对于 On Hold 场景，应保留 On Hold 基础列，但不要把它加入 Counted lifecycle 成员。

当前产品在 Time in Status、Average Time in Status 和 Status Count 中支持 Status Group。本方法使用 Time in Status，因为逐工作项分组单元格直接累加成员状态时长。不能把同一解释照搬到 Average Time in Status：Average 分组会相加成员状态已显示的平均值；当成员分母不同时，它不等于按工作项合并后的阶段平均值。

单独应用工作日历

状态纳入规则与工作时间规则回答两个不同问题：

Status Group 决定哪些状态计入。
Calendar 决定这些状态内部的哪些时钟区间计入。

假设 Monday–Friday Calendar 只计算 09:00–17:00，受控历史如下：

工作日历区间	状态	计入的工作时间
第 1 天 09:00–12:00	In Progress	3h
第 1 天 12:00–16:00	On Hold	排除 4h
第 1 天 16:00–17:00	Code Review	1h
第 2 天 09:00–13:00	QA	4h

表中四段工作日历区间合计 12h；Counted lifecycle 为 3h + 1h + 4h = 8h；On Hold 为 4h；所以 8h + 4h = 12h。夜间、周末、节假日和例外日期应先按所选 Calendar 计算。修改 Format 只会改变展示格式。

使用结果前完成边界测试

重复进入 On Hold

使用分别包含 0、1、2 次 On Hold 的工作项测试。所有纳入状态的每次进入都应累加，所有 On Hold 区间都应排除在 Counted lifecycle 外。

重新打开的工作项

Reopen 会产生新的纳入区间和 On Hold 区间。应明确报表是包含完整历史、使用固定 Trim History 窗口，还是只选择已解决总体。StatusPath 不会自动把 resolvedAt 当作永久停止点。

只有 Flagged 变化，没有状态流转

如果工作项始终停留在 In Progress，只修改 Jira Flagged 字段，基于状态的分组仍会计算这段 In Progress。本方法不能扣除只由字段变化表示的时间。

当前开放区间

当前纳入状态的时间会持续增长，直到报表时间端点变化或工作项发生流转。验算开放工作项时应固定 generated-at 时间。

重叠的 Status Group

如果一个状态同时属于多个分组，每个分组都可能包含同一段时长；不能把重叠分组合计。

这个小计代表什么、不代表什么

应把结果称为 Counted lifecycle、纳入状态时长或按状态定义的活跃流程时长。除非工作流和运营规则能够证明每个纳入状态都代表实际劳动，否则不要称它为实际工作时间。纳入状态内仍可能存在排队、等待评审、自动化运行和无人操作时间。

这个数字也不能自动解释等待原因。应保留基础状态列和 Jira History，让评审者能够区分 In Progress、Code Review、QA 与 On Hold，而不是只根据一个宽泛小计采取行动。

在 Jira 中执行同一组受控检查

StatusPath Reports 由 BlueGrove Labs 开发。在 Atlassian Marketplace 打开 StatusPath Reports，创建包含三个成员的 Counted lifecycle 分组，并先用一个工作项的 Jira History 验证 9h 纳入 + 19h On Hold = 28h，再把定义应用到更大范围。