敏捷方法的成功密技(五):Scrum 的三種角色


    在上一篇文章《敏捷方法的成功密技(四):Scrum的理想與現實的障礙》中,我們談到了Scrum明確定義的三種角色,Product Owner產品負責人Scrum Master 大師,以及Development Team開發團隊,接下來我們就一一來看看。

    Product Owner產品負責人

    也許您會開始感到狐疑,POProduct Owner產品負責人)這個角色跟傳統上對客戶的窗口,如產品經理(Product Manager)等,又有什麼不同呢?其實我認為,PO產品經理並沒有什麼太大的差異,同樣都是產品成敗的最終負責者。既然如此,那麼「理論上」,PO也應該被賦予相當高程度的產品發展方向決策權才對。

    很多人會錙銖必較地去比較不同角色的名稱和職責,也有很多人會死板板地抱著Scrum的定義,不顧現實上的各種組織差異,我覺得這樣意義並不大。任何方法和架構,其最終的目的,都在於「有效率地解決某個問題」。因此,PO的重點應該是,此人到底有沒有「能忠實傳達客戶需求和即時決策」的能力,以及得到充分的授權!

    如果PO有能力領導一個小組(也許是2-5人不等)去跟客戶/用戶面對面地討論需求,不論是在使用者經驗(User Experience)的設計層次上,或是在系統分析、架構設計(Architecture Design)、實作性、驗證性等技術層面上,都能考慮得夠周詳、夠務實、夠讓客戶/用戶滿意,那麼這位PO就是一位成功的PO了,不是嗎?

    有了這個前提之後,PO就有足夠可靠的代表性來代表客戶/用戶做對內的溝通。傳統的方法之所以會常常出問題,就是對客戶的窗口經常被內部開發團隊一問三不知,需求的釐清,在來來回回多趟之後,仍然是不清不楚,這才是最大的問題!

    有一位理想的PO(及其帶領的需求澄清小組)之後,理論上已經可以解決掉前篇文章中三大障礙中的第2個(工程人員態度)。而三大障礙中的第一個(客戶態度)也應該會被解決掉至少一半以上,因為這個小組能夠做到即時又有效率的各層面決策,無形之中就大幅縮短了客戶被不斷打擾問需求的總時間,客戶理應樂於接受這樣的互動方式才對。

    至於第三個障礙(需求規模龐大),我們押後再談。

    Development Team開發團隊

    上述的需求澄清小組中,除了PO之外,其他的人其實就是所謂的DTDevelopment Team開發團隊)的部分成員。DT的人數可能是5-9人「左右」的規模,「最好」能獨立完成、交付最終的產品或服務而不需外部的支援或協助。DT中的Architect、最有經驗RDQA人員等,都有可能被遴選為某一次需求澄清小組的成員,跟PO一起去和客戶談需求。

    需求談完了,可行、夠好的實作架構其實也就八九不離十了。當這些討論的成果被帶回DT之後,整個DT的成員還會進行一連串的細部設計和討論,進一步地落實它們成為產品或服務。

    Scrum Master 大師

    為了要讓Scrum這個架構能夠被「比較有效地」被執行、落實,所以需要一個SMScrum Master)來管理和監控整個DTScrum架構之下的運作狀況(當然,其中還包括與PO的互動部分)。

    SM不一定需要實際參與實作,但一定需要有極強的能力去「引導」(非命令)DT,在對的時間做對的事情,並且想方設法,讓DT能不斷地精益求精、止於至善,無論是在工作的成果品質,還是工作的速度效率之上。SM做的事情其實就跟很多組織的專案經理Project Manager)在做的事情其實是一樣的。

    彈性、彈性、彈性

    請別質疑我,為什麼我的說法跟Scrum的標準定義有些不一樣。事實上,沒人禁止PO帶著DT的成員去跟客戶見面討論事情,更沒人說專案經理不能是SM!也沒有人規定DT人數一定要在9人以下!一切的說法都只是「原則」(guideline),而不是「規定」。

    只要組織能接受,效果能出來,誰管你有沒有完全符合Scrum的標準定義?不相信的話,自己多Google一些Scrum的文章讀一讀,多買些書來看一看,你就會發現,各家說法都有些差異和變種!

    我要再次強調,請不要被任何人的定義綁住了你的思維,要能夠符合你的組織現況,能夠改善問題,甚至是徹底解決問題,這才是引用一個新方法架構的重點!尤其是,當你想要解決一個組織內的陳疴之時,最好也能像ScrumSprint衝刺)那樣,逐步漸進式地,看看效果如何之後,再修正一下,然後再往前進一步。就像你走路或開車一樣,都是邊走邊修正腳步,或邊開車邊調整方向盤,最後才能準確地到達目的地。

    待續...
    圖片來源:www.giz.de


    更多相關文章:《敏捷方法的成功密技》系列文章總覽