(此圖片由 AI 生成)
Agile 敏捷專案管理在近年來越來越受到重視，特別是在軟體開發領域。它的靈活性和迭代式的開發方式，使得團隊能夠更快速地適應變化與交付。在現行 PMBOK7 中更是加入了不少敏捷的內容，所以今天就讓我們來看看「理論上」敏捷專案的三個核心角色：產品負責人 Product Owner、敏捷教練 Scrum Master，以及開發團隊Development Team 差異。
首先來看看產品負責人，PO 產品負責人主要任務是確保開發團隊所做的一切工作都符合商業目標和客戶需求，其負責定義產品待辦清單（Product Backlog），這個清單包含了所有需要開發的功能、修正的錯誤以及其他技術需求。
也就是說，PO 會決定產品的功能優先級，但是，PO 不能決定 Sprint 中進行任務的優先級排列，聽起來很撓口對不對，每個 Sprint 決定進行的任務清單稱為衝刺待辦清單，這是由開發團隊決定的，關於這點在明天文章會有更多解釋。
還有一點很有趣，PO 的工作不僅僅是列出需求清單，他們還需要持續與利害關係人（如客戶、公司管理層）溝通，確保所有人的期望一致，PO 需要為團隊提供明確的目標和期望，讓團隊明白每個迭代的最終目的是什麼。
（這邊說有趣是因為，在一些「混合制」大公司中，由公司內部需求部門的提案者兼任 PO 往往不會對同公司資訊部門解釋迭代的最終目的，這個解釋任務常常被丟給同時存在的 PM 解釋。）
接下來談談敏捷教練。敏捷教練是幫助團隊遵循敏捷的原則和流程，確保專案管理方法論（如Scrum）能夠順利執行的角色。
敏捷教練不是團隊的主管，他們是指導者或服務者，要用「僕人式引導」幫助團隊成員克服任何阻礙專案進展的問題，並且持續改進團隊的工作流程。
敏捷教練會主持每日站立會議 Stand Up Meeting，幫助團隊檢視工作進度、解決問題，並且確保每個成員都能有效協作。他們也負責組織衝刺規劃會議 Planning Meeting、衝刺審查會議 Review Meeting 和衝刺回顧會議 Retro Meeting。
常見 PMP 考題，在解題時若題目明顯說這是走「敏捷管理」的公司，選項卻是敏捷教練分派工作，那這就是錯的。除非是「混合制」還有模糊空間，否則「敏捷管理」的敏捷教練不能指揮別人去做事。
（這在現實中也常常讓人困惑，因為台灣大多數中小型軟體公司都是「混合制」，敏捷教練角色常常由工程師小主管兼任，敏捷教練不能指揮人，但是小主管可以。所以考 PMP 一定要先辨識出題目描述公司是「敏捷制」管理還是「混合制」管理，不然很容易寫錯。）
開發團隊是整個專案進行的核心，他們負責實際的產品開發和交付。在敏捷管理中，開發團隊會決定如何實現 PO 所設定的目標。開發團隊可以決定如何分配工作和解決技術問題，以及如何在每個衝刺中交付高品質的工作成果。
在軟體開發中，設計師、工程師們通常就被歸類在開發團隊裡。
以上就是敏捷管理的三大核心角色，但很多公司除了 PO 還有 PM 同時存在，若為混合制，PM 可能會更偏向是專案經理（Project Manager; PjM）而不是產品經理（Product Manager; PdM），即便 PM title 是掛 PdM 產品經理，工作做的也可能偏向 PjM 專案經理。
當 PM 和 PO 同時存在，分工可能會如下：
專注於產品的價值、需求，確保產品符合商業目標和用戶需求，關注產品「為什麼」和「做什麼」。
專注於專案的執行，確保專案在有限資源與預定的時間內完成。此時 PM 主要關注的是專案的「怎麼做」和「什麼時候完成」。
以筆者我的公司而言，走的是「混合制」，所以 PM 即便 title 是掛 Product，但 PO 通常是內部其他提需求的單位員工兼任，所以 PM 在實作上就會偏向 PjM。
今天這篇以算是個過渡回，鐵人賽進度正式進入(Day1 目錄規劃的第四階段)敏捷內容。
注意敏捷與瀑布在現實世界是光譜量表的關係，不是二元性非 A 即 B 那樣的選擇，然而，在 PMP/PMBOK 中還是定義了敏捷的內容，PMP/PMBOK 的敏捷（一樣遵守敏捷宣言並且強調價值導向）更像是幫大家把敏捷的理論都整理好，至於現實的執行就看各位的公司了。
刷題或考試時，題目開頭通常會明說這是敏捷式、瀑布式或混合制公司，會將這間公司跑的制度先告訴考生，這時要按照題意去選相對適合的選項。
由於工程師你我在現實公司可能也是號稱跑敏捷，但又不是那麼的全面（就是混合制）這時在撰寫題目解答時容易搞混，按照自身經驗選了一個錯誤答案。所以傳寫題目時要有個認知就是，盡信書不如無書，但是要盡量選擇符合 PMP/PMBOK 的理論答案。
iThome鐵人賽
看影片追技術