在上一篇文章《敏捷方法的成功密技（四）：Scrum的理想與現實的障礙》中，我們談到了Scrum明確定義的三種角色，Product Owner產品負責人、Scrum Master 大師，以及Development Team開發團隊，接下來我們就一一來看看。
Product Owner產品負責人
也許您會開始感到狐疑，PO（Product Owner產品負責人）這個角色跟傳統上對客戶的窗口，如產品經理（Product Manager）等，又有什麼不同呢？其實我認為，PO和產品經理並沒有什麼太大的差異，同樣都是產品成敗的最終負責者。既然如此，那麼「理論上」，PO也應該被賦予相當高程度的產品發展方向決策權才對。
很多人會錙銖必較地去比較不同角色的名稱和職責，也有很多人會死板板地抱著Scrum的定義，不顧現實上的各種組織差異，我覺得這樣意義並不大。任何方法和架構，其最終的目的，都在於「有效率地解決某個問題」。因此，PO的重點應該是，此人到底有沒有「能忠實傳達客戶需求和即時決策」的能力，以及得到充分的授權！
如果PO有能力領導一個小組（也許是2-5人不等）去跟客戶／用戶面對面地討論需求，不論是在使用者經驗（User Experience）的設計層次上，或是在系統分析、架構設計（Architecture Design）、實作性、驗證性等技術層面上，都能考慮得夠周詳、夠務實、夠讓客戶／用戶滿意，那麼這位PO就是一位成功的PO了，不是嗎？
有了這個前提之後，PO就有足夠可靠的代表性來代表客戶／用戶做對內的溝通。傳統的方法之所以會常常出問題，就是對客戶的窗口經常被內部開發團隊一問三不知，需求的釐清，在來來回回多趟之後，仍然是不清不楚，這才是最大的問題！
有一位理想的PO（及其帶領的需求澄清小組）之後，理論上已經可以解決掉前篇文章中三大障礙中的第2個（工程人員態度）。而三大障礙中的第一個（客戶態度）也應該會被解決掉至少一半以上，因為這個小組能夠做到即時又有效率的各層面決策，無形之中就大幅縮短了客戶被不斷打擾問需求的總時間，客戶理應樂於接受這樣的互動方式才對。
至於第三個障礙（需求規模龐大），我們押後再談。
Development Team開發團隊
上述的需求澄清小組中，除了PO之外，其他的人其實就是所謂的DT（Development Team開發團隊）的部分成員。DT的人數可能是5-9人「左右」的規模，「最好」能獨立完成、交付最終的產品或服務而不需外部的支援或協助。DT中的Architect、最有經驗RD和QA人員等，都有可能被遴選為某一次需求澄清小組的成員，跟PO一起去和客戶談需求。
需求談完了，可行、夠好的實作架構其實也就八九不離十了。當這些討論的成果被帶回DT之後，整個DT的成員還會進行一連串的細部設計和討論，進一步地落實它們成為產品或服務。
Scrum Master 大師
為了要讓Scrum這個架構能夠被「比較有效地」被執行、落實，所以需要一個SM（Scrum Master）來管理和監控整個DT在Scrum架構之下的運作狀況（當然，其中還包括與PO的互動部分）。
SM不一定需要實際參與實作，但一定需要有極強的能力去「引導」（非命令）DT，在對的時間做對的事情，並且想方設法，讓DT能不斷地精益求精、止於至善，無論是在工作的成果品質，還是工作的速度效率之上。SM做的事情其實就跟很多組織的專案經理（Project Manager）在做的事情其實是一樣的。
彈性、彈性、彈性
請別質疑我，為什麼我的說法跟Scrum的標準定義有些不一樣。事實上，沒人禁止PO帶著DT的成員去跟客戶見面討論事情，更沒人說專案經理不能是SM！也沒有人規定DT人數一定要在9人以下！一切的說法都只是「原則」（guideline），而不是「規定」。
只要組織能接受，效果能出來，誰管你有沒有完全符合Scrum的標準定義？不相信的話，自己多Google一些Scrum的文章讀一讀，多買些書來看一看，你就會發現，各家說法都有些差異和變種！
我要再次強調，請不要被任何人的定義綁住了你的思維，要能夠符合你的組織現況，能夠改善問題，甚至是徹底解決問題，這才是引用一個新方法架構的重點！尤其是，當你想要解決一個組織內的陳疴之時，最好也能像Scrum的Sprint（衝刺）那樣，逐步漸進式地，看看效果如何之後，再修正一下，然後再往前進一步。就像你走路或開車一樣，都是邊走邊修正腳步，或邊開車邊調整方向盤，最後才能準確地到達目的地。
待續...
敏捷系列文章：
1. 敏捷方法的成功密技（一）：Scrum 為何對你很重要？
3. 敏捷方法的成功密技（三）：Scrum 如何擺脫「產品客戶不愛，團隊熱情不再」的窘境？
4. 敏捷方法的成功密技（四）：Scrum 的理想與現實的障礙
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
