對(duì)于軟件開發(fā)領(lǐng)域來(lái)講，變更始終是最讓人頭疼的東西，大家對(duì)于如何消除變更，如何控制變更，提出了很多很多的理論與方法。無(wú)奈變更這東西就像是個(gè)打不死的小強(qiáng)，倔強(qiáng)的與軟件開發(fā)一起生存了半個(gè)多世紀(jì)，到了現(xiàn)如今的網(wǎng)絡(luò)時(shí)代，不但沒有被壓制住，反倒更加猖獗了。那么在小強(qiáng)最繁榮的游戲圈里面，大家是如何面對(duì)變更的呢？

　　整體而言，游戲行業(yè)（尤其是網(wǎng)絡(luò)游戲行業(yè)）對(duì)于變更是又愛又恨的，很糾結(jié)，很痛苦。因此在網(wǎng)絡(luò)游戲行業(yè)中，變更管理也不是簡(jiǎn)單的放任或者控制，而是要權(quán)衡各方面的因素，讓變與不變維持在一個(gè)平衡點(diǎn)上。一句話概括其管理方式就是：胡蘿卜+大棒政策。

　　游戲公司中對(duì)于變更的兩種意見

　　主變派：策劃、制作人；觀點(diǎn)：變化乃游戲生存之本

　　變化是網(wǎng)絡(luò)游戲生存之根本，大家評(píng)判一個(gè)網(wǎng)絡(luò)游戲發(fā)展勢(shì)頭的最重要的標(biāo)準(zhǔn)有兩個(gè)：在線人數(shù)與更新頻率。一個(gè)更新頻率趨于變緩的游戲，基本上可以說(shuō)是快進(jìn)入消亡期了。追逐玩家們不斷變化的口味，引領(lǐng)游戲圈的新潮流，創(chuàng)造更高的吸金效率，這些都是以不斷的變化為基礎(chǔ)的。

　　因此，游戲必須變。不讓游戲發(fā)生變化，就等于是要了游戲的命。就算是限制變更，也相當(dāng)于扼住了游戲賴以生存的咽喉。

　　不變派：開發(fā)團(tuán)隊(duì)，項(xiàng)目經(jīng)理；觀點(diǎn)：變化是浪費(fèi)，是隱患

　　說(shuō)到底，游戲還是個(gè)軟件，單機(jī)游戲也好，網(wǎng)絡(luò)游戲也好，無(wú)非都是運(yùn)行在計(jì)算機(jī)上的軟件。變更對(duì)于軟件開發(fā)而言，災(zāi)難性的，這一點(diǎn)所有軟件開發(fā)人員都深有體會(huì)，變更會(huì)導(dǎo)致大量的重復(fù)工作，嚴(yán)重影響開發(fā)進(jìn)度；會(huì)對(duì)已完成的所有工作產(chǎn)生沖擊與影響，帶來(lái)更多的不可預(yù)期的Bug；沒有被良好重新設(shè)計(jì)的變更，甚至?xí)苯油{到軟件構(gòu)架的穩(wěn)定性，為將來(lái)埋下極大的隱患，等等。這些軟件本身的問題，同樣也適用于游戲開發(fā)。

　　更要命的是，頻繁的變更會(huì)讓開發(fā)團(tuán)隊(duì)感到強(qiáng)烈的挫敗感，自己辛辛苦苦做好的東西，沒過(guò)幾天就被徹底改掉了，感覺自己就像是做了很多沒有用的東西一樣，長(zhǎng)此以往，開發(fā)團(tuán)隊(duì)將會(huì)士氣受挫，導(dǎo)致開發(fā)效率低下。

　　看來(lái)矛盾是不可避免了。那么到底聽誰(shuí)的呢？聽策劃的，還是聽開發(fā)的？按照大自然物競(jìng)天擇的自然規(guī)律來(lái)判斷的話：誰(shuí)強(qiáng)，聽誰(shuí)的。

　　誰(shuí)更強(qiáng)？策劃，還是程序？如果我在這里挖個(gè)坑，蓋個(gè)樓的話，邀請(qǐng)大家來(lái)評(píng)價(jià)一下的話，我相信會(huì)相當(dāng)?shù)幕鸨?/p>

　　實(shí)施證明，策劃與程序，都很重要。

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

　　如果我們根據(jù)變更是否會(huì)對(duì)開發(fā)工作產(chǎn)生影響來(lái)對(duì)游戲需求變更進(jìn)行分類，我們可以整體上分為兩種變更：1.對(duì)當(dāng)前的游戲開發(fā)工作產(chǎn)生直接影響；2.不會(huì)對(duì)當(dāng)前的游戲開發(fā)工作產(chǎn)生直接影響。

