BlueGrove Labs
帮助中心StatusPath ReportsJira Cloud
联系支持
EN

为什么 Jira 当前状态的停留时间会持续增长

Jira 当前状态的停留时间会持续增长,是因为工作项已经进入该状态,但还没有后续状态变化来关闭区间。StatusPath Reports 会把开放区间计算到报表的有效结束边界;下一次运行时该边界继续向后移动,时长就会增加。要复现结果,请固定 Time in Status 计算口径以及报表范围和 Trim History 配置。

开放状态还没有记录退出事件

Atlassian 把 Jira 工作流定义为工作项在生命周期中经过的状态和流转。已完成的状态区间始于工作项进入该状态的记录,并以之后变为另一个状态的记录结束;当前区间只有进入记录,在可用历史中还没有下一次状态变化,因此时长报表必须为这个仍然开放的区间选择有效结束边界。

Jira 会在工作项的 Activity 区域记录操作,其中 History 包含工作项在工作流中的移动。可以使用 Jira 工作项 Activity 和 History核对最后一次状态变化。需要程序化核查时,Jira Cloud 还提供分页的工作项 changelog 接口,在 Jira 权限允许的范围内按日期返回 changelog。

这些 Jira 来源用于确认已经记录的工作流事件,不负责计算 StatusPath 时长。StatusPath 会把报表边界、Trim History、Calendar 和 Format 应用于这些事件。

可复现场景:开放区间和已完成对照

本例使用演示工作项、团队已配置的 UTC 24×7 Calendar 和 Decimal Hours,让边界算术保持清晰。生产结果必须同时记录该 Calendar 的工作时间与时区。

工作项 状态历史 两次运行之间应发生的变化
SR-3701 在 2026-07-13 00:00 UTC 进入 Waiting for Review,之后没有状态变化 报表结束边界向后移动时,开放的 Waiting for Review 区间增长
SR-3702 在 2026-07-13 00:00 UTC 进入 Waiting for Review,并在 04:00 UTC 流转到 Done 已完成的 Waiting for Review 区间保持 4 小时

两次观察之间必须保持报表类型、工作项范围、状态列、Calendar、Format、Work item date range 和 Trim History 不变。Atlassian 的工作流说明提供状态和流转模型。下方时间是记录下来的运行时刻,并不是用户可以设置的报表结束时间控件。

两次运行如何解释增长

可复现 Snapshot 在以下两个运行时刻记录同一份报表:

运行 记录的运行时刻 SR-3701 当前区间 SR-3702 已完成对照
A 2026-07-14 00:00 UTC 24.00 小时 4.00 小时
B 2026-07-15 00:00 UTC 48.00 小时 4.00 小时

开放工作项的计算为:

运行 A:2026-07-14 00:00 - 2026-07-13 00:00 = 24 小时
运行 B:2026-07-15 00:00 - 2026-07-13 00:00 = 48 小时
增长:48 - 24 = 24 小时

已完成对照有一条流转到 Done 的记录:

2026-07-13 04:00 - 2026-07-13 00:00 = 4 小时

它的结果不受两次运行各自结束边界的影响。如果两行都增长,这组对照就无法单独验证开放区间,应重新核对已记录的状态变化和报表配置。

Time in Status 报表中持续增长的当前 Waiting for Review 时长
在较晚的报表结束边界,开放的 Waiting for Review 区间达到 48.00 小时,已完成对照仍为 4.00 小时。

固定历史边界以复现结果

要在以后重新运行示例,同时避免开放区间继续向后增长:

  1. 保持同一份 Time in Status 报表和工作项范围。
  2. 保持选择同一个已配置的 UTC 24×7 Calendar 和 Decimal Hours。
  3. 打开 Trim History,把 From 和 To 都设置为 2026-07-13。
  4. 保存范围并等待报表刷新完成。
  5. 确认 SR-3701 显示 24.00 小时,SR-3702 显示 4.00 小时。

Trim History 使用所选 Calendar 时区中的日历日期边界。上面的 UTC 单日范围包含到 2026-07-13 23:59:59.999 UTC,因此开放区间的原始值是 24 小时减 1 毫秒,在 Decimal Hours 中显示为 24.00。结果旁必须同时记录时区和日期边界;缺少 Calendar 时区的日期不是完整的复现说明。

Time in Status 报表使用 UTC 单日 Trim History 固定当前 Waiting for Review 结果
固定 UTC 历史边界后,稍后再次运行时开放行仍为 24.00 小时,已完成对照仍为 4.00 小时。

不要用 Work item date range 代替该设置。它决定哪些已选工作项进入报表;Trim History 决定每个已纳入工作项的哪段历史参与计算。

常见错误

把每次增长都当成缺陷

先确认工作项是否仍然没有后续状态变化。当前区间保持开放且报表结束边界向后移动时,增长属于预期结果。

使用不同 Calendar 比较两次运行

工作时间 Calendar 可能只计算排班时段,All time 日历则计算全部自然时间。在把差异归因于开放区间之前,应固定 Calendar 和时区。

试图用 Work item date range 固定数值

Work item date range 过滤工作项范围,不负责设置状态历史计算的结束边界。固定比较应使用完整的 Trim History 范围。

忽略包含当天末尾的边界

此处 Trim History 接受日期,而不是任意时刻。人工核对原始毫秒数时,应把 To 日期转换为所选 Calendar 时区中包含当天末尾的边界。

常见问题

什么会关闭当前状态区间?

Jira 历史中后续流转到另一个状态时,当前区间才会关闭。在 Jira 记录该状态变化前,StatusPath 会使用有效报表结束边界计算开放区间。

Saved Report 会固定当前时长吗?

不会。Saved Report 保存可复用配置,不是 Jira 历史或结果行快照。除非固定计算边界,否则以后运行时开放区间仍可能更大。

Work item date range 能阻止当前区间增长吗?

不能。它可以根据所选 Jira 日期字段纳入或排除工作项。应使用 Trim History 裁剪参与时长计算的历史。

为什么过了一天,增长可能少于 24 小时?

所选 Calendar 可能排除夜间、周末、节假日或其他非工作时段。核对区间前,应确认 Calendar、时区、Trim History 和 Decimal Hours 输出。

相关指南

明确记录开放区间边界

同时记录进入该状态的变化、有效结束边界、Trim History 范围、Calendar、时区和 Format 后,持续增长的当前状态时长就可以复现。使用报表设置与范围设置历史边界,并用日历与时长记录计时时段。前往 Atlassian Marketplace 试用 StatusPath Reports,对照开放 Jira 状态与已完成状态。

截图预览