🎯 什麼情境該想到我
當你「開發者說『我這邊會動，做完了』，但沒人真的把它部署到類生產環境跑過」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：把「done」的定義從「程式功能正確」擴張成「已在類生產環境中被建置、部署、驗證過」，讓整合工作發生在日常工作裡，而不是堆到發布前。
書中演進兩版，兩版都要記得：
第一版（第 10 章，建立在隨選環境之上）
at the end of each development interval, we have integrated, tested, working and potentially shippable code, demonstrated in a production-like environment.
即：每個開發區間結束時，我們有已整合、已測試、可運作且具備出貨潛力的程式碼，並已在類生產環境中示範過。
第二版（第 16 章，建立在主幹開發之上，加粗部分為追加）
“At the end of each development interval, we must have integrated, tested, working, and potentially shippable code, demonstrated in a production-like environment, created from trunk using a one-click process, and validated with automated tests.”
即：追加**「由 trunk 以一鍵流程產生，並經自動化測試驗證」**。
補充判準：
- 只有在能被成功建置、部署、並確認在類生產環境中如預期運作時，才接受這份開發工作為 done——而不是「開發者自己覺得做完了」。
- 理想上，它是在類生產負載（production-like load）與類生產資料集（production-like dataset）下運行，而且遠早於 sprint 結束之前。
- 這條定義的作用是防止「某功能被稱為完成，只因為開發者能在自己筆電上跑起來，別的地方都跑不起來」。
- 理想上預生產環境使用與生產環境相同的工具（監控、日誌、部署），累積熟悉度與經驗。
- 遵守第二版的定義，可以消除「專案結尾另設一個獨立的測試與穩定化階段」這個常見做法。
原文（第一版）：「at the end of each development interval, we have integrated, tested, working and potentially shippable code, demonstrated in a production-like environment.」（L4879–4881）
原文（第二版）：「At the end of each development interval, we must have integrated, tested, working, and potentially shippable code, demonstrated in a production-like environment, created from trunk using a one-click process, and validated with automated tests.」（L5909–5912）
原文（補充判準）：「ideally, it runs under a production-like load with a production-like dataset, long before the end of a sprint.」（L4886–4887）
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 這是演進式的定義：沒有隨選環境就無法要求第一版，沒有主幹開發與可信自動化測試就無法要求第二版。硬性套用只會變成大家一起造假。
- 定義收緊時要同步提供能力（環境、一鍵流程、測試），否則「done 的門檻」變成純粹的懲罰。
🔗 相關工具
- 隨選環境與基礎設施即程式碼（第一版 done 的前提能力）
- 主幹開發（第二版 done 的「created from trunk」來源）
- 只自動化可信的測試（第二版的「validated with automated tests」若不可信就毫無意義）
- 自動化自助部署（提供「one-click process」的具體機制）
- DevOps手冊