敏捷原则要真正指导持续改进，需要把抽象表述转成团队能执行的动作和能核对的证据。本文围绕可工作的成果、短周期反馈、团队自组织和定期反思四条原则，说明如何建立一轮可重复的改进循环，并给出角色分工、示例与自查清单，帮助团队判断改进机制是否在运转。
要点总览（TL;DR）
- 把四条敏捷原则分别对应到可交付成果、短周期反馈、团队自组织和定期反思四个改进动作，并为每个动作配上可观察的证据，原则才能落到日常工作中。
- 一轮改进循环控制在一个迭代内：选定主题、形成可验证假设与度量、迭代中执行并收集反馈、回顾判断保留或调整、结论写入下一轮输入。
- 改进项需要明确负责人、关闭标准和验证证据，记录位置与日常工作项放在同一处，避免迭代切换时被稀释。
- 判断机制是否运转，看改进项关闭率、回顾结论进入下轮输入的比例和效果证据；回顾照常开但清单长期不变是失效的早期信号。
先给答案：四条原则对应四个改进动作
持续改进在敏捷实践中有一个基本前提：改进的对象是团队实际的工作方式和交付结果，改进的依据来自短周期内可观察的事实。把原则翻译成动作，再为动作配上证据，原则才不会停留在墙上的海报里。下表选取与持续改进最直接相关的四条原则，给出对应的改进动作和观察证据。
| 敏捷原则 | 对应的改进动作 | 可观察的证据 |
|---|---|---|
| 可工作的成果是进展的主要度量 | 每轮改进都指向一个可交付、可演示的成果，例如缩短某类需求的交付周期、降低某环节的返工率 | 迭代结束时能演示的成果；改进前后的交付周期或返工数据对比 |
| 短周期交付并获取反馈 | 把改进假设放进一个迭代内验证，限定观察窗口，到期用数据判断 | 迭代内收集的反馈记录；假设被证实或证伪的具体数据 |
| 自组织团队做出决策 | 由团队自己提出改进项、认领负责人、约定关闭标准，管理者提供资源与边界 | 改进项有明确负责人；团队会议记录中改进议题由成员发起 |
| 定期反思并调整行为 | 固定回顾节奏，回顾产出进入下一轮迭代的输入清单，并跟踪关闭 | 回顾结论清单；进入下轮输入的改进项数量与关闭率 |
这四条原则之间存在配合关系：短周期交付提供反馈素材，可工作的成果提供判断标准，自组织决定谁来改，定期反思保证改进不断线。单独使用其中一条，改进容易变成零散的活动；四条同时落地，才形成可持续的循环。
操作步骤：把原则转成一轮可执行的改进循环
一轮改进循环建议控制在一个迭代的时间跨度内，太长会让反馈失真，太短则难以观察到效果。以下五个步骤说明每一步的输入、动作、输出和完成标志。
第一步：从问题清单中选定本轮改进主题
输入是团队积累的问题来源，包括回顾会记录、缺陷分布、工作项滞留情况、成员日常反馈。动作是按影响范围和可改变程度排序，选出一个本轮要解决的问题，并写清问题现象而非笼统方向，例如“测试环境等待平均超过两天”比“提升协作效率”更可操作。输出是一句明确的改进主题陈述。完成标志是团队对该主题达成一致，且能说清它影响哪个交付环节。
第二步：把原则转成可验证的假设与度量方式
输入是改进主题和所选原则。动作是把主题写成假设句式：如果采取某个动作，预期某个指标在观察窗口内发生什么变化。同时确定度量方式，优先使用团队已有数据，例如工作项在各状态的停留时间、缺陷 reopen 次数、需求从进入到交付的周期。输出是假设、动作、指标、观察窗口四要素齐全的改进项。完成标志是指标口径被团队确认，数据来源可获得。
第三步：在迭代中执行并收集反馈
输入是本轮改进项和正常迭代工作。动作是把改进行动嵌入日常流程，例如调整某类工作的流转规则、改变评审时机、增加一次结对，并在迭代过程中记录执行情况和异常。输出是执行记录与过程数据。完成标志是改进行动按约定执行，数据被完整记录，未执行的部分有原因说明。
第四步：在回顾中判断保留、调整或放弃
输入是执行记录和度量数据。动作是对照假设逐项判断：达到预期则保留做法并考虑固化；部分改善则分析干扰因素后调整；没有变化或恶化则放弃并记录原因。判断要基于数据，同时允许团队补充数据之外的信息，例如成员对负担变化的感受。输出是每个改进项的结论。完成标志是每个改进项都有明确结论，没有悬而未决的条目。
第五步：将结论写入下一轮输入
输入是本轮结论。动作是把保留的做法写入团队工作约定，把调整后的方向转为下一轮候选主题，把放弃的原因记录在案避免重复尝试。输出是更新后的改进项清单和下一轮候选主题。完成标志是下一轮改进主题已选定，且能追溯到上一轮的结论。
角色与交付物：谁负责哪一段
改进循环能否持续，取决于每个环节是否有人对结果负责。角色分工的核心是让提出、执行、跟踪和资源支持各自有归属，避免改进项在迭代切换中被稀释。
| 角色 | 主要职责 | 交付物 | 交接点 |
|---|---|---|---|
| 团队成员 | 提出问题和改进想法，认领改进项并执行，提供过程反馈 | 问题描述、改进项执行记录 | 向回顾会提交执行结果 |
| Scrum Master / 敏捷教练 | 维护改进循环节奏，确保回顾产出被记录和跟踪，协助团队把主题转成可验证假设 | 改进项清单、回顾结论记录、跟踪状态 | 每轮回顾后向团队和下轮迭代交接改进项 |
| 产品负责人 | 判断改进项与产品目标的优先级关系，为涉及需求侧调整的改进提供决策 | 优先级判断、需求侧调整决定 | 在选定改进主题时参与排序 |
| 管理层 | 提供资源与授权边界，关注改进项关闭情况和跨团队障碍 | 资源支持决定、跨团队障碍的处理结论 | 定期查看改进项状态与关闭率 |
改进项的记录方式需要统一：每条改进项至少包含问题描述、对应原则、假设与指标、负责人、关闭标准、当前状态和结论。状态建议保持简单，例如待处理、进行中、已验证、已关闭、已放弃，避免状态过多导致维护成本上升。记录位置应与团队日常工作项放在同一处，减少改进项与迭代工作脱节的可能。在采用研发管理工具的团队中，这类记录可以由工作项承载，回顾结论也可以沉淀到团队知识库，便于下一轮引用。例如 ONES 支持在迭代完成后召开回顾会，结合燃尽图、工时日志、持续集成报告等数据复盘进度、质量和成本偏差，讨论改进建议；迭代经验还可以通过 ONES Wiki 沉淀为团队知识库。工具承担的是记录、跟踪和数据呈现，改进的判断仍由团队完成。
示例：一个团队如何用原则驱动两轮改进
以下为演示情景，用于说明方法如何落地，不代表特定团队的真实数据。
初始问题与所选原则
一个约八人的研发团队在回顾中发现，需求从开发完成到测试通过的平均等待时间偏长，部分需求在测试环节反复退回。团队选择“短周期交付并获取反馈”和“可工作的成果是进展的主要度量”两条原则作为本轮改进依据，因为问题集中在交付链条的中段，且可以通过周期数据观察变化。
第一轮：假设、动作与观察结果
团队形成的假设是：如果开发人员在提交测试前完成一次自测清单，测试环节的退回次数会下降。动作包括制定一份简短自测清单、在提交测试时附上自测结果、由测试人员记录退回原因。观察窗口为一个迭代。执行结果是退回次数有所下降，但等待时间没有明显改善。团队在回顾中判断：自测动作有效，予以保留并写入工作约定；等待时间问题另有原因，需要单独分析。
第二轮：根据结果调整
第二轮改进主题转向等待时间。团队通过工作项在各状态的停留数据发现，测试资源在迭代后段集中占用是主要因素。新的假设是：如果测试任务按需求进入测试环节的时间分散排布，平均等待时间会缩短。动作是调整测试排期规则，并每日在看板上对齐测试队列。一个迭代后，等待时间出现下降，团队决定保留排期规则，同时继续观察是否影响测试覆盖率。
改进项在迭代中的跟踪方式
两轮改进项都以统一格式记录，包含负责人、关闭标准和验证数据。第一轮的改进项在验证后关闭，自测清单进入团队工作约定；第二轮的排期规则处于已验证状态，仍保留观察项。回顾结论写入下一轮候选主题清单，团队在每轮开始时先查看上一轮遗留的观察项，再决定本轮主题。这样改进项不会因为迭代切换而丢失，也不会因为一次回顾结束就被视为完成。
完成检查：判断改进机制是否真的运转
改进机制是否有效，不能只看是否开了回顾会，而要看改进项是否被跟踪到关闭、结论是否进入下一轮、效果是否有证据。以下清单可用于团队自评，每项给出通过标准。
| 检查项 | 通过标准 |
|---|---|
| 改进项是否有明确负责人和关闭标准 | 每条改进项都能指出负责人，关闭标准可核对，不存在只有描述没有责任人的条目 |
| 回顾结论是否进入下一轮迭代输入 | 下一轮改进主题能追溯到上一轮结论，候选主题清单在迭代开始前已更新 |
| 改进效果是否有可观察证据 | 每个关闭的改进项都附有验证数据或可演示的结果，结论区分了有效、部分有效和无效 |
| 改进项是否按节奏关闭 | 连续两到三轮回顾中，改进项关闭率保持稳定，长期挂起的条目有明确处理决定 |
| 团队是否主导改进议题 | 改进主题多数由团队成员提出，管理者更多承担资源支持和障碍清除 |
机制失效通常有几个早期信号：回顾会照常召开但改进项清单长期不变；改进项只有提出没有结论；下一轮主题与上一轮结论没有关联；改进效果只能靠主观描述而拿不出数据。出现其中任一信号，团队应暂停新增改进项，先清理积压条目、补齐关闭标准，再恢复循环。改进机制的价值在于让团队每一轮都比上一轮多知道一点、多改对一点，检查清单的作用是及时发现循环在哪一段断掉。
常见问题
团队刚开始建立改进机制，第一轮应该选多大的改进主题？
第一轮建议选影响范围可控、在一个迭代内能观察到变化的主题，例如某类工作项的流转等待时间或某个环节的退回次数。主题过大，观察窗口内难以判断效果，团队容易在第一次回顾时就失去信心。判断标准是：团队能说清这个问题影响哪个交付环节，并且有现成数据可以对比改进前后。如果暂时没有数据，可以先补一个简单的记录方式，再开始第一轮。
改进项执行到一半发现方向不对，应该等迭代结束再处理吗？
不必等到迭代结束。改进项与普通交付任务的区别在于它本身就是一次验证，如果执行过程中已经出现明确的反向信号，例如改动作带来明显的额外负担且没有改善迹象，团队可以在日常沟通中先暂停或调整动作，并在回顾时记录调整原因。关键是保留记录：为什么中途调整、依据是什么，这些信息对下一轮判断同样有价值。回顾会仍然是做最终结论的场合，但不必成为唯一可以改变动作的时点。
管理层希望看到改进的量化效果，团队数据基础薄弱怎么办？
可以从团队已经在用的数据起步，例如工作项在各状态的停留时间、缺陷退回次数、需求从进入到交付的周期，这些数据通常已经存在于日常工具中。先固定一两个指标的口径，连续观察两到三轮，比一次性铺开大量指标更可靠。对于暂时无法量化的改进，例如会议效率或协作方式，可以用可演示的结果或团队共识作为证据，并在记录中注明证据类型。管理层关注的重点可以放在改进项关闭率和结论是否进入下一轮，这两项不依赖复杂度量。
回顾会开得正常，但改进项总是拖着不关闭，问题出在哪？
常见原因有三个：改进项没有明确负责人，大家默认别人会跟进；关闭标准写得模糊，无法判断什么时候算完成；改进项数量超过团队一个迭代能承担的范围。对应的处理是先清理积压条目，给每条补上负责人和可核对的关闭标准，对长期挂起的条目做出保留或放弃的明确决定，再恢复新增。团队也可以约定每轮改进项的数量上限，把精力集中在少数几条上。
用工具记录改进项时，需要单独建一套流程吗？
通常不需要单独建一套复杂流程。改进项可以与团队日常工作项放在同一处记录，用统一字段包含问题描述、对应原则、假设与指标、负责人、关闭标准和状态，状态保持简单即可。在采用 ONES 的团队中，迭代回顾可以结合燃尽图、工时日志、持续集成报告等数据复盘进度、质量和成本偏差，迭代经验也可以通过 ONES Wiki 沉淀为团队知识库，便于下一轮引用。工具承担记录、跟踪和数据呈现，改进的判断仍由团队完成。
