經過一個多月艱辛的努力，我們小組終于在1/14按時發布了真人拳皇的alpha版。按照計劃，這一周是總結過去這段時間的經驗教訓，為即將到來的beta階段作準備。回顧剛剛過去的一個多月，從plan階段的天馬行空，到后來的逐漸降級，然后分兩步走的計劃，我們走過了整個alpha開發的全過程，初步體驗了正規軟件開發。這當中，我們都收獲了很多，有好的經驗，也有不好的教訓，經過今天軟件工程課上組員的討論，總結出了其中比較重要的幾點。先說說教訓吧。

• 計劃階段要務實
  我們剛開始構想這個游戲時，完全是天馬行空的想象，比如自動提取用戶圖片中的肢體部位，將它們重新組合成各種人物模型，再比如何種奇怪的招式、特效，游戲做好之后可以怎樣惡搞等等。在第一個星期的plan階段，大家都在津津樂道這些，并沒有真正考慮其實現問題，在技術上可不可行，用戶到底有怎樣的需求，在兩個月的時間里能不能做出來等實際問題。等到進入了coding階段，才發現光要實現兩個人對打這個基本功能就很不簡單，需要自己從頭開始寫一個小的游戲引擎。做了一段時間，發現工作量還是蠻大的，于是就把原來設想的提取用戶的全身圖片改為只提取用戶的頭像，并且放到beta階段來實現，實際上和我們之前的預期相比已經大打折扣。這個教訓告訴我們，在確定下來做什么之后，一定要盡快的接觸技術細節，考慮其實現難度，適當的取舍，不能只停留在頭腦風暴階段。否則很有可能到實現階段發現技術上不可行，再回頭補plan的功課，延誤了進度。
  
• 重要任務要分攤
  我們的dev有三個，說起來也不少，但是回頭看看所寫的代碼，保守估計有2/3以上是一個dev寫的，這樣做給項目管理帶來很大困擾。一方面，干活多的dev抱怨，大部分活都是我干的，壓力很大；另一方面，另外兩個dev也很委屈，沒什么活要干，只是讀懂別人代碼。這樣也給項目帶來了不小的風險，因為重要的代碼都是一個dev寫，等于把雞蛋都放在一個籃子里，如果哪天這個dev組里比較忙，或者其它原因，不能coding，整個項目的進度就會因此而被延誤，其他人也只能干著急。所以說，模塊化編程非常重要，coding能力比較強的dev,可以做dev master，統籌整個的coding工作，合理的把程序劃分成各個模塊然后分配下去，讓每個dev都積極地參加進來，擺脫一人寫代碼，其他人讀代碼的現象。
  
• 組員溝通要及時
  這個主要還是從一次事故中得出的教訓。一次，某dev被要求描述人物招式動作的轉換狀態，當時對我們期望怎樣的輸出說的不是很清楚，于是這位dev就按照自己的理解用文字描述了轉換狀態，第二天Scrum時交給大家看，但是大家實際上期望的更為清楚的狀態轉換圖描述，而不是文字的描述。雖然完成文字描述對畫出狀態轉換圖有很大的幫助，但畢竟有點南轅北轍。如果這個dev當時能夠及時對不清楚的地方弄清楚，也不會發生這樣的事情。組員之間的溝通不僅限于每天的scrum，有什么不清楚的地方，一定要及時的溝通，不然自己很有可能out of track，浪費了精力，更極大地挫傷了積極性。

當然，教訓很多，這里就不一而足了。另一方面，能夠按時發布alpha版并基本實現預期功能，我們還是有些心得的。

• 分解目標——雪中送炭與錦上添花
  俗話說，一口吃不成大胖子。當我們在coding階段意識到做這個游戲并不像我們想象的那么簡單時，我們及時調整了策略，分析了什么事重要而基本的功能（雪中送炭），什么是可選的、不那么核心的功能（錦上添花），然后集中精力在alpah階段實現核心的、基本的功能。我們能夠按時的發布alpha版，實現基本的兩人對打功能，很大程度上得益于目標的合理分解。試想，如果我們當時既想做兩人對打，又要實現酷炫的特效、用戶自定義等等，恐怕我們到現在什么也做不成，很難有可以deliver的東西出來。
  
• 明確分工
  典型的一個軟件項目團隊有PM，dev和test三個角色，我們剛開始也是這樣設置的。但是后來發現，因為我們是做游戲，需要很多的設計工作，比如人物的招式、照片的拍攝與處理等工作，很難歸于上述三種角色的職能。于是我們又設立了兩名designer，來進行設計工作。這樣分工更加明確，也容易提高效率。

轉載于:https://www.cnblogs.com/MSRA_SE_TEAM/archive/2011/01/17/1937765.html

總結

以上是生活随笔為你收集整理的真人拳皇项目Alpha阶段的回顾——史经浩的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。