引導式流程 · 8 分鐘
探索軟體生命週期
追蹤匯出功能從需求到維運的過程。檢查每個階段的負責人、證據和決定。
情況說明
你負責一項客戶管理服務。管理者要求取得自己組織有效客戶的資料檔案。追蹤這項虛構功能，從請求走到維運。
情境：客戶資料匯出
證據是支持決策的文件或檢查結果。以下每個階段都有範例。可以依序進行，也可以直接選擇階段。
階段 1 / 7
需求
管理者需要匯出自己組織的有效客戶資料。
- 負責人
- 產品負責人
- 證據
- 已接受的結果與允許欄位
管理者每週花一小時整理有效客戶資料。已接受需求：將自己組織的客戶名稱與客戶 ID 匯出為 CSV。
階段 2 / 7
規格
定義有權使用的對象、允許的資料、失敗行為和驗收條件。
- 負責人
- 產品與資安負責人
- 證據
- 資料流與授權要求
驗收條件：組織 A 的管理者，即使修改請求識別碼，也不會取得組織 B 的紀錄。
階段 3 / 7
實作
代理程式在功能分支準備小型變更。
- 負責人
- 開發團隊
- 證據
- 連結到需求的變更差異
PR 為資料庫查詢加入組織篩選，以及另一個組織請求的測試。登入與帳務保持不變。
階段 4 / 7
驗證
檢查實際授權與禁止的請求。
- 負責人
- 獨立審查者
- 證據
- 針對最終 commit 的測試與審查
最終 commit 的測試顯示，組織 A 的使用者無法取得 B 的紀錄。審查者檢查授權鏈。
階段 5 / 7
發布
使用允許的部署角色，部署已接受的產物。
- 負責人
- 發布負責人
- 證據
- 產物識別碼、核准和復原計畫
發布負責人確認產物的 commit 與已審查 commit 一致。復原指示寫明先前版本，以及有權啟動版本回復的人。
階段 6 / 7
維運
監控匯出失敗、存取控制和服務行為。
- 負責人
- 服務負責人
- 證據
- 指標、範圍受限的稽核記錄檔，以及事件指示
匯出失敗告警會通知值班工程師。範圍受限的稽核記錄檔，記錄執行者和組織，不複製完整客戶清單。
階段 7 / 7
學習
下次變更前，評估使用情形與觀察到的問題。
- 負責人
- 產品負責人與團隊
- 證據
- 回饋與更新後的工作佇列
支援請求回報，大型客戶清單匯出失敗。團隊為下一項變更新增效能要求與測試。
這個順序可以重複。新證據可能讓工作回到規格或實作。
完成練習
程式碼已能運作，為何團隊不能停在「實作」？
對照解釋檢查答案
程式碼能運作，無法說明誰能存取紀錄，或誰會處理故障。「驗證」檢查資料邊界；「發布」將證據連結到已部署版本；「維運」分配執行中服務的責任；「學習」將觀察到的問題轉成下一次變更。
運用在工作中
選擇團隊的一項功能，指出發布負責人，以及接收故障告警的人。
選擇另一項練習