作者： Q.H. Wang

Scrum团队设Product Owner、Scrum Master和开发团队三类固定角色，以Sprint时间盒组织协作；Kanban团队沿用现有岗位分工，用看板和WIP限制管理流动。本文用同口径对照表比较两种团队形态，并给出选择与过渡的判断条件。

完成定义需要随团队成熟度定期评审和演进。本文说明如何建立DoD现状基线、识别定义老化的常见原因，按起步、成长、成熟三个阶段调整条目颗粒度与评审频率，并给出评审触发点、变更记录和效果验证的具体做法。

Scrum规定Product Owner、Scrum Master和开发团队三类角色，以Sprint固定节奏推进；Kanban不设必备角色，靠可视化工作流、WIP限制和拉动式流转协作。本文按角色设置与协作方式两个维度对照两者差异，并给出适配场景与组合使用的判断条件。

完成定义、质量门禁和发布标准约束对象不同，冲突多发生在覆盖交叉处。本文给出冲突分类方法、四步协调操作、裁决与维护的角色分工、一个演示示例和协调后的完成检查清单，帮助团队确定以哪套规则为准并留下书面记录。

完成定义与验收条件冲突时，先看规则层级：质量门禁和发布标准是底线，DoD 是团队统一承诺，AC 在底线之上细化。本文给出冲突分类、五步协调流程、角色分工、完整裁定示例和闭环检查清单，帮助团队把裁定落到书面规则并防止同类冲突复发。

DoD 老化往往表现为条目长期不变、评审流于形式、缺陷在交付后集中暴露。本文给出从现状基线、老化原因归类、评审节奏与角色分工，到逐条演进、前提代价和效果验证的完整做法，帮助团队把 DoD 维护成一份持续有效的团队约定。

完成定义要真正落地，工具需具备检查项模板、工作流门禁、审计留痕与跨团队复用四类配置能力。本文给出每类能力的判断口径，并说明如何用一条真实工作项在试用中逐项验证，最后给出取舍与治理建议。

维护 Definition of Done 的持续投入由检查项维护、评审执行、质量返工和配套支撑构成。本文以迭代为核算周期，把四类投入统一折算为人时，给出净投入产出比与回收周期公式，并说明口径假设、敏感因素和数据取数方法，帮助团队把 DoD 维护纳入预算与资源安排。

迭代容量估算偏高会带来承诺过载或容量浪费。本文给出从三类输入取数、四步估算形成可承诺区间、区间内承诺取量、迭代中调整与未完成项重新评估的完整方法，附数字示例与完成检查清单。

外部依赖多时，承诺容量按“可信产出减依赖损耗”确定：先折算成员可用容量，再用历史速率取可信产出区间，然后按依赖到位概率折减阻塞型事项，最后用缓冲和承诺分级锁定范围，并给出角色分工与迭代跟踪检查清单。