如何追踪在 Jira 状态之间反复流转的单个工作项

当一个 Jira 工作项在 Input Required、In Progress 和 QA 之间反复移动时，先不要把每次返回都称为返工，也不必先把全部时间戳抄进表格。应先固定工作项范围、报表生成时刻、Calendar 和历史窗口，再查看每次状态停留与有方向的流转；最后回到该工作项的 Activity 区域，用 History 中的关键工作流移动核对结论。

StatusPath Reports 2.5.0 可以缩短中间的重建过程：在主报表页面运行 Time in Status，使用工作项键旁的查看状态旅程（View status journey）操作，分别读取裁剪后的“所选报表状态贡献”和标记为完整历史（Full history）的状态时间线与历史路径图。两部分回答的问题不同，数值不应被强行对齐。

先明确要判断什么

本例调查合成工作项 NOVA-420。团队想知道它的延误更接近以下哪种情况：

• 一次特别长的等待；
• 多次返回同一阶段；
• 需要进一步核查的交接模式。

这三个判断需要不同证据。状态区间说明等待发生在何时；有向路径和重复次数说明工作项如何移动；流转操作者只说明谁提交了 Jira 状态变更，不能代替 Assignee 历史、实际工作投入或延误责任。

Atlassian 说明，工作项的 Activity 区域可以筛选 History，其中包括字段编辑和工作流移动。本文只把该 History 用作核对关键状态变更的来源，不把 Status Journey 称为原始 Jira History，也不声称 History 本身会自动计算逐段时长或重复路径。

固定 NOVA-420 的调查边界

这是一组不含客户数据的合成复现数据。本文截图展示的是当前本地 StatusPath 构建中的 Report Center 流程与界面输出，后文再用人工台账验算数字；它们不是仿制的 Jira 原生界面，也不证明某个 Marketplace 租户与本地构建完全一致。主报表配置为：

先用两张配置证据把 Calendar、时区和时长单位固定下来：

NOVA-421 和 NOVA-422 是控制项；调查对象仍是 NOVA-420。JQL 固定报表总体，Trim History 则裁剪已选工作项参与报表计算的历史。它们不能互相替代。

第一步：先读 41 小时的报表贡献

运行 Time in Status 后，NOVA-420 行只显示从 7 月 14 日 00:00 UTC 开始、截至报表生成时刻落入裁剪窗口的贡献：

Backlog       = —
In Progress   = 3h + 3h = 6h
Input Required = 10h + 19h = 29h
QA            = 2h + 2h = 4h
Done          = 2h

报表贡献合计 = 6h + 29h + 4h + 2h = 41h

第一段 Input Required 从 7 月 13 日 14:00 持续到 7 月 14 日 10:00，共 20 小时，但窗口只保留其中 7 月 14 日 00:00 之后的 10 小时。Backlog 的 1 小时和第一次 In Progress 的 4 小时都在窗口之前，所以不进入 41 小时。

这个表格回答的是“该工作项对所选报表窗口贡献了多少计算时长”，不是“它的完整状态路径有多长”。

第二步：打开九段完整状态时间线

在 NOVA-420 工作项键旁使用状态旅程操作，而不是点击用于打开 Jira 工作项的 Key 链接。完整 Journey 会保留报表贡献，同时把状态时间线标记为完整历史。

本地产品复现显示九个状态区间：

逐状态相加后，完整历史为：

Backlog        = 1h
In Progress    = 4h + 3h + 3h = 10h
Input Required = 20h + 19h = 39h
QA             = 2h + 2h = 4h
Done           = 2h

完整历史合计 = 1h + 10h + 39h + 4h + 2h = 56h

因此，56h - 41h = 15h 的差异可以完全追溯到裁剪起点之前的 1h Backlog + 4h In Progress + 10h Input Required。这不是产品故障，而是两个历史边界回答了不同问题。

这里的完整历史仍有明确边界：它表示当前可访问、截至报表生成时刻的状态历史不再按源报表的 Trim History 裁剪；它不包含未来变化，也不绕过 Jira 权限。显示时长仍使用本例的 24×7 Calendar 和 Decimal Hours 计算，并不是未经计算的原始时间戳列表。

第三步：用历史路径图确认重复方向

时间线保留九个区间，历史路径图则把相同状态合并成五个节点。节点累计值为：

