使用指南

Jira 工作流评审清单

可靠的 Jira 工作流评审 会在提出修改前检查：问题、工作项范围、行筛选窗口、Jira 历史记录（History）窗口、工作日历（Calendar）、样本量、明细行、平均值、异常项、精确流转方向、负责人、趋势和 Jira 历史记录。清单让每个结论都能追溯，避免把单个高值或一张图误写成对流程、团队或个人的判断。

可打印的工作流评审清单

把下列内容复制到评审记录中。只有记录或链接相应证据后，才勾选完成。

A. 定义评审

写出一个决策问题，并指定决策负责人。
记录定义数据范围的 Jira Project、Filter、JQL、Sprint 或 Epic。
记录用于筛选工作项行的日期字段和范围。
记录计算完整历史还是使用裁剪历史（Trim History）。
记录工作日历、时区、工作时间、节假日和时长格式（Format）。
确认数据范围使用的 Jira 工作流和看板列映射。

B. 检验信号

检查疑似阶段的状态停留时间（Time in Status）明细行。
对账总量、贡献项数量和平均状态停留时间（Average Time in Status）。
在判断系统性瓶颈前，检查最长行和分布。
在计算返工前，定义精确的来源状态 → 目标状态路径。
当重复进入状态很重要时，检查状态进入次数（Status Count）。
当假设涉及负责人或交接时，检查 Time in Assignee。
使用相同的时间桶和工作日历规则比较趋势。

C. 验证和决策

在 Jira 历史记录中打开处理较快、典型、处理较慢以及发生返回的代表性工作项。
至少记录一种可能的替代解释。
把已观察证据与推测原因分开。
指定一项范围明确的行动、负责人、截止日期和成功衡量标准。
保存报表配置，并链接行级证据。
在判断调整是否有效前，安排按相同定义重跑。

清单是本页的主要资产。下面链接的详细 Guides 解释各个指标；本页负责规定评审顺序和证据门槛。

真实 Jira 场景：Review 偏高，但这能证明什么？

受控 Jira 范围包含 12 个已完成 Story，即 SR-4501 至 SR-4512，使用完整 Jira 历史记录和 UTC 工作日 09:00–17:00 工作日历。它们的 In Review 时长为：

2h, 2h, 2h, 3h, 3h, 3h, 3h, 4h, 4h, 4h, 5h, 7h

其中 3 个 Story 从 In Review → In Progress 返回一次，随后再次进入 In Review；其余 9 个只进入过一次 In Review。

证据	验证值	可以支持	不能证明
In Review 总量	42h	In Review 在所选状态中的累计时长最高	时长为何累计
Review 贡献项	12	每个 Story 都进入过 Review	每个 Story 的经历相同
In Review 平均值	3.5h	按贡献项比较的基线	目标或服务承诺
最长 Review 行	7h	某一工作项需要检查 Jira 历史记录	存在系统性原因
In Review 进入次数	15	除 12 个 Story 各自首次进入外，又有 3 次进入	每次额外进入都可以避免
In Review → In Progress	3	发生 3 次明确的返回流转	返回是缺陷还是有效变化

Jira 状态停留时间表格按 In Review 时长排列十二个工作流评审 Story — 明细视图完整展示 12 个贡献项以及 2 至 7 小时的 Review 分布，便于在解释平均值前核对。

人工对账证据

时长计算为：

Review 总量   = 2 + 2 + 2 + 3 + 3 + 3 + 3 + 4 + 4 + 4 + 5 + 7 = 42h
贡献项        = 12
Review 平均值 = 42h ÷ 12 = 3.5h

In Progress 总量 = 24h
QA 总量          = 12h

重复进入次数需要单独计算：

12 个 Story 各自首次进入 In Review = 12 次
其中 3 个 Story 再次进入 In Review  =  3 次
In Review 总进入次数                 = 15 次
In Review → In Progress 返回         = 3 次

在本受控工作流中，状态进入次数显示 15 次进入 In Review。扣除 12 个 Story 各自的首次进入后，得到 15 - 12 = 3 次额外进入；流转次数（Transition Count）显示 3 次 In Review → In Progress 返回。两者能够对账，是因为每次纳入统计的返回之后都会再次进入 In Review。这个关系并非通用规则：工作项可能从其他方向进入状态；Jira 的循环流转也可能执行动作而不改变状态。Atlassian 说明工作流流转是单向的，来回流转需要两条独立的流转路径。

按顺序执行清单

1. 从决策开始，而不是从图表开始

使用“下一批可比工作项是否要测试 Review 负责人规则？”不要使用“Review 好不好？”前者可以得到范围明确的行动和重跑规则。

2. 验证 Jira 数据范围

运行计算前，先在 Jira 中确认应包含和应排除的工作项。Atlassian 说明 Jira 为 space、board、version、sprint 和工作项提供不同报表，并提醒 company-managed 报表必须使用正确的看板：Generate a report。

本文范围为：

project = SR
AND key in (SR-4501, SR-4502, SR-4503, SR-4504,
            SR-4505, SR-4506, SR-4507, SR-4508,
            SR-4509, SR-4510, SR-4511, SR-4512)
ORDER BY key ASC

上述明确列出的 Key 用于保持本文示例可复现。评审下一批实际工作项时，应保持相同纳入规则和计算定义，但通过滚动 Saved Filter 或更新后的工作项范围刷新工作项集合；原样重跑固定清单只会重新计算这 12 个 Story。