　　當(dāng)前的工作，是指正在開發(fā)、測(cè)試、美術(shù)人員手上處理，或者進(jìn)入到當(dāng)前迭代周期內(nèi)待處理的工作。發(fā)生直接影響，則是指會(huì)打斷當(dāng)前正在進(jìn)行的開發(fā)工作，比如一個(gè)游戲需求：玩家自定義聊天頻道功能，現(xiàn)在這個(gè)需求已經(jīng)到了程序手中，開始編寫代碼了，這時(shí)候如過(guò)策劃人員發(fā)起變更，就會(huì)對(duì)當(dāng)前工作產(chǎn)生直接的影響。而如是另一種情況：這個(gè)需求目前還在策劃階段，還沒有送到程序員與美術(shù)人員的手中，這時(shí)候策劃人員發(fā)起需求變更，不會(huì)對(duì)當(dāng)前的開發(fā)任務(wù)產(chǎn)生直接影響，因?yàn)楝F(xiàn)在還根本沒有人在開發(fā)這個(gè)功能。

　　如果我們仔細(xì)分析一下程序人員反對(duì)變更的理由的話，我們會(huì)發(fā)現(xiàn)，其實(shí)程序人員僅僅是反對(duì)會(huì)產(chǎn)生直接影響的變更，而對(duì)于那些不會(huì)產(chǎn)生直接影響的變更，則不是很反對(duì)。那些不產(chǎn)生直接影響的變更，雖然也會(huì)對(duì)現(xiàn)有的工作產(chǎn)生一些間接的影響，但是影響不會(huì)很大，這個(gè)問題我們會(huì)在后面來(lái)討論。

　　胡蘿卜+大棒

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

　　當(dāng)一個(gè)需求（或者策劃案）還處在策劃階段，還沒有被送去開發(fā)與實(shí)現(xiàn)的時(shí)候，我們?cè)试S這個(gè)需求發(fā)生改變，甚至允許它發(fā)生任何的改變，沒有任何限制。而一旦這個(gè)需求被送去開發(fā)與實(shí)現(xiàn)了，那么我們將不再允許這個(gè)需求發(fā)生任何改變，需求與設(shè)計(jì)將會(huì)被鎖定，開發(fā)人員將會(huì)按照鎖定的版本進(jìn)行開發(fā)。

　　如果在開發(fā)過(guò)程中，策劃人員實(shí)在忍不住要提出變更，那么他僅有兩個(gè)選擇：

　　1. 要求項(xiàng)目經(jīng)理徹底中斷掉該需求當(dāng)前的開發(fā)工作，將該需求從當(dāng)前的開發(fā)列表中取消，待其將需求變更修改好后，再重新納入到下一輪開發(fā)計(jì)劃中；

　　2. 等待已經(jīng)送交開發(fā)的需求開發(fā)完成，在已經(jīng)完成的基礎(chǔ)上提出修改（作為一個(gè)新需求）并納入到下一輪的開發(fā)計(jì)劃中。

　　當(dāng)一個(gè)需求被完成后，如果策劃人員需要對(duì)已經(jīng)完成的內(nèi)容進(jìn)行變更，那么他需要提出一個(gè)新需求，就叫做“對(duì)自定義聊天頻道修改”，將這個(gè)需求納入到需求庫(kù)中，并要求項(xiàng)目經(jīng)理納入到接下來(lái)的開發(fā)周期中，作為一個(gè)新的開發(fā)任務(wù)來(lái)處理。

　　那么以上的假設(shè)是否可行呢？有沒有人真的這么實(shí)踐過(guò)呢？答案是肯定的，敏捷開發(fā)方法論（不論是Scrum與XP）都是在以這種方法在管理需求變更，實(shí)踐的結(jié)果也是相當(dāng)不錯(cuò)的；另外，據(jù)我接觸的游戲公司中，也有一些公司在采用類似的方法來(lái)管理變更（金山的一些項(xiàng)目組就是這么做的，效果很好）。如果想更多的了解敏捷式變更管理，可以參考Ken Schwaber伯伯的書：《Scrum敏捷項(xiàng)目管理》（Agile Project Management With Scrum）

　　以上的做法，基本上滿足了策劃與程序的不同需求：策劃需要變更，開發(fā)不需要變更。開發(fā)人員應(yīng)該對(duì)這個(gè)方法很滿意，既然變化是勢(shì)不可擋的，但是只要不會(huì)直接影響當(dāng)前工作，也是完全可以接受的；但是策劃人員心里還是有一絲不爽：在漫長(zhǎng)的開發(fā)周期內(nèi)不能變更，是否太不人道了？

　　應(yīng)用正確的開發(fā)模型

　　網(wǎng)絡(luò)游戲開發(fā)應(yīng)該是有周期性的，短迭代周期的增量式開發(fā)是比較好的開發(fā)模型。瀑布模型肯定是行不通的，如果還有公司在用瀑布模型開發(fā)網(wǎng)絡(luò)游戲，唉，只能默默的祝愿他們一路走好了。長(zhǎng)周期的迭代（半年一個(gè)周期）也是行不通的，這倒不是這種方法本身有什么問題，而是太長(zhǎng)的迭代對(duì)于這個(gè)快速變化的花花世界來(lái)說(shuō)，太痛苦了。

