網絡遊戲開發中的需求變更管理

寫道 對于軟體開發領域來講，變更始終是最讓人頭疼的東西，大家對于如何消除變更，如何控制變更，提出了很多很多的理論與方法。無奈變更這東西就像是個打不死的小強，倔強的與軟體開發一起生存了半個多世紀，到了現如今的網絡時代，不但沒有被壓制住，反倒更加猖獗了。那麼在小強最繁榮的遊戲圈裡面，大家是如何面對變更的呢？

　　整體而言，遊戲行業（尤其是網絡遊戲行業）對于變更是又愛又恨的，很糾結，很痛苦。是以在網絡遊戲行業中，變更管理也不是簡單的放任或者控制，而是要權衡各方面的因素，讓變與不變維持在一個平衡點上。一句話概括其管理方式就是：胡蘿蔔+大棒政策。

　　遊戲公司中對于變更的兩種意見

　　主變派：策劃、制作人；觀點：變化乃遊戲生存之本

　　變化是網絡遊戲生存之根本，大家評判一個網絡遊戲發展勢頭的最重要的标準有兩個：線上人數與更新頻率。一個更新頻率趨于變緩的遊戲，基本上可以說是快進入消亡期了。追逐玩家們不斷變化的口味，引領遊戲圈的新潮流，創造更高的吸金效率，這些都是以不斷的變化為基礎的。

　　是以，遊戲必須變。不讓遊戲發生變化，就等于是要了遊戲的命。就算是限制變更，也相當于扼住了遊戲賴以生存的咽喉。

　　不變派：開發團隊，項目經理；觀點：變化是浪費，是隐患

　　說到底，遊戲還是個軟體，單機遊戲也好，網絡遊戲也好，無非都是運作在計算機上的軟體。變更對于軟體開發而言，災難性的，這一點所有軟體開發人員都深有體會，變更會導緻大量的重複工作，嚴重影響開發進度；會對已完成的所有工作産生沖擊與影響，帶來更多的不可預期的Bug；沒有被良好重新設計的變更，甚至會直接威脅到軟體構架的穩定性，為将來埋下極大的隐患，等等。這些軟體本身的問題，同樣也适用于遊戲開發。

　　更要命的是，頻繁的變更會讓開發團隊感到強烈的挫敗感，自己辛辛苦苦做好的東西，沒過幾天就被徹底改掉了，感覺自己就像是做了很多沒有用的東西一樣，長此以往，開發團隊将會士氣受挫，導緻開發效率低下。

　　看來沖突是不可避免了。那麼到底聽誰的呢？聽策劃的，還是聽開發的？按照大自然物競天擇的自然規律來判斷的話：誰強，聽誰的。

　　誰更強？策劃，還是程式？如果我在這裡挖個坑，蓋個樓的話，邀請大家來評價一下的話，我相信會相當的火爆。

　　實施證明，策劃與程式，都很重要。

　　變更的分類，哪些可以變？哪些不能變？

　　如果我們根據變更是否會對開發工作産生影響來對遊戲需求變更進行分類，我們可以整體上分為兩種變更：1.對目前的遊戲開發工作産生直接影響；2.不會對目前的遊戲開發工作産生直接影響。

　　目前的工作，是指正在開發、測試、美術人員手上處理，或者進入到目前疊代周期内待處理的工作。發生直接影響，則是指會打斷目前正在進行的開發工作，比如一個遊戲需求：玩家自定義聊天頻道功能，現在這個需求已經到了程式手中，開始編寫代碼了，這時候如過策劃人員發起變更，就會對目前工作産生直接的影響。而如是另一種情況：這個需求目前還在策劃階段，還沒有送到程式員與美術人員的手中，這時候策劃人員發起需求變更，不會對目前的開發任務産生直接影響，因為現在還根本沒有人在開發這個功能。

　　如果我們仔細分析一下程式人員反對變更的理由的話，我們會發現，其實程式人員僅僅是反對會産生直接影響的變更，而對于那些不會産生直接影響的變更，則不是很反對。那些不産生直接影響的變更，雖然也會對現有的工作産生一些間接的影響，但是影響不會很大，這個問題我們會在後面來讨論。

　　胡蘿蔔+大棒

　　基于上面提到的變更的分類方法，我們可以得到這樣一個變更管理的方法：

　　當一個需求（或者策劃案）還處在策劃階段，還沒有被送去開發與實作的時候，我們允許這個需求發生改變，甚至允許它發生任何的改變，沒有任何限制。而一旦這個需求被送去開發與實作了，那麼我們将不再允許這個需求發生任何改變，需求與設計将會被鎖定，開發人員将會按照鎖定的版本進行開發。

　　如果在開發過程中，策劃人員實在忍不住要提出變更，那麼他僅有兩個選擇：

　　1. 要求項目經理徹底中斷掉該需求目前的開發工作，将該需求從目前的開發清單中取消，待其将需求變更修改好後，再重新納入到下一輪開發計劃中；

　　2. 等待已經送交開發的需求開發完成，在已經完成的基礎上提出修改（作為一個新需求）并納入到下一輪的開發計劃中。

