天津網(wǎng)站制作/辦公軟件

　　整體而言，游戲行業(yè)（尤其是網(wǎng)絡(luò)游戲行業(yè)）對于變更是又愛又恨的，很糾結(jié)，很痛苦。因此在網(wǎng)絡(luò)游戲行業(yè)中，變更管理也不是簡單的放任或者控制，而是要權(quán)衡各方面的因素，讓變與不變維持在一個平衡點上。一句話概括其管理方式就是：胡蘿卜+大棒政策。
　　游戲公司中對于變更的兩種意見
　　主變派：策劃、制作人；觀點：變化乃游戲生存之本
　　變化是網(wǎng)絡(luò)游戲生存之根本，大家評判一個網(wǎng)絡(luò)游戲發(fā)展勢頭的最重要的標準有兩個：在線人數(shù)與更新頻率。一個更新頻率趨于變緩的游戲，基本上可以說是快進入消亡期了。追逐玩家們不斷變化的口味，引領(lǐng)游戲圈的新潮流，創(chuàng)造更高的吸金效率，這些都是以不斷的變化為基礎(chǔ)的。

天津網(wǎng)站制作/辦公軟件

　　因此，游戲必須變。不讓游戲發(fā)生變化，就等于是要了游戲的命。就算是限制變更，也相當于扼住了游戲賴以生存的咽喉。
　　不變派：開發(fā)團隊，項目經(jīng)理；觀點：變化是浪費，是隱患
　　說到底，游戲還是個軟件，單機游戲也好，網(wǎng)絡(luò)游戲也好，無非都是運行在計算機上的軟件。變更對于軟件開發(fā)而言，災(zāi)難性的，這一點所有軟件開發(fā)人員都深有體會，變更會導致大量的重復工作，嚴重影響開發(fā)進度；會對已完成的所有工作產(chǎn)生沖擊與影響，帶來更多的不可預(yù)期的Bug；沒有被良好重新設(shè)計的變更，甚至會直接威脅到軟件構(gòu)架的穩(wěn)定性，為將來埋下極大的隱患，等等。這些軟件本身的問題，同樣也適用于游戲開發(fā)。
　　更要命的是，頻繁的變更會讓開發(fā)團隊感到強烈的挫敗感，自己辛辛苦苦做好的東西，沒過幾天就被徹底改掉了，感覺自己就像是做了很多沒有用的東西一樣，長此以往，開發(fā)團隊將會士氣受挫，導致開發(fā)效率低下。
　　看來矛盾是不可避免了。那么到底聽誰的呢？聽策劃的，還是聽開發(fā)的？按照大自然物競天擇的自然規(guī)律來判斷的話：誰強，聽誰的。
　　誰更強？策劃，還是程序？如果我在這里挖個坑，蓋個樓的話，邀請大家來評價一下的話，我相信會相當?shù)幕鸨?/p>

天津網(wǎng)站制作/辦公軟件

