完成的定义 DoD 提示词（团队 DoD / DoR 清单：故事级、Sprint 级、发布级逐层约定）
团队对「做完了」理解不一致、经常出现「开发说完成了但还不能上线」时用：按故事级、Sprint 级、发布级三层写出能用是或否回答的 DoD 清单，对照现有质量问题查漏，再配一份轻量的 DoR，并把暂时做不到的条目移到目标清单。
通用大模型 对话模型通用
请帮我的团队起草「完成的定义」（DoD）和「就绪的定义」（DoR）。这两份清单要贴在看板旁边天天用，所以每一条都必须能用「是 / 否」回答。 团队与产品类型：[团队与产品类型] 技术栈与现有工具（代码评审、自动化测试、持续集成等）：[技术栈与工具] 最近反复出现的质量问题：[近期质量问题] 发布方式与频率：[发布方式与频率] 客户或合规方面的硬性要求：[硬性要求] 一、DoD 分三层写 - 故事级：一个待办项做到什么程度才能挪到「完成」； - Sprint 级：Sprint 结束时的增量要满足什么； - 发布级：推向正式环境前还要满足什么。 每层 5–8 条，覆盖代码、测试、文档、部署四个方面。每条写成可检查的事实，例如「至少一名非作者同事评审通过」，而不是「代码质量良好」。 二、针对我列出的质量问题，逐个说明 DoD 中哪一条能拦住它；拦不住的，补一条。 三、现实检查：对照我的工具现状，把每条 DoD 标成「现在就能做到」或「暂时做不到」。暂时做不到的不放进正式 DoD，移到「目标 DoD」清单，写明需要什么条件、计划什么时候纳入。DoD 是全团队每次都要守住的底线，写了做不到比不写更糟。 四、DoR 写得轻一些，不超过 6 条，只保留「不满足就没法开工」的条件，如验收标准已写明、依赖方已确认、估算不超过团队设定的上限。DoR 是帮团队在梳理时发现问题的清单，不要写成把需求挡在门外的关卡。 五、说明 DoD 与验收标准的区别：DoD 对所有待办项通用，验收标准是每个待办项各自的；各举一个例子。 约束：不要写我的工具做不到的条目；覆盖率、时限这类数值我没有提供的，写【团队商定】，不要替我们定。 输出：三层 DoD 清单 → 质量问题对照表 → 目标 DoD → DoR 清单 → 第一次和团队讨论这份清单时的 3 个引导问题。
高亮处换成你自己的内容：[团队与产品类型]、[技术栈与工具]、[近期质量问题]、[发布方式与频率]、[硬性要求]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[技术栈与工具] 写真实现状，比如「有代码评审，没有自动化测试，手工部署」，模型才不会给出做不到的条目。[近期质量问题] 写具体事件：「上线后发现没有更新接口文档，前端调用失败」。[硬性要求] 例如客户要求每次发布附测试报告。
常见失败与调整：
- 直接从网上抄一份很全的 DoD，团队第一周就开始破例。从五六条真正能守住的开始，每隔几个 Sprint 加一条。
- 条目写成「充分测试」「文档完善」。换成能看见的证据：用例执行记录、文档链接已贴在条目里。
- 把 DoR 当成拒收需求的理由，产品和开发互相卡。DoR 不满足时该做的是一起把它补齐。
示例输出
示例，仅供参考（虚构：6 人团队，维护一套门店管理后台，每两周发布一次，有代码评审、无自动化测试）
故事级 DoD
| 条目 | 现状 |
|---|---|
| 代码已合并到主干，至少一名非作者同事评审通过 | 现在就能做到 |
| 验收标准逐条由测试人员在测试环境验证通过，结果记录在条目评论中 | 现在就能做到 |
| 涉及接口变动的，接口文档已同步更新并贴上链接 | 现在就能做到 |
| 没有遗留的阻塞或严重缺陷 | 现在就能做到 |
| 核心流程有自动化回归用例 | 暂时做不到，移入目标 DoD |
质量问题对照：「上线后接口文档没更新」由第 3 条拦截。
目标 DoD：核心流程自动化回归——需要先搭建测试框架，计划两个 Sprint 后纳入，先覆盖登录、开单、退货三条流程。
区别举例：DoD——「接口文档已同步更新」；验收标准——「退货金额超过 500 元时必须由店长审批」。
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～