生命週期與專案階段：從構想到交付的全貌

當我們談論軟體開發的「生命週期」時，指的其實是一條從構想到交付的路徑。對 Disciplined Agile（簡稱 DA）來說，這條路徑不是單一路徑，而是一個可以因應不同情境調整的架構。

但無論團隊選擇的是 DA Agile、DA Lean 還是探索式（Exploratory）的生命週期，DA 都會把這個路徑劃分成四個主要階段：

1. 啟動（Inception）

   • 目的是「讓團隊能有方向地啟動工作」。
   • 內容包括建立共同願景、釐清初步範圍與架構、盤點資源與取得支持。

2. 建構（Construction）

   • 目的是「打造出可交付的解決方案」。
   • 透過小步快跑（如 Agile）或持續流動（如 Lean），持續產出、持續整合、持續獲得回饋。

3. 交付（Transition）

   • 目的是「安全地把成果釋出到真實環境中」。
   • 包含部署前檢查、準備作業環境、實際上線與驗證成效。

4. 持續（Ongoing）

   • 雖然不是一個階段，但這類任務貫穿整個生命週期。
   • 像是風險管理、團隊協作、持續改善與基礎設施管理等，都是每個階段都需要持續處理的事情。

很多人看到這種「階段式」劃分，就會誤以為 DA 是傳統瀑布的包裝版。但實際上，這四個階段不是線性的流程步驟，而是用來幫助我們理解「此刻團隊的工作重心在哪裡」。

以 DA Agile 為例，一個迭代的前期可能是「啟動」（先對某個功能做設計與規劃），中期是「建構」（實作與測試），尾聲是「交付」（上線與回饋），這些階段可以在一個迭代中交錯出現。DA 的強項就在於：它不規定團隊一定要怎麼走，而是提供清楚的指引幫助團隊選擇怎麼走。

如果沒有這樣的階段概念，團隊就很容易出現以下狀況：

• 還沒想清楚問題就急著寫程式（跳過「啟動」）
• 一直寫程式卻沒驗證是否真的可以上線（忽略「交付」）
• 沒有時間做反思與改善（遺漏「持續」的任務）
• 工作推進過程中，沒有釐清當下的工作重點（混亂的「建構」）

透過這四個階段，我們可以更清楚掌握團隊當下應該聚焦的任務，也更容易協調角色分工與資源投入。

DA 的生命週期架構不是流程圖，而是一種幫助思考與選擇的地圖。團隊可以從中找到方向，但不被綁住。可以在需要時調整節奏，也能在不同階段聚焦真正重要的任務。這樣的架構，正是 DA 「選擇你自己的工作方式（Choose your WoW）」背後的底層設計。

啟動階段：構想與方向設定

當一個團隊準備啟動一項新任務，不管是專案還是產品開發，第一步都不能是「直接動手寫程式」。否則就是沒看地圖就出發，迷失方向是遲早的事。

在 DA 中，我們把這個「起步之前的準備」稱為啟動階段，也可以理解成「構想階段」或「定錨階段」。目的是讓團隊朝著同一個方向出發，並有足夠的資訊來做出良好的第一輪決策。

啟動階段要解決的問題是什麼？

可以用一個簡單的問題來提問：「我們準備好了嗎？能不能開始動手做了？」。如果答案是「不知道」，那就表示啟動階段的任務還沒完成。

常見需要在開發前釐清的問題包括：

• 這件事的目標與價值是什麼？
• 有哪些利害關係人，他們期望什麼？
• 我們目前知道的範圍有哪些？
• 有什麼技術風險或法規限制？
• 團隊的組成、資源與節奏是否準備好？
• 接下來的交付節奏與規劃如何設計？

DA 強調精實而有價值的起步準備，不是要求團隊在啟動階段就規劃出完整藍圖，否則就又掉回瀑布式專案的老路。

可以把啟動階段想成是一場「協同啟動會議」（Collaborative inception workshop），由團隊和關鍵利害關係人一起進行幾個核心任務：

• 建立共同願景
  確認大家對「這件事的目標與價值」有共識。

• 初步探索範圍
  利用使用者故事、工作項目或原型概念來界定大方向。

• 確認技術與架構風險
  找出可能造成失敗的技術不確定性與限制條件。

• 評估利害關係人與合作關係
  誰會影響我們？我們要取得誰的支持？

• 建立基本工作方式（WoW）
  團隊初步討論如何協作、如何規劃與追蹤工作。

• 規劃第一輪交付
  包含最小商業增量（Minimum Business Increment, MBI）與預期的時間節奏。

