生命週期與專案階段：從構想到交付的全貌
當我們談論軟體開發的「生命週期」時，指的其實是一條從構想到交付的路徑。對 Disciplined Agile（簡稱 DA）來說，這條路徑不是單一路徑，而是一個可以因應不同情境調整的架構。
但無論團隊選擇的是 DA Agile、DA Lean 還是探索式（Exploratory）的生命週期，DA 都會把這個路徑劃分成四個主要階段：
- 啟動（Inception）
- 目的是「讓團隊能有方向地啟動工作」。
- 內容包括建立共同願景、釐清初步範圍與架構、盤點資源與取得支持。
- 建構（Construction）
- 目的是「打造出可交付的解決方案」。
- 透過小步快跑（如 Agile）或持續流動（如 Lean），持續產出、持續整合、持續獲得回饋。
- 交付（Transition）
- 目的是「安全地把成果釋出到真實環境中」。
- 包含部署前檢查、準備作業環境、實際上線與驗證成效。
- 持續（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 強調的建構是一種持續交付、快速回饋、持續學習的過程。有以下兩種模式來推進建構階段：
- 迭代式（Agile）
每隔一至兩週交付一次可用功能。像是 Scrum 的 Sprint。 - 流動式（Lean）
沒有固定時間框架，只要功能完成就立即交付。
不論哪種模式，關鍵都在於每次交付都要有實質可用的東西，而不只是「進度」或「文件」。
常見的建構任務與活動
在這個階段，團隊會重複進行以下任務，並透過實作與回饋不斷優化：
- 計畫迭代或拉取工作項目
- 決定這一輪要做哪些功能。
- 考量業務價值、技術風險與團隊負荷量。
- 實作與測試
- 撰寫程式碼、執行單元測試與自動化測試。
- 強調「把品質內建進流程裡」（Build Quality In）。
- 定義完成準則（Definition of Done）
- 團隊共識：做到什麼程度才算完成？
- 通常會包含「通過測試」、「整合成功」、「可被展示」。
- 展示與回饋（Demo / Iteration Review）
- 向利害關係人展示已完成的功能。
- 收集回饋，調整下一步方向。
- 持續改善（Retrospective）
- 團隊檢討這一輪做得好或需要改進的地方。
- 修正流程、工具或協作方式，持續改善工作方式。
建構階段的核心選擇：定義「完成」與「可交付性」
在建構階段，團隊天天都在「完成工作」，但什麼叫做「完成」？又什麼叫做「可以交付」？
如果這兩件事沒有明確定義，那團隊的進度很容易變成假象，甚至導致品質不穩、回饋延遲，最終傷害產品信任感。
DA 提醒我們：
要打造真正的價值，不能只做到「看起來完成」，而是要做到「真的可交付」。
什麼叫做「完成」？你說了不算，要有共識才算
在敏捷開發中，最常聽到的名詞之一就是 Definition of Done（DoD），也就是「完成的定義」。
它不是某個人心中的感覺，而是整個團隊對『完成』所設定的客觀標準，通常會包含：
- 程式碼撰寫完成，且通過檢視。
- 所有測試（單元、整合、自動化）通過。
- 必要的文件已撰寫或更新。
- 已部署至測試環境。
- 無重大缺陷。
- 符合商業規則、品質規格和驗收條件。
只有當所有條件都達成，這項工作才算「真正完成」，否則就是「只做一半」。
什麼叫做「可交付」？不是功能寫完就能交出去
即使工作完成了，也不代表就能馬上交付。「交付」的重點在於：這項成果是否能被使用者實際使用，並產生價值？
在 DA 中，我們強調產出的是可消費的解決方案，意思是：
- 對使用者來說，是有意義、可操作、有價值的。
- 對組織來說，是技術上、流程上都準備好能隨時交付的。
判斷是否「可交付」的幾個條件：
- 功能經過測試並可被實際使用。
- 使用說明與支援流程已準備好。
- 後台監控、追蹤、報表等基礎設施到位。
- 相關團隊（如客服、行銷）已知情並準備就緒。
- 若上線會影響其他系統，相關依賴與介接已處理。
一個功能只有在這些條件都備齊時，才真的稱得上「可以交到客戶手上」。
在建構階段，定義什麼叫做「完成」與「可交付」，不只是技術上的問題，更是團隊協作與品質保證的關鍵。這兩個定義就像是產品建構的共同語言，幫助大家對齊標準、減少誤會、提高穩定性，讓「持續交付價值」成為可能。
交付：部署與釋出
在 DA 的生命週期中，交付階段就是那個關鍵時刻：要把團隊花了數週甚至數月打造的成果，正式交到使用者手中。
但把產品部署出去這件事，不是按個按鈕那麼簡單。如果準備不足、步驟混亂、協作斷線，就可能導致：
- 用戶無法使用新功能，甚至系統癱瘓。
- 緊急回滾與搶修，造成開發與營運疲於奔命。
- 使用者信任受損，業務受到致命影響。
在交付階段，目標不是「盡快上線」，而是安全、穩定、可預期地把價值釋出。換句話說，交付階段的核心目的就是：
確認我們的成果「準備好了」，並且「能成功部署出去」。
這個階段包含兩個流程目標：
- 確認產品已準備就緒（Ensure Production Readiness）
要上線的東西是不是夠穩？夠完整？大家都準備好了嗎？ - 實際部署解決方案（Deploy the Solution）
部署過程有沒有自動化？有沒有應變方案？使用者體驗是否順利？
這兩個任務看似簡單，其實涵蓋了流程、技術、品質、風險、跨部門溝通等各層面。若處理不當，很容易讓團隊陷入「功能寫好了卻無法交付」、「部署完才發現大問題」的災難場景。
關鍵任務一：確認產品已準備就緒
在部署之前，確保產品技術上是穩定的、商業上是可接受的、營運上是能支援的。該做的事包含：
- 測試完成且通過
包括單元測試、整合測試、使用者驗收測試。 - 無重大缺陷遺留
任何高級別的缺陷都已修復或有明確替代方案。 - 文件與支援資訊到位
包含使用手冊、發佈公告、FAQ、客服應對準備。 - 法規與安全性合規
若牽涉金融、個資、法規等要求，確認都已符合。 - 資料與設定正確
測試資料清除、實際資料初始化、設定檔正確無誤。 - 基礎架構準備完成
環境已建置、效能測試通過、監控機制準備完善。 - 利害關係人資訊同步
包含業務、客服、行銷、客戶代表等人已同步了解並接受變更內容。
這不只是開發團隊的工作，而是一場跨角色、跨部門的集體確認行動。否則再完美的功能，也可能因為客服不知道怎麼回應，或是使用者不知道怎麼操作，而讓產品落入「準備好但沒人用」的結局。
關鍵任務二：實際部署解決方案
不是只是「成功部署」，而是讓使用者能在正確的時間、地點和方式下，無痛體驗產品價值。對於部署策略的選擇與準備可以考慮以下策略：
- 全量部署
小型系統或重大版本重構，可快速一次到位，但風險集中、若無法回滾版本時要特別小心。 - 分批釋出
多地區/多用戶群漸進導入，可觀察回饋、控制影響範圍，但實作上較複雜，需設計控制機制。 - 藍綠部署
部署時不中斷服務，可快速切換版本、方便回滾，但成本較高、需要雙環境支援。 - 灰度部署（Gray Release） / 金絲雀佈署（Canary Release）
想先驗證特定用戶反應，進行低風險的探索性上線，需要配合流量導向與監控機制。 - 功能切換（Feature Toggle）
功能可隨時開關控制，並佈署未開啟功能、隨時切換。需要管理好旗標狀態，避免技術債累積。
交付階段的兩大任務，不是技術團隊一頭熱地「把東西丟出去」就好，而是：
- 「內部」要準備好交出去（Production Readiness）
- 「外部」要能成功收到並開始使用（Deployment Strategy）
團隊可以選擇，但要根據所面對的複雜度與風險，選擇一條最適合的路徑。這才是現代軟體交付應該有的成熟與彈性。畢竟沒有穩定的交付，就談不上真正的敏捷。
持續：跨專案的持續任務
在 DA 的生命週期中，除了啟動、建構、交付這三個主要階段之外，還有一個經常被忽略但極其重要的維度，叫做持續。
這些工作不像功能開發那樣有明確的起訖時間，但它們貫穿整個生命週期，是維持團隊運作穩定、品質可控、持續改善的基礎。
所謂的持續，並不是某個特定時間點發生的任務，而是：
在整個產品或專案生命週期中，必須持續關注與執行的活動。
這些活動通常不會出現在產品待辧清單裡，也很少有專人提醒該做，但若忽視它們，就會讓團隊效率下降、風險升高、品質崩盤。
DA 將持續的任務歸納為九個主要的流程目標：
- 培育團隊成員（Grow Team Members）
提供學習與成長機會，讓團隊能持續提升專業與合作能力。 - 協調活動（Coordinate Activities）
確保團隊內外的工作能順暢銜接，減少等待與重工。 - 風險應對（Address Risk）
及早識別、透明化並處理風險，降低失敗的可能性。 - 演進工作方式（Evolve Way of Working）
持續檢視並改進團隊的做法，找到更合適的工作方式。 - 善用並優化既有基礎設施（Leverage and Enhance Existing Infrastructure）
重複利用組織現有工具與平台，必要時加以改良，而非一切從零開始。 - 治理團隊（Govern Team）
透過適度的規範、指標與支持，確保團隊運作符合組織目標。 - 工作接收（Intake Work）
建立明確的方式來接收與篩選新工作。 - 組織度量指標（Organize Metrics）
決定要追蹤哪些數據，確保能反映出團隊與產品的真實狀況。 - 衡量成果（Measure Outcomes）
不只看輸出（Output），更要關注是否真正創造價值（Outcome）。
想像團隊是架飛機，啟動是起飛、建構是飛行中建構系統、交付是安全降落，而持續就是整趟航程的導航、維護、補給與通訊系統。
如果忽略這些持續的工作，將會造成：
- 缺乏成長機會
團隊成員的能力會停滯不前，士氣低落。 - 缺乏協作機制
外部團隊溝通不良，造成依賴卡關。 - 沒有持續改善
一直重複不順的流程，卻沒人願意提出調整。 - 缺乏風險意識與處理能力
同樣的風險一直不斷重演。 - 缺乏治理與回報機制
組織對團隊的信任與支持逐漸流失。
持續的工作之所以重要，是因為它支撐了整個團隊的韌性與成熟度。如果把 DA 的各階段比喻為不同任務的主線，那持續就是始終在線、從不下線的底層運作邏輯。
在真正的高效團隊中，流程不是憑感覺走、成員不是憑本能活、交付不是靠衝刺撐，而是靠這些細水長流的持續任務穩穩推進。
四大階段之間的連結與過渡：避免斷裂、強化流動性
在 DA 生命週期的四大階段：啟動、建構、交付、持續，雖然每個階段都有其獨立的任務與焦點，但真正成熟的團隊，並不把這些階段當成「斷裂的階段任務」，而是視為一條持續流動的價值交付之路。
如果沒有善加銜接這些階段，就可能出現：
- 突然轉向的決策（啟動設定一套節奏，建構時完全沒理會）
- 任務重工或資訊重複搜集（交付時才發現產品不夠穩，再花時間回頭補測）
- 責任落空（建構階段解決不了的風險，沒人接手追蹤）
- 團隊疲於奔命，卻感受不到流暢進展
因此，讓階段之間能自然過渡、資訊與責任能平順傳遞，是打造高效能團隊不可或缺的能力。
但這並不表示每個階段一定要做出什麼文件，而是團隊應該根據階段任務與過渡需求，自定義出屬於自己的連接機制，像是：
- 使用交付檢查清單作為跨階段對齊工具
- 為不同階段定義流程目標與檢查點，定期檢視是否達成
- 每階段尾聲都安排一次「過渡規劃會議」，明確定義下一階段的進場條件與承接方式
這些都可以融入團隊的工作方式中，變成可執行、可改善、可持續演化的跨階段協作方式。
高成熟度的敏捷團隊，不只擅長在某個階段中交付成果，更能提前準備下一階段的需要，延續上一階段的智慧與脈絡，並且讓價值從起點一路順流到終點。
這樣的流動性，讓每一次交付不是一場臨時集結，而是一次又一次循環進化的自然節奏。而這種「無斷裂、自然流動」的團隊節奏，就是 DA 真正想幫助建立的敏捷力。
