本章描述開發團隊（Development Team）角色，涵蓋五項主要職責與十項理想特質。

概述#

傳統軟體開發定義了架構師、程式設計師、測試員、DBA、UI 設計師等職位。Scrum 則定義了開發團隊這個角色——一個跨功能的人員集合，團隊成員共同具備交付產品負責人所要求之商業價值的技能。

「開發團隊」一詞可能看似不夠精確（畢竟不只有開發人員），也有人使用 delivery team、design-build-test team 等替代名稱，但 Scrum 社群目前已收斂於使用 development team。

角色專屬團隊的問題#

許多組織習慣將不同職能拆分成角色專屬團隊（role-specific teams）——設計團隊、開發團隊、測試團隊各自獨立運作，工作完成後再交接。

在 Scrum 中，開發團隊必須在每個 Sprint 產出一個或多個垂直切片（vertical slices）的可運作功能，涵蓋設計、開發、整合與測試。因此需要一個在所有這些任務上都具備技能的團隊。

有些組織嘗試在實行 Scrum 的同時維持獨立的測試/QA 團隊。除非有法規要求，否則測試應完全融入每個 Sprint 的工作中，由執行該 Sprint 的開發團隊自行完成。

主要職責#

1. 執行 Sprint（Perform Sprint Execution）#

開發團隊成員進行設計、建構、整合與測試產品待辦事項，將其轉化為可交付的功能增量。團隊自行組織，共同決定如何規劃、管理、執行與溝通工作。這是團隊花費最多時間的活動。

2. 每日檢視與調適（Inspect and Adapt Each Day）#

每位成員參與每日站立會議（Daily Scrum），集體檢視朝向 Sprint 目標的進度並調整當日計畫。若有成員缺席，團隊可能遺漏全貌而無法達成 Sprint 目標。

3. 梳理產品待辦清單（Groom the Product Backlog）#

每個 Sprint 應撥出最多 10% 的可用產能協助產品負責人進行待辦清單梳理，包括建立與精煉、估算及排序產品待辦事項。

4. 規劃 Sprint（Plan the Sprint）#

Sprint 開始時，開發團隊與產品負責人合作、ScrumMaster 引導下進行 Sprint 規劃：

• 建立下個 Sprint 的目標
• 決定要完成哪些高優先級的待辦事項
• 兩週 Sprint 通常需要半天，四週 Sprint 可能需要一整天

規劃是反覆漸進的——不在開始時做龐大且不確定的詳細計畫，而是在每個 Sprint 開始時做一系列更小、更確定、更詳細的即時計畫。

5. 檢視與調適產品及流程（Inspect and Adapt the Product and Process）#

每個 Sprint 結束時參與兩項活動：

• Sprint Review：開發團隊、產品負責人、ScrumMaster、利害關係人一起檢視已完成的功能並討論後續方向
• Sprint Retrospective：Scrum 團隊檢視並改善其 Scrum 流程與技術實踐

特質與技能#

自我組織（Self-Organizing）#

團隊成員自行決定達成 Sprint 目標的最佳方式，沒有專案經理或其他管理者告訴團隊該怎麼做。自我組織是一種由下而上的湧現屬性（bottom-up emergent property），而非外部施加的指揮控制。

書中以加拿大雁群的 V 字隊形為例：雁群的飛行隊形並非由「管理鳥」召開會議指揮，而是透過簡單規則與持續回饋在複雜適應系統中自然湧現。

管理者在 Scrum 中仍扮演重要角色——他們建立（並重新建立）讓自我組織團隊得以運作的環境（詳見第 13 章）。

跨功能多元且充足（Cross-Functionally Diverse and Sufficient）#

團隊成員應具備跨功能多元性，集體擁有完成工作所需的充分技能。一個良好的團隊能從產品待辦清單取出項目，產出符合「完成定義」（Definition of Done）的高品質可運作功能。

跨功能多元團隊帶來的優勢：

這些多元性通常帶來更快的解決方案、更高品質的交付物與更大的創新。同時也應追求資深與資淺人員的良好搭配，避免太多資深人員造成摩擦或太多資淺人員導致能力不足。

T 型技能（T-Shaped Skills）#

T 型技能意味著團隊成員：

• 在其偏好的功能領域/專業上具有深厚技能（T 的垂直部分）
• 也能在核心專業領域之外工作（T 的水平部分），例如 UX 設計師也能幫忙做測試或文件

