StatusPath Reports使用指南
Jira 重复进入同一状态时，Time in Status 如何计算
当 Jira 工作项多次进入同一状态时，StatusPath Reports 会把每次停留视为独立的时间戳区间，对每个区间应用相同的历史窗口和 Calendar，再把计入时长相加到一个 Time in Status 单元格中。Status Count 则单独保留进入次数。因此，同样是 4 小时，既可能来自一次 4 小时停留，也可能来自两次各 2 小时停留。
完整的区间模型参见如何计算 Jira Cloud 中的状态停留时间。当前控件和结果结构见报表类型与工作项活动。
区分 Jira 历史与计算报表
Atlassian 将 Jira 工作流描述为工作项在生命周期中经过的一组状态与流转。Atlassian 还说明，工作流流转是单向的：从 In Progress 移动到 In Review，再从 In Review 返回 In Progress，需要工作流支持两个方向。
这些移动的底层证据来自 Jira。工作项的 Activity → History会记录字段编辑和工作流移动。应用也可以通过 Jira Cloud 的 changelog REST 资源读取带时间戳的 changelog，但结果受 Jira 权限和应用访问规则约束。
StatusPath 把这段有序历史转换为三个不同输出：
| 报表 | 计算方式 | 回答的问题 |
|---|---|---|
| Time in Status | 汇总每次进入某状态后被计入的时长 | 这个工作项在 In Progress 中累计了多少计算时长？ |
| Status Count | 统计计算历史窗口内进入该状态的次数 | 这个工作项进入 In Progress 几次？ |
| Transition Count | 统计一个指定方向的流转 | 哪条工作流路径造成了返回？ |
以上区分是 StatusPath 的行为，并不表示 Jira 原生提供完全相同的计算列。Jira 提供当前字段值和历史，StatusPath 再根据这些证据计算时长与次数报表。
可复现场景：两次停留，一个时长单元格
这个可复现演示在 Jira 测试项目中使用合成数据：六个 Story、配置为 UTC 时区的 24×7 Calendar、Decimal Hours，并关闭 Trim History。SR-3901 两次进入 In Progress；其他五行分别提供单次停留、跳过状态和相同时长对照。
使用以下报表定义：
| 设置 | 值 |
|---|---|
| 工作项范围 | JQL project = SR AND key in (SR-3901, SR-3902, SR-3903, SR-3904, SR-3905, SR-3906) ORDER BY key ASC |
| Work item date range | 留空 |
| Trim History | 关闭 |
| Time in Status Calendar | 已配置的 UTC 24×7 Calendar |
| Time in Status Format | Decimal Hours |
| 验证报表 | 先运行 Time in Status，再对相同范围和历史窗口运行 Status Count |
| 可见列 | Work item key、Summary 和 In Progress |
24×7 Calendar 使本例等于直接计算时间戳差值。Business Calendar 会对每个时长区间应用工作时间，而 Status Count 仍然统计事件次数。
按时间戳计算 SR-3901
相关工作流历史如下：
| 时间戳（UTC） | 新状态 | 对 In Progress 的影响 |
|---|---|---|
| 2026-07-06 09:00 | To Do | 尚未产生 In Progress 区间 |
| 2026-07-06 10:00 | In Progress | 第一次停留开始 |
| 2026-07-06 12:00 | In Review | 第一次停留在 2 小时后结束 |
| 2026-07-06 13:00 | In Progress | 第二次停留开始 |
| 2026-07-06 15:00 | Done | 第二次停留在 2 小时后结束 |
先分别计算每次停留，再求和：
第一次 In Progress 停留 = 12:00 - 10:00 = 2.00 小时
第二次 In Progress 停留 = 15:00 - 13:00 = 2.00 小时
Time in Status：2.00 + 2.00 = 4.00 小时
Status Count： 2 次进入
中间的 1 小时 In Review 不属于 In Progress 时长；它把两次停留分开，并产生返回流转 In Review → In Progress。Transition Count 可以核对这个方向，但“该返回是否属于返工”应交给Jira 返工分析指南中的书面定义和验证方法。
对账六个控制行
所有行都使用相同的 Calendar、历史窗口和显示格式：
| 工作项 | 计入的 In Progress 区间（UTC） | 人工时长 | 预期 Time in Status | 预期 Status Count |
|---|---|---|---|---|
SR-3901 |
10:00–12:00 和 13:00–15:00 | 2.00 + 2.00 小时 | 4.00 小时 | 2 |
SR-3902 |
10:00–11:00 | 1.00 小时 | 1.00 小时 | 1 |
SR-3903 |
10:00–12:30 | 2.50 小时 | 2.50 小时 | 1 |
SR-3904 |
10:00–16:00 | 6.00 小时 | 6.00 小时 | 1 |
SR-3905 |
从未进入 In Progress | 0.00 小时 | — | 0 |
SR-3906 |
10:00–14:00 | 4.00 小时 | 4.00 小时 | 1 |
人工验算为：
In Progress 总时长 = 4.00 + 1.00 + 2.50 + 6.00 + 0.00 + 4.00
= 17.50 小时
In Progress 总进入次数 = 2 + 1 + 1 + 1 + 0 + 1
= 6
SR-3901 与 SR-3906 说明了为什么只看时长无法判断是否重复进入：两者都是 4.00 小时，但进入次数分别为 2 和 1。SR-3905 的破折号是从未进入该状态时的空时长显示；可见的 Status Count 列则在这一行显示数字 0。
配置并核查两种报表
1. 固定同一个工作项范围
运行有明确边界的 JQL，确认只返回 SR-3901 至 SR-3906。在时长与次数核对之间，不要更换数据源、日期筛选或 Jira 权限。
2. 先对账 Time in Status
选择 Time in Status、已配置的 UTC 24×7 Calendar 和 Decimal Hours，并保持 In Progress 列可见。解释重复进入前，先确认六个预期单元格和 17.50 小时人工合计。
3. 保持历史范围不变，切换到 Status Count
选择 Status Count，保留相同的工作项范围和 Trim History 设置。Calendar 与时长 Format 不参与这个次数报表的计算。确认 In Progress 值依次为 2、1、1、1、0、1。
4. 在 Jira History 中检查异常行
打开 SR-3901，选择 Activity → History，确认两次进入 In Progress 以及各自的离开时间。Atlassian 的 JQL 字段参考说明 Status 支持 WAS、CHANGED 等历史运算符；这些条件可以筛选匹配工作项，但不能替代每个工作项的次数结果。
5. 仅用 Transition Count 核对方向
如果业务问题取决于流转方向，再单独检查 In Review → In Progress。状态进入次数说明工作项曾返回，方向流转则说明它从哪里返回。给出原因判断前，应继续检查 Jira 上下文。
常见错误
只保留最后一次停留
如果只计算 SR-3901 的 13:00–15:00，而忽略 10:00–12:00，结果会从 4.00 小时错误变成 2.00 小时。求和前必须重建每个被计入的区间。
把 4 小时读成 4 次进入
Time in Status 是时长，Status Count 是次数。两者的数字可能偶然相同，但单位和业务问题完全不同。
把 JQL 当作逐行次数结果
status WAS "In Progress" 或 status CHANGED TO "In Progress" 可以帮助选择存在匹配历史的工作项，但查询结果不能替代为每个工作项计算的 Status Count。
比较不同的历史窗口
Trim History 可能同时移除较早的时长区间和进入事件。对账两种报表时，应保持相同的工作项范围与历史窗口。
把没有改变状态的循环动作算成重新进入
Atlassian 允许目标仍是同一状态的循环流转。不能假设每个工作流动作都产生了新的状态停留；应确认是否真的存在 Status changelog 记录。
把每次第二次进入都称为返工
返回可能来自返工、获批的流程循环、自动化或其他工作流规则。归因前，应核对方向历史并应用团队书面定义。
常见问题
Time in Status 会为每次停留创建独立列吗？
不会。对同一个工作项和状态，StatusPath 会把被计入的各次停留相加到一个 Time in Status 值中。使用 Status Count 保留进入频率。
Business Calendar 会影响 Status Count 吗？
不会。Calendar 会改变 Time in Status 等时长计算；Status Count 统计进入事件。不过，Trim History 仍可能改变哪些事件位于计算历史窗口内。
标准 JQL 能显示每个工作项进入状态几次吗？
JQL 可以筛选 Status 曾经是某个值或曾变为某个值的工作项。需要逐工作项的数字进入次数时，应使用 Status Count 或基于 changelog 的审计。
第二次进入状态一定代表返工吗？
不一定。它只能证明该工作项在所选历史窗口内重复进入，不能证明原因。应检查方向流转和 Jira History，再应用团队书面返工定义。
相关指南
- 如何计算 Jira Cloud 中的状态停留时间
- 如何用 Status Count 和 Transition Count 分析 Jira 返工
- Jira 状态平均时长如何计算
- Jira Time in Status 日期范围如何裁剪历史
让每次重复停留都可审核
Time in Status 展示累计时长，Status Count 保留产生该时长的停留次数，Transition Count 说明返回路径。保持三者的工作项范围和历史窗口一致，再用 Jira History 核查一个异常行，然后再给出流程结论。
在 Atlassian Marketplace 试用 StatusPath Reports，用自己的 Jira 工作流和权限复现时长与次数核对。