完成定义（DoD）与验收条件（AC）冲突时，先看规则层级：组织级质量门禁和发布标准是底线，DoD 是团队对“做完”的统一承诺，AC 是单个工作项的具体判定。门禁与 DoD 冲突以门禁为准，DoD 与 AC 冲突按“就高不就低、窄范围细化”处理。本文给出冲突分类、协调步骤、角色分工、示例和闭环检查，帮助团队把裁定落到书面规则。
要点总览（TL;DR）
- 冲突时按“门禁→DoD→AC”的顺序判断：组织级质量门禁与发布标准是底线，完成定义是团队对“做完”的统一承诺，验收条件在底线之上细化单个工作项。
- 裁定遵循两条原则：就高不就低，低层级要求低于高层级时按高层级执行；窄范围细化，低层级要求更高时按低层级执行，并评估是否沉淀回高层级规则。
- 协调按识别、取证、裁定、回写、例外处理五步推进，由产品负责人主持，团队开发负责人与质量或发布负责人参与，形成书面裁定记录。
- 裁定后必须回写规则文档并通知相关角色；临时豁免需登记有效期与到期复查责任人，豁免只针对具体工作项和时段。
- 闭环检查与迭代节奏对齐：核对版本更新、记录可检索、同类冲突未复发、测试用例已按裁定调整。
先判断冲突类型，再决定以哪套规则为准
多数所谓“冲突”在核对文本后会发现只是表述差异，真正需要裁定的情况集中在几类规则之间。先分清规则约束的对象和层级，再判断以哪套为准，可以避免把措辞问题升级成流程争议。
四类规则的约束对象与层级
完成定义、验收条件、质量门禁、发布标准分别约束不同范围。层级越高，越接近组织底线；范围越窄，越接近单个工作项的具体判定。
| 规则 | 约束对象 | 典型内容 | 层级定位 |
|---|---|---|---|
| 质量门禁 | 组织或产品线的交付质量底线 | 必须通过的静态扫描、安全扫描、缺陷密度阈值 | 最高，不可由团队自行降低 |
| 发布标准 | 一次发布能否对外交付 | 回归通过率、上线检查项、回滚方案就绪 | 高，发布前必须满足 |
| 完成定义（DoD） | 团队对“工作项做完”的统一承诺 | 代码评审、单元测试、文档更新、自测通过 | 中，团队级底线 |
| 验收条件（AC） | 单个工作项的具体判定 | 某功能的性能指标、交互细节、边界场景 | 窄，在 DoD 之上细化 |
三类典型冲突
第一类是门禁与 DoD 冲突，例如 DoD 只要求单元测试通过，门禁却要求覆盖率不低于约定阈值。第二类是 DoD 与 AC 冲突，例如 DoD 规定接口响应时间满足通用标准，而某工作项 AC 提出更严或更松的指标。第三类是 AC 与发布标准冲突，例如 AC 允许某类已知问题遗留，发布标准却要求清零。三类冲突的裁定方向一致：底线规则优先，窄范围规则在底线之上细化。
优先级判断顺序与裁定原则
判断顺序为门禁→DoD→AC，发布标准在发布环节作为附加约束参与判断。裁定遵循两条原则：就高不就低，即低层级规则的要求低于高层级规则时，按高层级执行；窄范围细化，即低层级规则要求高于高层级规则时，按低层级执行，并评估是否把新增要求沉淀回高层级规则。协调由团队与产品负责人共同完成，形成书面裁定。
属于表述差异而非实质冲突的情况
以下情况通常不需要裁定，只需统一措辞：同一要求在不同文档中用了不同说法，例如“自测通过”与“开发自验完成”；AC 复述了 DoD 的通用条目而未增加新要求；门禁条目与 DoD 条目指向同一检查动作但名称不同。处理方式是核对检查动作和判定标准是否一致，一致则合并表述，不一致才进入裁定流程。
冲突协调的操作步骤：从识别到裁定落地
裁定原则需要落到具体动作上。下面按识别、取证、裁定、回写、例外处理五个环节展开，每个环节说明输入、动作、输出和完成标志。
第一步：识别冲突
输入是当前迭代的工作项、DoD 文档、AC 文本和门禁清单。动作是在四个时点主动比对：需求梳理时比对 AC 与 DoD，迭代计划评审时确认 AC 与 DoD 是否一致，验收时核对实际判定标准，发布前核对门禁与发布标准。输出是一份冲突登记，记录工作项、冲突双方、发现时点和影响范围。完成标志是每条冲突都有明确的责任人和处理时限。
第二步：取证
输入是冲突登记。动作是调取 DoD、AC、门禁与发布标准的现行版本，确认各自适用范围和生效时间，排除引用旧版本造成的假冲突。输出是冲突证据包，包含各规则的版本号、适用条款原文和差异点。完成标志是冲突双方都能确认所引条款为现行有效版本。
第三步：裁定
输入是证据包。动作是由产品负责人主持，团队开发负责人、质量或发布负责人参与，依据“门禁→DoD→AC”的顺序和“就高不就低、窄范围细化”原则给出结论。输出是一份书面裁定记录，写明冲突描述、适用原则、裁定结果、生效范围和生效时间。完成标志是相关角色在裁定记录上确认，记录可检索。
第四步：回写
输入是裁定记录。动作是更新对应文档：门禁与 DoD 冲突时回写 DoD，DoD 与 AC 冲突时视情况更新 AC 或把新增要求沉淀进 DoD，AC 与发布标准冲突时核对发布检查项。同步通知受影响的角色，并在下一次迭代计划会上说明变更。输出是更新后的规则文档和变更通知。完成标志是文档版本号更新、相关角色确认已阅读。
第五步：例外处理
输入是临时豁免申请。动作是说明豁免理由、影响范围和有效期，由质量或发布负责人审批，重大豁免需产品负责人共同确认。输出是豁免记录，包含审批人、有效期和到期复查责任人。完成标志是豁免记录登记在案，到期前有复查提醒。豁免只针对具体工作项和具体时段，不改变规则本身。
角色分工与各自交付物
冲突协调最常见的失败是无人拍板或多人重复裁定。把职责边界和交付物写清楚，可以让每次裁定都有明确的主持人和确认人。
| 角色 | 职责边界 | 交付物 |
|---|---|---|
| 产品负责人 | AC 的最终解释权，判断业务优先级，主持 DoD 与 AC 冲突的裁定 | AC 澄清结论、裁定记录中的业务判断部分 |
| 团队或开发负责人 | 评估 DoD 的技术可行性，守住团队质量底线，提出 DoD 修订建议 | 技术评估意见、DoD 修订草案 |
| 质量或发布负责人 | 执行门禁与发布标准，审批临时豁免，判断豁免对交付风险的影响 | 门禁执行记录、豁免审批记录 |
| Scrum Master 或项目管理者 | 组织协调会议，记录裁定，跟踪回写和通知，维护冲突登记 | 冲突登记、裁定记录、回写跟踪表 |
裁定记录采用统一格式，包含冲突描述、涉及规则及版本、适用原则、裁定结论、生效时间、确认人。确认方式可以是会议纪要签字、文档评论区确认或在协作工具中对裁定记录标记确认状态。涉及门禁和发布标准的裁定，质量或发布负责人必须确认；涉及 AC 解释的裁定，产品负责人必须确认。
裁定记录和规则文档需要有稳定的承载位置。ONES Wiki 可用于沉淀团队规则与经验，形成可检索的知识库；工作项上的验收标准与子任务拆分可在同一处对齐，测试环节依据验收标准编写和执行用例。裁定结论回写到对应文档后，相关角色在同一平台查看更新，减少版本分散带来的重复冲突。
示例：一次DoD与AC冲突的完整裁定过程
以下为演示情景，用于说明裁定原则如何落地，不代表真实项目数据。
情景设定
某团队 DoD 规定“接口在常规负载下响应时间满足团队通用标准”，某工作项的 AC 写明“列表接口在峰值负载下响应时间不超过更严格的指标”。开发人员认为按 DoD 自测通过即可提测，测试人员按 AC 判定不通过，双方在验收环节产生分歧。
冲突识别与取证
测试人员在验收时发现实际表现满足 DoD 通用标准，但未达到 AC 的峰值指标，登记为 DoD 与 AC 冲突。取证阶段调取现行 DoD 和该工作项 AC，确认两者均为当前版本，AC 的峰值指标是产品负责人根据业务场景新增的要求，属于实质冲突而非表述差异。
按“就高不就低”裁定的推理
AC 要求高于 DoD，属于窄范围细化。按“窄范围细化”原则，该工作项按 AC 执行；同时评估该峰值指标是否具有普遍性。若同类接口普遍面临峰值场景，则把峰值负载要求沉淀进 DoD，避免每个工作项重复提出。
裁定结果、回写动作与后续影响
裁定结果为：该工作项按 AC 的峰值指标验收，开发补充性能优化后重新提测；团队评估后将峰值负载要求写入 DoD 的性能条款，版本号更新并通知全体成员。后续同类工作项直接按更新后的 DoD 执行，不再逐项裁定。测试用例同步补充峰值场景。
反向情况的处理差异
若 AC 要求低于 DoD，例如 AC 只要求功能可用而未提代码评审，则按 DoD 执行，AC 不得降低团队底线。此时回写动作是澄清 AC 表述，说明 DoD 条款同样适用，无需修改 DoD。两种情况的方向不同，但判断入口相同：先比较要求高低，再决定按哪套执行、回写哪份文档。
完成检查：裁定是否真正生效
裁定记录写完不等于冲突已闭环。用下面这份清单逐项核对，可以确认规则已更新、团队已理解、同类问题不再反复出现。
- 规则文档版本已更新，版本号和生效时间明确，相关角色确认已阅读。
- 裁定记录包含冲突描述、适用原则、结论和确认人，可按工作项或关键词检索。
- 同类冲突在后续迭代中未重复出现；若再次出现，检查是规则未更新还是执行偏差。
- 豁免项均登记有效期和到期复查责任人，到期前完成复查并决定延续或关闭。
- 更新后的 DoD 或 AC 在迭代计划会上向团队说明，新成员入职材料同步更新。
- 测试用例和验收检查项已按裁定结果调整，验收环节不再引用旧标准。
- 裁定记录与规则文档存放在团队可访问的同一位置，避免多版本并存。
检查频率建议与迭代节奏对齐，在每个迭代回顾时抽查一到两条裁定记录，确认回写和通知已完成。连续多个迭代未出现同类冲突，说明规则已稳定；若冲突反复出现，优先检查规则文档是否真正更新并被团队理解，再考虑调整裁定流程本身。
常见问题
如果团队认为质量门禁的某条要求不合理，可以按完成定义执行吗？
不可以。质量门禁属于组织或产品线的交付质量底线，团队不能自行降低。若团队认为某条门禁要求与当前业务场景不匹配，正确路径是提出门禁修订申请，由质量或发布负责人评估并走变更流程；在门禁正式修订前，仍按门禁执行。完成定义可以写得比门禁更严，但不能低于门禁。
验收条件比完成定义更严时，是否每个工作项都要单独裁定一次？
不必。先判断该更严要求是否具有普遍性：如果同类工作项普遍面临相同场景，应把新增要求沉淀进完成定义，更新版本后统一执行，后续工作项不再逐项裁定。如果只是个别工作项的特殊要求，则在该工作项的验收条件中保留，按“窄范围细化”原则执行，并在裁定记录中说明适用范围。
临时豁免到期后没有复查，会带来什么影响？
豁免会变成事实上的规则松动。豁免记录应写明有效期和到期复查责任人，到期前由责任人确认是延续、关闭还是转为正式规则。若长期无人复查，同类工作项可能继续沿用豁免，质量门禁与发布标准的约束力被逐步削弱，后续再收紧会引发新的冲突。
裁定记录应该记到什么颗粒度，才能既可追溯又不成为负担？
每条记录至少包含冲突描述、涉及规则及版本、适用原则、裁定结论、生效时间、确认人。记录按工作项或关键词可检索即可，不需要把讨论过程全文照搬。涉及门禁和发布标准的裁定由质量或发布负责人确认，涉及验收条件解释的裁定由产品负责人确认，确认状态在记录上标记。
规则文档更新后，如何确认团队真正按新规则执行？
在迭代回顾时抽查一到两条裁定记录，核对回写是否完成、相关角色是否确认阅读、测试用例和验收检查项是否已按新标准调整。连续多个迭代未出现同类冲突，说明规则已稳定；若冲突反复出现，先检查规则文档是否真正更新并被理解，再考虑调整裁定流程本身。