　　但是在我們?cè)L談?dòng)涗浿校瑓s發(fā)現(xiàn)很多游戲公司居然沒有任何開發(fā)模型，完全是一種混沌的開發(fā)方法，買來(lái)一個(gè)現(xiàn)成的游戲引擎，想到什么就開發(fā)什么，感覺做的差不多了就打個(gè)包上線，沒采用任何開發(fā)模型，沒有什么明確的開發(fā)周期，一切都是憑著感覺來(lái)。這是一個(gè)很危險(xiǎn)的事情，很多這樣的公司，在游戲上線以后，會(huì)發(fā)現(xiàn)這個(gè)游戲制作工作徹底陷入了一團(tuán)糟的境地，任何局域性方法都無(wú)法提供有效的幫助，最終公司進(jìn)入一個(gè)死循環(huán)，決的辦法也變得很殘忍：要么死掉，要么徹底改革。

　　任何的針對(duì)具體軟件開發(fā)管理問題的解決辦法，都是要在軟件開發(fā)模型的大框架下才能起效果的。我們不可能把瀑布模型中制定計(jì)劃的方法用在敏捷開發(fā)模型下，我們也不能把打牌估算的方式用在瀑布模型中，因?yàn)檫@些具體方法都是在具體的開發(fā)模型的框架下，才具備了生存的條件。就像生態(tài)系統(tǒng)一樣，熱帶雨林里的鱷魚，放到沙漠里面，肯定活不下去的。所以如果一個(gè)游戲公司連基本的開發(fā)模型都沒有引入的話，那么就不要考慮變更怎么管理了；就像在真空中任何生物都無(wú)法生存一樣，在沒有開發(fā)模型的環(huán)境中，任何開發(fā)管理方法也都無(wú)法取得效果。

　　所以，上文提到的這種這種需求（策劃）變更管理方法，是要在敏捷開發(fā)的大環(huán)境下，才能夠起作用的，在瀑布、長(zhǎng)周期的迭代式開發(fā)模型中，都不會(huì)有啥正面作用。

　　迭代周期的選擇

　　一般的共識(shí)是這樣的：相對(duì)較長(zhǎng)的Sprint迭代周期，能夠有效的提高開發(fā)效率。因?yàn)橐粋€(gè)Sprint周期中，有些工作是不能被省略的，如Backlog的整理、估算、計(jì)劃會(huì)、評(píng)審會(huì)與反思會(huì)、代碼集成、測(cè)試、打包等，這些活動(dòng)一般都要占用不少的時(shí)間，越長(zhǎng)的Sprint周期，這些活動(dòng)所占用的時(shí)間比例會(huì)越少，為開發(fā)人員留下的整塊開發(fā)時(shí)間就越多，工作效率也越高。

　　而Sprint周期越短，對(duì)于需求變化的響應(yīng)速度就越快。人們對(duì)于未來(lái)變化的把握能力其實(shí)很弱，越短的時(shí)間，把握越強(qiáng)，考慮的也越詳細(xì)，太長(zhǎng)時(shí)間以后的事情（如2個(gè)月以后），則基本沒有什么把握能力了。

　　Sprint周期的選擇，就是開發(fā)效率與響應(yīng)速度之間的一個(gè)平衡。

　　一般在開發(fā)期的游戲，會(huì)選擇相對(duì)較長(zhǎng)的Sprint周期，如1-2個(gè)月左右，這時(shí)候策劃相對(duì)比較明確，還沒有引入玩家與運(yùn)營(yíng)反饋，需求變更相對(duì)較少，選擇相對(duì)較長(zhǎng)的開發(fā)周期能夠保證開發(fā)期的游戲開發(fā)效率，爭(zhēng)取盡早達(dá)到上線標(biāo)準(zhǔn)。這時(shí)候也希望策劃團(tuán)隊(duì)能夠盡可能減少不確定的變更，如果一個(gè)功能或玩法沒法確認(rèn)真的比改變前更好，那么就不要貿(mào)然提出改動(dòng)，等到上線之后聽到玩家的反饋后再提出，能節(jié)省不少工作量。

　　而從游戲上線封測(cè)開始，Sprint周期就開始逐步縮短，以適應(yīng)逐漸增多的Bug、調(diào)整與變更，在游戲正式運(yùn)營(yíng)后，一般都會(huì)將Sprint周期控制在1-3周左右，一般都是與游戲的更新周期保持同步。從管理的角度來(lái)說(shuō)，為了適應(yīng)更短的Sprint周期，很多管理上的規(guī)章與流程也要隨之相應(yīng)的簡(jiǎn)化，以適應(yīng)高相應(yīng)速度的要求。

　　產(chǎn)生間接影響的變更如何應(yīng)對(duì)

　　有一些變更雖然不會(huì)對(duì)當(dāng)前的開發(fā)工作產(chǎn)生任何影響，但是卻會(huì)在將來(lái)對(duì)開發(fā)工作產(chǎn)生一定的影響，如一個(gè)變更會(huì)導(dǎo)致我們對(duì)當(dāng)前的游戲構(gòu)架進(jìn)行調(diào)整，那么這個(gè)變更將會(huì)在未來(lái)產(chǎn)生相當(dāng)大的工作量。那么我們是否在當(dāng)前的工作中考慮這些存在著潛在影響的變更呢？

it知識(shí)庫(kù)：網(wǎng)絡(luò)游戲開發(fā)中的需求變更管理，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。