Scrum的三個角色分別有產品負責人(Product Owner)、Scrum Master以及開發團隊(Development Team)，這三個角色負責的範圍是不同的，他們有清楚、明確的定位與職責，他們之間緊密配合，如果你想取得這三個角色的認證資格可以查看Scrum Alliance的Explore Agile Certifications。想找樂子的話，把這個連結給老闆看，這個時候我們就可以看老闆表演是如何把整個Scrum框架給扭曲成他想要的樣子，例如：叫工程師兼任SM，或是叫PM兼任PO等等笑話。
60 秒看懂本篇文章
Scrum 的三個角色 PO, SM, DT
在 Scrum 框架中，有三個主要角色：PO（Product Owner，產品負責人）、SM（Scrum Master，敏捷教練）和 DT（Development Team，開發團隊）。這三個角色分工明確，共同協作完成項目。
PO（Product Owner）
負責定義產品需求和優先級，確保開發團隊專注於最高價值的目標。他們管理 產品待辦清單（Product Backlog），是團隊與客戶之間的橋樑。
SM（Scrum Master）
SM 的職責是促進 Scrum 流程的實施，移除團隊障礙，並確保團隊高效運行。他們像教練一樣支持團隊，幫助他們遵循敏捷原則。
DT（Development Team）
開發團隊是執行工作的核心，他們負責將 PO 定義的需求轉化為具體的產品功能。DT 是跨職能團隊，通常包含工程師、設計師等角色。
三者如何協作？
- PO 定義需求，提供清晰目標。
- SM 確保流程順暢，幫助團隊排除障礙。
- DT 將需求實現為可交付的產品。
順便學英文
“In Scrum, the Product Owner, Scrum Master, and Development Team work together to deliver value.”
在 Scrum 中，產品負責人、敏捷教練和開發團隊共同合作交付價值。
產品負責人(Product Owner)
產品負責人(Product Owner)是Scrum團隊中代表客戶利益的關鍵人。
他的主要職責在於從客戶和市場角度綜合思考，制定最終交付的成果應當具備的功能與特色，並將這些需求按優先順序整理為待辦事項清單，好讓整個團隊可以明確地理解產品的願景與目標。
在Scrum流程的操作層面中，產品負責人需要不斷檢視並調整待辦事項的排序，同時也需要負最後責任驗收每個Sprint所交付的目標。
這就要求產品負責人需要有出色的領導能力、商業頭腦與洞察力，才能真正代表客戶，做出讓團隊感知價值的排序決策。
簡單講，你要會說故事、告訴團隊產品的價值，跟團隊說清楚你的故事優先級。
就我的經驗，你還必須把「什麼叫完成」給定義清楚，不然Sprint結束後就難看了。
就需要具備的能力來說，就如前文所提，在台灣，通常都是產品經理、專案經理被抓去當PO，這就是台灣人（老闆）時常把Scrum扳成自己要的形狀了。
而且這樣的PO，往往都沒有得到充份的授權，PO的所有驗收成果全被老闆打槍。
在Scrum中，任何人都可以擔任PO（產品負責人），只要他能代表用戶。
Scrum Master
如果說產品負責人主要思考「做什麼」，那麼Scrum Master的關注的點是「怎麼做」。
專注於團隊動態，解決各種阻礙團隊運作的障礙，以確保整個Scrum流程的暢通執行。
就我的經驗來說，很多Scrum Master都是由團隊成員兼任，尤其他在技術能力的程度較差的話，又擔任了Scrum Master，那麼整個團隊通常不會理他了。
Scrum Master的主要工作是召開並主持各類規劃與回顧會議，協助團隊訂立切合實際的工作量，同時也會在日常工作中，傾聽並收集團隊成員的反饋，尋找專案協作的盲點與改進空間。
如果開發過程中出現偏離預期的情況，Scrum Master也會適時介入進行協調與救火。可以說Scrum Master就像是團隊的「潤滑劑」，讓整個Scrum框架得以順暢運作。
不過很多Scrum Master通常都是救火越救火越大，因為他自己原本的開發工作都做不完了，還要去協調別人的工作，這怎麼可能？
簡言之，Scrum Master需要絕佳的溝通技巧與人際關係管理能力，才能發揮這一「催化劑」的作用，具體來說，就好像魔戒裡的甘道夫，他就是一位標準的Scrum Master，詳細說明請到我寫的Scrum Master的5大特質。
Scrum Master是團隊協作架構「維護者」。
開發團隊(Development Team)
如果說前兩個角色主要著眼於產品與流程，那麼開發團隊則是最終負責「實現」產品功能並「交付」產出的工程團隊。
在Scrum開發中，這支團隊需要自我組織並進行協作，根據產品負責人提供的優先事項清單，動態調整並確定每個Sprint的工作內容，並在期限內協作完成這些任務。
開發團隊還需要作出工作量的估算，並在Sprint結束時讓PO驗收本次迭代的成果。
團隊成員之間需要有良好的溝通與互相信任，並且具備敏捷開發所需要的應變能力與創新思維，才能真正實現敏捷框架的效能。
這個團隊成員的能力是需要「跨技能」的，若有QA工程師，那麼就要具備API測試、除錯的能力，若有設計師，那麼就要有前端設計的基礎能力。
當然，這太理想化了，所以台灣人不這麼搞的。
一個典型的Scrum開發團隊規模為7±2人，通常包含具備各領域專長的設計師、工程師、測試等，而且成員是被挑選出來的。
三個角色的相互作用
在 Scrum 框架裡，產品負責人（Product Owner）、Scrum Master 和開發團隊（Development Team）就像《魔戒》裡的遠征隊成員一樣，每個人背景不同，但都有各自的專長，同時也具備一些共同技能。讓我們用遠征隊的角色來對比這些 Scrum 團隊的核心角色：
佛羅多·巴金斯（Frodo Baggins）——產品負責人（Product Owner）
- 專長：擁有堅定的意志和使命感，確保團隊聚焦目標，努力達成結果。
- 共同技能：有效溝通和團隊合作。
山姆·詹吉（Samwise Gamgee）——Scrum Master
- 專長：忠誠可靠，支持團隊、移除障礙，幫助成員克服困難。
- 共同技能：基礎支援能力，保護隊伍。
梅里雅達克·烈酒鹿（Merry）——開發團隊成員
- 專長：機智勇敢，擅長規劃和執行任務。
- 共同技能：與團隊成員一起解決問題。
皮瑞格林·圖克（Pippin）——開發團隊成員
- 專長：好奇心強，富有冒險精神，能提出創新想法。
- 共同技能：靈活適應變化，支援團隊。
阿拉岡（Aragorn）——資深開發者或技術領導（Tech Lead）
- 專長：出色的領導力和戰略眼光，能引導團隊走向成功。
- 共同技能：協作能力，與團隊成員共同前進。
甘道夫（Gandalf）——Scrum Master 或顧問（Consultant）
- 專長：擔任引導者與協調者，幫助團隊移除各種障礙。
- 共同技能：必要時提供支援。
勒苟拉斯（Legolas）——具特定技術專長的開發團隊成員
- 專長：精準執行特定任務（例如射擊技術）。
- 共同技能：與其他成員協作。
金靂（Gimli）——具特定技術專長的開發團隊成員
- 專長：強大的近戰能力，適合解決特定問題。
- 共同技能：與團隊成員無縫合作。
波羅莫（Boromir）——具特定技術專長的開發團隊成員
- 專長：領導力和戰鬥能力，能在需要時承擔責任。
- 共同技能：與團隊成員協作。
這些角色各自擁有獨特的技能與專長，但團隊運作的基礎來自共同的核心能力，例如溝通、合作和問題解決能力。這些共同點讓團隊能夠高效協作，一步步實現共同目標。
有工程師曾經抱怨 Scrum 太壓榨人，他們的理由是：工作進度透明到讓人壓力山大。
對於這種情況，其實更需要挑選適合的團隊成員。因為不願接受透明文化、缺乏協作意願的成員，本身就不應該被挑進 Scrum 團隊。畢竟，這樣的角色只會拖慢整個團隊的步伐，而不是幫助大家共同前進。
常見問題
Scrum 的三個角色具體分別負責什麼？
Scrum 的三個角色：產品負責人（PO）、Scrum Master（SM）、開發團隊（DT）各司其職，但必須協作。
PO：決定產品目標和優先級，負責整理和維護產品待辦事項清單，確保團隊做正確的事。
SM：協助團隊排除障礙，促進流程順暢執行，是團隊的「潤滑劑」。
DT：執行產品開發與交付，實現 PO 定義的需求。這個角色需要自我組織能力和技術專業性。
PO（產品負責人）和 PM（產品經理）有什麼不同？為什麼台灣常混為一談？
PO 是 Scrum 框架中的角色，聚焦於產品的價值排序和交付優先級，而 PM 更像是傳統專案管理中的角色，關注的是整體產品策略、資源分配和市場目標。
在台灣，因為不少公司對 Scrum 的理解有限，經常把 PM 拉去兼任 PO。結果呢？PM 被 PO 的職責淹沒，導致沒時間做市場和用戶調研，兩邊都做不好。
Scrum Master 在團隊中真的有必要存在嗎？是否可以由開發團隊兼任？
Scrum Master 是必要的，尤其是在團隊不熟悉 Scrum 或敏捷流程時。如果讓開發團隊兼任，會有幾個問題：
角色衝突：兼任的 SM 很難在開發和協調間平衡，容易顧此失彼。
缺乏信任：團隊可能不把兼任的 SM 當回事，導致協作困難。
所以，讓 SM 獨立存在能更專注於解決問題、推進流程。
Scrum 框架是否適合所有開發團隊？有哪些情況下不適用？
Scrum 不適合所有團隊，特別是以下情況：
需求穩定、不變動的專案：像硬體設計，需求通常在初期已經定案，瀑布式更高效。
團隊規模過小：如果團隊只有 3-4 人，Scrum 的會議流程可能過於繁重。
高層對透明文化不接受：如果管理層過度干預，Scrum 無法真正發揮效用。
在台灣，Scrum Framework 的實踐為什麼經常被「扭曲」？這樣會有什麼影響？
很多公司實踐 Scrum 時，缺乏對框架的正確理解，比如讓工程師兼任 SM，或讓 PO 沒有完整授權，導致團隊執行時步履維艱。這種「扭曲」會讓團隊失去敏捷的核心價值——自我組織和快速迭代，變成只是披著 Scrum 外皮的「偽敏捷」。
開發團隊需要具備哪些跨技能才能在 Scrum 團隊中發揮作用？
在理想狀況下，開發團隊成員應該是「跨技能選手」，比如：
後端工程師：了解 API 測試和效能調校。
前端工程師：熟悉 UX/UI 設計，能快速調整設計細節。
測試工程師：具備自動化測試能力，能執行多層次測試。
當然，這只是理想化。現實中，跨技能更多靠團隊內部合作補足，而不是要求每個人樣樣精通。
Scrum 的工作進度透明是否真的會讓工程師壓力山大？有什麼改善建議嗎？
透明的確會增加壓力，但這其實是雙面刃：壓力來自於缺乏緩衝時間或過於細節的任務拆解。改善方法是讓團隊一起參與規劃工作量，確保每個 Sprint 的目標切合實際，而不是 PO 一廂情願地壓時程。
為什麼 PO 需要對團隊講故事？這對產品開發有什麼幫助？
講故事是 PO 的核心技能之一。透過生動的場景描述，讓團隊理解用戶的痛點和產品的價值，更有助於激發團隊的創造力，打造出真正有價值的功能，而不是僅僅完成一堆清單上的任務。
Scrum Master 是否真的能有效解決阻礙，還是可能會讓問題更加複雜？
SM 的作用取決於他的能力和團隊文化。如果 SM 有足夠的經驗，確實能高效排除障礙，但如果 SM 缺乏影響力或團隊對他的角色不認可，他可能會淪為「聽眾」，甚至增加溝通成本。這就是為什麼選對人擔任 SM 很重要。
有哪些常見的 Scrum 團隊角色錯配情況？這會對項目產生什麼影響？
PM 被迫兼任 PO：分身乏術，產品方向容易迷失。
開發者兼任 SM：無法專注於協調，影響開發效率。
SM 缺乏權威：阻礙無法及時解決，導致 Sprint 目標無法達成。
這些錯配都會降低團隊的敏捷性和生產力，讓 Scrum 失去應有的價值。
要深入了解 Scrum Master 證照？請參考：Scrum Master證照怎麼考？