Backlog        = 1h
In Progress    = 10h
Input Required = 39h
QA             = 4h
Done           = 2h

八次状态移动中，有两个方向各发生两次：

Input Required → In Progress = 2
In Progress → QA              = 2

暂停与重播可以帮助按事件顺序跟随路径，但图中的连线计数只证明发生了重复移动。Atlassian 当前文档说明，Jira workflow 由状态和流转组成，并且流转是单向的；要从 A 移到 B 后再返回，需要支持两个方向的流转。

“方向与次数”仍不等于“业务原因”。Input Required → In Progress 可能表示信息已经补齐，也可能对应其他团队约定；QA → Input Required 也不能单凭图形自动归类为返工。需要团队先为明确的 From → To 路径写下分类规则，再检查上下文。

第四步：用 Jira History 核对决定性事件

NOVA-420 是合成复现数据，不应被包装成真实 Jira 客户工作项。在真实调查中，应在准备调整工作流或升级问题之前，打开目标工作项的 Activity 区域并筛选 History。若要把本例装载到测试 Jira 做同等核对，则应检查以下决定性状态移动：

1. 两次 Input Required → In Progress 是否确实出现在预期时间；
2. 两次 In Progress → QA 是否对应路径图中的计数；
3. QA → Input Required 前后是否存在解释返回原因的字段或团队记录；
4. History 实际显示的变更用户是否与 Journey 中相应区间的流转操作者一致。

Atlassian 官方页面支持“History 包含字段编辑和工作流移动”这一窄结论。它没有在该页面中承诺 StatusPath 式的逐段时长、累计节点或播放视图。因此，本文把 Jira History 用于核对关键变更，不把它与计算后的 Journey 互相替代。

这条路径能够支持什么结论

就这组证据而言，可以确认 NOVA-420 同时存在两段接近 20 小时的 Input Required 等待和重复的有向移动。仅凭 Journey 仍不能确认根因、责任归属或团队定义下的返工。

七个必须保留的解释边界

1. 报表贡献不是完整历史。 贡献卡和 Time in Status 行遵循报表总体、所选状态、Calendar 与 Trim History；状态时间线和历史路径图不应用该 Trim History 范围。
2. 完整历史也不是无限历史。 它只覆盖当前可访问的数据并截至报表生成时刻，权限或 changelog 可用性仍可能限制内容。
3. actor 不是 Assignee。 Journey 显示的是 Jira 状态 changelog 的变更账号，可能对应用户、自动化或 app；它不是实际劳动者、延误责任人或当前负责人。
4. 初始段没有进入流转人。 Backlog 是模型中的首段，没有更早的状态变更事件，因此 — 是预期结果。
5. 路径图不是历史工作流配置档案。 它把已加载的 Jira 状态历史与可用时取得的当前工作流状态元数据结合起来；不能据此证明事件发生当天的工作流定义与今天完全相同。
6. 重复或返回的边不是自动返工。 线和次数只证明移动；业务分类必须使用团队书面定义和 Jira 上下文。
7. 状态累计时长不是最新一次访问年龄。 Input Required = 39h 来自 20h + 19h，不能直接解释为最近一次进入 Input Required 后已经等待 39 小时。

本 Guide 使用的是主报表页面 Time in Status 行旁的直接 Journey 操作，不把同一入口泛化到 Status Count 或 Transition Count 表格。各模块的完整入口与数据边界见工作项下探与状态旅程文档。

相关指南

• 如何使用四种 Issue Activity 报表核对单个 Jira 工作项：当问题是四种计算汇总能否对回同一段历史时使用。
• Jira 重复进入同一状态时，Time in Status 如何计算：当问题是多次停留如何合并成一个时长单元格时使用。
• Jira 状态流转方向报表模板：当单工作项证据需要扩展为团队级 From → To 指标时使用。

在修改流程前保留一条可核对的状态路径

如果下一个高风险工作项又需要手工重建时间戳，可以先对包含它的真实 Jira 总体运行 Time in Status，记录 Calendar、Trim History 和生成时刻，再从该行打开 Journey。先解释报表贡献与完整历史的差异，随后只把决定性移动核对回 Jira History，最后再讨论工作流或返工定义。

在 Atlassian Marketplace 查看 StatusPath Reports 2.5.0，用自己的权限和工作流复现一个工作项的裁剪贡献与完整状态路径。