將既有程式碼庫帶入 Taiga

從現有系統開始

虛構設備申請服務已存在。團隊希望用 Taiga 維護它，同時保留正常運作的整合。

建立產品時，選擇 Import codebase。連結儲存庫並開始分析。這條途徑以儲存庫分析取代新產品對話。從零建立的產品，之後不能再新增這條匯入途徑。

確認儲存庫存取權，以及 Taiga 應使用的分支。在適當上下文層級加入長期限制。本範例應明確說明：必須繼續使用既有員工身分整合。

先審查推導出的規格

Taiga 從程式碼推導產品文件，並附上儲存庫引用。這些引用有助於檢查解讀，但無法確定每項既有模式背後的業務意圖。

檢查規格中的三件事：

• 目的： 描述的目標是否符合服務存在的理由？
• 限制： 哪些模式是刻意保留的要求？
• 已知缺陷： 哪些目前行為應改變？

設備服務含有舊版授權模組。文件可能正確指出它正在使用，但不代表團隊應繼續擴充它。

開啟引用檔案，將相關行為與陳述比較。記錄現有證據的限制，例如儲存庫以外的設定或維運行為。

選擇正確修正方式

匯入文件跟隨程式碼，不應視為手動維護的未來系統說明。重新整理文件時，也會重新推導它所依賴的文件。因此，重新整理較後面的文件可能需要更多工作。

對舊模組，指令可以寫：「不要新增舊版授權模組的呼叫者。新工作使用核准的替代介面。」先驗證介面存在，並指出實際儲存庫位置。

評估第一批 initiatives

匯入流程也會執行儲存庫掃描、依已發布政策評估，以及初始 initiative 規劃。某階段若缺少必要前提，可能附上說明後略過。規劃使用現有的掃描發現事項與政策評估。

對照儲存庫審查提出的缺口。初始 initiatives 處理缺少的能力、基礎，或相關未解相依問題，不是列出沒有人要求的新功能。

保留有用的既有能力。提案若會不必要地重建它，就拒絕或修正。新的業務需求，另外新增 initiative。

保留以證據為基礎的起點

完成 Discovery，並審查 initiative 提案。詳細規劃前，確認環境與交付責任。工作進行時，讓匯入結果、程式碼變更和產品指令保持一致。

成果是團隊了解起點，並取得可編輯的待辦清單，不是宣告所有既有行為都正確。繼續閱讀initiative 規劃。