DoR & DoD：敏捷開發的雙保險！
在 Scrum 敏捷開發中，Definition of Ready (DoR) 和 Definition of Done (DoD) 是確保開發順利進行的兩大關鍵標準——一個負責「準備好開始動工」，另一個確保「東西真正的完成」。
Definition of Ready (DoR) 是什麼？
DoR 代表一項任務、用戶故事（User Story）或需求，在進入 Sprint 或開發階段前，必須達成的一組清晰標準。它確保團隊在開始工作時擁有足夠資訊、資源和共識，減少開發過程中的返工與阻礙。
通常在 Sprint Planning 規劃會議 或 Backlog Refinement 會議 中，團隊會和 PO 一起確認任務是否符合 DoR，確保它的細緻度足夠，可以讓開發團隊順利執行。
DoR 的核心作用
✅ 提升準備度：確保開發前資訊完整，避免模糊需求。
✅ 減少浪費：避免因需求不清或資源不足導致的返工與延遲。
✅ 促進團隊共識：讓開發、測試與產品團隊對目標達成一致。
常見的 DoR 標準
每個團隊的 DoR 可能不同，但常見標準包含：
📌 第一點 : 需求清楚
- User Story 符合 INVEST 原則（獨立、可協商、有價值、可估算、小而可測試）。詳細介紹可看下面的 補充說明 INVEST 原則。
- 有清晰的 驗收標準（Acceptance Criteria），明確成功條件。
📌 第二點 : 設計與技術準備完成
- 初步的技術設計、解決方案已討論。
- API、數據模型、依賴關係已明確定義。
📌 第三點 : 優先級明確
- PO（Product Owner）確認需求價值，且已經排定優先順序。
📌 第四點 : 依賴問題解決
- 其他模組或資源的依賴關係已排除，不會阻礙開發。
📌 第五點 : 範圍 & 影響明確
- 團隊清楚需求的範圍，以及對系統和用戶的影響。
📌 第六點 :相關資料準備就緒
- 參考文件、設計草圖、用戶場景等輔助資料齊全。
補充說明 INVEST 原則
INVEST 原則 是敏捷開發中用來衡量 User Story（用戶故事） 質量的標準，確保需求具備良好的結構，能夠順利開發與測試。
🔍 INVEST 代表六個關鍵原則：
- I – Independent（獨立性）
- N – Negotiable（可協商性）
- V – Valuable（有價值）
- E – Estimable（可估算性）
- S – Small（小而適中）
- T – Testable（可測試性）
I – Independent（獨立性）
每個 User Story 應該能獨立開發、測試與交付，不應過度依賴其他需求。
- 好處：能提高開發靈活度，避免卡在前置需求而無法推進。
- 示例：
❌ 不佳：「作為使用者，我希望能夠在登入後查看訂單詳情。」（依賴登入功能，無法獨立開發）
✅ 佳：「作為使用者，我希望能夠查看我的訂單詳情。」（訂單詳情可先獨立開發，不受登入狀態影響）
N – Negotiable（可協商性）
User Story 不應該被視為「固定的規格書」，而是可以根據需求、技術可行性與優先級進行調整。
- 好處：開發團隊可以參與需求探討，透過討論找到更好的實現方式。
- 示例：
❌ 不佳：「報表功能必須以 Excel 下載，並使用固定格式。」（需求過於剛性，可能有更好的解決方案）
✅ 佳：「使用者應能下載報表，格式可以根據需求調整。」（允許與開發團隊討論最佳方案）
V – Valuable（有價值）
User Story 應該能為使用者或業務帶來明確價值，避免純技術性的開發項目。
- 好處：確保開發的功能對用戶或業務真正有意義，優先處理能帶來價值的項目。
- 示例：
❌ 不佳：「開發新的後端 API。」（技術性敘述，無法清楚展現價值）
✅ 佳：「作為用戶，我希望能夠搜尋歷史訂單，以便快速找到過去的消費紀錄。」（清楚表達使用者的價值）
E – Estimable（可估算性）
User Story 應該具備足夠資訊，使開發團隊能夠進行時間與工作量的估算。
- 好處：讓團隊能合理安排 Sprint 計畫，避免估算困難導致時間超支。
- 示例：
❌ 不佳：「優化搜尋功能，讓它更快。」（需求過於模糊，無法估算工作量）
✅ 佳：「將搜尋功能的回應時間從 3 秒減少到 1 秒，透過索引優化或快取機制實現。」（具體且可估算）
S – Small（小而適中）
User Story 應該足夠小，以便在一個 Sprint 內完成，避免過於龐大導致難以開發與測試。
- 好處：讓開發可以更快完成、測試與交付，保持敏捷迭代的節奏。
- 示例：
❌ 不佳：「開發完整的會員系統，包括註冊、登入、密碼找回、個人資料管理。」（過大，應拆分）
✅ 佳：「開發會員註冊功能，包括 Email 驗證機制。」（範圍小，能獨立完成）
T – Testable（可測試性）
User Story 應該有明確的驗收標準（Acceptance Criteria），以確保能夠被測試並驗證功能是否符合需求。
- 好處：減少溝通誤差，確保開發完成後能夠驗證是否符合預期。
- 示例：
❌ 不佳：「使用者應該能收到通知。」（模糊，如何測試？何時通知？）
✅ 佳：「當使用者的訂單狀態變更時，系統應發送 Email 通知，且通知內容包含訂單號與狀態。」（明確可測試）
INVEST 整理表
| 原則 | 說明 | 好處 |
|---|---|---|
| I – 獨立性 | User Story 應該能獨立開發與交付 | 避免受前置任務影響，提高開發彈性 |
| N – 可協商性 | 需求不是死板的規格書，可與團隊討論最佳方案 | 增加開發靈活度，找到更高效的解決方式 |
| V – 有價值 | 需求應能對使用者或業務帶來價值 | 確保開發的功能真正對使用者有幫助 |
| E – 可估算性 | 需求資訊充足，使開發團隊能夠估算工作量 | 避免開發進度失控，讓計畫更可預測 |
| S – 小而適中 | User Story 應該足夠小，能在一個 Sprint 內完成 | 讓開發更快完成，減少任務過大帶來的風險 |
| T – 可測試性 | 需求應具備明確的驗收標準，以便測試與驗證 | 確保開發完成後可驗證，降低溝通誤差 |
💡 掌握 INVEST 原則，讓 User Story 更加清晰、可執行，確保開發流程順暢！🚀
Definition of Done (DoD) 是什麼？
如果說 DoR 確保 「準備好開始」，那 DoD 則是確保「完成得妥當」。
DoD 代表一項任務在開發完成後，必須滿足的一組標準，以確保交付的產品符合品質要求、可交付且可驗證。
DoD 的執行者主要是開發團隊，確保最終交付的成果能達到「真正的完成」，避免「做好了但還不能用」的狀況。
DoD 的核心作用
✅ 確保品質標準：降低技術債，確保產品穩定性。
✅ 避免未完成的交付：確保「完成」的功能可驗證且可用。
✅ 促進透明與對齊：讓整個團隊對「何謂完成」有一致認知。
常見的 DoD 標準
視團隊與 PO 的溝通共識可能會有以下這幾種不同層次的 DoD 標準，也會隨著團隊越來越成熟，DoD 的完成標準越來越高。
📌 功能已開發完成 : 程式碼編寫完成並通過 Code Review。
📌 單元測試通過 : 符合預期行為。
📌 整合測試完成 : 確保與其他模組正常運作。
📌 驗收標準滿足 : PO 或測試團隊確認功能符合需求。
📌 已部署到測試環境 : 並通過基本測試。
📌 文件更新 : 包含 API 文件、操作手冊、變更記錄等。
DoR vs DoD：誰負責？
| DoR（準備好開始） | DoD（完成交付） | |
|---|---|---|
| 時間點 | 進入 Sprint 或開發前 | 開發完成、交付產品時 |
| 目標 | 確保需求明確、開發準備就緒 | 確保功能已開發、測試並可交付 |
| 負責人 | PO & 團隊 共同確認 | 開發團隊 確保品質 |
實際應用建議
🚀 DoR：在 Sprint Planning & Backlog Refinement 會議中，檢查是否達到標準，避免需求模糊影響開發效率。
🚀 DoD：透過看板（如 Jira）標記完成標準，確保所有交付物滿足品質要求，避免未完成的「半成品」流入產品中。
🚀 定期回顧與優化：隨著團隊成熟度提升，DoR & DoD 也應該持續調整，讓流程更加流暢。
結論 Recap
✔ DoR：確保 「準備好開工」，避免需求模糊導致混亂。
✔ DoD：確保 「交付真正完成」，避免未完成的功能影響品質。
✔ 一起用 DoR & DoD 打造高效敏捷團隊，讓開發流程更順暢！ 🚀
