1
尊重每項專業
不要求任何一位參與者取代所有專家。當變更涉及產品、領域、安全、可靠性、架構、品質或交付判斷時，負責相關專業的人便應直接參與。
工作流程
保留各項專業判斷的交付系統。
規格優先交付不要求一位工程師或一套 AI 系統，取代分布在產品、領域、架構、品質、安全與營運職能中的知識和判斷。它讓這些專業判斷在整個交付過程中都可以被取得、審查和使用。
共同工作約定
尊重專業判斷，並把它保留下來。
這套工作流程讓每位參與者在交付成果時都有清楚角色。它不會把產品、工程、領域、品質、安全與營運的責任歸屬，混合成一個沒有明確專業範圍的通用角色。
2
保留具名責任歸屬
每份重要文件都必須有具名負責人。AI 可以協助草擬和提出質疑，但不能成為文件的責任人，也不能取代人的審查。
3
把已確認的答案變成組織資產
已確認的答案應更新知識系統，而不是只停留在私人對話或某個人的記憶中。
提問與審查循環
每個重大問題都有明確的處理路徑和負責角色。
討論文件、規格、架構設計、技術工作和測試規格在形成期間，都會反覆經過這個循環。AI 未再提出重大問題，只是一個審查訊號，並不代表人的責任已經轉移。
對照現有知識提出問題
使用 AI 檢視需求、現有程式碼、已記錄的決策和相關限制，找出缺漏資訊、衝突、例外情況和相依關係。
向負責的專業角色查證
當問題屬於另一項專業時，應請相關同事作出決定、澄清或審查，而不是自行推論答案。
更新文件和知識系統
把決定記錄在適當的討論文件、規格、詞彙表、方法、限制或決策歷程中。
逐行審查
具名負責人應逐項檢查文件是否正確、清楚，並核對工作範圍、限制、必須保留的行為和驗收條件。
交付流程
一條清晰可見的流程，每個階段都有明確的責任歸屬。
以下階段說明一項需求如何由審慎討論，逐步成為範圍清晰的實作工作。當證據顯示原有理解需要修正時，提問與審查循環可以把工作帶回較早階段。
根據現有知識和程式碼界定變更
在決定實作方式前，先討論新功能、新應用程式或新需求。讓參與者和 AI 系統都能取得目前的產品意圖、決策歷程、程式碼、限制、介面和營運脈絡。
- 具責任歸屬的角色
- 重大功能由產品負責人主導；較小功能可由產品經理或計劃經理主導。業務分析師負責定義業務需求。若變更影響安全或可靠性責任，相關專家亦應參與。
- 主要工作產物
- 一份討論文件，以及對相關知識和程式碼庫的查證紀錄。
- 知識系統
- 需求可能揭示詞彙表、產品意圖、計算方法、使用情境、目前技術脈絡或外部連接資訊有所缺漏。
- 準備就緒的條件
- 團隊能說明預期成果、已檢視的脈絡、需要作出決定的人，以及仍未解決的重大問題。
審查並完善討論文件
請 AI 找出未解問題，向負責的同事取得答案，再修訂文件。持續重複，直到 AI 根據現有脈絡未再提出重大問題，而且文件負責人判斷討論已經足以進入規格階段。
- 具責任歸屬的角色
- 討論文件的具名負責人主導審查，對文件所提出問題負責的專家則提供相應判斷。
- 主要工作產物
- 一份經逐行審查的討論文件，包含答案、假設、未完成的決策，以及相關知識來源的連結。
- 知識系統
- 已確認的答案應更新未來工作需要的知識來源，包括術語、業務規則、產品意圖、限制和決策歷程。
- 準備就緒的條件
- 文件負責人已審查每項陳述，並已解決重大問題，或已確定由哪個角色透過甚麼程序完成決定。
撰寫功能與非功能規格
描述使用者可以觀察到的行為，包括正常流程、例外、錯誤、對話方塊、業務規則和驗收條件。非功能規格則在有需要時說明可靠性、可觀測性、警示、安全、效能或技術要求。
- 具責任歸屬的角色
- 對需求負責的人撰寫或擁有規格，並按需要納入產品、業務分析、安全、可靠性、品質和營運專業。
- 主要工作產物
- 功能規格，以及在需要時撰寫的非功能規格。
- 知識系統
- 規格讓已同意的行為、營運期望和驗收證據，可以由工程、QA 和後續變更重複使用。
- 準備就緒的條件
- 預期行為和營運期望已足夠明確，讓技術設計、技術規格和測試設計可以在無需猜測的情況下開始。
需要架構決策時，先設計解決方案
視需要進行當變更引入或改變系統責任、介面、相依關係、技術選擇或重大限制時，應把相關規格轉化為架構設計。修補工作和低風險變更未必需要這個階段。
- 具責任歸屬的角色
- 架構師負責架構決策，並與開發主管及受影響的專家合作。
- 主要工作產物
- 在變更需要時，產出一份經審查的設計文件。
- 知識系統
- 設計文件記錄工程團隊需要保留的決策、替代方案、理由、後果和限制。
- 準備就緒的條件
- 實作所需的架構決策已經明確並完成逐行審查，而且在相關範圍內沒有未解決的重大問題。
撰寫可供執行的技術規格
把已同意的需求和架構設計，轉化為工程師或 AI 程式開發代理可以執行的技術工作。較大的需求可以合理地拆分成三份、二十份或其他合適數量的技術規格。
- 具責任歸屬的角色
- 工程師撰寫技術規格；開發主管和其他專家則審查會影響其職責的問題。
- 主要工作產物
- 一組技術規格。一份功能或非功能規格可能產生多份技術規格。
- 知識系統
- 新的實作限制、程式碼庫發現、介面和決策，若改變已同意的理解，便應回到討論文件、需求、設計或其他知識來源。
- 準備就緒的條件
- 工程師判斷每份技術規格在其執行範圍和權限內，已沒有未解決的重大問題。
實作已同意的技術規格
工程師判斷技術規格已經準備就緒後，執行指示可以直接是「實作該規格」。新的資訊不應被默默吸收進程式碼，而應交回負責人，並更新適當的較早階段工作產物。
- 具責任歸屬的角色
- 工程師仍對技術規格的執行負責；若新發現的問題超出其權限，便應交由適當的負責人處理。
- 主要工作產物
- 實作成果、驗證結果，以及已符合既定規格的證據。
- 知識系統
- 產生的程式碼、偏差、驗證證據和營運所得知識，會成為下一次變更可用知識的一部分。
- 準備就緒的條件
- 實作已對照技術、功能、非功能和測試規格完成驗證，再交由適當角色作出驗收和發佈決定。
同步進行的品質工作
測試規格應從需求開始，而不是從實作倒推。
QA 和測試工程師應根據功能與非功能規格撰寫測試規格，讓驗收證據持續對應程式碼寫成前已同意的成果和營運期望。
從需求推導測試規格
把已訂明的行為、例外情況、可靠性期望、可觀測性要求和警示條件，轉化為可測試的情境和證據。
使用相同的提問與審查循環
QA 工程師請 AI 找出未解決的測試問題、更新知識系統，並逐行審查測試規格。屬於其他專業的問題，應交回負責相關判斷的同事。
讓驗收證據清楚可見
測試和營運證據顯示已同意的條件是否獲得滿足，讓驗收負責人可以作出決定，而不必在實作完成後重新定義需求。
組織交付能力延續
每完成一個交付增量，組織都更有能力處理下一次變更。
這套流程持續改善共享的知識和證據系統。它減少組織對單一個人記憶的依賴，但不會減低專業判斷的價值。
- 詞彙表、產品意圖、業務規則和計算方法
- 使用情境、例外情況、限制和必須保留的行為
- 架構決策、目前技術脈絡和外部連接資訊
- 可靠性目標、可觀測性、警示、測試規格和驗收證據
- 討論歷程、決策、實作所得知識和經審查的偏差