敏捷原则指导持续改进，关键是把抽象价值转成可执行的管理动作：以可工作的成果作为检验标准，用短周期暴露问题，靠团队自组织形成改进方案，再把改进项纳入下一轮迭代并留下证据。本文给出一套“原则—观察信号—改进动作—验证证据”的对照方法，并配套步骤清单、角色分工、示例和自查表，帮助团队判断改进是否真的发生。
要点总览（TL;DR）
- 把四条与改进直接相关的敏捷原则（可工作的成果、短周期交付、团队自组织、定期反思调整）各配一到两个可复核的观察信号，原则才从口号变成可对比的事实。
- 持续改进按五步闭环推进：收集信号、筛选排序、写成可验证动作、进入下一轮迭代执行并记录、用同一口径复测验证；未改善则回到分析环节。
- 改进项要写清负责人、验收人、时间盒和完成标志，负责人与验收人分开，回顾产出当轮进入迭代待办，避免停留在会议记录里。
- 判断机制是否运转，看改进项是否有负责人与完成标志、结论是否有同口径证据、未达成项是否被重新分析、改进项是否在迭代待办中可见。
- 单轮改进项控制在团队能完成的范围内，出现阻断条件时先修复记录与跟踪环节，再讨论新的改进方向。
把四条敏捷原则翻译成可观察的改进信号
敏捷原则本身是价值判断，直接写进改进计划容易变成口号。有效的做法是先为每条原则选定观察信号，再规定数据从哪里取、当前处于什么状态、打算往哪个方向改。观察信号要能被第三方复核，例如“迭代结束时可用功能是否完成联调”比“团队是否重视交付”更可操作。
与持续改进关系最直接的四条原则是：以可工作的成果作为进展的主要度量、短周期交付、团队自组织、定期反思并调整。下表给出对照表模板，团队可按自身迭代节奏填写。
| 敏捷原则 | 观察信号 | 反面信号 | 数据来源 | 当前状态 | 改进方向 |
|---|---|---|---|---|---|
| 可工作的成果是进展的主要度量 | 迭代结束时通过验收的需求数量；联调与测试完成比例 | 迭代末大量需求停留在“开发完成未验证”；演示时依赖临时拼凑 | 迭代评审记录、缺陷与测试报告 | 如：近三个迭代平均有三分之一需求未通过验收 | 把验收标准前置到需求拆分阶段，缩小单个需求粒度 |
| 短周期交付 | 需求从进入到可演示的平均时长；迭代内交付分布是否集中在前半段 | 工作项长期滞留同一状态；交付集中在迭代最后两天 | 工作项状态流转记录、看板滞留时间 | 如：平均滞留时间超过一个迭代长度 | 设置状态停留上限，在每日站会点名超期项 |
| 团队自组织 | 任务拆解与认领由团队成员完成的比例；站会中提出并当场解决的阻塞数量 | 任务全部由一人分配；阻塞项反复出现无人跟进 | 迭代待办、站会记录、阻塞项清单 | 如：多数任务由负责人统一派发 | 改为团队共同拆解、自愿认领，负责人只确认边界 |
| 定期反思并调整 | 回顾会产出的改进项数量与完成率；上一轮改进项在本轮的跟踪情况 | 回顾会只列问题不定动作；改进项连续多轮无进展 | 回顾记录、改进项清单 | 如：上轮五项改进仅一项有结论 | 限制每轮改进项数量，逐项指定负责人与完成标志 |
填写说明有三点。第一，“当前状态”写事实和数字，不写评价词，便于下轮对比。第二，一条原则可以对应多个信号，首轮建议每条原则只选一到两个最有把握取到数据的信号，避免表格过重。第三，改进方向先写假设，例如“缩小需求粒度可能缩短滞留时间”，假设是否成立留给验证环节判断。
持续改进的操作步骤：从信号到验证的闭环
有了观察信号，接下来要按固定顺序推进，让每个改进项都有输入、动作、输出和完成标志。五步闭环适用于大多数迭代团队，周期通常与迭代对齐。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 收集信号 | 迭代产出、协作记录、评审与回顾记录、过程数据 | 按对照表逐项取数，记录事实与时间范围 | 信号清单，含数据来源与取值口径 | 每条信号都能追溯到具体记录，口径前后一致 |
| 2. 筛选与排序 | 信号清单、团队当前目标 | 按影响范围、出现频次、可改变程度排序，剔除本轮无法着手的项 | 本轮改进候选列表，含排序理由 | 候选数量控制在团队一轮能完成的范围内，通常不超过三项 |
| 3. 写成可验证动作 | 改进候选 | 把“加强评审”改写为“每个需求在进入测试前完成一次同行评审并留记录”，指定负责人与时间盒 | 改进项条目：动作、负责人、验收人、截止时间、完成标志 | 条目可被他人独立判断是否完成 |
| 4. 执行并记录 | 改进项条目 | 纳入下一轮迭代待办，执行中记录进展、阻碍与偏差 | 执行记录与阶段状态 | 改进项在迭代待办中可见，状态有更新 |
| 5. 验证与再分析 | 执行记录、同一口径的观察信号 | 用与步骤1相同的数据口径复测，判断信号是否改善；未改善则分析原因，是动作设计问题还是假设不成立 | 验证结论：有效、部分有效或无效，及后续处理 | 结论有数据或记录支撑，无效项已给出重新分析的结果 |
第二步的排序依据需要事先约定，否则容易变成谁声音大谁优先。常用判断维度是：该问题是否反复出现、是否直接影响交付结果、团队本轮是否具备改变条件。第三步是闭环成败的关键，动作描述里要包含可观察的完成状态，例如“每周至少一次”“每个需求一份记录”，而不是“提高意识”。
改进项需要稳定的记录载体和状态跟踪，否则容易散落在会议纪要里。ONES 的敏捷研发管理方案覆盖需求、研发、测试的流程衔接，迭代回顾时可以借助燃尽图、工时日志、持续集成报告等数据复盘进度、质量与成本偏差；系统也会记录资源投入、缺陷分布、工作项滞留时间等过程数据，可作为步骤1和步骤5的取数来源。改进项本身可以按团队习惯以工作项或文档形式登记，并与迭代待办关联，使执行状态可查。
角色分工与各环节交付物
改进停留在讨论层面，多数时候是职责不清：有人提问题，没人对动作负责，也没人验收。把闭环中的决定权、执行权和验收权分开，能显著减少这类情况。
| 角色 | 职责边界 | 关键交付物 |
|---|---|---|
| 团队成员（整体） | 提供一线观察，参与信号收集与原因分析，认领改进动作 | 信号记录、改进项执行记录 |
| Scrum Master / 敏捷教练 | 维护对照表与取数口径，组织回顾，确保改进项被写成可验证动作并进入迭代待办，跟踪未达成项 | 信号清单、改进项台账、跟踪状态 |
| 产品负责人 | 判断改进项与当前目标的优先级关系，确认涉及需求与验收标准调整的改进方向 | 优先级结论、验收标准调整说明 |
| 改进项负责人 | 执行具体动作，更新状态，提交完成证据 | 执行记录、完成证据 |
| 验收人 | 按完成标志独立判断是否达成，给出有效或无效结论 | 验证结论 |
记录载体建议统一：改进项以条目形式登记，字段至少包含来源信号、动作描述、负责人、验收人、时间盒、状态和验证结论。状态可按“待开始—进行中—待验证—已验证/已关闭”流转，未通过验证的项回到“进行中”并补充原因。回顾会产出的改进项应在会后当轮进入下一轮迭代待办，而不是留在会议文档中等待下次讨论。
负责人与验收人应当分开。负责人对自己执行的动作做判断容易放宽标准，验收人可以是同团队其他成员、Scrum Master 或受该改进影响的下游角色。涉及跨团队协作的改进项，验收人宜选择能接触到结果数据的一方。
示例：一个改进项从提出到验证的完整过程
以下为演示情景，用于说明方法如何落地，数据为示意。
背景与信号。某研发团队连续三个迭代出现同一现象：迭代最后两天集中提交测试，测试阶段发现的问题导致部分需求无法在迭代内验收。对照表中“短周期交付”一行记录：工作项在“开发中”状态的平均滞留时间为9天，迭代长度为10个工作日；评审记录显示近两轮均有约三成需求延期验收。
改进项表述。回顾会上团队没有停留在“加强过程管理”，而是写成：将单个开发任务的预估工作量控制在3人日以内，超过的任务在拆解阶段必须拆分；负责人为团队技术骨干，验收人为 Scrum Master，时间盒为下一轮迭代全程，完成标志是“下一轮迭代中超过3人日的开发任务数量为零，且工作项平均滞留时间较本轮下降”。
执行与记录。改进项进入下一轮迭代待办，与常规需求并列显示。拆解阶段，团队按新规则检查任务粒度，两名成员对两个偏大的任务做了二次拆分。执行中记录到一次偏差：某需求因外部依赖无法拆分，团队将其标记为例外并说明原因，未计入完成标志的统计。
验证与结论。迭代结束后按同一口径复测：超过3人日的开发任务数量为零，平均滞留时间从9天降至6天，延期验收需求比例下降。验收人依据看板记录与统计结果判定“有效”，改进项关闭，同时把“外部依赖类需求如何拆分”作为新信号进入下一轮候选。
可迁移的规律。这个例子体现三点：信号要来自可复核的记录而非印象；动作要包含数量或频次等可判断的标准；验证必须使用与收集阶段相同的口径，否则改善可能来自统计方式变化。例外情况单独记录，既保证规则可执行，也避免完成标志被稀释。
完成检查：判断改进机制是否真的在运转
机制是否有效，不看回顾会开了几次，而看改进项是否形成可追踪的闭环。以下清单可按迭代或按月自查，每项给出通过标准与阻断条件。
| 检查项 | 通过标准 | 阻断条件 |
|---|---|---|
| 改进项是否有明确负责人与完成标志 | 本轮全部改进项均有负责人、验收人、时间盒和可判断的完成标志 | 存在无负责人或完成标志为“提升意识”类表述的条目 |
| 改进结果是否有证据支撑 | 每个关闭的改进项附有数据或记录，且与收集阶段口径一致 | 结论仅凭口头确认，或复测口径与初始口径不一致 |
| 未达成的改进项是否被重新分析 | 未通过验证的项已记录原因，并给出调整后的动作或终止理由 | 未达成项被直接删除或长期挂起无说明 |
| 改进项是否进入下一轮迭代并被跟踪 | 回顾产出的改进项在下一轮迭代待办中可见，状态有更新 | 改进项只存在于会议记录，迭代待办中查不到 |
| 改进项数量是否与团队承载能力匹配 | 单轮改进项数量在团队可完成范围内，未挤占交付工作 | 改进项大量堆积、连续多轮无进展 |
阻断项的处理原则是：出现任一阻断条件，本轮改进机制判定为未有效运转，先修复记录与跟踪环节，再讨论新的改进方向。全部检查项通过，且连续两轮保持，可认为闭环已稳定运行。此时可适当扩大观察信号范围，例如把缺陷分布、资源投入等过程数据纳入对照表，让改进从单点问题转向对交付质量的持续观察。
常见问题
团队刚开始做持续改进，第一轮应该选几条原则、几个信号？
建议从与改进关系最直接的四条原则入手，但每条原则首轮只选一到两个最有把握取到数据的信号，例如“迭代结束时通过验收的需求数量”或“工作项在某一状态的平均滞留时间”。信号过多会让取数成本超过改进收益，团队容易在第二轮就放弃维护对照表。等闭环稳定运行两三轮后，再逐步把缺陷分布、资源投入等过程数据纳入观察范围。
改进项在下一轮迭代中没有完成，应该怎么处理？
先区分原因：是动作设计得过大、负责人投入不足，还是外部依赖导致无法推进。处理方式有三种——拆小动作后继续跟踪、调整负责人或时间盒、给出终止理由并关闭。无论哪种，都要在改进项记录中留下说明，不能让条目长期挂起或直接删除。连续多轮无进展的改进项本身就是一个信号，说明筛选环节的排序依据需要重新约定。
验证改进效果时，数据口径和第一轮不一致会有什么问题？
口径变化会让改善无法归因。例如第一轮统计“开发中”状态滞留时间，验证时改成统计整个迭代周期，数字下降可能只是统计范围变了。做法是在收集信号时就记录数据来源、取值口径和时间范围，验证阶段沿用同一口径复测。确有必要调整口径时，应同时保留新旧两组数据，并在结论中说明调整原因。
回顾会产出的改进项，用什么载体记录和跟踪比较合适？
关键是让改进项与迭代待办在同一处可见、状态可更新。团队可以按自身习惯选择工作项或文档登记，字段至少包含来源信号、动作描述、负责人、验收人、时间盒、状态和验证结论。ONES 的敏捷研发管理方案覆盖需求、研发、测试的流程衔接，迭代回顾时可借助燃尽图、工时日志、持续集成报告等数据复盘进度、质量与成本偏差，系统也会记录资源投入、缺陷分布、工作项滞留时间等过程数据，可作为收集信号和复测验证的取数来源；改进项可与迭代待办关联，使执行状态可查。
改进机制运行多久可以认为稳定，之后要做什么调整？
常见判断是全部检查项通过且连续两轮保持，可认为闭环已稳定运行。此后可以适当扩大观察信号范围，把改进从单点问题转向对交付质量的持续观察，例如纳入缺陷分布和资源投入数据。扩大范围时仍要控制单轮改进项数量，避免新增观察维度挤占交付工作。
