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

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

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

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

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

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

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

    以上的做法，基本上滿(mǎn)足了策劃與程序的不同需求：策劃需要變更，開(kāi)發(fā)不需要變更。開(kāi)發(fā)人員應(yīng)該對(duì)這個(gè)方法很滿(mǎn)意，既然變化是勢(shì)不可擋的，但是只要不會(huì)直接影響當(dāng)前工作，也是完全可以接受的；但是策劃人員心里還是有一絲不爽：在漫長(zhǎng)的開(kāi)發(fā)周期內(nèi)不能變更，是否太不人道了？
  網(wǎng)絡(luò)游戲開(kāi)發(fā)應(yīng)該是有周期性的，短迭代周期的增量式開(kāi)發(fā)是比較好的開(kāi)發(fā)模型。瀑布模型肯定是行不通的，如果還有公司在用瀑布模型開(kāi)發(fā)網(wǎng)絡(luò)游戲，唉，只能默默的祝愿他們一路走好了。長(zhǎng)周期的迭代（半年一個(gè)周期）也是行不通的，這倒不是這種方法本身有什么問(wèn)題，而是太長(zhǎng)的迭代對(duì)于這個(gè)快速變化的花花世界來(lái)說(shuō)，太痛苦了。

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

   任何的針對(duì)具體軟件開(kāi)發(fā)管理問(wèn)題的解決辦法，都是要在軟件開(kāi)發(fā)模型的大框架下才能起效果的。我們不可能把瀑布模型中制定計(jì)劃的方法用在敏捷開(kāi)發(fā)模型下，我們也不能把打牌估算的方式用在瀑布模型中，因?yàn)檫@些具體方法都是在具體的開(kāi)發(fā)模型的框架下，才具備了生存的條件。就像生態(tài)系統(tǒng)一樣，熱帶雨林里的鱷魚(yú)，放到沙漠里面，肯定活不下去的。所以如果一個(gè)游戲公司連基本的開(kāi)發(fā)模型都沒(méi)有引入的話(huà)，那么就不要考慮變更怎么管理了；就像在真空中任何生物都無(wú)法生存一樣，在沒(méi)有開(kāi)發(fā)模型的環(huán)境中，任何開(kāi)發(fā)管理方法也都無(wú)法取得效果。
   因此，上面提到的這種需求變更管理方法，在瀑布、長(zhǎng)周期的迭代式開(kāi)發(fā)模型中，都不會(huì)有太大的正面作用，但是在敏捷開(kāi)發(fā)的大環(huán)境下，它就會(huì)發(fā)揮出自己的作用來(lái)，優(yōu)化你的項(xiàng)目管理。