測試管理。目前國內(nèi)網(wǎng)游團(tuán)隊(duì)的測試能力相對較弱，大部分都沒有高效、全面的缺陷管理系統(tǒng)，甚至有一些測試工作與客戶支持任務(wù)都由同一團(tuán)隊(duì)來負(fù)責(zé)。相反，測試在歐美游戲公司中起了非常重要的作用，這也是歐美游戲品質(zhì)上乘的重要原因之一。
有效的需求管理方法
從游戲研發(fā)項(xiàng)目特點(diǎn)不難發(fā)現(xiàn)，目前存在于游戲開發(fā)管理中的很多問題都源于需求管理環(huán)節(jié)。
量化需求管理
如前所述，游戲項(xiàng)目通常規(guī)模巨大，涉及部門眾多。很多歐美視頻游戲的開發(fā)投入都在千萬美元以上，通常需要200人以上的專業(yè)團(tuán)隊(duì)開發(fā)2到3年時間。游戲項(xiàng)目的需求涉及到很多內(nèi)容，包括游戲類型、界面類型、引擎、游戲性等。
游戲項(xiàng)目的需求文檔最初來源于策劃案，內(nèi)容包括劇情創(chuàng)意、玩法、美術(shù)風(fēng)格等。結(jié)合游戲硬件和軟件環(huán)境等因素，被分解生成《游戲功能描述書》，包含眾多內(nèi)容，若用整篇的文檔來指導(dǎo)開發(fā)和測試工作，很容易引起任務(wù)分配的混亂;當(dāng)發(fā)生需求變更時，也很難追溯歷史版本。TechExcel從實(shí)踐中提煉出一個行之有效的解決方法—用規(guī)范點(diǎn)（Specification，以下簡稱Spec）量化需求，正規(guī)表達(dá)每一個功能單元。只需打開《游戲功能描述書》的WORD文檔，就可以利用插件，將其中的功能單元逐條地復(fù)制出來，在需求管理系統(tǒng)DevSpec中直接生成Spec。相對于需求，Spec是更面向技術(shù)人員的語言。
有序管理需求變更
在實(shí)際項(xiàng)目中，實(shí)現(xiàn)需求變更的成本隨著開發(fā)進(jìn)度呈指數(shù)級增長。需求變更的流程化管理能保障正常的開發(fā)進(jìn)度，將變更及時反應(yīng)到開發(fā)測試部門。
以下描述的是一個典型過程（如圖1）。一項(xiàng)變更請求在需求管理系統(tǒng)中被提交后，與之關(guān)聯(lián)的各個部門，如市場、程序、美術(shù)、測試等，都會有相關(guān)人員接到系統(tǒng)通知而介入。他們將組成評估團(tuán)隊(duì)，根據(jù)實(shí)施難度、周期、費(fèi)用、對其他機(jī)制的影響等指標(biāo)，對該變更進(jìn)行全面考察和評估。在理想的游戲研發(fā)管理平臺中，需求管理與所有規(guī)劃、開發(fā)、測試管理過程相集成。因此，需求的正規(guī)表達(dá)Spec，以及圍繞Spec正在或?qū)⒁M(jìn)行的開發(fā)任務(wù)和測試任務(wù)，都能被納入綜合考慮的范疇，便于評估團(tuán)隊(duì)估算該變更造成的“牽一發(fā)而動全身”的潛在影響。有時，還要結(jié)合商業(yè)需求進(jìn)行考量，為了趕上最佳發(fā)布時機(jī)，有些變更將被拒絕。這個過程由獨(dú)立的工作流控制，通常包括請求、復(fù)查、討論、調(diào)整、批準(zhǔn)和拒絕等狀態(tài)，只有具備權(quán)限的項(xiàng)目成員才能改變狀態(tài)。按照預(yù)設(shè)的流程，各方審批全部通過后，該變更才能被接受。
變更請求被批準(zhǔn)后，與之相關(guān)聯(lián)的開發(fā)、測試任務(wù)都會在系統(tǒng)中被一一標(biāo)記出來，以提醒程序和測試部門的相關(guān)負(fù)責(zé)人，引發(fā)這些任務(wù)的需求已經(jīng)變更，請他們做出相應(yīng)的調(diào)整處理。在系統(tǒng)中跟蹤這些任務(wù)的進(jìn)展，可以實(shí)時掌握該變更的落實(shí)情況。變更完成后，也可以核算它對開發(fā)周期和費(fèi)用的實(shí)際影響，與評估時的預(yù)測相對比，找出差異原因，為將來更準(zhǔn)確地評估提供參考。
此文章共有3頁 上一頁 1 2 3 下一頁
文章來源：中國項(xiàng)目管理資源網(wǎng)
 軟件開發(fā)項(xiàng)目管理培訓(xùn)課程方案
|
Leadge.com首頁 > 知識庫 
