在敏捷的世界裡，我們經常被告知要「快速交付」、「持續學習」、「擁抱變化」。但問題是所有團隊都適合用同一種交付方式嗎？
想像以下三種情境：
這三種團隊，能套用一樣的迭代節奏、一樣的待辦清單管理模式嗎？顯然不行。
而這正是 Disciplined Agile（簡稱 DA）所要解決的問題。
DA 不認為有一體適用的交付流程，而是提供多種生命週期（Life Cycle）選項，讓團隊依據自身情境選擇最適合的工作方式（Way of Working, WoW）。這些生命週期就像是一組多功能工具箱，團隊可以根據自己所處的環境，自由選擇最合適的方式來進行工作。不但可以降低流程與文化的衝突，也更容易取得實際成效。
以下將逐一介紹這些生命週期的特性、適用情境、背後的設計原則，並說明如何根據專案階段與團隊成熟度做出最適選擇。因為在 DA 裡頭，「選擇最適合的交付方式」不是起點，更是一種持續進化的能力。
對多數剛接觸敏捷的團隊來說，Scrum 是最常見也最容易入門的做法。而 DA 的 Agile 生命週期，就是從 Scrum 出發，再加上更完整的實務考量，讓它能在現實情境中更穩定落地。
這個生命週期以時間盒迭代（Time-boxed iteration）為基礎，團隊會在固定的週期（例如兩週）內，完成一批具有價值的功能，並於迭代結束時進行驗收、回顧與規劃下一輪工作。乍看之下與 Scrum 非常相似，但實際上它做了幾項關鍵性的擴充：
Scrum 著重於建構（Construction）階段，但在實務中，團隊在開始之前往往需要一些準備工作，例如組建團隊、釐清目標、設計整體架構等。在交付之後也可能還有一連串的部署、驗收與移交流程。
DA Agile 生命週期因此將專案劃分為三個主要階段：
這樣的安排更貼近現實，也讓團隊在各階段能有明確的流程目標（Process Goals）與導引。
在 Scrum 裡，流程是固定不可變動的：每天站會、每兩週一次迭代、回顧與展示等。但 DA 並不要求團隊照做流程，而是提供一系列的流程目標與選項，讓團隊可以根據情境作出最佳選擇。這些選項都以「目標導向」的方式組織，不只是教團隊「怎麼做」，而是先問「為什麼要做」，再引導「有哪些做法可選」。
DA 是一個方法論的集合體，因此強調術語中立。在 DA Agile 生命週期中，雖然流程與 Scrum 類似，但不一定非得使用 Scrum 的語言，例如可以說「工作項目清單（Work Item List）」而不是「產品待辦清單（Product Backlog）」，也可以使用自己的命名與習慣，只要團隊有共識。這種設計降低了實施門檻，也讓不同背景的團隊能有更順暢的適應過程。
DA Agile 生命週期特別適合以下情境使用：
DA Agile 生命週期也是最常被用來作為敏捷轉型初期的起點，在熟悉流程與觀念之後，日後可以再轉換成其他生命週期，例如 DA Lean 生命週期或持續交付生命週期等。
不是每個團隊都適合用「固定兩週為一輪」的迭代方式運作。
有些團隊面對的需求來得快、變得也快，根本沒時間規劃完整的迭代。有些團隊的任務無法事先估算工作量，只能邊做邊調整節奏。還有些團隊工作性質就像是流水線，當誰有空誰就做，做完就交付，不需要等到迭代結束才交付。
這時候，DA Lean 生命週期會是一個更好的選擇。
DA Lean 生命週期不再使用固定週期的「迭代（Iteration）」概念，而是以拉動式（Pull-based）的工作機制為核心。只要團隊有空，就從工作池中拉取（Pull）下一項任務進來處理。
也就是說，團隊不是根據「現在第幾週」，而是根據「有沒有空、有沒有完成」來決定什麼時候開始新工作。
傳統迭代方式，會把規劃、設計、編碼、測試、展示、回顧等活動都綁在同一個節奏上。但在 DA Lean 生命週期中，這些活動可以各自照自己的節奏進行。
這讓團隊可以依實際狀況安排節奏，而不是為了配合迭代而「硬湊流程」。
在 Scrum 中，工作會排成一個待辦清單（Product Backlog），由產品負責人排好優先順序，再依序拉進迭代中。
而在 DA Lean 生命週期中，工作來源變得更彈性，稱為「工作池（Work Item Pool）」。這個池子中可能有：
有些任務還必須插隊處理，有些可以等一等，這就需要團隊透過明確的「拉動規則」來管理。
為了讓這種流動式的流程能夠順利運作，DA Lean 生命週期通常會搭配看板系統：
這也是 DA 工具箱中強調「視覺化價值流程」與「限制 WIP」的實務應用。
DA Lean 生命週期特別適合以下情境：
不過前提是團隊具備有一定的自主管理能力，否則容易因流程過於鬆散而無法掌握節奏。
對於成熟的產品型團隊來說，單靠固定的迭代節奏已經不夠敏捷。若每次迭代都還要再等待一段時間才能部署到生產環境，不僅會延遲價值交付，也會增加部署風險與複雜度。
這就是為什麼 DA 提供了持續交付 Agile（Continuous Delivery: Agile）的生命週期選項，讓團隊不只能「每兩週交付一次」，而是能夠「每兩週部署一次」，甚至更頻繁。
DA 持續交付 Agile 生命週期是在 Scrum 式迭代節奏的基礎上，加強 DevOps 與品質自動化能力，使團隊能夠在每次迭代結束時，將完成的功能直接釋出到正式環境中，而不再只是內部驗收。這代表：
這不但減少了等待與延遲，也讓使用者能更快體驗到價值。
要實現這種部署節奏，團隊必須同時具備以下幾項能力：
若缺乏這些基礎，就算流程規劃再敏捷，部署仍然可能成為瓶頸。
持續交付 Agile 生命週期並不是強調「每天一定要上線」，而是具備隨時部署的能力，並根據產品與業務情境設定合適的頻率。
常見的部署節奏包括：
重點在於：部署不再是特別的事，而是日常的一部分。
DA 持續交付 Agile 生命週期適合以下團隊使用：
DA 持續交付 Agile 生命週期是一個過渡階段。當團隊進一步打通組織內部的批准流程、環境配置與基礎架構協作，便可以再向上升級為：
這代表，從持續交付 Agile 生命週期出發，是推動組織敏捷與 DevOps 能力成熟的關鍵起點。
當團隊已經建立起完整的 DevOps 能力與自動化部署流程後，就不再需要等到「一個迭代結束」才部署。只要有價值，就可以隨時交付。
DA 持續交付 Lean（Continuous Delivery: Lean）生命週期就是專為這類高度成熟團隊設計的生命週期。它取消了固定的節奏限制，讓團隊可以用最小單位持續交付價值，甚至達到每天多次上線的能力。
不同於 Scrum 式的迭代交付，DA 持續交付 Lean 採用的是流動式工作模式，每個工作項目一完成就可以部署。
這種模式強調：
這讓整個交付流程變得更加即時，也讓市場回饋更快速。
能夠實踐持續交付 Lean 的團隊，通常具備以下成熟能力：
這些基礎建設與工作習慣的養成，往往需要幾年時間逐步演進，並非一蹴可幾。
在持續交付 Lean 生命週期模式下，部署節奏不是規定出來的，而是自然流動的結果。以下是常見的模式：
換句話說，部署會變成一種日常背景作業，而不是需要特別通知、準備或配合的「大事」。
DA 持續交付 Lean 生命週期特別適合下列類型的團隊或組織：
典型案例如雲端服務平台、行動應用團隊、API 開發服務等。
不是每個專案在一開始就知道「要做什麼」。有時候，我們只是有一個模糊的想法，想解決某個問題、嘗試某個商機，或者只是想測試一個假設。這種情境下，若一開始就投入大量人力開發，風險極高，很可能會花了很多錢，卻發現方向錯了。
探索式生命週期（Exploratory Life Cycle） 正是為了解決這種「經驗知識不足」的情境而設計。它融合了 Lean Startup 的實驗精神與敏捷開發的迭代回饋機制，幫助團隊在最小投入下快速學習，逐步驗證想法，直到確認可以進入產品化階段。
與其他生命週期強調「交付可用產品」不同，探索式生命週期的重點在於：
這些問題無法透過規劃會議回答，只能透過實驗與實作學習而來。每一次實驗就像是在試探地圖上的一條路徑是否可行。
在探索式生命週期中，我們不做完整產品，而是設計一連串的「最小可行實驗（Minimum Viable Experiment, MVE）」，每次只驗證一個核心假設：
這些 MVE 通常會以著陸頁（Landing Page）、互動原型、假功能測試（Fake Door Testing ）、手動服務、AB 測試等形式呈現，重點不是功能完整，而是快速獲得真實反饋。
探索式生命週期的驗證邏輯通常會依序經過以下四個層次：
問題是否值得解決？
若沒人覺得有問題，就不需要解法。
需求是否有市場？
有幾個人需要，不重要，重要的是「夠不夠構成一個市場」。
解法是否被接受？
解法可能合理，但若使用者不願使用，也無法落地。
使用者是否願意付出代價？
真正的價值驗證，是用戶願意用時間、金錢、信任來交換成果。
唯有通過這些驗證，我們才具備足夠信心，讓產品從「實驗」走向「產品化」。
探索不會無限期持續，當團隊完成足夠的驗證後，就會轉入其他生命週期，切換至 DA Agile 生命週期或 DA Lean 生命週期，進行建構與交付。這樣的設計讓探索階段不只是試水溫，而是正式納入交付節奏中的一環，與其他生命週期自然銜接。
探索式生命週期適合以下情境：
這類團隊通常需要高度的學習意願、數據分析觀念，以及快速實驗與決策的能力。
當單一團隊無法獨立完成產品交付時，就需要多個團隊協作。但只要牽涉到跨團隊，就不只是工作分配問題，而是整體架構、節奏、責任與決策的協調問題。這正是 Program 生命週期的角色：為多團隊協作建立一個有節奏、有治理的運作架構，確保大家朝著同一個產品願景共同前進，同時維持各自的敏捷性。
在 Program 生命週期模式下，不同的子團隊（Sub-teams）可能採用不同的生命週期：
每個子團隊可依自身情境選擇最適合的工作方式（WoW）。但在此之上，需要一個統一的「Program 層治理」來整合節奏、技術架構與交付計畫。
架構一致性
每個團隊做的模組都要能整合成一個完整的系統，不能各自為政。
交付節奏協調
雖然各團隊節奏不同，但仍需有共同的整合和釋出時機，避免落差過大。
跨團隊依賴管理
功能與功能之間往往互有依賴，需有人持續追蹤、調整與協調優先順序。
利害關係人對齊
商業面、技術面、使用者端需定期整體溝通，避免只聽到個別團隊的聲音。
整體可視化與決策透明
包括整體進度、風險、品質、財務與目標的追蹤與調整。
在 Program 生命週期模式中，除了各個交付子團隊外，還需設置一個專責的 Program 團隊，負責整合與治理，典型角色包括：
Program 生命週期模式不是把 Scrum 放大，也不是讓每個團隊硬塞在同一個節奏裡。而是透過讓團隊各自敏捷（Loosely Coupled）但整合節奏點（Tightly Aligned），治理但不干涉細節，而是關注整體流動與價值的方式進行分層協作。
這樣才能真正實現「多團隊自主、整體協作高效」的交付能力。
Program 生命週期特別適合以下情境：
常見的例子包括：企業級內部系統平台開發、大型電商網站重構、跨國開發專案等。
DA 最大的特色，就是它不會說「應該怎麼做」，而是幫團隊找到「什麼最適合團隊」。這個觀念在選擇交付生命週期時尤其重要。因為不同的團隊、不同的產品階段、不同的技術成熟度與市場需求，都可能需要不同的交付方式。沒有一種做法能通吃所有情境。
在選擇生命週期之前，可以先自問這三個問題：
我們對產品要做什麼，有多明確？
是已經確認的產品？還是剛開始探索方向？
團隊能多快把功能變更部署到使用者手上？
是靠手動部署？還是已有完整自動化流程？
目前的開發團隊人數與結構？
是單一團隊就能搞定？還是需要多個團隊協作？
這些問題能幫助團隊判斷自己目前所處的成熟度與情境，進而找到對應的生命週期選擇。
最重要的是，選擇生命週期不是一次性的決定，而是一個隨著情境演進而不斷調整的過程。DA 鼓勵團隊每隔一段時間就檢視現況、分析成效，並思考是否該調整工作方式。這種心態，才是持續改善的根本。所以不用擔心一開始選錯答案，重點是有沒有能力與意識去「選擇、試驗、調整、再選擇」。
敏捷團隊之間的差異，不只是規模或工具的不同，更是交付節奏、工作特性、組織責任與學習方式的根本差異。因此交付生命週期不該只有一種選擇，也不應該永遠只用一種方式。真正有彈性的團隊會根據學習結果調整生命週期配置，甚至在一個大型產品中同時運行多種生命週期，並透過流程目標與 WoW 改進機制，持續優化整體交付流程。
敏捷不是做法，而是一種思維方式。DA 用一系列實用的生命週期，幫助團隊將這種思維轉化為日常工作習慣，從而建立真正有適應力的組織文化。
iThome鐵人賽
看影片追技術
看更多