　　實施證明，策劃與程序，都很重要。
　　變更的分類，哪些可以變？哪些不能變？
　　如果我們根據(jù)變更是否會對開發(fā)工作產(chǎn)生影響來對游戲需求變更進行分類，我們可以整體上分為兩種變更：1.對當前的游戲開發(fā)工作產(chǎn)生直接影響；2.不會對當前的游戲開發(fā)工作產(chǎn)生直接影響。
　　當前的工作，是指正在開發(fā)、測試、美術(shù)人員手上處理，或者進入到當前迭代周期內(nèi)待處理的工作。發(fā)生直接影響，則是指會打斷當前正在進行的開發(fā)工作，比如一個游戲需求：玩家自定義聊天頻道功能，現(xiàn)在這個需求已經(jīng)到了程序手中，開始編寫代碼了，這時候如過策劃人員發(fā)起變更，就會對當前工作產(chǎn)生直接的影響。而如是另一種情況：這個需求目前還在策劃階段，還沒有送到程序員與美術(shù)人員的手中，這時候策劃人員發(fā)起需求變更，不會對當前的開發(fā)任務(wù)產(chǎn)生直接影響，因為現(xiàn)在還根本沒有人在開發(fā)這個功能。
　　如果我們仔細分析一下程序人員反對變更的理由的話，我們會發(fā)現(xiàn)，其實程序人員僅僅是反對會產(chǎn)生直接影響的變更，而對于那些不會產(chǎn)生直接影響的變更，則不是很反對。那些不產(chǎn)生直接影響的變更，雖然也會對現(xiàn)有的工作產(chǎn)生一些間接的影響，但是影響不會很大，這個問題我們會在后面來討論。
　　胡蘿卜+大棒
　　基于上面提到的變更的分類方法，我們可以得到這樣一個變更管理的方法：
　　當一個需求（或者策劃案）還處在策劃階段，還沒有被送去開發(fā)與實現(xiàn)的時候，我們允許這個需求發(fā)生改變，甚至允許它發(fā)生任何的改變，沒有任何限制。而一旦這個需求被送去開發(fā)與實現(xiàn)了，那么我們將不再允許這個需求發(fā)生任何改變，需求與設(shè)計將會被鎖定，開發(fā)人員將會按照鎖定的版本進行開發(fā)。
　　如果在開發(fā)過程中，策劃人員實在忍不住要提出變更，那么他僅有兩個選擇：
　　1. 要求項目經(jīng)理徹底中斷掉該需求當前的開發(fā)工作，將該需求從當前的開發(fā)列表中取消，待其將需求變更修改好后，再重新納入到下一輪開發(fā)計劃中；
　　2. 等待已經(jīng)送交開發(fā)的需求開發(fā)完成，在已經(jīng)完成的基礎(chǔ)上提出修改（作為一個新需求）并納入到下一輪的開發(fā)計劃中。
　　當一個需求被完成后，如果策劃人員需要對已經(jīng)完成的內(nèi)容進行變更，那么他需要提出一個新需求，就叫做“對自定義聊天頻道修改”，將這個需求納入到需求庫中，并要求項目經(jīng)理納入到接下來的開發(fā)周期中，作為一個新的開發(fā)任務(wù)來處理。

天津網(wǎng)站制作/辦公軟件

　　那么以上的假設(shè)是否可行呢？有沒有人真的這么實踐過呢？答案是肯定的，敏捷開發(fā)方法論（不論是Scrum與XP）都是在以這種方法在管理需求變更，實踐的結(jié)果也是相當不錯的；另外，據(jù)我接觸的游戲公司中，也有一些公司在采用類似的方法來管理變更（金山的一些項目組就是這么做的，效果很好）。如果想更多的了解敏捷式變更管理，可以參考Ken Schwaber伯伯的書：《Scrum敏捷項目管理》（Agile Project Management With Scrum）
　　以上的做法，基本上滿足了策劃與程序的不同需求：策劃需要變更，開發(fā)不需要變更。開發(fā)人員應(yīng)該對這個方法很滿意，既然變化是勢不可擋的，但是只要不會直接影響當前工作，也是完全可以接受的；但是策劃人員心里還是有一絲不爽：在漫長的開發(fā)周期內(nèi)不能變更，是否太不人道了？
　　應(yīng)用正確的開發(fā)模型
　　網(wǎng)絡(luò)游戲開發(fā)應(yīng)該是有周期性的，短迭代周期的增量式開發(fā)是比較好的開發(fā)模型。瀑布模型肯定是行不通的，如果還有公司在用瀑布模型開發(fā)網(wǎng)絡(luò)游戲，唉，只能默默的祝愿他們一路走好了。長周期的迭代（半年一個周期）也是行不通的，這倒不是這種方法本身有什么問題，而是太長的迭代對于這個快速變化的花花世界來說，太痛苦了。
　　但是在我們訪談記錄中，卻發(fā)現(xiàn)很多游戲公司居然沒有任何開發(fā)模型，完全是一種混沌的開發(fā)方法，買來一個現(xiàn)成的游戲引擎，想到什么就開發(fā)什么，感覺做的差不多了就打個包上線，沒采用任何開發(fā)模型，沒有什么明確的開發(fā)周期，一切都是憑著感覺來。這是一個很危險的事情，很多這樣的公司，在游戲上線以后，會發(fā)現(xiàn)這個游戲制作工作徹底陷入了一團糟的境地，任何局域性方法都無法提供有效的幫助，最終公司進入一個死循環(huán)，決的辦法也變得很殘忍：要么死掉，要么徹底改革。
天津網(wǎng)站制作/辦公軟件