1. 从一次迭代评审的翻车现场说起去年我参与了一个移动端项目的敏捷转型团队刚跑完第三个Sprint。评审会上产品负责人问了一句“这个用户登录模块算完成了吗”开发说完成了测试说还有两个边界场景没覆盖产品说验收标准里没写清楚第三方授权登录算不算。结果一个本该15分钟结束的评审会硬生生开了两个小时最后结论是“下个Sprint再补”。这不是个例。我后来复盘发现问题的根源不在人而在团队从来没有明确定义过两个东西DoDDefinition of Done完成的定义和DoRDefinition of Ready就绪的定义。这两个概念在敏捷圈里被反复提及但真正落地到日常协作中的团队并不多。很多团队把“完成”当成一种感觉把“就绪”当成一种默契结果就是无尽的返工和扯皮。这篇文章想做的事情很具体把DoD和DoR这两个概念从“听起来很专业”变成“明天就能用起来”。我会拆解它们各自解决什么问题、怎么制定、怎么落地、踩过哪些坑以及在不同团队规模下怎么调整。不管你是刚接触敏捷的新人还是带过几个团队的老手都能从这里找到可以直接抄作业的东西。2. DoD和DoR到底在解决什么问题2.1 没有DoD的团队每天都在经历什么先说不好的情况。一个没有DoD的团队通常会出现以下几种典型症状“完成”的定义因人而异开发认为代码提交了就是完成测试认为用例跑完了才算完成产品认为上线了才叫完成。三个人三个标准每次评审都在对齐认知。技术债越积越多因为没有明确的完成标准单元测试可以不写、代码评审可以跳过、文档可以后补。每个Sprint看起来都交付了功能但代码质量在持续下滑。返工成为常态上个Sprint说完成的功能这个Sprint又冒出来一堆bug和遗漏团队永远在“补作业”。估算越来越不准因为“完成”的边界模糊估算时每个人心里算的工作量不一样导致Velocity速率数据失真迭代计划失去参考价值。这些症状的共同根源是团队缺少一个共享的、明确的、可验证的完成标准。DoD就是来解决这个问题的。2.2 DoR存在的意义别让半成品进入迭代再说DoR。很多团队把注意力都放在DoD上忽略了DoR结果就是迭代计划会上讨论的需求本身就不成熟——需求描述模糊、验收标准缺失、依赖关系没理清、设计稿还没出。这种需求进入Sprint之后开发做了一半发现做不下去或者做完了发现不是产品想要的。DoR的核心作用是在需求进入迭代之前确保它已经足够清晰、足够具体、足够可执行。它是一道门槛把“还需要讨论”的需求挡在Sprint外面让团队在迭代期间能够专注于交付而不是一边开发一边澄清需求。用一个类比来说明DoR像是餐厅后厨的“备菜检查”——食材洗好了、切好了、调料配齐了厨师才能开火炒菜。DoD则是“出餐标准”——菜炒好了、摆盘了、温度对了、没有异物才能端给客人。两者缺一不可。2.3 两者的边界与协作关系DoD和DoR不是孤立的它们共同构成了敏捷交付的质量防线。DoR管入口DoD管出口。入口不严迭代期间就会频繁被打断出口不严交付物就会带着问题流入下个环节。这里有一个容易混淆的点DoD是针对所有工作项的统一标准而DoR通常是针对用户故事级别的检查清单。DoD一旦确定团队所有成员都必须遵守不因故事大小而改变DoR则可以根据故事类型功能开发、缺陷修复、技术优化有所调整。还有一个常见误区把DoD当成验收标准Acceptance Criteria。验收标准是针对单个故事的具体条件比如“用户可以用邮箱和密码登录”DoD是跨故事的通用标准比如“所有代码必须经过同行评审”。两者是互补关系不是替代关系。3. 制定DoD从“我觉得完成了”到“大家公认完成了”3.1 一条合格的DoD应该长什么样先给一个可以直接参考的DoD模板适用于大多数Web应用开发团队检查项具体要求验证方式代码实现功能代码已完成并通过自测开发自测报告代码评审至少一名团队成员完成Review代码平台记录单元测试新增代码覆盖率不低于80%CI流水线报告集成测试相关接口联调通过测试环境日志验收标准所有AC逐条验证通过测试用例执行记录文档更新API文档、用户手册同步更新文档仓库提交记录部署验证在预发布环境部署并验证通过部署日志产品验收产品负责人确认功能符合预期验收签字或系统状态这个模板不是标准答案但它展示了一条合格DoD的几个特征具体、可验证、有明确的责任人和验证方式。3.2 制定DoD的实操步骤制定DoD不是项目经理一个人拍脑袋写出来的它需要团队共同参与。我通常建议按以下步骤来第一步收集现状。让每个角色开发、测试、产品、运维分别列出“我认为一个功能算完成必须满足哪些条件”。这一步的目的是暴露认知差异。第二步归类合并。把所有条件贴到白板上合并同类项去掉重复和过于琐碎的条目。通常一个10人以下的团队DoD条目控制在8到12条比较合适。第三步逐条讨论可验证性。对每一条问三个问题这条能不能被客观验证谁来验证验证的成本高不高如果一条标准无法被验证或者验证成本过高就要考虑是否值得纳入。第四步试运行两个Sprint。DoD不是一成不变的先试运行在迭代回顾会上讨论哪些条目太严、哪些太松、哪些根本没人执行。第五步固化并可视化。把最终确定的DoD打印出来贴在团队看板上或者在项目管理工具里设置为检查清单确保每次评审都对照执行。3.3 不同团队的DoD差异化调整DoD不是越严格越好它需要匹配团队的成熟度和项目特点。以下是我在不同类型团队中观察到的调整策略初创团队5人以下DoD可以精简到5到6条重点放在代码评审和基本测试上。不要一上来就要求80%覆盖率先养成写测试的习惯更重要。成长期团队5到15人可以引入CI流水线、自动化测试、文档更新等条目。这个阶段的关键是建立稳定的工程实践。多团队协作15人以上需要区分“团队级DoD”和“项目级DoD”。团队级DoD管日常开发项目级DoD管跨团队集成和发布。合规要求高的项目需要增加安全扫描、审计日志、权限验证等条目并且这些条目的验证方式要留痕。注意DoD一旦确定就不要因为进度压力而随意降低标准。如果某个Sprint确实无法满足全部DoD正确的做法是缩小故事范围而不是放宽完成标准。4. 落地DoR把“半成品需求”挡在迭代门外4.1 DoR检查清单的典型结构DoR的核心是一份检查清单用来判断一个用户故事是否已经准备好进入Sprint。以下是一个经过多个团队验证的DoR模板检查维度具体问题通过标准价值清晰这个需求解决什么问题能用一句话说清用户价值验收标准怎么判断做完了至少有3条可测试的AC依赖关系依赖哪些外部系统或团队依赖已确认且无阻塞设计支持是否有UI/UX设计稿设计稿已评审通过技术方案技术实现路径是否明确无重大技术不确定性工作量估算团队是否达成一致估算偏差在可接受范围测试准备测试用例是否已设计关键路径用例已就绪这份清单的目的是在迭代计划会上快速过一遍任何一个维度不通过这个故事就不应该被拉入Sprint。4.2 为什么很多团队的DoR形同虚设我见过不少团队制定了DoR但执行效果很差。常见原因有三个原因一产品负责人压力太大。业务方催得紧产品负责人不敢把不成熟的需求挡回去怕被说不配合。这种情况下DoR就变成了一张废纸。原因二DoR条目太多太细。有的团队列了20多条DoR每次检查要花半小时久而久之大家就懒得看了。DoR应该控制在7到10条聚焦最关键的几个维度。原因三没有明确的“不通过”处理机制。检查发现不通过然后呢如果没有后续动作检查本身就失去了意义。正确的做法是不通过的故事放回待办列表由产品负责人补充信息后重新提交。4.3 DoR与迭代计划会的配合方式DoR最自然的落地场景就是迭代计划会。我通常建议在计划会开始之前由产品负责人先做一轮自检把明显不满足DoR的故事提前筛掉。计划会上团队再对剩余故事做快速检查。具体操作可以这样计划会的前15分钟团队一起过一遍候选故事的DoR检查清单。每个故事由产品负责人用1分钟说明团队用1分钟提问。如果发现某个维度不满足直接标记为“未就绪”不纳入本次Sprint。这样做的好处是计划会的焦点从“这个能不能做”转移到“这个怎么做”效率会明显提升。而且团队在迭代期间被打断的次数会大幅减少。5. 真实项目中的踩坑与调优记录5.1 坑一DoD太严导致迭代无法交付有一次我帮一个团队制定DoD大家讨论得很兴奋最后列了18条包括“所有API必须有Swagger文档”“所有前端组件必须有Storybook示例”“所有数据库变更必须有回滚脚本”。结果第一个Sprint就翻车了——团队为了满足这些标准把大部分时间花在了写文档和补测试上核心功能反而没做完。复盘时我们发现问题不在于这些标准本身不对而在于一次性引入太多新要求。团队之前没有这些习惯突然全部加上去认知负荷太大。调整方案是把DoD分成“必须满足”和“逐步引入”两类。必须满足的只有5条代码评审、单元测试、AC验证、部署验证、产品验收其余条目分三个Sprint逐步纳入。这样团队有一个适应过程执行起来也不会太痛苦。5.2 坑二DoR被当成“需求冻结”的借口另一个团队在引入DoR之后产品负责人变得过于保守要求所有需求必须100%满足DoR才能进入Sprint。结果待办列表里积压了大量“未就绪”的故事团队连续两个Sprint都没什么可做的。这个问题的本质是把DoR当成了“完美需求”的标准而不是“足够开始”的标准。DoR的目的是确保需求足够清晰、足够可执行而不是完美无缺。有些细节可以在迭代期间澄清只要不影响整体开发方向。调整方案是把DoR条目分为“硬性门槛”和“软性建议”。硬性门槛包括价值清晰、验收标准明确、无重大依赖阻塞软性建议包括设计稿完善度、测试用例详细度。硬性门槛必须满足软性建议可以带着问题进入迭代但要在Sprint期间解决。5.3 坑三DoD和DoR混淆导致检查重复还有一个常见问题是团队把DoD和DoR的检查项搞混了。比如在DoR里写了“代码必须经过评审”在DoD里也写了同样的内容。结果每次检查都要重复确认浪费时间。正确的做法是DoR关注的是需求本身的质量价值、验收标准、依赖、设计DoD关注的是交付物的质量代码、测试、文档、部署。两者检查的维度不同不应该有重叠。我通常建议团队用一张表格来区分维度DoR检查DoD检查需求描述是否清晰具体不检查验收标准是否可测试是否全部通过代码质量不检查是否通过评审测试覆盖不检查是否达到标准部署状态不检查是否验证通过这样每个检查项都有明确的归属不会出现重复或遗漏。6. 让DoD和DoR真正活起来的几个关键动作6.1 可视化让标准随时可见DoD和DoR如果只存在于文档里大概率会被遗忘。我见过执行得最好的团队都是把这两份清单物理可视化的。具体做法包括在团队看板旁边贴一张大海报左边是DoR右边是DoD用不同颜色区分。在项目管理工具如Jira、Trello里设置检查清单模板每个故事创建时自动带出DoR每个故事完成时自动带出DoD。在每日站会的白板上留一个角落专门标注当前Sprint中哪些故事未满足DoR、哪些未满足DoD。可视化的核心目的是降低执行成本。当检查清单就在眼前团队成员不需要刻意回忆自然就会对照执行。6.2 回顾会上的定期审视DoD和DoR不是刻在石头上的它们需要随着团队成熟度和项目阶段不断调整。我建议在每个Sprint的回顾会上固定留出10分钟来审视这两份清单。审视的问题可以包括这个Sprint有没有因为DoD不明确导致的返工有没有故事在进入Sprint后才发现不满足DoR有没有DoD条目实际上从未被执行过有没有新的质量要求需要加入DoD通过这种定期审视DoD和DoR才能保持生命力而不是变成一份“写完就忘”的文档。6.3 新成员入职时的必读材料DoD和DoR还有一个容易被忽略的价值它们是团队协作规范的载体。新成员加入时与其口头解释“我们团队怎么干活”不如直接给他看这两份清单。我通常建议团队把DoD和DoR纳入新成员入职培训的第一周内容并且安排一次专门的讲解。讲解时不只是念条目而是结合具体案例说明为什么这条标准重要不遵守会导致什么问题之前有没有因此踩过坑这样做的好处是新成员从第一天起就清楚团队的交付标准不需要通过反复犯错来学习。7. 不同规模团队的差异化实践建议7.1 小团队轻量但不可省略5人以下的小团队最容易觉得“我们人少不需要这些形式化的东西”。但我的经验是人越少越需要明确的标准因为每个人承担的角色更多边界更容易模糊。小团队的DoD可以精简到5条左右DoR可以精简到5条左右。关键不是条目多少而是团队是否真的对照执行。我见过一个4人团队DoD只有三条代码评审、自测通过、产品确认。但因为他们每次评审都严格对照交付质量反而比很多大团队都好。7.2 中型团队分层与自动化10到20人的团队通常已经分成多个小组。这时候DoD和DoR需要考虑分层设计团队级DoD每个小组根据自己的技术栈和业务特点制定比如前端组可能强调组件测试后端组可能强调接口契约测试。项目级DoD跨小组协作时使用的统一标准比如集成测试通过、端到端流程验证通过。DoR通常由产品负责人统一维护但不同小组可以根据自己的技术领域做微调。中型团队还有一个关键动作是自动化检查。把能自动化的DoD条目如代码覆盖率、静态扫描、构建状态接入CI流水线减少人工检查的负担。7.3 大型团队标准化与灵活性平衡20人以上的团队往往涉及多个项目和多个产品线。这时候最大的挑战是既要保证交付标准的一致性又要允许不同项目根据自身特点做调整。我的建议是采用核心扩展的模式核心DoD由工程效能团队或架构组制定所有项目必须满足通常包括代码评审、安全扫描、部署验证等。扩展DoD各项目根据业务特点自行添加比如金融类项目可能增加审计日志要求社交类项目可能增加性能测试要求。DoR通常由产品部门统一制定框架各项目根据需求类型做细化。这种模式下核心标准保证了底线质量扩展标准保留了灵活性。8. 一个可以直接抄的落地模板8.1 DoD模板通用版## 完成的定义DoD ### 代码质量 - [ ] 功能代码已完成并通过开发自测 - [ ] 至少一名团队成员完成代码评审 - [ ] 无严重级别的静态扫描告警 ### 测试验证 - [ ] 新增代码单元测试覆盖率不低于80% - [ ] 相关集成测试用例全部通过 - [ ] 验收标准逐条验证通过 ### 文档与部署 - [ ] API文档已同步更新 - [ ] 在预发布环境部署并验证通过 - [ ] 产品负责人确认功能符合预期8.2 DoR模板通用版## 就绪的定义DoR ### 需求清晰度 - [ ] 用户价值能用一句话说清 - [ ] 验收标准至少3条且可测试 - [ ] 无未解决的业务规则疑问 ### 技术可行性 - [ ] 无重大技术不确定性 - [ ] 外部依赖已确认且无阻塞 - [ ] 团队对工作量估算达成一致 ### 设计支持 - [ ] UI/UX设计稿已评审通过如适用 - [ ] 测试用例关键路径已设计这两个模板可以直接复制到团队文档里根据实际情况增删条目。关键是先跑起来再优化不要等到“完美”了才开始用。9. 我个人的几条实操心得最后分享几条我在多个团队中总结出来的经验不一定对所有人都适用但至少能帮你少走一些弯路。第一条DoD和DoR的条目数量宁少勿多。我见过太多团队一开始列了十几二十条结果执行两周就没人看了。先定5到8条跑顺了再逐步增加。记住能被执行的5条标准比没人看的20条标准有价值得多。第二条DoD是团队自己的承诺不是管理层强加的要求。如果DoD是领导拍板定的团队执行起来就会应付了事。只有团队自己讨论、自己制定、自己承诺的标准才会有真正的约束力。第三条DoR不通过的故事要有明确的处理流程。不能只是标记一下就算了要明确谁负责补充信息、什么时候重新提交、下次检查是什么时候。没有闭环的检查等于没检查。第四条定期回顾比严格执行更重要。团队在不同阶段的成熟度不同DoD和DoR也需要随之调整。每个Sprint花10分钟审视一下比制定一份“完美”的清单然后束之高阁要有效得多。第五条不要用DoD和DoR来考核个人。这两份清单是团队协作的工具不是绩效考核的依据。一旦用来考核个人团队成员就会倾向于降低标准或者隐瞒问题反而破坏了它们的价值。这些心得都是我在实际项目中踩过坑之后总结出来的不一定每条都适合你的团队但至少可以作为一个参考起点。DoD和DoR的本质不是形式主义而是帮助团队建立共享的期望和明确的边界。当每个人都知道“什么算完成”和“什么算就绪”协作效率自然会提升扯皮和返工自然会减少。