如何知道啟動階段是否已完成？

啟動階段的重點不在於「有沒有做」，而是要做到什麼程度才算足夠。這會依照團隊的情境而不同，例如：

• 對於長期穩定的產品型團隊，啟動階段能只需要幾個小時就能對齊共識。
• 對於新創產品或跨部門協作專案，啟動階段可能需要幾天的工作坊來聚焦願景、探索架構與確認協作模式。
• 對於嚴格法規要求的系統，啟動階段可能還需要額外的風險分析與法遵規劃。

在 DA 中，我們會透過「流程目標（Process Goals）」來評估每個階段是否達成目的。對啟動階段而言，最關鍵的檢查點就是：

• 團隊是否已建立共同願景？
• 是否已探索範圍並形成可行的初步規劃？
• 是否明確定義了「這是我們第一階段要完成的東西（最小商業增量）」？
• 是否有基本的工作協議，知道團隊與利害關係人該怎麼協作與追蹤進度？
• 是否了解關鍵的風險與依賴關係？

如果這些問題大致都有答案，表示已經具備「有方向地開始」的條件。啟動階段是為了讓團隊有信心出發，而不是拖延起跑的理由。只要準備達到「足夠清楚可以開始行動」的程度，就可以從啟動階段進入到建構階段。

建構階段：持續打造可交付成果

在 DA 的生命週期中，建構階段是最具「產出感」的時期。這時候，團隊已經完成了啟動階段的初步準備，要開始動手「把解決方案做出來」，並且持續打造出可交付的成果。

但這並不代表我們只是埋頭寫程式。建構階段真正的核心，是以使用者價值為中心，逐步交付高品質的可用產品。

這個階段不只是寫程式，更包含整體的產品建構活動。所有這些工作，都是為了確保每一階段都能產出具備價值的東西。

不同於傳統瀑布方法將建構集中在中期、最後才驗收，DA 強調的建構是一種持續交付、快速回饋、持續學習的過程。有以下兩種模式來推進建構階段：

1. 迭代式（Agile）
   每隔一至兩週交付一次可用功能。像是 Scrum 的 Sprint。

2. 流動式（Lean）
   沒有固定時間框架，只要功能完成就立即交付。

不論哪種模式，關鍵都在於每次交付都要有實質可用的東西，而不只是「進度」或「文件」。

常見的建構任務與活動

在這個階段，團隊會重複進行以下任務，並透過實作與回饋不斷優化：

1. 計畫迭代或拉取工作項目

   • 決定這一輪要做哪些功能。
   • 考量業務價值、技術風險與團隊負荷量。

2. 實作與測試

   • 撰寫程式碼、執行單元測試與自動化測試。
   • 強調「把品質內建進流程裡」（Build Quality In）。

3. 定義完成準則（Definition of Done）

   • 團隊共識：做到什麼程度才算完成？
   • 通常會包含「通過測試」、「整合成功」、「可被展示」。

4. 展示與回饋（Demo / Iteration Review）

   • 向利害關係人展示已完成的功能。
   • 收集回饋，調整下一步方向。

5. 持續改善（Retrospective）

   • 團隊檢討這一輪做得好或需要改進的地方。
   • 修正流程、工具或協作方式，持續改善工作方式。

建構階段的核心選擇：定義「完成」與「可交付性」

在建構階段，團隊天天都在「完成工作」，但什麼叫做「完成」？又什麼叫做「可以交付」？

如果這兩件事沒有明確定義，那團隊的進度很容易變成假象，甚至導致品質不穩、回饋延遲，最終傷害產品信任感。

DA 提醒我們：

要打造真正的價值，不能只做到「看起來完成」，而是要做到「真的可交付」。

什麼叫做「完成」？你說了不算，要有共識才算

在敏捷開發中，最常聽到的名詞之一就是 Definition of Done（DoD），也就是「完成的定義」。

它不是某個人心中的感覺，而是整個團隊對『完成』所設定的客觀標準，通常會包含：

• 程式碼撰寫完成，且通過檢視。
• 所有測試（單元、整合、自動化）通過。
• 必要的文件已撰寫或更新。
• 已部署至測試環境。
• 無重大缺陷。
• 符合商業規則、品質規格和驗收條件。

只有當所有條件都達成，這項工作才算「真正完成」，否則就是「只做一半」。

什麼叫做「可交付」？不是功能寫完就能交出去

即使工作完成了，也不代表就能馬上交付。「交付」的重點在於：這項成果是否能被使用者實際使用，並產生價值？

在 DA 中，我們強調產出的是可消費的解決方案，意思是：

