完成的定義 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 條評論
還沒有評論，來搶沙發～