在 Taiga 建立新產品

準備一個清楚結果

本情境使用虛構設備申請服務。管理者記錄員工的設備申請與決定，員工自助服務留待之後擴充。學習期間使用合成紀錄，本情境不授權使用真實人事資料。

建立產品前，確認組織與相關共用上下文已設定。指出誰負責服務結果，以及哪個團隊負責維運環境。

寫下初始邊界：第一版記錄申請與決定，不訂購設備、不自動核准支出，也不修改薪資紀錄。

選擇產品起始方式

為這項新服務選擇 Start from scratch。如果既有儲存庫應作為起點，就使用 Import codebase。匯入是在建立產品時做的選擇，應審慎決定。

建立時也會詢問是否由 Taiga 撰寫 Infrastructure code 與 CI/CD pipelines。這是兩項獨立責任。平台團隊若已提供其中一項，就關閉該項生成選項，並描述目前做法。

例如：「我們的平台透過既有儲存庫管線部署已審查的容器映像檔。使用該管線的工作負載身分與環境設定。」依賴這段說明前，先確認內容正確。

先提供上下文，再開始對話

Discovery 從 Context 開始。對話前，加入相關產品參考資料與長期適用指令。多個產品共用的規則，放在組織或工廠層級。

對設備服務而言，有用上下文包括員工身分方法、核准資料服務，以及管理者存取規則。明確指出未解問題，不要為了填完表單，就捏造資料保留期間。

接著在對話中描述服務。說明使用者、預期結果、限制，以及範圍外事項。工作期間，規格會儲存為草稿。

審查並發布產品意圖

閱讀規格，找出會改變實作的假設。在本情境中，檢查管理者能查看所有員工申請，還是只有自己團隊的申請。這項差異影響權限、資料流和測試。

內容適合供後續工作使用時，發布規格。草稿變更不會取代已發布版本，必須再次發布才生效。繼續完成必要文件，並審查假設。Discovery 課程說明相依關係與過期文件。

八份必要文件全部發布後，完成 Discovery，再規劃 initiatives。生成的順序是可檢查與修改的提案。

連結真實交付目標

詳細規劃 initiative 前，先連接儲存庫。同時定義預定環境，即使開始規劃並不強制要求已有環境。

環境說明不會授予雲端存取權。部署由管線執行。與負責團隊確認儲存庫分支、身分、基礎架構責任，以及必要設定任務。

本情境的有用成果，是產品已定義，且工作可供審查、依據真實交付環境規劃。使用Taiga 流程模擬，練習決策順序。