敏捷團隊規模要從工作範圍、技術複雜度與協作成本開始判斷。
Disciplined Agile（DA）會把團隊規模視為協作設計：小型團隊適合範圍明確、溝通直接的工作，中型團隊能容納更多專業能力，多團隊與大型結構則需要額外的協調與治理。
判斷合適規模時，可以先看問題範圍與技術複雜度，再確認團隊是否具備完整交付能力，最後觀察等待、重工、跨團隊依賴與決策延遲是否已經拖慢交付節奏。
為什麼團隊規模會影響交付能力
人數增加，溝通與協作成本同步上升
團隊規模一旦增加，最直接的變化，會先出現在資訊的傳遞上。
人與人之間的溝通關係，會以比人數更快的速度擴張。
若用簡單方式計算，團隊中的溝通關係數量可以用「n × (n – 1) / 2」表示。人數一增加，每位成員都需要和其他人建立溝通連結，整體溝通網絡也就會迅速變得複雜。
舉例來說，2 個人單純只有 1 條溝通關係，3 個人會變成 3 條，4 個人則是 6 條，5 個人就成了 10 條。人數一路增加時，溝通成本也會以非線性的方式快速上升。
在小團隊中，資訊多半可以透過直接對話快速同步，問題也能當場釐清。團隊一旦變大，溝通就開始依賴會議、文件或中間角色傳遞，資訊在流動過程中也會增加延遲與落差。
這樣的情況，會讓開發活動開始出現等待。無論是需求確認、設計對齊，還是測試溝通，都可能因為資訊尚未同步而暫時停下來。
導致工作表面上看起來還在推進，實際上價值流動的速度已經放慢。
因此，團隊規模一旦擴大，協作成本就會一層層堆上來，並一步步影響整體交付節奏。
規模會改變問題處理與決策方式
除了溝通成本之外，團隊規模也會影響問題的處理方式。
在規模較小時，團隊成員多半能直接參與討論，決策建立在共享的理解之上。當需求或技術問題出現，可以迅速聚焦重點並做出調整，回應節奏也較為穩定。
隨著人數增加，決策過程需要更多協調。不同角色之間的觀點需要被整合，討論面向和範圍擴大，決策時間也隨之拉長。
為了讓運作維持在可控範圍，團隊會逐步引入流程與分工，讓責任邊界與決策路徑變得更明確。
這些安排確實能支撐較大規模的運作，也會提高決策成本。當每一次調整都涉及跨角色或跨團隊協調，變更節奏就會受到牽動。
時間一拉長，團隊規模帶來的影響會一層層堆上來。它會影響能完成多少工作，也會改變問題被處理的方式，進而反映在交付的穩定性與反應速度上。
規模會改變協作方式，進而影響交付節奏
團隊規模帶來的影響，會體現在協作方式的變化上。
當團隊維持在較小規模時，溝通路徑單純，決策可以快速形成，工作也較能順暢推進。隨著規模擴大，協作開始仰賴更多機制來維持運作，相關成本也會一層層堆上來。
交付能力的差異就出現在這些日常協作的細節之中。
當協作維持順暢，價值可以持續往前流動。一旦協作出現阻塞，交付節奏就會逐步失去穩定。
Disciplined Agile（DA）中的團隊規模選項
小型團隊（2～15人）
小型團隊是最接近理想敏捷運作的規模。
人數較少時，成員可以直接溝通，也較能建立共同理解。問題一出現，多半能在短時間內被看見並處理。
在這樣的規模下，協作不需要太多額外機制。討論可以快速聚焦，決策也能及時完成。團隊成員對整體工作的掌握度較高，責任感與參與感也更清楚。
這類團隊適合處理單一產品功能，或範圍明確的開發工作，較能維持穩定節奏並持續交付。
需要留意的是，當技能分布不足時，小型團隊仍可能依賴外部資源，例如特定技術能力或業務專業知識。這些依賴會帶來等待與交接，進一步影響交付的流動。
中型團隊（10～30人）
當問題範圍變大或需要更多專業能力時，團隊規模就會逐步擴展到中型。
這樣的規模，能讓不同領域的專業角色加入團隊，例如 UX、資料庫，或特定技術領域的專家，讓團隊在面對需求時具備更完整的處理能力。許多原本需要依賴外部團隊的任務，也會改由團隊內部完成決策與交付。
不過隨著人數增加，溝通與協作的負擔也會開始上升。團隊需要建立基本的協作方式，例如固定節奏的同步、清楚的工作分工，以及共同的完成標準，藉此維持運作的一致性。
若團隊成員彼此距離接近，例如位於同一地點，或本來就維持高頻互動，再加上團隊是隨著需求逐步成長，這種規模仍有機會維持穩定運作。
多團隊結構（10～50人）
當單一團隊已經難以承接整體工作範圍時，常見做法是將人員拆分成多個子團隊。
每個子團隊維持小型團隊的規模，專注在特定領域或功能模組，讓協作依然落在可控範圍內。
這樣的設計，能同時處理較大範圍的問題，也能避免單一團隊因人數過多而讓協作變得遲緩。
這類結構需要額外的協調機制，例如跨團隊同步會議（如 Scrum of Scrums, LeSS, Nexus），用來處理依賴關係、進度協調與整合問題。
同時，也可能出現成員同時參與多個子團隊的情況。這會提高排程複雜度與個人負荷，因此更需要清楚安排工作分配與優先順序。
大型團隊（30人以上）
當規模繼續擴大時，團隊會演變為多團隊的組織形式，單一團隊運作會承受更高的協調壓力。
在這種情境下，協作會從團隊內部，延伸到跨團隊之間的整體運作設計。需求管理、技術整合與團隊協調，將成為影響交付穩定性的關鍵因素。
在 Disciplined Agile 中，這類大型敏捷團隊會建立額外的協作結構，支撐整體運作，例如：
- 產品管理團隊（Product Management Team）
負責整體產品方向、優先順序與價值決策，讓多個團隊能在同一個產品目標下協同推進。 - 產品協調團隊（Product Coordination Team）
協助跨團隊進行需求對齊與依賴管理，降低重工與衝突的發生。 - 架構團隊（Architecture Team）
維持技術方向的一致性，處理跨團隊的技術決策與整合問題。
這些團隊會讓多個團隊在同一個產品與技術脈絡下運作，協助降低整體協作風險，原本的開發團隊仍然負責交付工作。
隨著規模增加，組織層級的決策、技術治理與跨團隊協調，會成為日常運作的一部分。若缺乏這些機制，整合問題與依賴關係容易在後期集中出現，影響交付品質與節奏。
這類規模的團隊能處理複雜且大型的問題，也需要投入更多心力在整體協作與治理上，才能維持穩定交付。
不同規模代表不同的協作模式
團隊規模的選擇，實際上是在選擇一種協作方式。
當團隊維持在較小規模時，溝通路徑直接，決策可以快速形成。擴展到中型規模後，團隊會在能力完整性與運作效率之間取得平衡。進一步發展為多團隊或大型組織時，則需要透過結構與治理機制來維持整體運作的一致性。
沒有任何一種規模可以適用所有情境。關鍵在於理解各種規模背後的運作方式，並依據問題的範圍與複雜度，選擇合適的團隊設計，讓協作與交付能夠維持在可控範圍內。
不同規模的實務取捨
小型團隊的效率與依賴風險
小型團隊多半能維持較高的協作效率。
成員之間互動距離近，溝通可以直接進行，問題也能在短時間內被釐清與處理。決策流程相對簡單，討論成本較低，整體節奏也較能維持穩定。
在這樣的環境下，開發人員對系統的理解會漸漸一致，工作較少被侷限在單一角色，協作彈性也隨之提高。當需求發生變動時，調整方向的速度可以維持在較快的節奏。
需要留意的是，當團隊缺乏某些關鍵技能時，工作會轉而依賴外部團隊或特定人員完成。這些依賴會帶來等待時間，也會增加交接成本。
當依賴關係變多，原本的效率優勢會被慢慢抵銷。交付節奏不再完全由團隊掌握，也會受到外部因素的牽動。
中型團隊的平衡狀態
中型團隊多半是在效率與能力完整性之間取得平衡。
隨著人數增加，團隊可以涵蓋更多專業技能，例如設計、測試或特定技術領域，讓更多工作能在團隊內部完成，降低對外部資源的依賴。
這樣的結構有助於讓需求從討論到交付都能維持在同一個節奏中。
在這種規模下，協作會需要一些基本機制來維持一致性，例如固定的同步節奏、明確的責任分工，以及清楚的完成標準。
這些安排會帶來一定程度的溝通成本，好讓團隊在面對較複雜的問題時，仍能維持穩定運作。
若團隊能隨著需求一步步成長，在過程中建立共同的工作方式，且成員處於相近的地理位置，中型團隊就有條件維持良好的交付穩定性。
大團隊的協調與整合成本
當團隊規模持續擴大時，協作方式會出現明顯變化。
溝通已經無法再靠所有人直接對話完成，需要透過會議、角色分工與文件來傳遞資訊。這些安排讓團隊得以持續運作，也讓資訊流動變得更間接，理解落差與傳遞延遲的風險也會隨之增加。
在這種情境下，跨團隊依賴會愈來愈頻繁。不同團隊之間需要協調進度、對齊需求，並處理整合相關問題。
這些活動會消耗時間，也會提高整體運作的不確定性。
當整合與協調缺乏妥善設計時，許多問題就會在後期才集中浮現，處理成本也會明顯上升。
當團隊規模愈大，成功率會受到協作成本牽動。人力增加後，若協調與整合沒有跟上，整體節奏就會被拖慢。
規模取捨的核心在於協作成本
不同團隊規模帶來的差異，最後都會反映在協作成本上。
小型團隊協作效率高，也需承擔外部依賴帶來的風險。中型團隊在能力完整性與運作效率之間取得較好的平衡。大型團隊則需要投入更多成本在協調、整合與治理上，整體運作才有辦法維持穩定。
從團隊規模的角度考量團隊組建時，可以直接觀察目前的協作方式是否依然順暢，以及這些協作成本是否已經開始影響交付節奏。
團隊規模過大時的調整方式
把問題拆小，降低單一團隊負擔
當團隊規模開始變大時，代表目前面對的問題，已經超出單一團隊能有效處理的範圍。這個時候若只是直接增加人力，協作複雜度也會跟著上升。
較穩定的做法，是先回頭檢視問題該如何切分。透過需求拆解與業務分析，將原本範圍較大的目標，整理成多個可以獨立交付的工作單位。
當工作被適當拆分之後，每個團隊只需要聚焦在較小的範圍內運作，溝通範圍與協作複雜度也會跟著下降。這樣的安排，會讓交付活動較能維持在穩定節奏中。
拆分成多個可運作的小團隊
當問題無法再進一步縮小時，可以透過團隊結構調整來維持運作效率。
將大型團隊拆分為多個小型子團隊，讓每個團隊維持在可協作的規模內。每個子團隊負責明確的範圍，並具備完成工作的基本能力，讓工作可以盡量在團隊內部完成。
這樣的設計可以保留小團隊的協作優勢，也比較有機會同時處理較大範圍的需求。
團隊拆分若只停留在人員分組，效果有限。康威定律（Conway’s Law）提醒我們，系統架構經常會反映組織的溝通結構。
換句話說，團隊怎麼分工，系統也應跟著長成相似的樣子。
因此，當大型團隊要拆成多個小團隊時，也需要同步進行系統解構，讓系統邊界與團隊邊界盡量對齊。
將原本高度集中、彼此緊密依賴的系統，拆成較清楚的模組，甚至朝微服務化方向調整，讓每個團隊有機會在自己的範圍內獨立開發、測試與交付。
若系統仍然高度耦合，即使表面上已經分成不同小組，團隊之間還是會因為共用程式碼、資料結構或部署流程而頻繁互相等待。最後看起來有多個團隊同時運作，實際上仍然被同一套耦合結構綁在一起。
所以拆分大型團隊的重點包含重畫組織圖、重新整理系統邊界、依賴關係與交付方式。
當團隊結構與系統結構能夠彼此配合，協作成本才有機會真正降下來。
調整組織與文化，避免無效擴編
團隊規模變大，有時是受到組織習慣或管理方式的影響，問題範圍未必真的需要這麼多人。
例如，組織為了提高資源利用率而建立集中人力池，或期待透過增加人數來加快進度。這些做法在短期內看起來可能有效，時間一長，協作成本就會一步步堆上來。
在調整團隊規模時，可以先回頭檢視目前的工作方式與決策模式，找出是否存在結構或流程上不必要的複雜度。透過改善工作方式（Way of Working, WoW），讓團隊在較小規模下也能順利運作，能減少擴編帶來的協調負擔。
優先調整問題與結構，再考慮人數
當團隊規模已經開始影響交付節奏時，首先該考慮的重點應該是重新設計工作方式。
先調整問題的切分方式，再檢視團隊結構，最後才評估是否需要增加人力。
這樣的順序，能讓協作維持在可控範圍內，也讓交付能力隨時間穩定累積，避免因短期補充人力而帶來額外的協作成本與浪費。
如何決定合適的團隊規模
根據問題規模與複雜度決定人數
決定團隊規模時，第一步還是回到要處理的問題。
工作範圍越大、系統越複雜，需要的協作與專業能力也會跟著增加。
這會直接影響需要投入多少人，以及是否要進一步拆分成多個團隊來處理。
如果問題可以拆成多個相對獨立的部分，就適合由多個小團隊並行處理。
相對地，若工作之間高度耦合，拆分過細反而會讓整合成本持續上升。
因此，團隊規模應該從問題結構推導出來，再決定合適的團隊設計。先設定人數再回頭分配工作，容易讓協作成本被低估。
評估是否能形成完整交付能力
除了人數之外，更重要的是團隊是否具備完成工作的能力。
一個合適的團隊，應該在大多數情況下，都能從需求理解一路走到交付驗證，並在團隊內部完成主要工作。
當團隊需要頻繁依賴外部角色或其他團隊時，流程中就容易出現等待、交接與中斷。
因此在評估團隊規模時，也需要一起觀察技能分布是否足以支撐日常開發，例如是否具備設計、開發、測試，以及必要的技術能力。
當團隊能在內部完成大部分工作時，交付節奏便能更穩定，問題也能被及時看見與處理。
地理位置分布會放大協作成本
除了人數與技能之外，團隊的地理分布也會直接影響實際可運作的規模。
當成員位於同一地點時，溝通可以透過即時對話快速完成，許多細節也能在日常互動中被及時釐清。在這種情況下，即使人數稍多，協作仍有機會維持在可控範圍內。
當團隊分散在不同地點，甚至跨越不同時區時，溝通就會更依賴線上會議、訊息工具與文件紀錄。資訊傳遞需要經過更多環節，回應時間也會被拉長。
在這種情境下，原本就存在的協作成本會被進一步放大。例如需求確認需要等待、問題無法即時釐清、決策需要跨時區協調，這些情況都會讓工作節奏變得不連續。
因此在評估團隊規模時，也需要一併考慮地理分布帶來的影響。分散式團隊會需要更明確的工作邊界、更清楚的協作規則，以及更高程度的自主性，交付節奏才比較容易維持穩定。
如果這些條件還沒有建立起來，先將人數維持在較小規模，會更有利於團隊順利運作。
觀察協作成本是否開始影響節奏
團隊規模是否合適，最直接的判斷依據，是協作是否仍然順暢。
當團隊開始出現頻繁的同步會議、溝通延遲、決策時間拉長，或工作因等待他人而停滯時，代表協作成本已經開始影響整體節奏。
這些現象一開始不一定明顯，會隨著規模擴大一層層堆上來。當這些訊號開始反覆出現，就需要重新檢視目前的團隊規模與結構是否仍然合適。
直接觀察日常運作中的阻礙，能反映團隊的真實狀態。
以協作狀態檢視團隊規模
團隊規模的決定，是在調整協作方式。
先理解問題，再確認團隊是否具備完整的交付能力，最後觀察協作成本是否仍維持在可控範圍內。
這樣的判斷順序，能幫助團隊在不同情境下找到較合適的規模。
當團隊規模能支撐順暢協作時，交付節奏才會穩定下來，團隊能力也能隨著時間沉澱下來。
結語：團隊規模影響的是「協作成本」
規模變化會帶動協作方式一起改變
團隊規模一旦改變，協作方式也會跟著調整。
人數較少時，資訊傳遞路徑較短，成員之間可以直接討論，問題也較容易在第一時間被釐清。
隨著人數逐步增加，團隊運作會開始依賴更多同步機制，例如會議、文件、角色分工與跨團隊協調。
這些安排有助於維持運作秩序，也會讓資訊流動路徑變長，議題確認與決策所需的時間增加。
當交付節奏開始受到影響時，訊號會從這些日常協作方式的變化中慢慢浮現。
協作成本會藏在日常工作中
協作成本會分散在每天的工作之中，並隨著一次次溝通、確認、等待與整合一層層堆上來。
例如，需求需要反覆確認、設計需要多次對齊、跨團隊協調需要等待回應，或到了整合階段才發現彼此理解存在落差。這些情況單次看起來影響不大，只要在每個迭代中持續出現，累積效果就會愈來愈明顯。
時間一長，團隊會投入更多心力在同步與協調上，用來完成工作與推進價值的時間就會被壓縮，交付節奏也會失去穩定。
團隊規模需要維持在可協作的範圍內
合適的團隊規模，會落在一個能讓協作順暢發生的範圍內。
這個範圍沒有固定數字，還需要視工作複雜度、技能組成、產品結構與組織環境而定。
只要團隊中的資訊能順利流動，決策能在合理時間內完成，工作也能持續往前推進，這樣的規模就足以支撐穩定交付。
當團隊開始頻繁出現等待、重複對齊、整合延遲與責任邊界模糊等情況時，就值得重新檢視目前的規模與結構是否仍然合適。
用協作成本觀察團隊規模是否合適
團隊規模是否合適，可以從協作成本來觀察。
當協作順暢時，溝通會更直接，決策速度也較穩定，工作因此能夠順利往前推進。
當協作摩擦開始增加，等待、延遲與整合風險也會跟著上升，交付能力自然會受到影響。
因此，團隊規模可以視為一項需要持續調整的設計決策。隨著問題規模、需求特性與組織情境改變，團隊結構與人數配置也需要跟著調整。
- 團隊不是組好就結束：Disciplined Agile 團隊演化策略解析
- Strategies for Organizing Large Agile Teams
- How Large Are Agile Teams in Practice?
