伪敏捷往往不是某一个环节做错了，而是多重压力叠加的结果：组织仍按传统项目方式考核与控制，却要求团队套用敏捷仪式；角色改了名字，决策权没有下放；迭代节奏保留下来，需求、范围与验收标准仍由外部单方面决定。本文先给出可对照的症状清单，再按“治理与考核—角色与授权—需求与范围—实践与工件—文化与能力”逐层提出原因假设，用可观察证据排除，最后说明处置步骤与恢复验证方式。讨论聚焦框架层面的成因，单个 Sprint 的执行细节不在本文展开。
要点总览（TL;DR）
- 伪敏捷通常是治理考核、角色授权、需求范围、实践工件、文化能力五层问题叠加的结果，单看某一层容易误判。
- 诊断按“治理与考核—角色与授权—需求与范围—实践与工件—文化与能力”逐层提出假设，用考核记录、变更记录、会议观察等可观察证据排除，不把猜测当结论。
- 区分实施不成熟与伪敏捷，看过去三到六个迭代是否有可观察的行为改变：有改变有反复属于不成熟，长期形式与实质背离更接近伪敏捷。
- 处置先解决治理与授权，再调整实践细节；涉及考核制度与组织架构调整需管理层共识、试点与回退方案。
- 用迭代范围稳定性、评审反馈闭环率、回顾改进项完成情况等行为指标验证恢复，关键规则写入团队工作约定与完成定义以防复发。
伪敏捷有哪些典型症状，范围如何界定
判断伪敏捷，先把主观评价换成可核对的现象。以下症状单独出现时未必说明问题，若同一团队在多个迭代中反复出现三项以上，就值得启动一次系统诊断。
- 仪式齐全但交付节奏未变：站会、评审、回顾按时召开，发布频率、需求交付周期与引入敏捷前基本一致，团队说不出最近三个迭代交付了什么。
- 迭代内范围频繁插入：迭代开始后仍不断接到新需求，团队默认“插进来就做”，迭代目标形同虚设，承诺的交付内容屡屡延期。
- 评审只做演示不做反馈：评审会变成成果汇报，干系人看完即走，没有形成对下一迭代的输入，也没有对“是否满足验收标准”作出明确判断。
- 回顾结论不落地：每次回顾都能列出一堆问题，下一迭代无人跟进，同样的问题连续几个迭代被重复提出。
- 看板只用于汇报：看板上的状态由专人定期更新，用于向上展示进度，团队成员日常并不依赖它协调工作，卡片状态与实际进展脱节。
需要区分“实施不成熟”与“伪敏捷”。实施不成熟表现为团队知道该做什么、正在改进，只是熟练度不足，例如回顾改进项偶尔遗漏、验收标准写得不够细；伪敏捷则表现为形式与实质长期背离，团队把仪式当作合规动作完成，组织层面也没有改变控制方式，改进缺少发生的空间。一个实用的判断口径是：过去三到六个迭代中，团队是否出现过可观察的行为改变。有改变、有反复，属于不成熟；长期无改变、且团队普遍认为“这就是走流程”，更接近伪敏捷。
本文聚焦框架层面的成因，包括治理规则、角色授权、需求与范围管理、实践质量与文化条件。具体某个 Sprint 如何规划、如何主持回顾，属于迭代管理的操作话题；产品待办列表如何梳理维护，属于需求池管理话题，本文只在成因分析需要时提及。
原因假设与排除证据：五类常见成因怎么验证
诊断的关键是把猜测变成可验证的假设。建议按“治理与考核—角色与授权—需求与范围—实践与工件—文化与能力”的顺序排查：越靠前的层次对团队行为的约束越强，若上层问题未解决，直接调整下层实践往往收效有限。每一类假设都要找到对应的证据来源，证据不足时保留为待验证项，不急于下结论。
| 层次 | 原因假设 | 可观察证据 | 排除方法 |
|---|---|---|---|
| 治理与考核 | 组织仍以工时、文档数量、里程碑达成作为主要考核口径，敏捷指标只是附加项 | 考核表、绩效面谈记录、项目汇报模板；团队是否因“填工时”“补文档”挤占交付时间 | 查阅近两个考核周期的实际评分依据；访谈团队与直属主管，确认考核口径是否与迭代目标一致 |
| 角色与授权 | 产品负责人无决策权，需求优先级由上级或销售决定；Scrum Master 兼多职，无暇推动改进 | 需求优先级变更的实际决策人；产品负责人能否独立确认迭代范围；Scrum Master 的日常工作量构成 | 追踪三次优先级变更的决策链；查看角色职责说明与实际会议参与记录 |
| 需求与范围 | 迭代内随意插单，缺少变更规则；验收标准缺失或事后补充 | 迭代范围变更记录及次数；需求条目中验收标准的完整率；变更是否经过团队评估 | 抽取最近两三个迭代的需求清单，统计中途新增与撤出比例；检查验收标准在开发开始前是否已明确 |
| 实践与工件 | 站会变逐人汇报，回顾无跟进，完成定义形同虚设 | 站会时长与发言结构；回顾改进项的跟踪记录；完成定义是否被用于判断“做完” | 旁听一次站会与回顾；抽查已完成事项是否逐条满足完成定义 |
| 文化与能力 | 缺少透明与试错空间，问题被掩盖；敏捷培训停留在流程层面，未覆盖估算、拆分、验收等具体技能 | 团队是否敢在评审中暴露风险；培训内容与实际工作方法的差距；新成员如何学习团队做法 | 匿名收集团队对“暴露问题是否安全”的看法；比对培训大纲与团队实际使用的实践清单 |
排查时注意两点。其一，证据要来自实际记录和行为观察，而非问卷里的自我评价，团队往往会把“应该怎样”当成“实际怎样”回答。其二，多个假设可能同时成立，此时优先确认影响面最大的那一层，例如考核口径与授权问题同时存在时，先处理治理与授权，因为实践层的调整需要以团队拥有一定自主空间为前提。
一个常见的误判是把所有问题都归到“团队执行力不够”。若证据显示迭代范围由外部单方面决定、优先级变更无需团队评估，那么团队再努力也难以稳定交付，成因在需求与范围层，而非团队能力。反过来，若范围稳定、授权清晰，团队仍长期只做形式，则应重点检查实践质量与文化条件。
确认成因后的处置步骤
处置顺序建议与排查顺序一致：先处理治理与授权，再调整实践细节。治理与授权问题不解决，团队即使改进了站会形式或回顾方法，也会在下一轮外部压力下退回原状。
- 与干系人对齐迭代范围与验收规则。把“迭代内可以插入什么、由谁批准、需要什么代价”写成明确规则，例如紧急插入需替换等量工作并由产品负责人确认。同时约定需求进入开发前必须具备可检验的验收标准。这一步的产物是一份干系人共同确认的范围与验收约定，完成标志是下一个迭代按此执行且变更有记录。
- 明确角色职责与决策权。用一页纸写清产品负责人对优先级和范围的决策权、Scrum Master 对流程改进的推动职责、团队对工作方式的自主范围。若产品负责人确实无法获得授权，应如实调整角色设置，而不是保留名义角色。涉及汇报关系调整时，先在小范围试点并设定观察期。
- 把回顾结论转为可跟踪的改进项。每次回顾最多确定两到三项改进，指定负责人与完成时点，纳入下一迭代的日常工作跟踪，并在下次回顾开头逐项检查。改进项长期无人跟进，是伪敏捷最容易被忽视的复发点。
- 补齐实践技能。针对估算、需求拆分、验收标准编写、评审引导等具体技能安排训练，训练内容以团队当前真实工作项为素材，避免只讲流程概念。
涉及考核制度与组织架构调整时，需要交代条件和风险边界。考核口径的修改通常超出团队权限，应先取得直属管理层支持，并设置过渡期，避免新旧口径并行造成混乱；组织架构调整影响面更大，建议先在单个团队或项目试点，明确观察指标与回退方案，试点未达预期时恢复原状的成本要提前评估。任何一步都不宜在缺少管理层共识的情况下由团队单方面宣布。
在处置与验证环节，工具可以承担一部分规则落地的工作。以 ONES 为例，产品负责人可依据需求优先级把需求规划至对应迭代，并在迭代计划会议上与团队就本迭代要完成的需求和验收标准达成一致，再由设计、研发、测试人员拆分子任务跟踪（F2、F5）；迭代过程中团队通过敏捷看板管理任务状态，在站会中对齐进度与风险，并用燃尽图观察效率变化（F3、F6）；迭代回顾时可借助燃尽图、工时日志等报表复盘进度、质量与成本偏差，经验沉淀到 Wiki 形成团队知识库（F4）。多层级权限可按组织架构、用户组与项目角色分配（F7），便于把范围变更的审批职责落到具体角色。需要说明的是，回顾改进项如何转为可跟踪任务并统计完成情况，需结合团队实际配置确认；完成定义是否以独立检查清单形式承载，也应在试用中核实。
如何验证恢复并防止复发
处置是否生效，用行为指标判断，不用满意度打分。建议在处置启动后的第二到第三个迭代开始观察，给规则落地留出适应时间。
- 迭代范围稳定性：统计迭代内新增与撤出需求占承诺范围的比例，比例持续下降说明范围规则开始起作用。
- 评审反馈闭环率：评审中提出的意见有多少在下一迭代得到回应或纳入待办，闭环率低说明评审仍是演示会。
- 回顾改进项完成情况：上一轮确定的改进项按期完成的数量与比例，连续两个迭代完成为零即触发再诊断。
- 完成定义的执行一致性：抽查已完成事项是否逐条满足完成定义，偏差集中出现说明标准未被真正使用。
复查安排上，建议由 Scrum Master 或团队指定的流程负责人每两个迭代汇总一次上述数据，在回顾会上公开讨论；管理层每季度听取一次进展，重点看规则是否被遵守，而非只看交付数字。责任分工要写清楚：范围规则的维护归产品负责人，改进项跟踪归 Scrum Master，完成定义的执行归团队集体。
防止复发，把关键规则写入团队工作约定与完成定义，让新成员加入时有据可依，也让规则变更需要显式讨论。复发预警信号包括：连续两个迭代出现无记录的紧急插单、回顾会开始跳过上次改进项的检查、看板重新变成对外汇报工具、团队对新需求的第一反应是“先做再说”。出现其中任意两项，就应重新启动一次分层诊断，从治理与授权层开始核对，而不是直接归因于团队态度。
常见问题
团队仪式都做了，但交付节奏没变，这算伪敏捷吗？
单看仪式齐全不能下结论，需要结合交付行为判断。如果站会、评审、回顾按时召开，但发布频率和需求交付周期与引入敏捷前基本一致，团队也说不清最近三个迭代交付了什么，这属于值得启动诊断的信号。建议先核对过去三到六个迭代是否存在可观察的行为改变：有改变、有反复，更可能是实施不成熟；长期无改变且团队普遍认为在走流程，才更接近伪敏捷。
多个原因假设同时成立时，应该先处理哪一个？
优先处理影响面最大的那一层，通常从治理与考核、角色与授权开始。实践层的调整需要以团队拥有一定自主空间为前提，如果考核口径仍以工时和文档为主、迭代范围由外部单方面决定，团队改进站会形式或回顾方法后，往往会在下一轮外部压力下退回原状。确认上层问题后再调整实践细节，收效更稳定。
产品负责人拿不到优先级决策权，处置时应该怎么处理？
先如实评估授权现状，再决定角色设置。若产品负责人确实无法获得优先级和范围的决策权，应调整角色安排或明确实际决策人，保留名义角色会让团队持续处于被动。涉及汇报关系调整时，建议先在小范围试点并设定观察期，把试点期间的决策链记录作为评估依据，未达预期时按事先约定的方式恢复。
回顾会提出的改进项总是没人跟进，有什么可操作的改法？
把改进项数量压下来、跟踪做起来。每次回顾最多确定两到三项改进，指定负责人与完成时点，纳入下一迭代的日常工作跟踪，并在下次回顾开头逐项检查完成情况。连续两个迭代改进项完成为零，就应触发一次再诊断。工具层面，ONES 支持通过燃尽图、工时日志等报表复盘进度、质量与成本偏差，经验可沉淀到 Wiki 形成团队知识库；改进项能否直接转为可跟踪任务并统计完成情况，需结合团队实际配置确认。
调整考核制度或组织架构时，团队层面能直接推动吗？
这类调整通常超出团队权限，需要先取得直属管理层支持。考核口径修改建议设置过渡期，避免新旧口径并行造成混乱；组织架构调整影响面更大，先在单个团队或项目试点，明确观察指标与回退方案，并提前评估恢复原状的成本。缺少管理层共识时，团队单方面宣布规则变化容易引发反复。
