如何查找 Jira 中状态累计时长最长的工作项

要查找 Jira 中状态累计时长最长的工作项，先固定当前状态范围，再选择统一的 Calendar 和 Format，对目标状态列应用严格时长阈值，按时长降序排列，导出检查清单，并打开代表性工作项核验。Time in Status 单元格会累计历史边界内的每次停留，因此结果不能自动解释为当前开放区间的年龄。

先限定累计时长检查范围

本文只回答一个运营问题：在一组当前处于 Waiting for Review 的工作项中，哪些行累计的 Waiting for Review 时长最高，应优先检查？ “延迟是否广泛且持续，足以说明系统层面的约束”由工作流瓶颈指南负责；单个开放状态区间的年龄由当前状态时长指南负责。

Atlassian 的 JQL 字段参考说明，status 支持等于以及 WAS、CHANGED 等历史运算符，但 Status 字段不支持 >、>= 等数值比较。因此，JQL 可以筛选 status = "Waiting for Review"，却不能用原生 Status 比较表达“Waiting for Review 时长大于 16 个工作小时”。该时长计算与筛选由 StatusPath 提供。

可复现 Jira 场景：20 个当前等待评审的工作项

报表包含 SR-4701 至 SR-4720，20 个工作项当前全部处于 Waiting for Review。文章截图使用受控的 Jira 测试数据和以下固定报表定义：

只有在该示例工作日历中，16 小时才等于两个各 8 小时的计划工作日；它不代表两个自然日。它只是本场景选择的检查阈值，不是默认值、基准或通用 SLA。

使用以下有明确边界的 JQL 选择工作项：

project = SR
AND status = "Waiting for Review"
AND key in (SR-4701, SR-4702, SR-4703, SR-4704, SR-4705,
            SR-4706, SR-4707, SR-4708, SR-4709, SR-4710,
            SR-4711, SR-4712, SR-4713, SR-4714, SR-4715,
            SR-4716, SR-4717, SR-4718, SR-4719, SR-4720)
ORDER BY key ASC

JQL 固定当前状态范围；应用再依据 Jira 历史记录、选定的 Jira 历史记录窗口和工作日历计算 Waiting for Review 时长。

预期明细与严格 >16h 结果

下表已按累计时长从高到低排列。对于只进入一次状态的工作项，累计时长等于当前开放区间。SR-4711 和 SR-4715 两次进入 Waiting for Review，因此两项指标不同。

人工验算行动清单

20 个累计时长值为：

4 + 6 + 8 + 10 + 12 + 14 + 16 + 18 + 20 + 22
+ 24 + 26 + 28 + 30 + 32 + 36 + 40 + 48 + 56 + 64
= 514 个工作小时

严格“大于”筛选会排除 16 小时这一行，保留从 18 至 64 小时的 13 个值：

筛选后行数 = 13

筛选后时长 = 18 + 20 + 22 + 24 + 26 + 28 + 30
             + 32 + 36 + 40 + 48 + 56 + 64
             = 444 个工作小时

排除的时长 = 4 + 6 + 8 + 10 + 12 + 14 + 16
             = 70 个工作小时

核对         = 514h - 70h = 444h
筛选部分占比 = 444h ÷ 514h = 86.38%

86.38% 只描述这个受控的 20 项数据集，不是基准或性能结论。更重要的是，筛选结果是一份需要检查的具名工作项队列，不能证明整个 Waiting for Review 阶段构成瓶颈。

在 StatusPath Reports 中制作检查清单

1. 选择当前处于目标状态的工作项

运行上面的限定 JQL，或使用包含相同当前状态规则的 Jira Saved Filter。确认结果正好有 20 行，而且每行的 Current status 都显示 Waiting for Review。

这里应使用 status = "Waiting for Review"，而不是 status WAS "Waiting for Review"。Atlassian 的 JQL 运算符参考说明，WAS 会匹配当前或历史值，CHANGED 会查找字段发生过变化的工作项，并支持 FROM、TO、AFTER、BEFORE 等谓词。若没有另加当前状态条件，这些历史谓词会纳入已经离开该状态的工作项。

2. 固定计算控件

选择状态停留时间（Time in Status）；本完整历史场景关闭 Trim History；选择 UTC 工作日 09:00–17:00 的工作日历；使用 Decimal Hours。报表设置与范围文档区分工作项范围筛选与 Jira 历史记录窗口。工作日历与时长文档说明了为什么改变工作日、工作时间、时区或例外日期，会在 Jira 历史记录不变的情况下改变数值。

3. 保留身份字段和证据列

在 Columns 中保留 Key、Summary 和 Current status。把 Waiting for Review 作为筛选与排序列，并保留 In Progress 作为辅助历史上下文，以便查看此前的工作流停留。只有在 Assignee、Priority 或其他已发布 Jira 字段有助于分派检查任务时才添加它们，不要仅凭字段值推断延迟原因。

