前幾天收到email 得知在加拿大受訓時候的instructor 被scrumwork layoff了。
看起來最近的金融危機對整個行業都產生了影響。
突然想到之前在gameres看到的一篇文章 再找出來發在這裏 算是留做幾年 也是喚起自己對這一管理模式的一種更深層次的思考 － scurm在中國的生存與發展
原文發表於08年7月 遊戲創造
http://bbs.gameres.com/showthread.asp?postid=689437
Scrum， 這隻敏捷家族中的生力軍，現在正被越來越多的人認識並且接受。在遊戲開發領域中，近年來國內的許多企業也開始嘗試採用Scrum進行遊戲開發。Scrum 這種強調頻繁交付緊密溝通的開發方式似乎證明了比它的前輩們更適合遊戲開發領域。但正如人月神話中的那句老話“No silver bullet”。那麼對於如今國內佔主流的大型多人在線遊戲（MMO）開發領域而言，Scrum是否就是那枚傳說中的銀彈，一經發射，就能讓擺在你面前的 所有問題都瞬間灰飛煙滅？我們在具體的執行層面又應該怎麼去控制和管理它呢？筆者希望以下的文字能幫助你解答以上兩個問題。
Scrum與傳統方式之間的不同在 使用Scrum之前，公司或者開發團隊多多少少已經有一些成型並且大家都已經習慣的開發模式。打個比方說，策劃先行，然後召集大家討論策劃案，之後得出程 序和美術的工作量再定義出里程碑擬訂好開發計劃，然後大家開始正式分頭動工。在這個開發流程中，開發人員面臨的最大困難是策劃案也就是需求的變化量非常 大，並且這種變更，很大一部分情況可能是直到里程碑快結束的時候，大家才一起意識到有些功能壓根就無法實現或者勉強實現的效果並不理想。這時似乎只剩下修 改策劃案這一條路。於是大家對於無論如何嚴格的審覈策劃案，到中途總是會以這樣那樣的理由變更的情況已經習以爲常。因爲需求變更而導致產品推出時間可能一 推再推，以至於最後不得不砍掉一些功能才能確保產品在可以接受的時間之內被推出。
儘管傳統的開發方式可能有些地方老是出問題，但大多數情況 下大家也會比較傾向於下次注意點，而不是嘗試一套新的開發方法。在MMO的開發模式的選擇上，Scrum在許多地方的確可以解決傳統模式所遇到的問題，比 如Scrum能在擁抱變化這一點上極大的幫助開發者。類似這樣的優點，在Scrum的擁護派看來，可以列出好幾頁來。但是，要說服一個原有的團隊選擇一種 新的開發模式來代替大家已經熟悉的方式，光列舉優點是不夠的，我們也需要直面Scrum與現有模式的其他差別，有些甚至是Scrum的劣勢。
1． 每次提交可運行的版本Scrum 的精髓在於擁抱變化，並強調通過頻繁的交付來獲得及時的反饋，以便於儘可能快的調整不合理的需求。但對於某些大型MMO而言，比如MMORPG，系統的復 雜度往往超出我們的想象。如果沒有一款已經使用過的引擎，光是前期對低層技術的開發就是一個漫長的過程，如果採取Scrum的方式，要求每一小段時間提供 一個可運行的版本無疑是一個噩夢。而對於同時進行的策劃案的撰寫，要求提供一個反應策劃內容的版本更是困難。Scrum在這個階段如何開展，是需要克服的 一個問題。
2． Sprint的劃分
相對於傳統的基於里程碑的開發，Scrum要求劃分出一個個相對較短的Sprint。並且每個
Sprint需要有可以提交的版本，以及一個比較明確的可以體驗的目標。而在MMO的開發中許多工作，比如系統架構設計，數據庫設計，美術概念討論等都很
難在Sprint中體現出來，也就無法通過Sprint
Review的形式獲得反饋。但是這些東西又跟所有的人的工作息息相關。Scrum如何在能夠保持緊密溝通的同時，對類似的相對獨立的部分也照顧周全？
3． Scrum的管理
Scrum
是一個強調自我管理的開發方式。無論是Stand Up Meeting還是Sprint
Planning的時候都要求少干涉多聆聽。對於項目經理來說，某些時候參與感很差，總是好像找不到自己在團隊中合適的位置。但是項目經理又不得不對進度
負責，面對各個並行的小組，每天都可能有大量新的task提出，又有大量task被否決，如果你這個時候去問項目經理“我們到底能不能按時完成，如果推
遲，那還需要多久”這樣的問題的話，他也許只能對你搖搖頭。我們在使用Scrum的時候，進度管理上的缺失也是我們需要直接面對的問題。
類似的問題，在我們推廣Scrum的時候可能會遇到很多。爲什麼會有如此的問題歸納一下，原因可能如下：
1． Scrum最早來自於軟件工程，雖然現在擴展到開發的各個方面，由於其自身的限制性，註定要面臨許多困難。（筆者曾經聽說過某公司號稱用Scrum進行管理，要求銷售，HR部門都實行Scrum方式，很難想象這是一種怎麼樣的Scrum。）
2． MMO開發本身結合了跨平臺，分佈式，週期長，變動大等多個開發難題， Scrum能夠很好的解決一些問題，但對需要長期規劃的問題明顯缺乏控制力。
融合：和其光 避其塵
在
筆者看來，Scrum是一種優秀的開發方法，許多特徵的確證明了它比它的前輩們更好的解決了遊戲開發中所遇到的諸多問題。可是，如同它的前輩一
樣，Scrum並不是遊戲開發中的那顆Sliver
Bullet，再次應徵了Brooks大師所言。所幸的是，我們可以使用Scrum與傳統開發方式“混血”式執行的辦法，根據自身情況，靈活的選擇有利的
方面執行，對不適應的地方進行改進，從而能最大限度的在MMO遊戲的開發中發揮出Scrum的威力。
筆者有幸在參與的一些項目中使用過 Scrum方法，同樣也經歷了Scrum與本土MMO開發結合時候遭遇的種種尷尬。筆者認爲，Scrum對於MMO遊戲的開發，有其利也有其弊，對於整體 進度的把握以及對於文檔工作的控制Scrum做得並不是十分到位。對於任何一種開發方法論而言，執行團隊都需要從自身實際的條件出發，選擇性的使用。最怕 的是盲目執行，暴力式地推行，而其他軟件的工作卻不跟上，執行的團隊並不明其所以，最後可能搞得人人談敏捷而色變，失敗當然是一個必然的結果。筆者始終認 爲，工具，方法始終是死的，如何使用纔是真正出學問的地方，只有從自己實際出發，冷靜分析，在合適的地方用合適的工具，才能做到庖丁解牛，遊刃有餘。
那麼Scrum應該如何結合傳統的MMO開發方式呢？我們從項目開發的各個階段來一一分析，如何讓Scrum發揮自己的威力。
項目前期項 目前期我們面臨的問題有哪些？首先是產品尚未成型，團隊也許對將要製作的產品並沒有一個十分清晰的概念，更談不上對項目規模的預估。其次有一大堆技術性的 難題擺在團隊面前。這些難題能否解決，如何解決，都勢必會對策劃案的成型有決定性的影響。這個時候，我們可以分兩頭採取不同的開發模式。
對 於將面對的技術難題，這個時候目標明確，團隊規模較小。比較適合採用Scrum的形式一一攻克這些問題。我們可以把大家公認會遇到的難題列舉出來，通過 Scrum Planning的形式分解成一個個User Story再劃定各個問題的優先級和互相的依賴關係，然後分別組建Scrum團隊。這個時候的目標很明確，即得到這些難題的解決方案。我們希望在這個階段 結束的時候，程序對所要面對的技術問題心中有數，策劃也對哪些能做哪些不能做有一個清楚的認識。同時我們還希望對一些我們必須要克服的東西，在這個階段已 經能產生一些行之有效的工作流程。
對於Scrum小組的組建，這個階段我們可以以程序爲主，策劃和美術作爲某些User Story的Customer，負責對程序工作成果的審查。爲避免過早的陷入需求更改的陷阱，這個時候策劃除了驗收成果之外，不應過多的干涉程序實現的方 法，而僅僅在設計User Story的時候提出自己的意見（事實上很多User Story應該由策劃和美術直接提出）。在Sprint的劃分上，我們可以以2～4周的標準劃分。儘量將這個階段控制在2～4個Sprint之內（這取決 於團隊的大小和技術基礎）。對於一些經過驗證存在困難的User Story可以在每個Sprint Review結束後的Planning Meeting上經大家討論做少許更改，讓下一個Sprint向更接近我們的目標（切實可行的解決方案）的方向上前進。對於Scrum的範圍，筆者建議盡 量不涉及高耦合的工作，將涉及多個方面的User Story拆分成相對獨立的部分再分頭進行。舉個例子來說，可以將服務器端和客戶端的技術難題分開進行，對於涉及服務器端和客戶端交互的功能再單獨提出來 作爲一個Scrum，儘量保證工作的粒度比較小，減少互相依賴的關係。我們的首要目標是證明技術可行性，這對整個流程的開展有一定的好處。
對 於策劃案以及美術風格的概念設計，這個時候則採取較爲傳統的方式，由策劃和美術師內部產生。策劃在對程序的Scrum小組提出User Story的同時即提出了自己的疑問，在程序執行Sprint的過程中獲得對自己提出問題的反饋，進而決定自己的策劃案如何撰寫。美術則在這個時候確定美 術風格，以及在與程序Scrum小組合作的過程中確定某些美術工作的工作流程。筆者不建議這個時候就加入程序對策劃案進行討論，這也許和某些團隊採取的方 式不同。這種方式對策劃和美術的要求較高，既需要向程序的Scrum小組提出User Story，並從審查中獲得反饋；也需要保持設計工作的相對獨立，做好策劃案的前期工作。這需要策劃或美術在前期就對中期可能發生的問題有所預見，向程序 有針對性的提出需要測試的地方而不是等待程序來告訴你不可行。如果這個時候能有富有經驗的產品經理或者製作人來負責這兩方面的協調工作，也是一個確保這個 過程可以順利進行的有效因素。對於程序美術在前期就加入討論，筆者是持保留意見的。比如曾經經歷過的一個項目就因爲太早凍結策劃案以至於美術和程序花了幾 天來討論每個UI元素的具體座標是多少，但最後卻不得不尷尬的面臨因爲用戶體驗不友好而更改UI方案的情況。
在這個階段結束的時候，我們應 該得到一個策劃案的初稿，起碼完成了整個系統以及世界的架構，可以估計出項目將來在程序，美術和策劃工作上的規模。還應該有幾套行之有效的工作流程，能根 據項目的預計規模估計出將要投入的人力和項目需要進行的時間，以便於之後的市場等多項工作的計劃和開展。接着，我們就便可以投入更多資源進入正式開發的階 段。
項目中期在MMO項目中期，我們面對的主要問題是對整體進度的把握，確保能按時推出我們需要的版本。其中面臨最主要的難 題就是對需求變更的控制。這個方面Scrum有其決定性的優勢，但如何在高度擁抱變化的同時又不失對進度的把握是Scrum在這個階段所要面臨的問題。筆 者建議這個時候需要根據團隊對Scrum的熟悉程度來選擇不同的解決辦法，分別採取以Scrum方式爲主導傳統方式爲輔的方式，或者反之。
對 於一個熟悉Scrum的團隊而言，筆者的建議是在正式開發之前，整個團隊坐在一起，討論策劃案。將策劃案中劃分的各種系統分解爲不同階段的User Story，再通過團隊之間的討論以及各組之間的工作配合需要制定出優先級。現在我們有了一大堆由策劃案分解出來的User Story，這些User Story有一定的依賴關係和不同的優先級，這時候根據我們的需要將這些User Story組合成不同的Sprint，再視這些Sprint的目標和內容組合成不同組合，每個組合我們可以視之爲一個里程碑。如果你的項目的時間預算非常 有限，你可能會傾向於將一些不是很重要但如果不完成其他部門就無法開展工作的User Story先行製作；如果你的時間充裕，你則可能更傾向於先有一個完備的系統設計以及一個方便擴充的靈活架構，讓其他部門暫時等待或者做其他的事情。總 之，這一切取決於項目具體的需要和團隊資源，並沒有孰是孰非之分。
由User Story來構建里程碑這對團隊的Scrum能力而言是一個考驗，需要團隊對User Story乃至Sprint的劃分有一定經驗，並且能夠預見整個過程中可能面臨的風險。選擇合適，制定好的，可實現的User Story可以規避很多由於後期Sprint變更時候帶來的連鎖反應。這也是爲什麼筆者建議有一定Scrum經驗的團隊選用該方法的原因。
對 於初次嘗試Scrum的團隊，可以嘗試採取相對保守的方法。通過傳統的方式對策劃案進行技術評估後，劃分出里程碑，然後根據每個里程碑的目標制定User Story，再劃分Sprint。這在一定程度上降低了對User Story制定上的要求。同時在每個Sprint結束的時候根據Sprint完成情況結合里程碑的目標對User Story進行修正。聽起來似乎和上個方式大同小異，但執行過程中可以省略對Sprint篩選和組合的過程，可以說目標更加明確，對嘗試達成這個目標的團 隊來說也相對輕鬆一些。
無論採取什麼樣的方式，對於進度的管理上都是需要按照傳統的方式劃分里程碑。這可以方便我們把握項目整體進度,防止 由於Sprint過多並且更改過快以至對項目整體進度沒有概念。每個里程碑就像一扇扇保險門，明確里程碑所要達到的目的以後就不再輕易變更，嚴格控制好裏 程碑中間Sprint的變更範圍。從某種意義上講，這種互相結合的方式能夠有效降低項目中期由於變更過多而造成進度失控的風險。
這個階段的 Scrum團隊的組建也不同於項目前期。這時一個Scrum團隊是一個包含程序，美術，策劃乃至市場人員的複合小組。這個階段中的Sprint的之間的變 更乃至小組成員的身份的變化也會更加複雜。同一個Sprint中一個User Story的執行者可能是另一個User Story的Customer，需要在開發過程中保持高效的溝通。小組成員也並不是固定不變，在一個Sprint結束之後根據下個Sprint的目標可能 組合成不同的小組。比如這2周做NPC交易的小組成員，可能下個Sprint會和其他人組成擺攤系統的Scrum小組。重要的是我們作爲一個整體的團隊如 何達成每個Sprint的目標，而不是保持單個Scrum小組的獨立性，畢竟靈活性也是Scrum的一大優勢。
這是一個頻繁迭代的階段，也 是遊戲內容不斷增加和修正的過程，在每個Sprint結束的時候，我們都應該得到一個可以運行的版本用於衡量該Sprint的目標是否達到。策劃要在每個 Sprint review之後總結更正自己的設計，美術也隨着一個個Sprint的完成，看到自己的作品一批批導入到遊戲中的效果。所有這些都需要建立在團隊成員之間 高效的溝通，以及默契的合作之上。這也對團隊的自我管理能力也提出考驗。
在項目中後期，我們會面對成批從QA部門反饋的bug以及爲配合市 場活動而臨時增加的開發需求。Scrum的靈活性在這個時候可以得到進一步的發揮，隨着投入資源的增多，我們可以對這些工作內容建立單獨的Scrum團 隊，用於解決這些瑣碎但龐大的新增需求。別忘了，Scrum是最善於解決目標相對明確的短週期需求。
隨着Sprint的一個個進行，里程碑的一個個完成，我們終於走到項目交付和維護的時候，這個時候我們面對的是單機遊戲不曾經歷的維護和運營階段。
項目後期一 個MMO的開發並不隨着產品發行的結束而結束，無休止的維護和資料片的推出是團隊必須要面對的現實。同時團隊人員的更迭也需要在這個時候開始進行。我們慢 慢要把原來開發團隊的部分人員抽離出來，以便於開始新的項目。對現有項目的維護和對新加入人員的培訓是我們在項目後期需要面對的主要問題。
項 目後期的工作，筆者看來分爲兩大類，一是原有系統的BUG，運營商的2次開發需求以及來自於市場或者策劃方面的活動需求，二是並行的資料片開發。先說資料 片開發，開發量和內容都基本上相當於項目中期的一個或兩個里程碑，對於Scrum的處理方式可以按照項目開發中期的方式通過複合的Scrum團隊來處理。 通常會在版本控制系統中建立一個平行的分支進行開發，值得注意的是需要隨時準備集成對原有版本的改動。對於第一類問題，則通常不會涉及太多原有系統的改 動，可以單獨建立程序或者美術+程序的Scrum小組進行有針對性的開發。通常這個時候，進度已經不會再成爲壓力，對積累了開發階段Scrum經驗的團隊 來說，不會有太大問題。值得一說的是如果不是自主營運，對來自運營方的需求如果要對方來適應Scrum的開發模式可能有點強人所難。好消息是來自運營方的 需求並不會像我們可愛的策劃案一樣頻繁變更。Scrum小組定義好一個接口人以後可以仍然按照自己習慣的方式進行開發，把哪些惱人的外部溝通工作扔給接口 人吧，這樣可以在一定程度上降低我們溝通的成本。
Scrum的過程控制工具在使用Scrum的過程中，尤其是週期比較長的項目，對於負責項目進度控制的人來說，整體進度把握和對基礎架構工作的控制都是比較頭痛的問題。這時，有許多工具可以幫助我們對目前的風險和進度有一個清楚的認知。
可交付物件列表（Deliverable Check List）不 同於其他採取Scrum方式進行開發的軟件項目，MMO的開發過程中，文檔還是扮演着相當重要的角色。一個MMO可能產生上萬甚至百萬字的文檔工作量，我 們既需要保證開發的高速和靈活，也要保證這些文檔的創建和維護。在項目的各個階段我們需要有一個或者多個可交付物件列表。這個列表可以方便我們跟蹤策劃 案，美術工作量，以及諸多程序設計的文檔的製作情況。
列表中的每一項都是一個可提交的物件，每個物件都需要設定相關的負責人，審批人以及預 計完成時間。這種列表是傳統開發方式的產物，然後在Scrum進行的過程中，這些物件可以作爲一個個User Story分佈在各個階段的Sprint中，也可以獨立在Scrum之外。通常這些文檔可以作爲某個階段結束的標誌，然後再以這些文檔爲基礎來做下個 Sprint的Planning。通過維護這樣的一個列表，我們可以對一定範圍內的整體工作量有所控制，能夠彌補原本Scrum在這點上的不足。
每天編譯 （Daily Build）存 在着多個並行的Scrum小組就意味着會可能同時存在多個不同的版本。前面建議大家在Scrum過程中儘量將不同Scrum小組目標的耦合度降低正是爲了 減少系統集成的時間。有不少團隊採取分頭開發，然後在一個約定的時間統一進行系統集成的辦法。然而筆者並不建議採用這種方式，主要原因是隨着分頭開發的持 續，各個小組之間並不清楚對方在做什麼，代碼上產生的差異會累積下來。等到做系統集成的時候，有時候會被迫面對二者只能取其一或者又要花費大量的時間來修 改已經完成的系統的尷尬情況。這個時候，建立一套每天自動編譯最新版本的系統可以幫助你化解這個方面的危機。
這個系統每天會從版本控制系統 中更新最新的代碼來編譯一個可運行的版本，並自動做一些簡單的系統測試工作。這裏的測試工作相當簡單，往往只要能保證啓動程序或者連上服務器端這樣的基本 功能。當編譯出錯或者系統測試無法通過的時候，該系統能夠通知相關人員，從而迫使程序員在上傳代碼的時候做好merge工作。爲了合併好代碼，不同的 Scrum小組之間也需要經常溝通，以瞭解對方的工作進展，幫助程序員養成符合Scrum精神的工作習慣。
向下燃燒進度表（Burn down Chart）對 於Sprint與Sprint之間，乃至里程碑與里程碑之間的完成情況，通過Burn down chart這個工具我們可以隨時瞭解任務的完成情況以及和計劃的偏差。同時Burn down chart也能很好的反映在項目進行過程之中，user story的變更情況。
拿下面的一個burn down chart來說。
這
是一個持續了3周的sprint，這個表反應的是在這個sprint過程中所有任務每天的完成情況。這裏每天的完成百分比是由從第二天在每日起立會議以後
收集到的任務完成情況決定的。我們可以看到在4-28和5-2這兩天的計劃曲線有一個起伏，這是由於當天有新增加的任務，這對我們Sprint
review的時候評估這個Sprint的完成情況可以起到參考作用。
其他的比如告示板，索引卡，Sprint Planning等工具和方法，一般的Scrum的書籍都有介紹，筆者在這裏就不再一一列舉。筆者主要列舉的是基於MMO的Scrum開發過程各個層面上的簡單進度控制工具，以幫助團隊及早發現風險，並得出應對之策。
推廣Scrum過程中要注意的問題
向一個已經有過開發經驗團隊推廣Scrum的方式並不是一件輕鬆的事情。沒注意好的話，往往最後流於形勢，不僅團隊的積極性沒有調動起來，甚至會讓人產生反感。
環境的營造使 用一個類似Scrum這樣自組織式的開發方式的時候，需要特別注意的是對於整個Scrum環境的營造。尤其不要流於形式，不然就真的是費力不討好的事情 了。筆者遇到的一個很典型的例子是：Sprint Review之前，程序的版本並沒有集成編譯過。於是爲了準備Review中需要演示的東西，花了大半天的時間來合併代碼並修改，演示結果可想一般。更糟 糕的是，在user story被否決了以後，團隊的積極性受到打擊，對Scrum也頗有微詞。
讓團隊真正理解什麼是Scrum並不是簡單 跟大家宣讀一下章程這麼簡單。持續的培訓和心得交流是一個比較好的辦法，有助於讓團隊瞭解每一步的意義和目的。同時還要鼓勵大家多溝通交流，在 Planning的時候提出自己的想法，多瞭解同伴的工作情況。不能再像原來一樣各家自掃門前雪。
團隊適應能力談團隊素質是 一個比較尷尬的問題，中國的遊戲業畢竟還非常年輕。筆者的一個朋友曾經跟筆者抱怨過，原來嘗試過Scrum方法，但試行了半年之後就放棄了。理由是 Scrum太講究團隊的自我管理能力，他的團隊並不能很好的適應這種自我管理的方式，而他的團隊中還不乏有多年經驗的開發人員。筆者的觀點則是團隊的適應 能力跟團隊成員的態度有關。我們當然不能苛求所有的團隊成員都有多年的開放經驗，尤其是項目失敗經驗，以便於他們理解Scrum可以幫他們解決多少他們曾 經遇到過的問題。同樣，就算有多年經驗，抱着原來的方式不放，覺得這些新東西只是花招式，還不如自己的老三套來得實在也要不得。
團隊是否能 很好的適應Scrum方法，跟團隊是否抱着積極開明的學習的態度有關。這在一定程度上也是依賴於團隊內部的環境建設。而團隊成員中參差不齊的素質筆者認爲 並不是太大的問題，我們並不需要所有人都能夠對任務的規劃和分解深刻把握，團隊成員在這個高度強調溝通的環境中反而成長會更爲迅速。
多次交付VS多次迭代多 次迭代並不等於多次交付，這是Scrum常有的一個誤區。在每個Sprint開始的時候，我們都必須要明確這個Sprint結束的時候我們需要 Review的是哪些東西。很多時候，如果一個Scrum開展不是很順利，在Sprint Review的時候我們常常會聽到這樣的理由，“因爲某些原因，這個功能我沒有辦法展示給你，但是這個功能是有了的，我只需要改動小小一點東西就可以了。 ”或者是“這個部分與另一個系統相關，我代碼已經寫好了，但我要一起改好了你纔可以看到。”如果放任的話，這些理由到後期會氾濫成災。我們所能做的，除了 拒絕通過這些相關的User Story之外，在每個Sprint開始的時候還應該幫助團隊瞭解到我們需要在Sprint Review上看到什麼東西。強調我們重視的是可交付的版本，而不是一個口頭上的功能增加。
有些時候這也取決於我們的User Story是否範圍太大太空以至於無法實現。這也對要求我們提出更具體可實現的User Story，否則就需要及時拒絕它或者再細化。
結隊是 否結隊編程這個問題，筆者是持保留意見的。曾經有過一段不太愉快的結隊經歷，雖然不是隨時“面向顯示器編程”但相當時候兩個人坐在一起寫一段代碼是常有的 事情。個人認爲在兩人沒有達到足夠默契的程度的話，還是不要輕易嘗試結隊開發。而對於Scrum來說，除了結隊，也可以通過buddy check（在提交代碼前交由另一人檢查提交）來確保互相對工作情況的瞭解。同時前面提到的每天Merge同伴的代碼也是一個幫助團隊成員互相瞭解工作情 況的好機會。
最後Scrum畢竟是個新東東，大家還正從適應中慢慢了解和熟悉。但從筆者看來，它的確是目前最適合遊戲開發的 方法論之一。除了能夠從容應對需求的變化之外，他鼓勵溝通的方式也能一定程度上激發團隊的創造力，促進團隊內氣氛。在面對中國式MMO的開發上，靈活的把 Scrum和傳統方式相結合，通過不同的工具進行控制，能很好的彌補原來Scrum對長期進度缺乏控制，以及文檔管理缺失的一些劣勢，從而發揮其在需求管 理，針對性解決問題上的優勢，更好的解決我們在開發過程中可能會遇到的問題。