3. 分别固定行筛选与 Jira 历史记录计算

工作项日期范围（Work item date range）决定哪些行进入报表；裁剪历史改变每条入选工作项 changelog 中参与计算的部分。即使其中一项为空，也要分别记录。产品边界见报表设置和数据范围。

4. 固定时间口径

本文使用 UTC 工作日 09:00–17:00 和 Decimal Hours。其他工作日历也可能合理，但它们属于不同指标定义。跨团队或周期比较前，参见Jira 工作日历指南。

5. 同时检查明细、总量、平均值和异常项

在状态停留时间中按 In Review 降序排列。将 12 个贡献项的 42h 与平均状态停留时间的 3.5h 对账。7h Story 是检查目标，不是流程诊断。平均值与总量指南解释了为什么两种指标都需要保留。

Atlassian 的 Control Chart会在公司管理型空间（company-managed space）中显示所配置的 cycle/lead time、平均值、滚动平均、标准差和异常项。它可以提供波动旁证，但其定义不会自动等于单状态 Review 时长。

6. 用方向定义返工，而不是用标签

先运行状态进入次数查找重复进入 In Review 的工作项，再运行流转次数，并选择明确的 In Review → In Progress 列。使用状态流转方向报表模板记录为什么纳入这条路径，以及要检查哪些样本。

Jira 流转次数表格显示三次从 In Review 返回 In Progress 的流转 — 方向列定位三个发生返回的 Story，但不会自动判断这些流转的原因。

Atlassian 的 JQL 运算符参考记录了 status CHANGED FROM ... TO ...。该条件用于筛选匹配工作项；文档没有把它定义为逐行流转次数或可复用矩阵。

7. 只有假设需要时才检查负责人

如果推测原因涉及交接或归属不清，再加入 Time in Assignee 证据。不要依据负责人持有时长给个人排名。Time in Assignee 指南区分历史负责人时长与实际记录工时。

8. 使用相同定义比较趋势

比较等价的数据范围、工作日历、Jira 历史记录边界和时间桶。Jira 的 Cumulative Flow Diagram中，持续变宽的看板列带通常代表瓶颈，但解释取决于看板列映射。StatusPath 趋势可显示所选报表指标随时间变化；两者都不能单独确定原因。

9. 验证 Jira 历史记录，并记录范围明确的决策

打开 7h Story、一条典型 3h Story，以及其余两个发生返回的 Story。7h Story 本身就是三个返回项之一，因此最终检查 4 个不同工作项的 Jira 历史记录，而不会重复计入该 Story。Atlassian 说明 Activity → Jira 历史记录记录字段编辑和工作流中的流转。

按以下格式记录决策：

已观察：12 个 Story 的 Review 共 42h；平均 3.5h；3 次已定义的返回流转。
未知：排队、评审人员可用性、范围变化或有效迭代。
行动：检查 4 个代表性工作项的 Jira 历史记录，并测试一条 Review 负责人规则。
负责人：指定评审负责人。
复查：按同一纳入规则刷新工作项集合，再对下一批可比工作项使用已保存的同一计算定义重跑。

常见错误

未验证范围就修改工作流

错误看板、过期 Filter、范围过宽的 Project 或不匹配的 Sprint 都可能产生看似可信但无关的结果。

把工作项日期范围和裁剪历史当成一个控制项

两者分别回答哪些行被选中、哪些历史参与计算。

比较平均值却不说明贡献项和分布

3.5h 平均值需要同时说明 12 个贡献项和 2 至 7 小时的范围。小样本或异常项会改变平均值。

把任何返回都称为“返工”

团队必须定义精确路径并检查代表性 Jira 历史记录。Jira 自定义工作流没有统一的“反向流转”定义。

推断个人生产率

状态停留可能包含排队、交接、依赖、人员缺席、批处理或规则造成的等待，不等于记录工时或通用生产率分数。

记录结论却没有负责人或重跑规则

只有记录行动、负责人、截止日期和按同一定义复查的安排后，评审才完整。

常见问题

Jira 工作流评审多久执行一次？

选择能够形成可比数据范围并满足决策所需样本量的节奏。活跃交付流程可按周进行；低数据量团队可能需要更长周期。不存在通用样本量阈值。

应先打开哪种报表？

如果要了解各工作项分别在哪些状态花费了时间，先用状态停留时间。只有在检验具体假设时，再添加平均状态停留时间、状态进入次数、流转次数、Time in Assignee 和趋势。

Review 平均值高就能证明存在瓶颈吗？

不能。还要检查贡献项数量、分布、累计时长、趋势、其他阶段和代表性 Jira 历史记录。它只是待检验信号。

JQL 能计算本文三次返回吗？

Atlassian 文档说明，JQL 历史条件可查找状态从一个值变为另一个值的工作项。本文的逐工作项次数来自流转次数，不是 JQL 文档定义的计数输出。

会议结束后应保存什么？

保存可复用报表配置、决策记录、Jira 样本链接，以及记录所需的特定时间点的表格或图表导出。已保存报表（Saved Report）本身不是冻结快照。

一次只改变一件事，再使用同一定义重跑

只有当证据、不确定性、行动、负责人和复查都可见时，清单才算完成。刷新滚动工作项范围时保持相同纳入规则和计算定义，下一次评审才能检验调整效果，而不是变更测量边界。

在 Atlassian Marketplace 试用 StatusPath Reports，汇集工作流评审所需的明细、平均值、流转和趋势证据。