• 對使用者來說，是有意義、可操作、有價值的。
• 對組織來說，是技術上、流程上都準備好能隨時交付的。

判斷是否「可交付」的幾個條件：

• 功能經過測試並可被實際使用。
• 使用說明與支援流程已準備好。
• 後台監控、追蹤、報表等基礎設施到位。
• 相關團隊（如客服、行銷）已知情並準備就緒。
• 若上線會影響其他系統，相關依賴與介接已處理。

一個功能只有在這些條件都備齊時，才真的稱得上「可以交到客戶手上」。

在建構階段，定義什麼叫做「完成」與「可交付」，不只是技術上的問題，更是團隊協作與品質保證的關鍵。這兩個定義就像是產品建構的共同語言，幫助大家對齊標準、減少誤會、提高穩定性，讓「持續交付價值」成為可能。

交付：部署與釋出

在 DA 的生命週期中，交付階段就是那個關鍵時刻：要把團隊花了數週甚至數月打造的成果，正式交到使用者手中。

但把產品部署出去這件事，不是按個按鈕那麼簡單。如果準備不足、步驟混亂、協作斷線，就可能導致：

• 用戶無法使用新功能，甚至系統癱瘓。
• 緊急回滾與搶修，造成開發與營運疲於奔命。
• 使用者信任受損，業務受到致命影響。

在交付階段，目標不是「盡快上線」，而是安全、穩定、可預期地把價值釋出。換句話說，交付階段的核心目的就是：

確認我們的成果「準備好了」，並且「能成功部署出去」。

這個階段包含兩個流程目標：

1. 確認產品已準備就緒（Ensure Production Readiness）
   要上線的東西是不是夠穩？夠完整？大家都準備好了嗎？

2. 實際部署解決方案（Deploy the Solution）
   部署過程有沒有自動化？有沒有應變方案？使用者體驗是否順利？

這兩個任務看似簡單，其實涵蓋了流程、技術、品質、風險、跨部門溝通等各層面。若處理不當，很容易讓團隊陷入「功能寫好了卻無法交付」、「部署完才發現大問題」的災難場景。

關鍵任務一：確認產品已準備就緒

在部署之前，確保產品技術上是穩定的、商業上是可接受的、營運上是能支援的。該做的事包含：

• 測試完成且通過
  包括單元測試、整合測試、使用者驗收測試。

• 無重大缺陷遺留
  任何高級別的缺陷都已修復或有明確替代方案。

• 文件與支援資訊到位
  包含使用手冊、發佈公告、FAQ、客服應對準備。

• 法規與安全性合規
  若牽涉金融、個資、法規等要求，確認都已符合。

• 資料與設定正確
  測試資料清除、實際資料初始化、設定檔正確無誤。

• 基礎架構準備完成
  環境已建置、效能測試通過、監控機制準備完善。

• 利害關係人資訊同步
  包含業務、客服、行銷、客戶代表等人已同步了解並接受變更內容。

這不只是開發團隊的工作，而是一場跨角色、跨部門的集體確認行動。否則再完美的功能，也可能因為客服不知道怎麼回應，或是使用者不知道怎麼操作，而讓產品落入「準備好但沒人用」的結局。

關鍵任務二：實際部署解決方案

不是只是「成功部署」，而是讓使用者能在正確的時間、地點和方式下，無痛體驗產品價值。對於部署策略的選擇與準備可以考慮以下策略：

• 全量部署
  小型系統或重大版本重構，可快速一次到位，但風險集中、若無法回滾版本時要特別小心。

• 分批釋出
  多地區/多用戶群漸進導入，可觀察回饋、控制影響範圍，但實作上較複雜，需設計控制機制。

• 藍綠部署
  部署時不中斷服務，可快速切換版本、方便回滾，但成本較高、需要雙環境支援。

• 灰度部署（Gray Release） / 金絲雀佈署（Canary Release）
  想先驗證特定用戶反應，進行低風險的探索性上線，需要配合流量導向與監控機制。

• 功能切換（Feature Toggle）
  功能可隨時開關控制，並佈署未開啟功能、隨時切換。需要管理好旗標狀態，避免技術債累積。

交付階段的兩大任務，不是技術團隊一頭熱地「把東西丟出去」就好，而是：

• 「內部」要準備好交出去（Production Readiness）
• 「外部」要能成功收到並開始使用（Deployment Strategy）

團隊可以選擇，但要根據所面對的複雜度與風險，選擇一條最適合的路徑。這才是現代軟體交付應該有的成熟與彈性。畢竟沒有穩定的交付，就談不上真正的敏捷。

