Scrum 專案的變化不僅限於引入 ScrumMaster 和 Product Owner 兩個新角色。自組織團隊的本質消除了傳統技術團隊領導的角色，個人被要求跨越專業界限協助團隊，重點從撰寫需求文件轉向口頭討論，團隊必須在每個 Sprint 結束時產出可交付的成果。這些變化改變了團隊與組織內的角色關係，也是組織採用 Scrum 時面臨挑戰的原因之一。
在閱讀這些角色時，請記住：任何參與產品或軟體開發的團隊成員，首先且最重要的身分是開發者（developer）。當使用 tester 這樣的術語時，指的是一位偏好測試工作、但會承擔團隊所需任何高優先任務的開發者。Analyst 同理。
Analysts（分析師）#
具備深厚產品知識和溝通能力的分析師，在 Scrum 中往往會自然轉向 Product Owner 角色。在大型專案使用產品負責人層級結構時尤其常見。
即時分析取代超前規劃#
- 傳統專案中，分析師的目標是盡可能跑在團隊前面
- Scrum 專案中，改為 just-in-time analysis：僅稍微領先團隊，提供當前和近期功能的有用資訊
- 分析師的首要優先是達成當前 Sprint 的目標，包括協助測試、回答問題、參與所有 Sprint 會議等
從中間人到促進者#
- 傳統專案中，分析師常成為團隊與 Product Owner 之間的中間人
- Scrum 專案中，分析師應成為團隊與 Product Owner 對話的促進者（facilitator），而非所有對話的管道
- 資訊分享方式從正式文件轉向非正式溝通，雖仍需文件（尤其是分散式團隊），但形式更輕量（如 wiki）
前瞻工作的處理#
- 分析師未被當前 Sprint 完全佔用的時間，可用來前瞻
- 但前瞻不等於提前一個 Sprint 工作：跑太前面反而會影響當前 Sprint，且需求細節往往在團隊實際開發前就已改變
- Sprint planning 中能辨識的分析任務應納入 Sprint backlog；若下一個 Sprint 的工作尚不確定，則不需納入
許多分析師在適應 Scrum 後發現，雖然放棄了「客戶需求唯一詮釋者」的角色，但團隊的統一感和協作品質大幅提升，互相指責的現象被「以團隊為單位」的心態所取代。
Project Managers（專案經理）#
在傳統瀑布式開發中，專案經理需要管理專案的一切——範圍、成本、品質、人員、溝通、風險、採購等。但其中許多職責其實屬於其他人，例如範圍控制理應由客戶負責。Scrum 承認這個不可持續的角色並將其消除。
職責的重新分配#
消除角色不代表消除工作與職責：
- 自組織團隊承擔了過去由專案經理肩負的大量責任（例如：團隊成員自行選擇任務，而非由專案經理分配）
- 其他職責轉移至 ScrumMaster 或 Product Owner
前專案經理的轉型路徑#
| 轉型方向 | 適合對象 |
|---|---|
| 回歸技術角色 | 原本因職涯路徑才擔任 PM、實際懷念技術工作的人 |
| Product Owner | 透過 PM 角色累積了豐富商業與客戶知識的人；適合難以完全放棄「告訴團隊做什麼」的人 |
| ScrumMaster | 能克服指揮團隊、替團隊做決策舊習慣的人；這是採用 Scrum 的組織中最常見的轉型 |
成為 ScrumMaster 的建議#
- 盡量按書操作 Scrum：初期緊跟 Scrum 書籍或教練的建議，累積實際經驗後再客製化
- 盡可能與其他 ScrumMaster 交流：組成實踐社群（community of practice），分享經驗與教訓
- 盡快大量學習：閱讀書籍與文章、參加敏捷社群活動與研討會
為何要改頭銜？#
Ken Schwaber 在 1997 年發明 ScrumMaster 一詞，部分原因是要提醒所有人這不僅是專案經理角色加減幾項職責。Schwaber 認為「Scrum 的詞彙是變革的詞彙，這些詞刻意不美觀——burndown、backlog、ScrumMaster——因為它們提醒我們變革正在發生。」
保留舊頭銜會阻礙新思維的採用。如果人們連改變職稱這樣微小的事都不願意，他們很可能也不願意做出採用 Scrum 所需的更大改變。
Architects（架構師）#
架構師面對 Scrum 時的兩大顧慮：
- 團隊還會實作我指定的架構嗎？
- 沒有前期架構階段，如何確保架構品質？
第一個顧慮：影響力來自尊重#
答案取決於架構師本人。許多架構師會發現工作變化不大——他們的建議之所以被採用，是因為其他開發者尊重他們並信任其判斷。即便在自組織團隊中，當一位同事在架構決策上有良好的口碑，其他人自然會主動諮詢。
第二個顧慮：漸進式架構#
架構需求與商業目標結合，共同驅動 Product Backlog 的優先排序。架構師可以：
- 聚焦於應用程式中的架構不確定性
- 與 Product Owner 密切合作，說明 backlog 項目的架構影響
- 通過審慎安排 Sprint 內容，幫助團隊提早獲取關鍵知識、發現或避免風險
非撰碼型架構師（The Non-Coding Architect）#
被 Scott Ambler 稱為「象牙塔架構師」（ivory tower architects）的非撰碼型架構師，將面臨最大的變化。Scrum 專案中，架構師的角色從命令者轉變為顧問與促進者。
- 架構師不需要全職寫程式，一、兩個 Sprint 不寫 production code 也可以
- 關鍵區分在於：還能寫程式的架構師 vs. 寫程式能力已落後的架構師
- 要小心那些抗拒動手參與的架構師——有些人選擇架構師路線是為了逃避實際程式設計
Figure 8.1: Different types of functional managers
Functional Managers（功能經理）#
開發經理、QA 主管等功能經理在轉型至 Scrum 後通常會經歷一些權力削減，但具體程度取決於組織先前如何定義該角色。
持續保留的職責#
- 人員指派：將個人分配到專案（但不再分配個別任務——任務選擇由團隊自組織決定）
- 跨專案標準：建立品質、可維護性、可重用性等標準
- 人才培育：為團隊成員爭取預算參加研討會、安排具挑戰性的專案、鼓勵加入或組建實踐社群
- 績效評估與人事決策：在 Scrum 環境中，需要更多來自同事與客戶的 input
領導風格#
根據 Jeffrey Liker《The Toyota Way》的框架，功能經理依知識深度與管理風格可分為四類。在採用 Scrum 的組織中，功能經理應位於右上象限——結合對工作的深度理解與由下而上（bottom-up）的管理風格，成為「學習型組織的建構者」（Builder of Learning Organizations）。
採用 Scrum 後，多數功能經理發現自己有更多時間可以更密切地聯繫直屬部屬、了解各專案的進展（透過參加各種 Sprint Review 等），以及關注跨專案標準與未來方向。
Programmers（程式設計師）#
主動參與而非被動接收#
Scrum 團隊中的程式設計師最顯著的變化是：不能再坐在座位上等別人告訴你寫什麼。程式設計師——如同團隊中所有人——被期待共同承擔產品成功的責任。
- 預期要與客戶和使用者對話（不需要變成業務員，但至少要能舒適地偶爾與使用者交流）
- 預期要更多與同事互動：參與討論、幫助他人解決問題、進行 pair programming
- 預期要為了優化團隊整體產出而在必要時走出舒適圈（例如寫測試、使用不熟悉的語言）
技術實踐的改變#
Chapter 9 描述的許多技術實踐對程式設計師來說都是新的。團隊不一定需要一次全部採用，但都值得考慮和嘗試。
Database Administrators（資料庫管理員）#
資料庫專業人員（DBA、資料庫工程師等）可能是最抵制 Scrum 的角色之一。傳統方法強調在專案前期完成完整的資料分析，因為「應用程式會變，但資料是永恆的」。
漸進式資料庫設計#
- 雖然完整分析在理論上很好，但在進行分析的同時，世界持續變化——使用者需求改變、競爭者推出產品
- DBA 日常工作不會有大幅變化，但工作的排程與方式將戲劇性地改變
- 使用者體驗設計、架構和資料庫設計本質上是同一個挑戰的特例：對需要全局思考的事物進行漸進式工作
Testers（測試人員）#
從符合規格到符合使用者需求#
傳統測試基於 Philip Crosby 對品質的定義：「符合需求」（conformance to requirements）。但在 Scrum 中，我們承認完美預測所有使用者需求是不可能的。品質的定義從符合需求規格提升為符合使用者的真實需求。
從文件驅動到對話驅動#
- 測試人員的主要方式變為與 Product Owner 對話，了解功能應如何運作、驗收標準為何
- 測試人員不限於只從 Product Owner 獲取資訊，也應與使用者、客戶和其他利害關係人交流
迭代式測試#
- 最大的變化之一是學習迭代式工作
- 不能簡單地宣佈「每個 Sprint 的最後一週用來測試」——這會製造 Sprint 內的迷你瀑布
- 初期幾個 Sprint 測試人員會面臨巨大挑戰：程式設計師也在學習迭代式工作，團隊可能高估承諾量
測試自動化#
- Scrum 短 Sprint 的節奏使測試自動化成為必需
- 雖然部分自動化工具本質上就是寫程式，但透過時間、訓練和與程式設計師 pairing，多數手動測試人員都能成功轉型
Lisa Crispin（《Agile Testing》合著者）的建議：「不要坐著等工作來找你，要主動出擊！測試人員不能等測試任務來到面前，必須站起來參與、弄清楚該做什麼。」
Figure 8.2: UED and development can occur in parallel tracks
User Experience Designers（使用者體驗設計師）#
UED 對採用 Scrum 有合理的顧慮：他們習慣在其他開發活動之前先進行自己的迭代，但 Scrum 專案不希望在開始開發前完成所有 UED 工作。
雙軌並行模式#
根據 Lynn Miller 和 Desirée Sy 的方法，專案應有兩條並行軌道：
- 開發軌道（Dev Track）
- 互動設計軌道（UED Track）
UED 工作始終領先開發工作至少一個 Sprint，透過初始的 Sprint Zero 和在第一個 Sprint 聚焦於低 UI 影響的功能來實現。
心態比流程更重要#
關鍵不在於 UED 做了什麼工作（兩種心態下工作內容相同），而在於如何定位自己：
- 錯誤心態：「我是 UED，我在開發者前一個 Sprint 工作，確保他們開始時有設計可用。」
- 正確心態：「我在開發團隊上，主要工作是確保我們完成 Sprint 承諾的一切。剩餘時間我會前瞻一兩個 Sprint，蒐集資料、做設計原型。」
UED 必須將自己視為團隊的一部分。跨功能團隊的理念是 Scrum 的基礎——團隊需要包含從構想到實現所需的所有人。UED 的首要優先是交付當前 Sprint 的承諾，前瞻工作是次要的。
Three Common Themes（三個共同主題）#
本章討論了分析師、專案經理、架構師、功能經理、程式設計師、DBA、測試人員和 UED 的角色變化。三個貫穿所有角色的主題：
- 漸進式工作（Work incrementally）：始終努力在 Sprint 內產出可交付的產品增量
- 迭代式工作（Work iteratively）：功能可以在後續 Sprint 中重新審視和改進
- 跨越專業工作（Work beyond your specialty）：為了在 Sprint 結束時產出可交付的成果，個人需要願意偶爾跨出自己的專業領域