伪敏捷通常源于四类原因叠加：把敏捷当成流程套壳，照搬站会、看板、迭代等形式，却没有改变需求进入方式与决策授权；需求与优先级由外部单点决定，团队无法在迭代内形成稳定承诺；角色职责错位，产品负责人缺位或由多方兼任，Scrum Master 变成进度催办；度量与考核仍按工时、文档和交付数量计，团队为满足指标而表演敏捷。排查时应先确认症状出现在哪个环节，再用证据逐条验证假设，最后按原因处置并观察两到三个迭代的恢复情况。
要点总览（TL;DR）
- 伪敏捷常见四类原因：流程套壳、需求与优先级失控、角色职责错位、度量与考核导向偏差，实际中往往叠加出现。
- 判断是否属于伪敏捷，看问题是否连续多个迭代持续且无收敛趋势；偶发偏差属于正常磨合。
- 排查顺序建议先查需求进入与变更，再查角色授权，最后查度量导向，每类原因都要找到可核对的证据再下结论。
- 处置先改机制再改仪式，涉及考核与授权的调整先小范围试点并设定停止点。
- 处置效果看连续两到三个迭代的趋势：变更次数下降、承诺达成趋稳、回顾改进项按期关闭。
伪敏捷的典型症状与判断范围
判断伪敏捷，先看问题是否持续存在。仪式齐全但迭代交付不稳定、回顾会结论不落地、估算与承诺长期脱节，这些表现如果连续多个迭代出现且没有改善趋势，就超出了正常磨合的范围，值得按伪敏捷做系统排查。正常的敏捷落地初期也会出现估算偏差、回顾会讨论发散，区别在于团队能否在几个迭代内形成可见的收敛。
下面这份自查清单可以帮助团队做初步判断。每条按“持续出现”“偶发”“未出现”三档记录，并注明观察了几个迭代。
| 症状 | 观察要点 | 指向的问题 |
|---|---|---|
| 仪式齐全但交付不稳 | 站会、评审、回顾按时开，迭代结束仍有大量未完成项 | 迭代边界与需求准入失效 |
| 回顾会结论不落地 | 改进项连续两三个迭代重复出现，无人跟进关闭 | 改进机制空转，缺少责任人与跟踪 |
| 估算与承诺脱节 | 计划会上承诺的范围与实际完成量长期差距明显 | 优先级来源不稳或授权不足 |
| 迭代内需求频繁插入 | 迭代开始后仍不断接收新需求，团队被动接单 | 需求进入缺少规则与决策人 |
| 角色名存实亡 | 产品负责人不决策优先级，Scrum Master 主要催进度 | 职责错位 |
| 团队关注点偏向指标 | 成员更在意工时填报、文档数量而非交付结果 | 度量与考核导向偏差 |
需要说明本文的讨论范围：以下聚焦框架层面的机制与原因，即需求如何进入、谁做决策、角色如何分工、用什么度量。Sprint 规划、执行、评审、回顾的具体操作方法，以及 Product Backlog 的维护与梳理技巧，属于另外的主题，本文不展开。这样界定是为了把诊断做深，避免把原因分析和操作教程混在一起。
原因假设与排除证据：四类根因如何验证
症状只是线索，不能直接当结论。下面四类原因假设需要各自找到可核对的证据，逐条验证或排除。排查顺序建议从需求进入与变更查起，再看角色授权，最后看度量导向，因为前两者往往直接造成交付不稳，度量问题则更多影响行为方式。
| 顺序 | 原因假设 | 验证证据 | 排除条件 |
|---|---|---|---|
| 1 | 形式套壳：仪式照搬，决策机制未变 | 迭代内需求被随意插入的次数与来源；计划会承诺是否被外部直接推翻 | 需求变更均有记录、经责任人确认且团队参与评估 |
| 2 | 需求与优先级来源单一或频繁变动 | 迭代内变更次数、承诺达成情况、优先级调整是否有统一出口 | 变更次数低且承诺达成稳定，波动可用外部事件解释 |
| 3 | 角色职责错位 | 产品负责人是否实际决定优先级；Scrum Master 的时间是否主要花在催进度 | 优先级由产品负责人决策，Scrum Master 主要处理障碍与流程 |
| 4 | 度量与考核导向偏差 | 考核表使用的指标；团队为满足指标做的额外动作 | 考核以交付结果和改进项完成情况为主 |
验证时要避免单一证据下结论。例如迭代内出现需求变更，可能来自真实的市场变化，也可能来自需求入口没有把关。区分方法是看变更是否经过统一的责任人评估、是否留下记录、团队是否有机会反馈影响。如果变更频繁但每次都有评估和记录，问题更可能在容量规划；如果变更随意进入且无人对优先级负责，则指向假设一和假设二。
角色错位的验证可以看两个具体信号：产品负责人是否在计划会上对优先级做最终决定，还是把决定权交回给上级或客户；Scrum Master 的日常时间分配中，催进度、追工时占比是否明显高于清除障碍和守护流程。度量偏差的验证则直接看考核表：如果评价团队的主要依据是工时饱和度、文档页数或提交数量，团队行为向指标靠拢就是可预期的结果。
按原因处置：分场景的纠正动作
确认原因后再动手，不同原因对应不同的纠正动作。处置的共同原则是先改机制再改仪式，先小范围试点再推广，涉及考核与授权的调整尤其要设定停止点。
流程套壳型
先固定迭代边界与需求准入规则：明确一个迭代的时间盒，规定迭代开始后哪些需求可以进入、由谁批准、需要什么评估。规则落地后再回头调整各个仪式的目的，让站会服务于障碍暴露，让评审服务于结果确认，而不是为了开会而开会。停止点设在规则执行两三个迭代后，如果变更次数没有下降，需要重新检查规则是否被绕过。
需求失控型
建立需求进入与优先级决策的责任人，指定唯一或明确的决策角色，所有需求经统一入口登记，变更留下记录。优先级调整可以发生，但要经过评估并同步给团队。这里的关键产物是一份可追溯的变更记录，让团队能看到需求为什么变、由谁决定。若组织层面存在多个平级需求来源，需要先在上层明确裁决机制，否则团队层面的规则难以执行。
角色错位型
明确产品负责人对优先级的决策权，把“谁说了算”写进团队工作约定；Scrum Master 的职责转向障碍清除、流程守护和团队辅导，减少催进度类事务。调整角色授权涉及组织制度，建议先在一个团队试点，观察一个季度，确认协作关系顺畅后再推广。停止点：如果授权后决策效率明显下降或出现职责真空，应暂停推广并补充配套规则。
度量偏差型
替换考核指标，改用可观察的交付结果与改进项完成情况，例如迭代承诺的达成趋势、回顾改进项的按期关闭率、需求从进入到交付的周期变化。指标替换同样属于制度调整，先在小范围试行，保留原有考核作为过渡，避免一次性推翻现有体系造成团队不安。停止点：新指标运行两三个迭代后，如果团队行为没有向交付结果靠拢，需要检查指标是否仍被旧口径稀释。
在记录变更与改进项这件事上，团队可以借助工作项与文档工具把需求变更、决策记录、回顾改进项统一留痕。例如 ONES 支持用工单收集各方反馈并转化为需求、整理产品 Backlog，并可按实际场景自定义工作流，使需求流转有据可查；迭代回顾中可用燃尽图、工时日志等报表复盘进度与偏差，并用 Wiki 沉淀经验。这些能力服务于记录与追溯，具体规则仍需团队自己制定。
恢复验证与复发预防
处置是否生效，要看趋势而不是单次表现。建议连续观察两到三个迭代，重点看三个信号：迭代内需求变更次数是否下降并趋于可控；承诺达成情况是否稳定，波动能否用已知外部事件解释；回顾会改进项是否按期关闭，而不是反复出现在下个迭代的清单里。
验证时把处置前后的数据放在同一口径下比较。变更次数要区分来源，承诺达成要看完成项与承诺项的比例，改进项关闭要看是否在约定时间内完成并有明确结果。单次迭代表现好可能只是需求恰好平稳，连续两三个迭代的趋势才说明机制在起作用。
复发预防依靠把规则固化下来。把需求准入、角色授权与度量口径写入团队工作约定，作为团队共同遵守的文本，并在回顾中定期复核这些约定是否仍被遵守、是否需要调整。约定本身也要有维护责任人，避免写在文档里无人问津。
为了让复核有据可依，变更记录和改进项需要形成可追溯的证据链。团队可以在工作项系统中记录每次需求变更的原因、决策人和影响评估，把回顾改进项转为可跟踪的工作项并设定关闭标准，用报表观察工作项滞留时间等过程数据的变化。ONES 会自动记录资源投入、缺陷分布、工作项滞留时间等研发过程数据，团队可据此对照处置前后的差异；改进经验也可沉淀到知识库，供后续迭代复核时参考。工具承担记录与呈现，判断是否恢复仍由团队结合证据做出。
常见问题
团队刚开始推行敏捷，估算不准、回顾会讨论发散，算伪敏捷吗？
不一定。落地初期出现估算偏差、回顾会讨论发散属于常见磨合现象，关键看团队能否在几个迭代内形成可见的收敛。如果同类问题连续两三个迭代重复出现、没有改善趋势，才值得按伪敏捷做系统排查。建议先按症状清单记录观察结果，注明持续出现的迭代数，再决定是否进入原因验证。
需求频繁变更，是需求管理问题还是团队执行力问题？
先看变更的进入方式。如果每次变更都经过统一的责任人评估、留下记录、团队有机会反馈影响，问题更可能出在容量规划；如果需求随意插入、无人对优先级负责，则指向需求入口失控和流程套壳。验证时不要只看变更次数，还要看变更来源、决策人和影响评估是否齐全。
调整考核指标和角色授权时，怎样控制风险？
这两类调整涉及组织制度，建议先在一个团队试点，保留原有做法作为过渡，避免一次性推翻现有体系。同时设定停止点：新指标运行两三个迭代后团队行为仍未向交付结果靠拢，或授权后决策效率明显下降、出现职责真空，应暂停推广并补充配套规则。
处置之后多久能判断是否见效？
建议连续观察两到三个迭代，看趋势而非单次表现。重点看三个信号：迭代内需求变更次数是否下降并趋于可控；承诺达成情况是否稳定、波动能否用已知外部事件解释；回顾改进项是否按期关闭。单次迭代表现好可能只是需求恰好平稳，连续趋势才说明机制在起作用。
记录需求变更和改进项，用工具能起到什么作用？
工具的价值在于留痕和可追溯，让复核有据可依。例如 ONES 支持用工单收集各方反馈并转化为需求、整理产品 Backlog，并可按实际场景自定义工作流；迭代回顾中可用燃尽图、工时日志等报表复盘进度与偏差，系统也会自动记录工作项滞留时间等过程数据。规则怎么定、判断是否恢复，仍由团队结合证据做出。