　　當一個需求被完成後，如果策劃人員需要對已經完成的内容進行變更，那麼他需要提出一個新需求，就叫做“對自定義聊天頻道修改”，将這個需求納入到需求庫中，并要求項目經理納入到接下來的開發周期中，作為一個新的開發任務來處理。

　　那麼以上的假設是否可行呢？有沒有人真的這麼實踐過呢？答案是肯定的，靈活開發方法論（不論是Scrum與XP）都是在以這種方法在管理需求變更，實踐的結果也是相當不錯的；另外，據我接觸的遊戲公司中，也有一些公司在采用類似的方法來管理變更（金山的一些項目組就是這麼做的，效果很好）。如果想更多的了解靈活式變更管理，可以參考Ken Schwaber伯伯的書：《Scrum靈活項目管理》（Agile Project Management With Scrum）

　　以上的做法，基本上滿足了策劃與程式的不同需求：策劃需要變更，開發不需要變更。開發人員應該對這個方法很滿意，既然變化是勢不可擋的，但是隻要不會直接影響目前工作，也是完全可以接受的；但是策劃人員心裡還是有一絲不爽：在漫長的開發周期内不能變更，是否太不人道了？

　　應用正确的開發模型

　　網絡遊戲開發應該是有周期性的，短疊代周期的增量式開發是比較好的開發模型。瀑布模型肯定是行不通的，如果還有公司在用瀑布模型開發網絡遊戲，唉，隻能默默的祝願他們一路走好了。長周期的疊代（半年一個周期）也是行不通的，這倒不是這種方法本身有什麼問題，而是太長的疊代對于這個快速變化的花花世界來說，太痛苦了。

　　但是在我們訪談記錄中，卻發現很多遊戲公司居然沒有任何開發模型，完全是一種混沌的開發方法，買來一個現成的遊戲引擎，想到什麼就開發什麼，感覺做的差不多了就打個包上線，沒采用任何開發模型，沒有什麼明确的開發周期，一切都是憑着感覺來。這是一個很危險的事情，很多這樣的公司，在遊戲上線以後，會發現這個遊戲制作工作徹底陷入了一團糟的境地，任何局域性方法都無法提供有效的幫助，最終公司進入一個死循環，決的辦法也變得很殘忍：要麼死掉，要麼徹底改革。

　　任何的針對具體軟體開發管理問題的解決辦法，都是要在軟體開發模型的大架構下才能起效果的。我們不可能把瀑布模型中制定計劃的方法用在靈活開發模型下，我們也不能把打牌估算的方式用在瀑布模型中，因為這些具體方法都是在具體的開發模型的架構下，才具備了生存的條件。就像生态系統一樣，熱帶雨林裡的鳄魚，放到沙漠裡面，肯定活不下去的。是以如果一個遊戲公司連基本的開發模型都沒有引入的話，那麼就不要考慮變更怎麼管理了；就像在真空中任何生物都無法生存一樣，在沒有開發模型的環境中，任何開發管理方法也都無法取得效果。

　　是以，上文提到的這種這種需求（策劃）變更管理方法，是要在靈活開發的大環境下，才能夠起作用的，在瀑布、長周期的疊代式開發模型中，都不會有啥正面作用。

　　疊代周期的選擇

　　一般的共識是這樣的：相對較長的Sprint疊代周期，能夠有效的提高開發效率。因為一個Sprint周期中，有些工作是不能被省略的，如Backlog的整理、估算、計劃會、評審會與反思會、代碼內建、測試、打包等，這些活動一般都要占用不少的時間，越長的Sprint周期，這些活動所占用的時間比例會越少，為開發人員留下的整塊開發時間就越多，工作效率也越高。

　　而Sprint周期越短，對于需求變化的響應速度就越快。人們對于未來變化的把握能力其實很弱，越短的時間，把握越強，考慮的也越詳細，太長時間以後的事情（如2個月以後），則基本沒有什麼把握能力了。

　　Sprint周期的選擇，就是開發效率與響應速度之間的一個平衡。

　　一般在開發期的遊戲，會選擇相對較長的Sprint周期，如1-2個月左右，這時候策劃相對比較明确，還沒有引入玩家與營運回報，需求變更相對較少，選擇相對較長的開發周期能夠保證開發期的遊戲開發效率，争取盡早達到上線标準。這時候也希望策劃團隊能夠盡可能減少不确定的變更，如果一個功能或玩法沒法确認真的比改變前更好，那麼就不要貿然提出改動，等到上線之後聽到玩家的回報後再提出，能節省不少工作量。

　　而從遊戲上線封測開始，Sprint周期就開始逐漸縮短，以适應逐漸增多的Bug、調整與變更，在遊戲正式營運後，一般都會将Sprint周期控制在1-3周左右，一般都是與遊戲的更新周期保持同步。從管理的角度來說，為了适應更短的Sprint周期，很多管理上的規章與流程也要随之相應的簡化，以适應高相應速度的要求。

　　産生間接影響的變更如何應對

　　有一些變更雖然不會對目前的開發工作産生任何影響，但是卻會在将來對開發工作産生一定的影響，如一個變更會導緻我們對目前的遊戲構架進行調整，那麼這個變更将會在未來産生相當大的工作量。那麼我們是否在目前的工作中考慮這些存在着潛在影響的變更呢？