4. 应用时长筛选并排序

打开 Waiting for Review 列筛选，选择大于（Greater than），按照 Decimal Hours 输入提示填写 16，再按同一列降序排列。表格视图文档列出了支持的时长比较，并说明时长排序使用计算后的数值。

共享清单前检查三条边界数据：

• SR-4708 是最短的纳入项，时长为 18h。
• SR-4707 为 16h，不大于 16h，因此被排除。
• SR-4720 为 64h，降序排列后位于首行。

5. 在称其为当前等待时长前检查重复进入

使用相同工作项范围和 Jira 历史记录窗口切换到状态次数（Status Count），或检查 Issue Activity，找出不止一次进入 Waiting for Review 的工作项。本场景中，SR-4711 与 SR-4715 均进入两次。重复进入状态计算指南说明了为什么进入次数与累计时长必须分开。

6. 导出已核查的队列

确认筛选、排序、可见字段、工作日历和格式后，再导出 CSV 或 XLSX。导出文档说明，支持的表格筛选和排序会应用于完整报表结果，而不只是浏览器视口。开放区间和 Jira 数据之后仍可能变化，因此需要记录导出时间。

当前开放区间与累计状态时长的区别

工作项当前处于 Waiting for Review，不代表显示的 Time in Status 单元格只是当前这一次进入状态的计时器。该单元格会在指定工作日历和 Jira 历史记录窗口下，累加每一次纳入计算的 Waiting for Review 区间。

如果行动问题是“哪些当前工作项在历次进入该状态期间累计超过 16 个工作小时？”，Time in Status 的 13 行清单是正确答案。如果问题是“哪些当前开放区间本身已超过 16 个工作小时？”，应在 Jira History 中核查最近一次进入时间，并在同一工作日历下只计算这段开放区间。Issue Activity 可以核对计算后的时长和进入次数，但不显示原始事件时间线。按后一种定义，本场景有 12 行：SR-4711 当前这次停留正好为 16h，因此被排除。

不要在不说明的情况下替换两种定义。清单标题应明确写“累计状态时长”或“当前开放区间”，并保留报表运行时间。当前状态时长指南说明了为什么开放区间会在两次运行之间继续增长。

常见错误

把示例阈值称为通用 SLA

>16h 是在一种每天 8 小时的工作日日历下选择的场景规则。团队 SLA 应来自自己的政策、风险、服务承诺和工作日历。

把累计时长当作本次进入状态后的时长

重复进入会让两个数值不同。使用“当前已等待”这类表述前，应检查 Status Count 与 Jira History 中最后一次进入记录。

使用历史 JQL，却没有当前状态条件

status WAS "Waiting for Review" 会纳入已经离开该状态的工作项。当前行动清单应使用 status = "Waiting for Review"。

期望 JQL 比较状态时长

Jira Status 字段不支持数值 > 或 >= 比较。使用 JQL 选择工作项范围，再用 StatusPath 时长筛选应用计算后的阈值。

两次检查使用不同工作日历或 Trim History

不同工作计划或 Jira 历史记录边界可能改变哪些行超过 16 小时。应把配置与检查清单一同保存。

把长尾清单称为工作流瓶颈

若干长时长行只能定位待检查工作。瓶颈结论还需要分布、样本量、可比周期和旁证。

常见问题

JQL 能否查找当前处于某个 Jira 状态的工作项？

可以。status = "Waiting for Review" 等条件会选择当前 Status 匹配的工作项。JQL 也可以用 WAS 和 CHANGED 查询 Status 历史，但 Status 字段不支持按停留小时数进行数值比较。

超过 16 个工作小时是否等于超过两个工作日？

在本示例中相等，因为所选工作日历的每个工作日包含 8 个计划小时，且没有例外日期。若工作计划、时区、节假日或例外日期不同，换算也可能不同。严格 >16h 还会排除正好 16h 的工作项。

为什么当前正在等待的工作项会显示比本次停留更长的时长？

Time in Status 会累加同一状态所有纳入计算的停留区间。如果工作项曾离开后又返回，显示的总量会包含前一次已结束区间和当前开放区间。

能否导出筛选后的行动清单？

可以。StatusPath 表格导出会把支持的筛选、排序、可见列、工作日历和格式应用到完整结果。这是一个时点材料，需要记录生成时间和配置。

相关指南

• 如何计算 Jira Cloud 中的 Time in Status
• Jira 重复进入状态如何影响 Time in Status
• 为什么 Jira 当前状态时长持续增长
• 如何查找 Jira 工作流瓶颈

把累计时长转化为可检查队列

一份有用的行动清单应记录当前工作项范围、累计或当前边界、阈值、工作日历、Jira 历史记录窗口和报表时间。它用于安排检查优先级，而不是直接判定原因。在 Atlassian Marketplace 试用 StatusPath Reports，筛选并排序 Time in Status、核查重复进入记录，并导出已确认的工作项队列。