不需要每個人都能做每項工作——在高度專業化的領域（如遊戲開發），這不切實際。目標是團隊成員的技能有適當的重疊，提供額外的靈活性。

對於純粹的專家（如只做 UX 設計的 Sue），可以讓她分配時間到多個團隊，但不能過度分散。更好的做法是鼓勵其他成員學習相關技能，減少對專家的過度依賴。

三劍客態度（Musketeer Attitude）#

團隊成員需要秉持**「人人為我，我為人人」**的精神。關鍵要點：

• 團隊共同承擔完成工作的責任——共贏或共敗
• 不應該出現「我完成了我的部分，你沒完成你的，所以我們失敗了」這樣的說法
• 即使技能限制使人無法跨功能工作，仍應組織工作以確保 Sprint 中的良好流動
• 每個團隊成員都有責任充分參與，即使在非自己專業的領域也應積極發言

高頻寬溝通（High-Bandwidth Communications）#

團隊成員需要以快速、高效、低開銷的方式溝通，以最大化資訊價值並加速決策。實現方式包括：

• 面對面溝通是首選，盡可能讓團隊成員共處一地（colocated）
• 對於分散式團隊，適當的技術支持（如高品質視訊會議設備）可以改善頻寬
• 跨功能團隊本身就有更精簡的溝通管道，因為完成工作所需的人員就在團隊內
• 減少低價值的儀式性活動（ceremonies），如多層間接才能跟客戶說話、不必要的文件或冗長的審批流程
• 保持小團隊規模：溝通通道按 N(N-1)/2 公式增長（5 人 = 10 條通道，10 人 = 45 條通道）

透明溝通（Transparent Communication）#

溝通應該透明，遵循最小驚訝原則（Principle of Least Astonishment）——溝通方式應盡量不讓人驚訝。不透明或刻意誤導的溝通會破壞信任，進而阻礙團隊自我組織與達成 Sprint 目標的能力。

適當規模（Right-Sized）#

Scrum 偏好小團隊，一般建議 5 至 9 人（作者經驗中 5 至 7 人是最佳甜蜜點）。小團隊的優勢（Cohn, 2009）：

• 減少社會懈怠（social loafing）
• 更可能產生建設性互動
• 花在協調上的時間更少
• 沒有人能隱身於背景中
• 成員滿意度更高
• 較不易產生有害的過度專業化

當產品需要超過 9 人時，Scrum 不是擴大單一團隊，而是建立多個適當規模的 Scrum 團隊，再透過 Scrum of Scrums 等方式協調。

專注與投入（Focused and Committed）#

研究數據顯示：

• 同時參與 1-2 個專案的生產力最佳
• 同時參與 3 個以上專案是糟糕的經濟選擇——更多時間花在協調、回想與追蹤資訊上
• 對於不得不跨多個產品的專家，應讓專家自己決定能同時投入多少產品

解決專家過載的方法：

1. 減少同時進行的專案數量
2. 僱用更多專家分擔負荷
3. 幫助其他人拓展技能以涵蓋該專業
4. 以上三者的組合

以可持續的節奏工作（Working at a Sustainable Pace）#

傳統循序開發將整合與測試等重要活動延後到後期，導致後期工作強度急劇攀升（death march）。Scrum 則透過每個 Sprint 持續開發、測試、整合可運作功能，搭配重構、持續整合、自動化測試等良好技術實踐，讓工作量趨於平穩。

結果是：

• Sprint 結束前強度可能略增（確保符合完成定義），但整體上每個 Sprint 的強度相近
• 團隊較少加班，降低倦怠風險

長壽團隊（Long-Lived）#

有效使用 Scrum 需要的是團隊（team），而非群體（group）。團隊是一群多元、跨功能的協作者，朝向共同願景努力；群體只是共享一個標籤的人員集合。

長壽團隊的經濟效益極佳：

• 研究（Katz, 1982）顯示長壽團隊比新組建的群體更有生產力
• 團隊熟悉度（Staats, 2011）對團隊產出的效率與品質有正面影響
• 團隊累積了重要的歷史資訊（如速率 velocity、共同的估算歷史）

敏捷的貨幣是團隊。大多數組織如果採用保持核心團隊不變、將團隊整體從一個產品移到另一個產品的策略，會比頻繁搬動個人更經濟。頻繁拆散團隊會破壞信任、完整性與運作效率。

有時打散團隊是合理的——例如團隊功能失調，或採用分裂播種策略（split-and-seed strategy）來推廣 Scrum 的採用。但這些應是例外而非常態。