之前寫了一篇關於Scrum精神的說明。 發現還確實有些朋友對此方法有興趣，所以接下來繼續分幾個篇幅來多介紹一下這方法的一些細節吧。
但我也要再次提醒，世界上沒有「聖杯」。 並非你學了這方法，專案就能避免一切問題。 所有方法都有「適用性」的問題。 適用性「並非跟產業相關」，更跟專案規模、類型、組織、人員能力、還有文化相關。 如果在不合適的環境中嘗試不合適的方法，最後就會得到不對的結果。 所以請別誤以為你是做軟體開發或是遊戲開發，這方法就一定適合你。
但在繼續討論Scrum的方法細節前，我想先解釋一下Scrum中幾個「管理角色」的界定。 因為這方法很仰賴每個人能正確扮演好自身角色。 如果只是在傳統組織中套用Scrum的方法論，那其實是不會有任何效果的。(換言之，想導入Scrum的，請先確保你能先改造「組織結構與工作職責」。)
那這角色定位是如何的呢？ 基本上，Scrum把專案中的成員分成三個角色：
- Product Owner
- Scrum Master
- Team Member
Product Owner
是所有利害關係人(Stakeholder)的代表。 他負責整合不同的利害關係人，並協助專案來定義Vision。 換言之，他決定專案到底最後要做成甚麼樣子，確保投資的回報能最符合組織(其他利害關係人)的需求。 最後尤其重要的，他得定義專案的完成日期。
也因為他肩負這樣的責任，他在專案開始前，必須要了解各利害關係人的考量，並根據這考量定義出這個專案的需求/功能清單(Scrum的術語稱之為Product Backlog)，以及各需求的優先順序。 甚至在專案的每個循環(Scrum術語稱為Sprint)，他得定義各循環的需求、調整需求的優先順序、甚至根據成果來刪減或增加Product Backlog的內容。
至於團隊在做每個循環的計畫(術語稱為Sprint Planning Meeting)時，他也得全程參與，確保團隊對於需求的認知無誤，要走的方向與內容也都可被接受。
最後，在每個循環完成後，他得代表其他的利害關係人來檢視本次循環的完成狀態是否有符合認知。
所以大家可以看到。 要使用Scrum的第一個要項，就是你得要有一個有擔當的Product Owner。 他得去整合不同的利害關係人，並把大家的需求界定清楚、並標出優先順序。 再來，他得從頭到尾參與專案的開發，在每次計畫會議中確認大家沒有偏離方向，在每次循環(Sprint)結束後檢視結果，並根據團隊執行的能力來調整後續範疇。
如果扮演這角色的人不瞭解需求、不能搞定其他利害關係人、不能分辨每次進度的狀態，那這方法就注定不會成功。
從此我們其實已經可以先簡單得到一個結論：幾乎台灣99%外包為主的案子都別想用Scrum。 兩個原因。 首先，客戶通常不會有耐心這麼陪你玩。 二來，要做甚麼通常合約都寫死了，不可能根據實際執行狀況機動調整。 所以除非是內部的開發案，不然這方法論幾乎沒有適用空間。
Scrum Master
這角色跟一般人認為的PM其實有很大的差異。 與其說他是一般專案組織的管理負責人，他更像是一個「家教」。
Scrum Master其實並「不負責管理團隊，而是負責教育團隊」 - 確保大家以符合Scrum精神的方式做事情。 另一個主要的工作，是幫忙團隊把問題擋在外面。
比方說，有人提出不在這循環定義要做的需求時，Scrum Master得出頭幫忙阻擋。 或是把這人引導到Product Owner那邊。 有人的電腦壞了，但是IT並沒辦法一下子提供新替換機器，他得出頭去跟IT部門協調。
至於每次循環進行中，他還是得協助團隊計畫、監控進度，並在每日的會議中確保團隊知道自己在幹嘛、沒有偏離方向，並在察覺萬一有人偏離方向時出來「撥亂反正」。 並把一些改善的流程、溝通方法記錄下來，確保團隊的效率與效能能隨著多次循環後能一直提升。 至於數據面，則得熟悉團隊的能力上限，並在每次循環的計畫會議中要定義工作上限時，能把資料提供給Product Owner。 避免Sprint Backlog中的內容太多或是太少。
光看這內容就會發現，這又是另一個在很多組織裏頭很難簡單落實的要求。 因為大部分組織還是有很深的部門籓籬，但一個要執行Scrum的組織，你必須讓部門變成專案的從屬結構，僅負責支援專案。 這時候Scrum Master才有辦法去為專案立刻爭取到所需的資源。 Scrum要把變更阻擋並引導到Product Owner這點，也是很多人不習慣做的事情。 但這可是Scrum模式要成功非常重要的一個關鍵。
Team
在這裡，Team指的則是剩下的所有人。 包含不同技術領域的團隊成員，或是技術主管帶領的工作人員都算。 而且他們通常是以整合的方式處理同一工作。
這方法中，團隊本身要擔負大半比例的管理工作。 在一般方法論中，技術人員通常是僅被PM指派工作，並被要求在一定的時間中完成。 但在Scrum中，主張要讓Team更高的自主性，並希望跨專業(Cross Discipline)的團隊能自發的根據Product Owner的需求來「設計與建構做事的方式」。
就這方法的概念是，團隊若能充分理解需求內容時，比較能根據彼此專業合作設計出對的做事方法。 此外也比較能對這工作有所熱情、以及Commitment。
也因為這概念，所以每個循環(Sprint)前，都要花最少四小時的時間，請Product Owner來說明需求的內容。 團隊再根據這內容規劃本次循環的Task(工作內容)，以及需要投入的時間。 等所有Team的成員都界定清楚本階段的工作後，這次的循環才正式開始。
而一旦循環開始後，大家就根據原本規劃的工作分派執行。 每天則另外要花約十五分鐘的時間「全員」聚在一起討論進度作微調；或是當有外部阻礙時，在這會議中告知阻礙讓Scrum Master去解決。
那這也是這方法要採行前另一個要思考的點。 這方法因為很重視團隊的自主管理能力( Self-organizing，以及Self-managing)。 這可不是口號喊喊就好。 而是真的很多部分得讓團隊須能合力規劃，並自行解決專案內部的問題。 所以若團隊實力差距太大，這方法未必會比聽命辦事的模式更有效率。
以上是這三個角色的基本責任定義。 下篇在來跟大家分享在這方法論下，整個專案執行流程的架構吧。
文前圖片取自於Page 45, Agile Game Development with Scrum
本站所有文章未經事先書面授權，請勿任意利用、引用、轉載。
