理解團隊所處的情境
「我們已經用了 Scrum，為什麼還是交不出東西？」
「別人兩週交付一次，我們怎麼一個月都搞不定一個版本？」
「這些流程在新創團隊很好用，但在我們這種金融業根本無法執行。」
這些問題，其實都不是流程本身的錯，而是忽略了團隊所處的情境差異。
在 Disciplined Agile（簡稱 DA）中，有一個很重要的觀念叫做：Context Counts（情境至上）
不同的團隊，就像不同的土壤條件、氣候環境，種植物當然不能只靠一種種法。如果你沒有先分析情境，就直接套用某套方法，那成功機率其實是靠運氣。
當我們談到「選擇自己的工作方式（Way of Working, WoW）」時，第一步就是要先理解團隊所處的情境。因為就像穿衣服要看天氣與場合，工作方式也不能一體適用，必須根據現場狀況量身打造。
即使屬於同一家公司，每個團隊的組成、人數、合作對象、所開發的產品類型、技術架構、交付壓力、合規要求、時區分布都可能大不相同。而這些差異，會直接影響團隊如何協作與溝通，以及適合採用哪一種開發節奏與交付方式等工作方式。
如果不考慮這些情境差異，只是盲目套用「某個看起來很先進的敏捷方法」，不但很容易水土不服，還可能讓原本可以好好運作的團隊陷入混亂。因此團隊在選擇流程、工具與做法時，應該先釐清自身的限制與需求，再從挑選出最適合當前情境的選項。
七大擴展因子
要真正理解團隊所處的情境，就不能只靠直覺或個人經驗。DA 提供了一個結構化的分析工具，幫助團隊用具體的維度來檢視自己目前的工作環境，這些維度就叫做「擴展因子（Scaling Factors）」。
在敏捷實務中，最常聽到的「擴展」的問題是：「我們團隊現在 10 人做得還不錯，但之後變成 100 人時該怎麼辦？」
但其實影響擴展能力的不只有人數，還包含組織架構、技術複雜度、地理位置，甚至是法規合規性、業務領域難度等因素。這些都會影響：
- 要不要拆成多個子團隊？
- 團隊之間該怎麼協作與溝通？
- 決策流程該怎麼設計才不會卡住？
DA 將這些關鍵的影響因素整理成七大類，並以雷達圖的方式視覺化團隊的複雜度，也讓「選擇 WoW」時有跡可循。
團隊規模（Team Size）
團隊的規模大小，是最常被拿來當作「擴展」判斷依據的因素。人數越多，管理與協作的難度也會跟著上升。但問題不在於人多，而在於這群人是否能有效地協同作業。
團隊人數的變化，會大幅影響整體流程設計。DA 不要求所有團隊都遵循同樣的模式，而是鼓勵團隊根據規模彈性選擇合適的 WoW。
- 小團隊的特性與優勢
一般來說，5～9 人的小型團隊，是最容易採用敏捷做法的規模。因為：- 溝通成本低，互相都能直接對話。
- 工作狀態容易透明化，不需要太多文件或會議。
- 決策可以快速進行，容易培養團隊默契。
- 中型團隊：需要基本的協調機制
當團隊人數來到 10～30 人左右，即便還是同一個產品，也需要開始劃分責任區與協作方式：- 可考慮依功能或模組拆成子團隊。
- 定期進行「Scrum of Scrums」或跨團隊協調會議。
- 可能需要一位以上的團隊引導者（Team Lead）協助跨團隊溝通。
- 重工與衝突（兩邊都做了一樣的功能）。
- 瓶頸（某個子團隊卡住整體進度）。
- 誤解（不同團隊對需求認知不同）。
- 大型團隊：從「一個團隊」變成「團隊的團隊」
若團隊人數已經超過 30 人，甚至高達上百人，那這已不再是「一個團隊」，而是一個需要有架構與節奏設計的團隊生態系。這時候就需要考慮：- 明確的團隊分工（例如以子系統、地區、職能等劃分）。
- 整體產品願景與技術策略的對齊機制。
- 定期的同步儀式，如計畫增量會議（Program Increment Planning）或是共同迭代規劃會議（Common Sprint Planning）。
- 整合與驗證流程，例如自動化測試、CI / CD 等技術支持。
- 跨團隊領導者群組，可視為「團隊引導者的團隊」，用來處理整體架構與進度協調。
地理分布（Geographic Distribution）
當團隊成員不再全部坐在同一個辦公室，而是分散在不同樓層、不同城市，甚至不同時區時，「地理分布」就成為影響協作效率的重要因子。
這不只是時差問題，更是資訊流動速度、信任建立難度與工具依賴程度的問題。
- 本地團隊（Collocated Team）
當團隊所有成員都在同一地點工作時，有許多天然的優勢：- 面對面溝通，資訊傳遞速度快。
- 隨時可以非正式交流（如茶水間討論）。
- 團隊感與信任建立比較自然。
- 協作成本低，敏捷儀式執行也更有效。
- 分散團隊（Distributed Team）
當團隊成員位於不同城市或時區時，挑戰就出現了。包括但不限於：- 時差問題
早晚開會的疲勞、沒有重疊工時。 - 溝通延遲
訊息來來回回、容易誤解。 - 信任建立困難
難以靠直覺感受同事的努力與狀態。 - 工具依賴高
需要強化數位化工具的使用與規範。
- 時差問題
當地理分布情境變得複雜時，建議採取以下做法與調整：
- 強化資訊可視化
使用虛擬看板、儀表板與聊天紀錄保持資訊公開。 - 建立明確的溝通規則
例如「每日重疊時段回報進度」、「線上會議固定時程」。 - 善用非同步工具
如錄影簡報、通訊軟體的討論串記錄。 - 設計有意義的儀式
例如每週一次的「虛擬咖啡時間」，強化人與人之間的連結。
地理分布不是問題，缺乏設計才是問題。DA 鼓勵團隊根據分布情況選擇合適的 WoW，不是把過去面對面團隊的做法直接照搬過來用，而是要針對協作成本進行調整與優化。
組織分布（Organizational Distribution）
除了「人在哪裡工作」以外，還有一個常被忽略但影響巨大的擴展因子是：這些人是屬於哪個單位或組織？
這就是「組織分布」所指的範疇。當一個團隊的成員橫跨不同部門、外包單位、甚至是合作企業，會導致資訊流動、權責劃分與協作機制都更加複雜。
典型的組織分布情境像是：
- 同公司不同部門
前端團隊屬於產品部，後端屬於研發部。 - 跨事業單位或跨地區公司
北美團隊與亞洲團隊共同開發核心系統。 - 委外開發或外包團隊
某些模組由外包廠商負責。 - 與合作夥伴共同開發
金融業與科技公司共創金融新創服務。
在這些情況下，成員可能各自隸屬於不同的管理體系，績效與回報方式也不一致，容易出現：
- 責任不明、決策卡關
當跨部門協作時，若沒有清楚的職責定義與決策流程，很容易變成互踢皮球。 - 缺乏共識與共同目標
不同部門或組織通常有不同的績效指標，容易導致優先順序不同，甚至互相牴觸。 - 認知與文化落差
同樣一句話，對不同部門或公司來說可能有不同解讀，造成溝通誤會。 - 信任基礎薄弱
特別是與外包單位合作時，若缺乏透明度與參與感，雙方容易只完成交辦任務，無心優化品質。
當團隊橫跨多個部門或公司時，流程設計的關鍵在於明確分工、主動協作與建立信任，建議採取以下做法與調整：
- 跨部門工作協定（Working Agreement）
明確定義誰負責什麼、如何溝通與協作。 - 可視化的工作系統
像是 Jira 看板、Confluence 文件等，讓不同單位的人都能清楚看到工作狀況。 - 共享的團隊願景與里程碑規劃
讓大家朝同一方向努力，而非只顧自身部門 KPI。 - 輪值主持每日站會
輪流讓不同單位的人主導會議，有助於建立平等與參與感。
技能可用性 (Skill availability)
再完整的計畫、流程和工具，但如果團隊中缺乏關鍵技能，「沒有人能做、也沒人懂怎麼做」，不但無法落實這些策略，反而會因為不斷卡關、誤解與低品質交付而造成更大浪費。
這種情況在以下場景特別常見：
- 團隊被指派導入新技術，但沒人真正熟悉相關工具或架構。
- 系統需支援多語系與無障礙設計，但團隊無 UX 專才。
- 合規單位要求資安強化，但團隊無資安相關處理經驗。
- 要求每日自動化測試與部署，但團隊只會手動測試與人工上線。
這些狀況下，即便流程設計得再好，也會因為「人做不出來」，結果導致不是進度延誤，就是品質不穩，甚至讓流程淪為形式，談不上真正的敏捷交付。
DA 並不預設每個團隊都很厲害，而是承認現實、擁抱差異，讓團隊從當下的技能條件出發，設計出「做得到」的流程與改善路徑。不需要假裝會，也不用強硬遵守別人設計好的流程。只要團隊願意透明地看見技能差距，並設計一條可持續補足的路徑，那就是敏捷精神最真實的展現。
合規要求（Compliance）
在某些產業中，光是把功能做出來還不夠，還必須符合各種外部規範與內部流程，才能合法上線、持續營運。這些額外要求，就屬於「合規要求」的範疇。
合規要求可以來自：
- 政府法規（例如金融業的 KYC、個資保護法 GDPR、醫療法規 HIPAA）。
- 產業標準（如 ISO 27001 資安規範、PCI-DSS 信用卡處理標準）。
- 內部治理（如資安稽核、品質管理、流程控制）。
這些需求往往需要「事前規劃、過程記錄、事後驗證」，無法像一般敏捷流程那樣只靠自主管理就能應付。
為了符合合規性的要求，敏捷可能會面臨下面的挑戰：
- 需額外交付文件與佐證
不只是交付程式碼，還要提供測試報告、設計文件、稽核記錄等。 - 流程無法全然彈性
有些審查流程是固定的、不得跳過，會與敏捷中「迭代、小步快跑」的節奏衝突。 - 多角色參與與審核延遲
常涉及法務、資安、稽核等部門，且他們未必熟悉敏捷流程，導致溝通與節奏不一致。 - 部署與驗收門檻較高
必須確保產品在各方面都符合規範，才有辦法上線。
為了支援合規情境，應透過適當的設計與流程結合，將必要的合規步驟「內建」在 WoW 中，而不是等到事後才被迫補救。這樣做才能在維持敏捷價值的同時，兼顧法規要求。必須強調，合規並不代表僵化。真正僵化的，是忽略合規情境的敏捷實踐，那才是對情境缺乏理解的失敗。
技術複雜度（Technical Complexity）
一個看起來簡單的功能，背後可能牽涉到大量的資料處理、系統整合、效能考量與安全性機制。這些都屬於「技術複雜度」的範疇。當技術複雜度越高，就越需要更嚴謹的設計決策與品質管理流程。
技術複雜度的來源非常多樣，常見的包括：
- 系統整合需求
需與多個外部系統（如金流、ERP、CRM）連接及交換資料。 - 高併發或大資料量處理
需要應對瞬間大量使用者或每日數十萬筆資料。 - 高可靠性與容錯需求
系統一旦出錯或崩潰會導致金錢或聲譽損失。 - 多平台或多裝置支援
同時支援網頁、手機或不同作業系統與瀏覽器。 - 新技術導入或技術債累積
需處理舊系統過渡、新技術不熟悉等技術風險。
這些情況下，開發就不只是「把功能做出來」，而是要持續思考如何控制風險、保持彈性、確保品質。
技術複雜度高，並不代表無法敏捷，而是必須有計劃、有節奏地「探索、驗證、調整」。將技術風險視為可管理的流程設計問題，而不是開發人員的個人壓力來源。
領域複雜度（Domain Complexity）
有些產品功能單純也很好驗證，但有些需求即使講了一整天，團隊還是霧裡看花、摸不著頭緒。這背後的關鍵差異，就在於「領域複雜度」。
領域複雜度指的是這個業務領域本身的規則、流程、限制與邏輯的複雜程度。通常越複雜的領域，越難界定清楚需求，也越容易出現誤解與返工。
常見領域複雜度偏高的情況有：
- 規則繁多且高度交錯（如稅務、保險、電信費率）。
- 需求者與使用者不是同一人（如 B2B 系統、內部流程工具）。
- 領域語言專業難懂（如醫療、金融、法律、物理或高等數學）。
- 實際需求會隨情境動態改變（如物流調度、即時風控）。
- 業務變化快且常出現例外情況。
在這些情境下，即使請到業務專家親自說明，也不代表團隊就能一次理解、馬上開工。
越是複雜的領域，越需要透過高品質的溝通與適當的節奏設計來降低誤差與浪費。因此流程設計並不能照本宣科，而是透過多樣的策略選項，依據實際情境選出最適合自己團隊的做法。
如何影響團隊工作方式
要選出適合自己團隊的 WoW，不是靠感覺，也不是看別人怎麼做就照著套用。真正有效的選擇，是來自對「自己團隊情境」的理解與分析，然後再從流程選項中做出最有根據的決策。
每個擴展因子都像是影響團隊運作的「變因」。變因不同，就應該採取不同的流程設計與實踐方式。
舉例來說：
- 如果團隊地理分布廣泛，那麼同步會議的設計就必須特別謹慎，可能需要強化非同步溝通與文件紀錄。
- 如果合規需求高，就要在流程中安排更多品質檢查點，並確保有足夠的審查與驗證活動。
- 如果同時面對高技術與高領域複雜度，那麼你可能需要架構負責人（Architecture Owner）和領域專家（Domain Expert）共同參與每次的迭代計畫與驗收。
流程不能單靠「經驗法則」堆疊出來，而是要針對情境量身設計。
結語：理解情境，才有策略可言
DA 的獨特設計在於，它不是要求「該怎麼做」，而是提供一套完整有效的指引，包含：
- 流程目標（Process Goals）
你應該思考哪些面向？ - 決策點（Decision Points）
有哪些關鍵選擇要做？ - 選項與風險分析：有哪些方法
各自的優缺點是什麼？
這樣一來，就可以根據當前的團隊情境，有邏輯地挑出最合適的做法，而不是盲從某個框架或書上的建議。
團隊會成長，技術會變化，需求與組織也可能不斷演進。因此 WoW 應該是可調整、可學習、可改善的，這正是 DA 提倡的「引導式持續改善（Guided Continuous Improvement, GCI）」精神。
只要能掌握情境的變化，並具備工具與判斷力來調整對應策略，團隊就能持續在最適合的節奏中成長與交付價值。
