採用指引

# 採用規格優先交付

採用規格優先交付，可以先從一類真實變更開始，令它更容易理解和控制。選擇最接近眼前工作的路徑，再用它建立一套規格系統，讓意圖、決策、實作與證據持續相連。

## 讓規格系統貼近變更本身。

我們的參考實作把文件提交至程式碼儲存庫，與程式碼一同版本控制。這樣，每份規格都有可追蹤版本、可供審查的存放位置，亦能與所引導的變更保持接近，而且不依賴某一套交付工具。

這是一項不受特定工具限制的設計選擇，而不是硬性規定。若產品或知識平台能可靠地連接 AI 程式開發代理，並採用相同的責任歸屬、審查和變更控制，也可以使用。Spec Kit 等工具可以協助團隊組織規格驅動的工作，但不能代替具責任歸屬的決策或驗收證據。

四條務實的起步路徑

## 從你現在真正需要改變的軟體出發。

以下流程提供建立第一條可信賴交付路徑所需的最低工作次序，而不是一套固定程序。再按工作的後果、新穎性、模糊程度和相依關係，調整每項工作產物的深度。

情境 1

### 全新系統開發

開發全新產品或服務，是在非正式慣例累積之前建立共同語言和工作約定的最佳時機。先交付一個細小但有價值的作業，同時建立足夠基礎，讓後來的參與者理解塑造產品的決策。第一個作業不只用來驗證產品構想，也用來驗證日後變更應遵循的工作慣例。

#### 先建立基本交付系統，再完成第一個可信賴的作業。

全新系統交付流程

- **確認成果與決策權:** 在選擇架構或建立實作工作前，說清楚預期成果、使用者、工作範圍、非目標、重大風險和決策負責人。
- **建立共同語言:** 建立精簡詞彙表，辨識角色與使用情境，描述正常流程、例外、規則和驗收條件，並標明哪些假設仍等待負責人決定。
- **訂明限制與介面:** 記錄系統脈絡、主要元件、資料語意、外部契約、安全與營運要求和品質屬性，並保留架構選項及其理由。
- **讓交付知識與程式碼一同演進:** 建立程式碼儲存庫結構、管治指示、範本、測試慣例和文件責任歸屬，並把相關材料與程式碼一同版本控制，讓同一條變更路徑保留其歷程。
- **交付一個作業並吸收經驗:** 把第一個作業拆成範圍清晰的工作，依照規格實作和驗證，再記錄驗收證據、偏離和所得經驗，供下一個作業使用。

情境 2

### 既有系統開發

面對既有程式碼庫，首要工作不是一次過描述整個系統，而是為下一項變更建立足夠可靠的脈絡，並清楚呈現仍未確定的部分。現有程式碼只是證據之一；測試、營運情況、文件和有經驗的人員同樣重要。第一個試點完成後，程式碼庫應比開始前更容易被安全修改。

#### 先令下一項變更更安全，再逐步改善整個系統。

既有系統交付流程

- **建立可運作的基線:** 恢復或確認建置、測試、部署和回退流程，找出系統負責人、關鍵相依關係、營運限制，以及最適合作為首個試點的變更。
- **整理現有證據:** 比較程式碼、測試、資料結構、介面、操作手冊、工作單和持份者知識。記錄矛盾與缺口，不要預設任何單一來源自然具有權威。
- **重建變更範圍:** 說明哪些行為需要改變、哪些必須保留，以及受影響的資料、契約、失敗模式和驗收條件。未解的語意問題應交由適當負責人決定。
- **加入深度相稱的工作規則:** 只在支援這項變更所需的位置加入程式碼儲存庫指引、決策紀錄、規格範本和證據存放方式；不要把所有既有習慣或技術債直接制度化。
- **交付可追溯的試點:** 完成一個範圍清晰的作業，把實作和驗證連結至相應規格，再利用審查結果完善知識庫，然後選擇下一項改善。

情境 3

### 重寫既有系統

重寫不是用新技術重新製作舊程式碼，而是先決定哪些行為、資料語意、控制措施和營運要求必須保留。把既有證據提煉成可審查的規格，才能為新系統建立可靠起點。業務上的矛盾不應由開發團隊透過實作選擇暗中裁決。

#### 在重建任何部分之前，先提煉真正重要的內容。

重寫交付流程

- **說明替換決策:** 訂明業務成果、目標範圍、限制和切換要求，並解釋為甚麼全面重寫優於逐步替換、平台遷移或直接退役。
- **收集並提煉證據:** 檢視需求、程式碼、測試、資料、介面、正式環境行為、事故和實務人員知識，整理成一組可審查的主張，並標明相關可信程度和支持證據。
- **分類既有行為:** 由具明確責任歸屬的決策負責人判斷哪些行為應保留、修正、替換、退役、延後或仍待處理。既有實作是重要證據，但不會自動成為目標規格。
- **訂明目標系統與遷移方式:** 建立目標行為、架構、資料、契約、營運、安全、相容性和遷移規格，並定義等價證據、回退限制和分階段切換條件。
- **按已驗收的作業逐步重建:** 以一般規格優先工作方式交付每個替換作業，對照已核准的目標和舊系統義務，並在保留證據後才擴大範圍或退役舊功能。

情境 4

### 客製化商用或開源軟體

客製內容往往要到下一次升級失敗時才完整浮現。規格集合應清楚說明組織新增了什麼、依賴什麼，以及接受了哪些取捨，讓團隊在供應商基線改變時，可以有意識地重建、替換或退役相關功能。目標不是永久保留每項修改，而是讓每個保留決定都可以被重現。

#### 讓客製行為在每次升級後仍可被重現。

客製化交付流程

- **界定升級範圍:** 確認供應商版本、受支援的擴充點、必要業務成果、客製內容負責人、相容性責任，以及可供升級使用的營運時段。
- **盤點客製行為:** 追蹤設定、程式碼擴充、資料變更、整合、報表、存取控制和權宜做法，並把每項內容連結至使用者需要、負責人和現有行為證據。
- **決定哪些內容需要保留:** 把每項客製內容分類為保留、調整、以供應商原生功能替換、退役或延後，並記錄新基線與既有業務或技術限制之間的衝突。
- **訂明重建路徑:** 記錄擴充點、轉接層、遷移步驟、測試案例、資料轉換、回退方案和驗收條件；在可行情況下，讓客製程式碼與供應商基線保持分離。
- **憑證據完成升級:** 在受控環境套用升級，同時驗證供應商原生行為與客製行為，憑證據驗收結果，並更新規格集合以準備下一個版本。

## 採用最小但足以產生可靠經驗的路徑。

四個情境都遵循同一項紀律：把專業判斷說清楚、為每項決策指定負責人、訂明執行範圍與權限，並只在證據充分時驗收。第一條路徑運作後，再根據組織所得經驗改善下一條路徑。

[查看規格優先交付概覽](https://specfirstdelivery.org/zh-tw/overview)