持續：跨專案的持續任務

在 DA 的生命週期中，除了啟動、建構、交付這三個主要階段之外，還有一個經常被忽略但極其重要的維度，叫做持續。

這些工作不像功能開發那樣有明確的起訖時間，但它們貫穿整個生命週期，是維持團隊運作穩定、品質可控、持續改善的基礎。

所謂的持續，並不是某個特定時間點發生的任務，而是：

在整個產品或專案生命週期中，必須持續關注與執行的活動。

這些活動通常不會出現在產品待辧清單裡，也很少有專人提醒該做，但若忽視它們，就會讓團隊效率下降、風險升高、品質崩盤。

DA 將持續的任務歸納為九個主要的流程目標：

1. 培育團隊成員（Grow Team Members）
   提供學習與成長機會，讓團隊能持續提升專業與合作能力。

2. 協調活動（Coordinate Activities）
   確保團隊內外的工作能順暢銜接，減少等待與重工。

3. 風險應對（Address Risk）
   及早識別、透明化並處理風險，降低失敗的可能性。

4. 演進工作方式（Evolve Way of Working）
   持續檢視並改進團隊的做法，找到更合適的工作方式。

5. 善用並優化既有基礎設施（Leverage and Enhance Existing Infrastructure）
   重複利用組織現有工具與平台，必要時加以改良，而非一切從零開始。

6. 治理團隊（Govern Team）
   透過適度的規範、指標與支持，確保團隊運作符合組織目標。

7. 工作接收（Intake Work）
   建立明確的方式來接收與篩選新工作。

8. 組織度量指標（Organize Metrics）
   決定要追蹤哪些數據，確保能反映出團隊與產品的真實狀況。

9. 衡量成果（Measure Outcomes）
   不只看輸出（Output），更要關注是否真正創造價值（Outcome）。

想像團隊是架飛機，啟動是起飛、建構是飛行中建構系統、交付是安全降落，而持續就是整趟航程的導航、維護、補給與通訊系統。

如果忽略這些持續的工作，將會造成：

• 缺乏成長機會
  團隊成員的能力會停滯不前，士氣低落。

• 缺乏協作機制
  外部團隊溝通不良，造成依賴卡關。

• 沒有持續改善
  一直重複不順的流程，卻沒人願意提出調整。

• 缺乏風險意識與處理能力
  同樣的風險一直不斷重演。

• 缺乏治理與回報機制
  組織對團隊的信任與支持逐漸流失。

持續的工作之所以重要，是因為它支撐了整個團隊的韌性與成熟度。如果把 DA 的各階段比喻為不同任務的主線，那持續就是始終在線、從不下線的底層運作邏輯。

在真正的高效團隊中，流程不是憑感覺走、成員不是憑本能活、交付不是靠衝刺撐，而是靠這些細水長流的持續任務穩穩推進。

四大階段之間的連結與過渡：避免斷裂、強化流動性

在 DA 生命週期的四大階段：啟動、建構、交付、持續，雖然每個階段都有其獨立的任務與焦點，但真正成熟的團隊，並不把這些階段當成「斷裂的階段任務」，而是視為一條持續流動的價值交付之路。

如果沒有善加銜接這些階段，就可能出現：

• 突然轉向的決策（啟動設定一套節奏，建構時完全沒理會）
• 任務重工或資訊重複搜集（交付時才發現產品不夠穩，再花時間回頭補測）
• 責任落空（建構階段解決不了的風險，沒人接手追蹤）
• 團隊疲於奔命，卻感受不到流暢進展

因此，讓階段之間能自然過渡、資訊與責任能平順傳遞，是打造高效能團隊不可或缺的能力。

但這並不表示每個階段一定要做出什麼文件，而是團隊應該根據階段任務與過渡需求，自定義出屬於自己的連接機制，像是：

• 使用交付檢查清單作為跨階段對齊工具
• 為不同階段定義流程目標與檢查點，定期檢視是否達成
• 每階段尾聲都安排一次「過渡規劃會議」，明確定義下一階段的進場條件與承接方式

這些都可以融入團隊的工作方式中，變成可執行、可改善、可持續演化的跨階段協作方式。

高成熟度的敏捷團隊，不只擅長在某個階段中交付成果，更能提前準備下一階段的需要，延續上一階段的智慧與脈絡，並且讓價值從起點一路順流到終點。

這樣的流動性，讓每一次交付不是一場臨時集結，而是一次又一次循環進化的自然節奏。而這種「無斷裂、自然流動」的團隊節奏，就是 DA 真正想幫助建立的敏捷力。