Day-07 Disciplined Agile 交付團隊的角色與分工模式
團隊角色基本構成
在 Disciplined Agile（簡稱 DA）中，一個交付團隊的組成不只是把幾個工程師湊在一起就能開始開發系統。要能真正有效運作，團隊的每一個角色都必須明確、適當配置，才能在快速變化的環境中穩定交付成果。
團隊的角色設計並不是僵硬固定的，而是根據情境彈性調整。不同於 Scrum 只有三個主要角色（Product Owner、Scrum Master、Team），DA 提供了更完整的角色構成，確保團隊能同時兼顧價值交付、品質、協作與組織對齊。
DA 將團隊中的角色分為：
- 主要角色（Primary Roles）
每個交付團隊都需要具備的核心角色。 - 支援角色（Supporting Roles）
視情況加入，幫助團隊因應特定需求與挑戰。
一個健康且能自我組織的團隊，至少要包含以下五個主要角色：
- 產品負責人（ Product Owner）
- 團隊引導者（Team Lead）
- 架構負責人（Architecture Owner）
- 團隊成員（Team Member）
- 利害關係人（Stakeholder）
除了上述五個主要角色之外，在實務中常常需要引入其他專業人員來支援團隊，例如：合規人員（Compliance Officer）、資安專家（Security Specialist）等。這些角色並非每個團隊都需要，而是根據團隊面臨的情境與需求，例如在面對特定挑戰（如法規遵循、大型資料整合、跨團隊協作等）時靈活地引入與配置，扮演關鍵角色。
責任與協作方式
主要角色：建立高效敏捷團隊的基礎
主要角色是每個交付團隊不可或缺的基礎角色。這些角色涵蓋了從「做對的產品」到「用對的方法做產品」的完整責任範圍，也是讓團隊能夠自我組織、持續改善的關鍵。
- 產品負責人（ Product Owner）
- 核心任務：確保團隊「打造正確的產品」。
- 職責包含：
- 管理與優先排序產品待辦清單
- 與利害關係人溝通，釐清需求與期望
- 定義產品目標與驗收標準
- 與團隊密切合作，釐清需求、解釋背景與定義價值。
- 團隊引導者（Team Lead）
- 核心任務：幫助團隊「快速打造產品」。
- 職責包含：
- 協助團隊自我管理、移除障礙
- 協調會議，確保節奏一致與資訊同步
- 引導團隊持續學習與改善工作方式
- 架構負責人（Architecture Owner）
- 核心任務：確保「用對的方法打造產品」。
- 職責包含：
- 引導整體架構設計方向
- 處理技術決策與系統整合問題
- 與其他團隊的架構負責人協作，維持一致性
- 團隊成員（Team Member）
- 核心任務：實際打造解決方案。
- 包含成員：工程師、測試人員、設計師、資料分析師等多元技能的跨職能角色
- 利害關係人（Stakeholder）
- 利害關係人不是「外部人物」，而是被視為團隊的一部分。
- 可能包含：最終用戶、業務代表、法遵部門、營運團隊等
在 DA 的設計裡，這五個角色構成一個跨職能、價值導向的團隊，彼此互補、共同承擔成功與失敗的責任。
支援角色：彈性支援與專業導入
除了主要角色之外，DA 也設計了多種「支援角色」，這些角色不一定在每個團隊都需要出現，而是根據團隊面臨的情境與需求，靈活地引入與配置。
在實務工作中，有些任務具備高度專業性、跨部門性或合規性，若全部交由核心團隊處理，不但負擔過重，也容易出錯。這時就需要引入具有特定知識或權限的支援角色，協助處理相關事務。
以下列舉部分常見的支援角色（實際角色名稱依組織而異）：
| 角色名稱 | 功能與說明 |
|---|---|
| 敏捷教練（Agile Coach） | 協助團隊導入敏捷方法，釐清問題、提升敏捷成熟度。 |
| 獨立測試人員（Independent Tester） | 在法規、風險或品質要求較高的情境下，提供客觀驗證。 |
| 合規專員（Compliance Officer） | 協助確保系統運作與交付過程符合外部法規與內部政策。 |
| 資安工程師（Security Engineer） | 確保交付內容符合資安標準，避免漏洞與風險。 |
| Data Specialist（資料專家） | 處理資料模型設計、資料品質與流通相關議題。 |
| 介面／體驗設計師（UI/UX Designer） | 強化用戶體驗，協助將需求轉化為具體設計與互動邏輯。 |
| 發行管理人員（Release Manager） | 支援版本整合、部署流程與變更控制。 |
| 基礎設施工程師（Infrastructure Specialist） | 協助處理部署環境、雲端服務與平台整合事宜。 |
這些角色不一定長駐在團隊中，可能是以諮詢、短期支援或輪值方式參與。
支援角色應按需導入，不可濫用，其存在是為了補足專業，而不是取代團隊本身的責任。即便引入支援角色，核心決策權仍應由團隊主導，保持團隊的自我組織性，不應將問題「外包」出去。另外，如果支援角色會長期代勞，就應思考如何讓團隊逐步具備相對應的能力，確保知識傳承與技能內化。
可以把一個 DA 團隊想像成是一個足球隊：
- 主要角色是場上的球員，直接參與比賽。
- 支援角色則像是教練、隨隊醫師、戰情分析師等，在場邊提供關鍵的戰術、數據或支援服務。
重點在於：支援角色是「幫助團隊變得更強」，而不是「替團隊做決定」。
角色可兼任，責任不可含糊
在實務工作中，團隊人力資源有限，一個人常常需要同時扮演多個角色。對強調面對現實的 DA 而言，這是可以接受的。例如：
- 小型新創團隊中，產品負責人也可能負責架構設計。
- 有經驗的工程師可能同時是團隊成員和架構負責人。
- 有教練能力的資深成員，可能兼任團隊引導者的職責。
重點不在於「誰」做什麼，而是「這個角色的責任是否有人確實負責」。
但如果兩個角色之間有利益衝突或任務本質不同，就不適合由同一人兼任。在未考慮周全的情況下兼任，容易引發以下風險：
- 角色邊界不清，工作重疊
例如團隊引導者兼任架構負責人，導致技術決策缺乏團隊共識，只靠個人判斷。 - 責任分工模糊，難以釐清問題
例如產品發生問題時，產品負責人與團隊引導者若為同一人，容易不知道問題出在哪個角色職責上。 - 團隊缺乏對角色的共同認知
若大家都搞不清楚誰負責需求、誰負責架構、誰處理風險，就容易造成協作障礙與推諉責任。
為了避免角色混亂，需要明確定義每個角色的職責，即使由同一人擔任多個角色，也要清楚在什麼時間點是用哪個角色的身份行事。並且定期回顧角色分工是否仍合適，隨著團隊規模與情境變化，也可能需要重新調整人員與角色分配。
DA 雖支持靈活的角色安排，但絕不能讓這種彈性變成「誰都可以做、誰都不需負責」的混亂狀態。角色可以合併，責任必須清楚。 職能可以重疊，決策不容模糊。
跨職能與 T 型人才
一個團隊要能真正落實「持續交付價值」，就必須具備跨職能（cross-functional）的能力。這代表團隊成員合起來要能涵蓋從需求探索、設計、開發、測試到部署的完整能力，而不是依賴外部部門來完成。
如果團隊過度依賴外部部門（例如測試、架構組、資料庫管理），每一次任務交接都會帶來延遲、誤解與浪費。跨職能團隊能降低這種依賴，確保大部分工作可以在團隊內部完成。這樣團隊才能真正對整體價值交付負責，而不是「只完成自己那一段工作」。
跨職能並不是要每個人都變成「萬能全才」，而是強調 T 型能力（T-Shaped Skills）。T 的垂直的一筆（專精）表示成員在某個領域具備深厚專業，例如後端程式設計、測試自動化、UX 設計。而水平的一橫（廣度）則除了本職專業外，能理解並支援其他相關領域，例如開發人員能撰寫部分自動化測試或是業務分析師能幫助檢視驗收條件是否具可測試性。
這樣的團隊結構能帶來三大好處：
- 縮短交付時間
少了跨部門等待，需求能更快轉換成可用的解決方案。 - 提升協作品質
因為對彼此的專業有基本理解，討論時更能找到共識。 - 增強團隊韌性
當某個專家不在場時，其他人仍能部分接手，確保交付不中斷。
但要注意的是跨職能不是要取代個人專業，而是在專精基礎上拓展支援能力，目標是團隊整體涵蓋交付所需能力，而不是要求每個人什麼都要精通。另外成為 T 型人才需要時間，組織應提供適當的培訓與學習機會。
總結來說，跨職能與 T 型人才是為了打造一個能獨立完成價值交付的團隊。這樣的設計不僅提升效率，也讓團隊真正能落實持續為顧客創造價值的核心精神。
結語：從分工合作，到價值共創的敏捷團隊觀
在傳統組織中，角色分工常常被當成權責的界線，誰做什麼、誰負責什麼，好像只要切割清楚，工作就能順利推進。但其實角色不是為了劃分責任，而是為了促進協作與價值交付。
DA 並不拘泥於傳統職能的角色名稱，而是根據團隊的任務與情境，明確定義各角色的任務與行為準則。這讓團隊可以用更彈性的方式來編制人力，也更容易根據需要調整責任歸屬。除了明確的主要角色（如團隊引導者、產品負責人、架構負責人），在需要時也可以靈活引入支援角色（如測試、資安、資料分析等），透過跨職能團隊共同創造價值。
組織應該繞著產品與服務設計團隊結構，目標是加速從「構想」到「實現價值」的流動，而不是在流程中不斷卡關與等待。每個角色都應該能對價值實現負起責任，而不只是「完成分內工作」。敏捷團隊的成功不是靠角色設定有多嚴謹，而是靠團隊成員之間形成的共同目標與價值觀。
