定義Scrum的角色
Scrum中不再有傳統意義上的產品經理、項目經理，而是使用了Product Owner、Scrum Master、Team和Stake holder這樣的新角色，當項目組是從傳統開發模式轉變過來的時候，我們需要重新定義這些新的角色。
團隊
這裏所有的團隊，是指Scrum中的團隊，而非整個遊戲項目組。在遊戲開發中推行Scrum時，團隊是人員結構中最大的改變。
對於傳統Scrum而言，團隊是一個跨職能團隊，分析設計人員、開發人員、測試人員一起組成了一個團隊，大家在弱化分工，每個人都參與設計、開發與測試中。之所以能夠實現這種跨職能的團隊，是因爲在傳統軟件開發中，我們只寫代碼，文字和美術圖片只不過是軟件的一個完全可以忽略的方面，客戶不會因爲文字優美，界面漂亮而認同一款軟件，他們要的是軟件功能。再看看傳統軟件團隊中的各種角色，都在和代碼直接打交道，分析、設計人員往往都是程序員出身，白盒測試人員本身也是要寫代碼的，這使得在傳統項目中所謂的分工是完全能被打破的。
對於遊戲團隊，尤其是大型網絡遊戲團隊，實現跨職能團隊有相當大的難度。遊戲公司大多采用矩陣式結構，按照職能，會分爲策劃、開發、美術、測試等部門，根據項目再從各個部門抽調人手形成項目組。策劃人員工作在文字上，美術人員工作在2D、3D圖像上，均不和代碼打交道，只有程序、測試人員，纔在代碼上工作。假象如果我們讓策劃、美工、程序、測試坐在一起，一同討論數值大小，腳本動作，一起些策劃案，編代碼，寫腳本，畫模型，想必是件很瘋狂至極的事情。大家都很希望能找來一大批又能策劃有能編碼還能畫畫的全才來開發遊戲，不過現實是一個也找不出來。
老紀也沒有找來這些全才，他的手下也是策劃人員、程序人員、美工人員和測試人員，矩陣式的組織結構使來自不同職能部門的人組成了一個項目組。老紀很想組成一個大範圍的跨職能的團隊，但是發現不大現實：策劃人員是需求提出者，更應該被歸爲Product Owner，美工團隊有點像內部外包，定期反饋完成的作品。能組成團隊的，就只有程序與測試人員了，於是老紀將所有的開發與測試人員組成了他的團隊。
這個團隊也可以是跨職能的，這裏的跨職能是一個小範圍的跨職能，是相對於傳統的開發方法而言的。在傳統的遊戲開發團隊中，每個程序都負責一個特定的功能模塊，如有人專門負責生活技能的代碼，有人專門負責聊天系統，大家都有明確的分工，不但程序如此，測試人員也是如此。對於Scrum的跨職能團隊而言，我們希望能夠打破程序、測試人員的分工，我們希望所有程序人員都能應對多個功能於模塊的代碼，測試人員也能瞭解多個模塊的業務邏輯，這樣，實際開發工作中，團隊成員能夠互相幫助，評估過程中，團隊成員也能各抒己見，加深大家對於功能的理解，提高團隊生產效率。
在很多遊戲公司中，測試人員被分爲兩類，一類是和程序人員坐在一起，進行單元測試的人員，一般我們稱爲程序測試，另一類則是在體驗服務器上進行功能、系統、壓力、集成測試的人員，我們一般稱爲系統測試人員；在組織團隊的時候一定要將這兩類測試人員均放入團隊中，共同作爲團隊的一部分。
老紀所在的遊戲公司，代表了絕大多數遊戲公司的組織架構情況，事實上，我們在幾乎所有的實施敏捷的遊戲公司和項目組中，都是用了和老紀相同的團隊定義。
Scrum Master
Scrum Master是Scrum項目中的靈魂人物，按照Scrum中的定義，Scrum Master不再是一個執行管理技能的領導，而是一個秩序維護者、教練以及團隊成員的第一助手。Scrum Master要爲團隊、Product Owner教授Scrum知識，維護Scrum秩序，必須要在整個項目組內有很高的威望，甚至要有能力調配測試、美工、策劃資源，在T公司中，老紀是一位資歷很深的項目經理，是項目組中的二號人物（一號人物是一名公司股東，並不過問項目具體事宜），因此由老紀來擔當Scrum Master的職位。
當團隊規模還很小的時候（項目初始階段，5人不到的時候），Scrum Master還會兼職做一些開發之類的事情，當團隊開始擴大到10人左右時，Scrum Master就要求爲全職了，要一心一意的來維護這個團隊。當團隊繼續擴大，超過10人以後，就要考慮分拆，使用Scrum of Scrum的管理形式；在傳統的Scrum定義中，Scrum of Scrum是Scrum Master的議事廳，不再有Scrum of Scrum的Scrum Master，但是在遊戲項目組中，我們必須要有一名能夠統管全局的Scrum Master，他需要協調其他部門的資源，能夠直接面對強勢的主策劃、製作人，告訴他們團隊應該怎麼做，不應該怎麼做；這個Scrum of Scrum Master的最終人員，還是落回了優秀的項目經理的頭上。
Scrum of Scrum 中，子團隊的項目成員在每個Sprint中都有可能發生一些變動，但是一定要保證子團隊中的Scrum Master不要經常發生變動，這樣對於保障團隊開發效率是極爲不利的。
Product Owner
傳統敏捷項目中，Product Owner大多是由原來的產品經理負責，也就是直接對產品負責的人來。Product Owner要負責維護Product Backlog，爲Product Backlog排序，爲團隊逐條講解Product Backlog，解答團隊的疑惑。
按照最簡單的映射關係來看，Product Owner應該非遊戲主策劃莫數，他直接對遊戲負責，總管遊戲需求。不過遊戲項目和傳統軟件項目差別很大，簡單的映射關係是沒法成立的。
傳統Scrum要求我們只能有一個Product Owner，對於傳統的不太大的敏捷項目來講，只有5-9名項目成員，User Story最多也不過百十餘條，1名Product Owner足以應付。但是在大型網絡遊戲開發中，當遊戲開發到後期時，動輒會有上千份策劃文檔，其中過百頁的文檔少說也有百餘份，如果將這些策劃文檔整爲User Story，會有幾千條，如果讓一個主策劃來維護這個海量的Product Backlog，恐怕所有的主策都會被嚇跑了吧。現實中的狀況是：策劃人員（包括主策在內），共同在維護龐大的策劃庫。
因此我們應當將全部策劃人員一同作爲Product Owner組，這個組內，每個策劃人員維護遊戲中的一部分功能的策劃案，主策劃作爲Product Owner組的總負責人。Product Owner組共同討論遊戲功能的分割，創建並維護遊戲Product Backlog，計劃會上，每個策劃分別講解他所負責的Backlog 條目，並在團隊開發過程中幫助團隊成員解答疑問。在Sprint結束後的評審會議中，全體策劃人員也都要參加評審，給出自己的評審意見。
雖然Product Owner的範圍方面我們做了很大的改變，但是對於Product Owner的職能、Product Owner應當遵守的紀律，我們沒有做任何的變動。對於Scrum而言，最大的風險就是我們實施了Scrum But。
Scrum of Scrums
隨着遊戲項目的進展，項目組會逐漸擴大，老紀所領導的項目組，最初只有10個人，5個策劃，4個程序，等到了遊戲內測階段，項目組已經發展爲90多人，近30名策劃，近40名程序與測試人員，20名美術人員和幾名產品組成員。
按照我們關於團隊的定義，老紀的開發團隊在後期已經達到了40人的規模，關於團隊的規模，傳統Scrum一直認爲5-9人是一個最佳範圍，團隊過小，管理成本會過高，團隊過大，則不利於團隊的溝通，降低團隊工作效率。在40人團隊規模下如果要繼續有效的使用Scrum方法，唯一的辦法就是分拆團隊，採用Scrum of Scrum的方法。
當開發團隊規模較小的時候，如不超過10個人，我們可以採用一個Scrum團隊的管理方式，項目經理即爲Scrum Master。如果團隊擴大到10人以上以後，那我們就不得不拆分團隊了。其實拆分團隊並不困難，當團隊擴大以後，自然就形成了一個分割，如某一些人專門負責技能與任務的開發，另一些人則專門負責副本的開發與維護，這樣我們就可以把開發內容有緊密關聯的團隊成員組成一組，人數控制在5-10人左右，在這個組內再任命一名技術、管理能力均衡的成員作爲這個小組的Scrum Master，管理所在的子團隊，同時聽命於項目經理。
當我們剛剛開始在T公司實施Scrum的時候，老紀手下只有4名程序員，他是Scrum Master。當團隊擴大到12個人的時候，老紀將團隊分拆爲兩個子團隊，一個團隊專門做幫會系統，4個固定人員，1個臨時幫忙的成員，老紀選擇了一名最早加入該項目組的成員作爲這個子團隊的Scrum Master。其他7個人組成另外一個子團隊，負責幫會系統以外的其他開發工作，依然由老紀作爲Scrum Master。
在團隊分拆過程中，最容易發生的問題是按照工作職能劃分子團隊，如：邏輯程序員一組，腳本程序員一組，測試人員一組；這是萬萬要不得的，我們費盡千辛萬苦才淡化了團隊分工，形成了跨職能團隊，如果以這樣的錯誤方式進行的分組，我們的工作豈不是全都白費了？
隨着老紀的團隊擴大和項目的進展，老紀後來又對團隊作了幾次分拆與合併。團隊的重組在每個Sprint之間進行，每次重組都是和團隊成員協商後的結果，子團隊的Scrum Master也基本沒有更換過。Scrum of Scrum的團隊形式從項目的第4個月開始持續到現在已經1年多了，運轉非常良好。
策劃人員的數量在遊戲團隊中佔有了相當大的比重，當團隊擴大時，策劃人員必然也會要進行分組。傳統策劃分組是按照遊戲功能模塊進行分組，如會被分爲技能組、副本組、陣營組、任務組等，每個組會有一個組長，負責管理本組工作，並向主策劃彙報工作進度。當我們採用了Scrum方法後，策劃人員在決定分組的時候，應當和Scrum團隊進行溝通，尤其在團隊實行Scrum of Scrum之後，策劃人員的分組，應當儘可能和團隊的分組保持一致，一組策劃人員最好能夠和一個Scrum子團隊對應，並形成一個相對較穩定的Scrum組合，有利於提高團隊工作效率。