理解團隊所處的情境

「我們已經用了 Scrum，為什麼還是交不出東西？」
「別人兩週交付一次，我們怎麼一個月都搞不定一個版本？」
「這些流程在新創團隊很好用，但在我們這種金融業根本無法執行。」

這些問題，其實都不是流程本身的錯，而是忽略了團隊所處的情境差異。

在 Disciplined Agile（簡稱 DA）中，有一個很重要的觀念叫做：Context Counts（情境至上）

不同的團隊，就像不同的土壤條件、氣候環境，種植物當然不能只靠一種種法。如果你沒有先分析情境，就直接套用某套方法，那成功機率其實是靠運氣。

當我們談到「選擇自己的工作方式（Way of Working, WoW）」時，第一步就是要先理解團隊所處的情境。因為就像穿衣服要看天氣與場合，工作方式也不能一體適用，必須根據現場狀況量身打造。

即使屬於同一家公司，每個團隊的組成、人數、合作對象、所開發的產品類型、技術架構、交付壓力、合規要求、時區分布都可能大不相同。而這些差異，會直接影響團隊如何協作與溝通，以及適合採用哪一種開發節奏與交付方式等工作方式。

如果不考慮這些情境差異，只是盲目套用「某個看起來很先進的敏捷方法」，不但很容易水土不服，還可能讓原本可以好好運作的團隊陷入混亂。因此團隊在選擇流程、工具與做法時，應該先釐清自身的限制與需求，再從挑選出最適合當前情境的選項。

七大擴展因子

要真正理解團隊所處的情境，就不能只靠直覺或個人經驗。DA 提供了一個結構化的分析工具，幫助團隊用具體的維度來檢視自己目前的工作環境，這些維度就叫做「擴展因子（Scaling Factors）」。

在敏捷實務中，最常聽到的「擴展」的問題是：「我們團隊現在 10 人做得還不錯，但之後變成 100 人時該怎麼辦？」

但其實影響擴展能力的不只有人數，還包含組織架構、技術複雜度、地理位置，甚至是法規合規性、業務領域難度等因素。這些都會影響：

• 要不要拆成多個子團隊？
• 團隊之間該怎麼協作與溝通？
• 決策流程該怎麼設計才不會卡住？

DA 將這些關鍵的影響因素整理成七大類，並以雷達圖的方式視覺化團隊的複雜度，也讓「選擇 WoW」時有跡可循。

團隊規模（Team Size）

團隊的規模大小，是最常被拿來當作「擴展」判斷依據的因素。人數越多，管理與協作的難度也會跟著上升。但問題不在於人多，而在於這群人是否能有效地協同作業。

團隊人數的變化，會大幅影響整體流程設計。DA 不要求所有團隊都遵循同樣的模式，而是鼓勵團隊根據規模彈性選擇合適的 WoW。

• 小團隊的特性與優勢

  一般來說，5～9 人的小型團隊，是最容易採用敏捷做法的規模。因為：

  • 溝通成本低，互相都能直接對話
  • 工作狀態容易透明化，不需要太多文件或會議
  • 決策可以快速進行，容易培養團隊默契

  因此對於這類團隊，可以選擇比較輕量的流程，例如基本的 Scrum 或 Kanban，搭配日常站會與簡單的工作看板就能有效運作。

• 中型團隊：需要基本的協調機制

  當團隊人數來到 10～30 人左右，即便還是同一個產品，也需要開始劃分責任區與協作方式：

  • 可考慮依功能或模組拆成子團隊
  • 定期進行「Scrum of Scrums」或跨團隊協調會議
  • 可能需要一位以上的團隊引導者（Team Lead）協助跨團隊溝通

  在這個規模下，資訊流通與工作節奏的協調變得至關重要。否則很容易出現：

  • 重工與衝突（兩邊都做了一樣的功能）
  • 瓶頸（某個子團隊卡住整體進度）
  • 誤解（不同團隊對需求認知不同）

• 大型團隊：從「一個團隊」變成「團隊的團隊」

  若團隊人數已經超過 30 人，甚至高達上百人，那這已不再是「一個團隊」，而是一個需要有架構與節奏設計的團隊生態系。

  這時候就需要考慮：

  • 明確的團隊分工（例如以子系統、地區、職能等劃分）
  • 整體產品願景與技術策略的對齊機制
  • 定期的同步儀式：如計畫增量會議（Program Increment Planning）或是共同迭代規劃會議（Common Sprint Planning）
  • 整合與驗證流程：例如自動化測試、CI / CD 等技術支持
  • 跨團隊領導者群組：可視為「團隊引導者的團隊」，用來處理整體架構與進度協調

  這樣的情境下，已經進入「戰術敏捷擴展（Tactical Agility at Scale）」的層次，選擇流程與 WoW 時也需要從多個角度來評估。

地理分布（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）」精神。

只要能掌握情境的變化，並具備工具與判斷力來調整對應策略，團隊就能持續在最適合的節奏中成長與交付價值。

• Scaling Factors
• Choosing Your WoW: The Situation Context Framework (SCF)