隨著開發(fā)技術(shù)的不斷演進(jìn)和玩家需求的日新月異，游戲產(chǎn)品日趨復(fù)雜。那么如何來(lái)更好的管理游戲產(chǎn)品呢?這里我們引入敏捷方法來(lái)進(jìn)行更高效的產(chǎn)品交付。

　　敏捷(Agile)的介紹

　　敏捷(Agile)是一種新型軟件開發(fā)方法，以用戶的需求進(jìn)化為核心，采用迭代、循序漸進(jìn)的方法進(jìn)行軟件開發(fā)，可以應(yīng)對(duì)快速變化的需求。

　　敏捷的原則(即敏捷宣言)：

　　個(gè)人與交互 重于 流程和工具

　∩工作的軟件 重于 完備的文檔

　⊥戶協(xié)作 重于 合同談判

　　響應(yīng)變化 重于 按部就班

　　敏捷核心是價(jià)值驅(qū)動(dòng)和快速迭代，是一種基于經(jīng)驗(yàn)的過(guò)程控制方法，而非傳統(tǒng)項(xiàng)目管理中基于預(yù)測(cè)的過(guò)程控制方法。

　　敏捷適用的范圍：

　　當(dāng)需求存在不確定性、對(duì)于實(shí)現(xiàn)難以達(dá)成一致意見(jiàn)，那么就會(huì)呈現(xiàn)出復(fù)雜系統(tǒng)的特征，例如開發(fā)一款全新的游戲產(chǎn)品。敏捷方法對(duì)于這種需要作出復(fù)雜決策的項(xiàng)目中是很好的選擇。

　　(另外，如果一個(gè)項(xiàng)目中大部分的細(xì)節(jié)已經(jīng)知道，很多事情大家都很容易達(dá)成之一，且具有較大的確定性，那么瀑布式方法可能是最好的選擇，例如換皮項(xiàng)目。)

　　Stacey Matrix

　　游戲產(chǎn)品適用敏捷方法

　　游戲是一種復(fù)雜的產(chǎn)品，需要融合技術(shù)、美術(shù)、音樂(lè)、數(shù)值、劇情、付費(fèi)等等，玩家的需求又是多種多樣、快速變化。所以游戲項(xiàng)目需要復(fù)雜決策，適用敏捷方法。

　　大到 Activision Blizzard, Supercell 這樣的巨無(wú)霸，小到無(wú)數(shù)歐美的游戲工作室，都在一定程度上使用了敏捷方法，來(lái)提升產(chǎn)品交付的速度和價(jià)值。

　　結(jié)合這幾年我在手機(jī)游戲項(xiàng)目中的實(shí)際工作經(jīng)驗(yàn)和項(xiàng)目上的思考，分享一些對(duì)大家有價(jià)值的敏捷方法和實(shí)踐。

　　產(chǎn)品管理

　　1. 使用 MVP 和 MMF 來(lái)構(gòu)建游戲產(chǎn)品

　　MVP，最簡(jiǎn)化可實(shí)行產(chǎn)品，即用最快、最簡(jiǎn)明的方式建立一個(gè)可用的產(chǎn)品原型，這個(gè)原型要表達(dá)出你產(chǎn)品最終想要的效果，然后通過(guò)迭代來(lái)完善細(xì)節(jié)。

　　MVP的幾個(gè)關(guān)鍵點(diǎn)

　　要深入挖掘用戶的最本質(zhì)需求;

　　每次迭代結(jié)束都有一個(gè)可行性產(chǎn)品;

　　切勿追求大而全，簡(jiǎn)化任何不重要的功能，減少任何不需要的功能。

　　例如下圖中，用戶的初始需求是：我想要一輛汽車。深入挖掘后得到用戶的最本質(zhì)需求：我要方便出行。那么可以通過(guò)每次迭代都有一種交通工具產(chǎn)出，來(lái)滿足用戶的最本質(zhì)需求，去掉任何不相關(guān)的功能。

　　MVP

　　MMF，最猩售功能

　　MMF是可以給用戶增加價(jià)值的最小單位的交付物;

　　通過(guò)將項(xiàng)目拆分為若干個(gè)MMF，團(tuán)隊(duì)可以專注于開發(fā)一組有價(jià)值的小功能，并迅速交付給客戶;

　∩以把MVP理解為一組最核心MMF的集合。

　　對(duì)于一個(gè)游戲產(chǎn)品，特別新產(chǎn)品，可以去考慮：

　　游戲?qū)τ谕婕易畲蟮膬r(jià)值是什么?游戲最核心的玩法是什么?

　　基于這個(gè)核心玩法，并對(duì)其他系統(tǒng)進(jìn)行簡(jiǎn)化，從而快速構(gòu)建一個(gè)游戲產(chǎn)品;

　　及早、眷交付，進(jìn)行買量測(cè)試、收集反饋。每次交付都應(yīng)該是一個(gè)完整的、經(jīng)過(guò)測(cè)試的、玩家可以體驗(yàn)的游戲;

　　所有游戲功能應(yīng)該按照對(duì)玩家的價(jià)值進(jìn)行：分類、排序、分解;

　　團(tuán)隊(duì)?wèi)?yīng)該優(yōu)先關(guān)注在一組高優(yōu)先級(jí)的游戲功能上，而不是所有的功能實(shí)現(xiàn)上;

　　不要急于做一個(gè)大而全的游戲產(chǎn)品，一下子把攤子攤得太大。要先完成核心功能，然后逐步完善其他系統(tǒng)。

　　2. 使用 Product Backlog 和 Sprint Backlog 來(lái)管理需求

　　Scrum是敏捷方法中一種重要的軟件開發(fā)方法，Scrum包含了一套完整的項(xiàng)目流程的框架，如下圖所示：

　　Scrum

　　Product Backlog (產(chǎn)品待辦列表)是一個(gè)排序的列表，包含所有產(chǎn)品需要的東西，也是產(chǎn)品需求變動(dòng)的 來(lái)源。產(chǎn)品負(fù)責(zé)人負(fù)責(zé)維護(hù)產(chǎn)品待辦列表的內(nèi)容、可用性和優(yōu)先級(jí)。

　　Sprint Backlog(迭代待辦列表)是一組為當(dāng)前 Sprint (沖刺=迭代)選出的 Product Backlog，外加交付產(chǎn)品增量和實(shí)現(xiàn) Sprint 目標(biāo)的計(jì)劃。Sprint Backlog是開發(fā)團(tuán)隊(duì)對(duì)于哪些功能要包含在下個(gè)增量中，以及交付那些功能所需工作的預(yù)計(jì)。

　　在實(shí)際工作中的使用

　∩以把 Product Backlog 作為產(chǎn)品的中長(zhǎng)期目標(biāo)，使用Excel來(lái)記錄產(chǎn)品的功能點(diǎn)、優(yōu)先級(jí)、大致工作量等，列表內(nèi)容進(jìn)行持續(xù)更新、逐漸細(xì)化;

　　Sprint Backlog 作為產(chǎn)品的短期目標(biāo)，需要撰寫詳細(xì)的策劃案，明確清晰的定義功能，并且能在迭代周期內(nèi)容按時(shí)完成;

　　一次迭代完成后，從Product Backlog中抽取 優(yōu)先級(jí)的功能需求，放入Sprint Backlog中，進(jìn)行細(xì)化并實(shí)現(xiàn)，以此往復(fù)。

　　對(duì)于Product Backlog

　　 性：作為產(chǎn)品需求 的來(lái)源，所有需求必須放入Product Backlog中進(jìn)行統(tǒng)一管理;

　　動(dòng)態(tài)性：產(chǎn)品待辦列表一直是動(dòng)態(tài)的，需要持續(xù)更新，初期主要包括理解最透徹的那些產(chǎn)品需求，然后隨著產(chǎn)品及其應(yīng)用嘲的改變而不斷演進(jìn)，會(huì)逐步增加新的玩法需求、玩家反饋、運(yùn)營(yíng)需求、系統(tǒng)優(yōu)化等等，來(lái)保持產(chǎn)品需求的適應(yīng)性、競(jìng)爭(zhēng)力和實(shí)用性，這將貫穿于整個(gè)產(chǎn)品生命周期的始終;

　　漸進(jìn)明細(xì)：定期進(jìn)行“產(chǎn)品待辦列表細(xì)化”，主要工作內(nèi)容是為待辦列表?xiàng)l目補(bǔ)充細(xì)節(jié)描述、工作量估算(可以采用相對(duì)估算)、對(duì)大型條目進(jìn)行合理拆分，必要時(shí)調(diào)整待辦列表?xiàng)l目的優(yōu)先級(jí)順序，始終優(yōu)先開發(fā)高價(jià)值的功能;

　　負(fù)責(zé)人：有專人進(jìn)行定義維護(hù)Product Backlog，可以是制作人或者主策，然后讓所有項(xiàng)目參與者達(dá)成共識(shí)，加深對(duì)游戲發(fā)展的方向的理解，提前做好準(zhǔn)備。Product Backlog可以作為產(chǎn)品的中長(zhǎng)期目標(biāo)。

　　對(duì)于Sprint Backlog

　　內(nèi)容：包含當(dāng)前迭代的需求，也就是Product Backlog中優(yōu)先級(jí) 的需求，而且能夠在一個(gè)迭代中完成;

　　細(xì)化：需要進(jìn)行細(xì)化，并分解為完成需求的多個(gè)具體任務(wù)，每個(gè)任務(wù)應(yīng)該能在1天內(nèi)完成;對(duì)于特別大的功能，應(yīng)該考慮進(jìn)行拆分，逐步在各個(gè)Sprint里交付;或者單獨(dú)拉分支進(jìn)行開發(fā);各個(gè)任務(wù)的工作量應(yīng)該進(jìn)行合理評(píng)估，從而形成清晰可見(jiàn)的工作計(jì)劃;

　　工作分配：按照之前實(shí)際項(xiàng)目經(jīng)驗(yàn)，每次迭代中，合理的工作量分布大概為：新玩法： 1/3;付費(fèi)和留存改進(jìn)：1/3;bug fix和系統(tǒng)優(yōu)化：1/3。所以對(duì)于每個(gè)迭代，不能完全放滿新玩法的實(shí)現(xiàn)，需要留出足夠的時(shí)間去做各方面的改進(jìn)和優(yōu)化。

　　負(fù)責(zé)人：Sprint Backlog的內(nèi)容，可以在主策的組織下進(jìn)行任務(wù)細(xì)化，形成當(dāng)前版本的詳細(xì)策劃案，所有團(tuán)隊(duì)成員通過(guò)評(píng)審、討論、工作量評(píng)估，完全理解策劃案的內(nèi)容。Spring Backlog可以作為產(chǎn)品的短期目標(biāo)。

　　日常工作

　　1. 任務(wù)管理

　　通過(guò)每日站會(huì)、看板來(lái)建立一個(gè)信息透明、及時(shí)反饋的工作環(huán)境;

　　每日站會(huì)，15分鐘3個(gè)問(wèn)題，目的讓大家分享工作成果、確定今天計(jì)劃、及早發(fā)現(xiàn)和解決問(wèn)題;

　〈板(Kanban)，實(shí)現(xiàn)管理的可視化，所有信息可以集成到看板中，進(jìn)行統(tǒng)一管理。甚至可以用看板管理所有的需求、bug、工作中障礙，風(fēng)險(xiǎn)等等;

　　鼓勵(lì)每個(gè)人來(lái)積極參與，互相協(xié)作，主動(dòng)去選擇工作任務(wù)，共同承擔(dān)團(tuán)隊(duì)的工作。

　　Kanban

　　2. 持續(xù)集成

　　對(duì)于“工作完成”(Definition of Done)有著明確定義，團(tuán)隊(duì)理解并能嚴(yán)格遵循;

　∩以進(jìn)行每日構(gòu)建 (Daily build)，及早發(fā)現(xiàn)工作中的問(wèn)題;

　　早、頻繁交付，持續(xù)收集內(nèi)部、外部反饋，并指導(dǎo)下一步的工作;

　　保持一個(gè)恒定的工作節(jié)奏(Cadence)，更加有利于工作的持續(xù)進(jìn)行，例如1個(gè)月進(jìn)行1次正式發(fā)布。

　　3. 團(tuán)隊(duì)管理

　　團(tuán)隊(duì)集中辦公 (Co-location)，通過(guò)面對(duì)面的溝通提高工作效率;

　　研運(yùn)一體 (DevOps)，提高協(xié)作效率，降低發(fā)布風(fēng)險(xiǎn);

　　減少外部干擾，減少不必要的會(huì)議，讓團(tuán)隊(duì)更加專注于工作本身;

　　通過(guò)項(xiàng)目回顧 (Retrospective)，讓團(tuán)隊(duì)對(duì)工作流程和方法進(jìn)行自我學(xué)習(xí)和自我完善。

　　4. 團(tuán)隊(duì)激勵(lì)

　—放和透明的環(huán)境，鼓勵(lì)嘗試，允許犯錯(cuò)，提高每個(gè)人的參與度;

　　清晰可見(jiàn)的工作進(jìn)展，持續(xù)不斷的驗(yàn)收交付，提升個(gè)人成就感;

　　能夠迅速得到市場(chǎng)的反饋、玩家的評(píng)價(jià)，即時(shí)的外部認(rèn)可、績(jī)效反映;

　　及時(shí)、合理的物質(zhì)激勵(lì)，和個(gè)人績(jī)效和團(tuán)隊(duì)績(jī)效緊密掛鉤。合理的利益分配機(jī)制是一個(gè)公司長(zhǎng)久發(fā)展的基石。

　　測(cè)試驅(qū)動(dòng)

　　測(cè)試驅(qū)動(dòng)開發(fā)TDD(Test-Driven Development)，是一種敏捷的開發(fā)實(shí)踐，是指先對(duì)軟件的驗(yàn)收測(cè)試進(jìn)行定義，再編寫模塊代碼，這些代碼將圍繞著通過(guò)這些測(cè)試而構(gòu)建，只要寫對(duì)代碼必然應(yīng)該通過(guò)測(cè)試。

　　如果宏觀的去思考測(cè)試驅(qū)動(dòng)，對(duì)于任何一個(gè)游戲產(chǎn)品，最終的驗(yàn)收標(biāo)準(zhǔn)都會(huì)是：是否能夠得到市場(chǎng)的認(rèn)可、得到玩家的喜愛(ài)。如果我們圍繞著這個(gè)標(biāo)準(zhǔn)去做，盡早得到市場(chǎng)和玩家的反饋，從而指導(dǎo)游戲的設(shè)計(jì)和開發(fā)，那么可以更好的幫助我們得到一個(gè)受到市場(chǎng)和玩家歡迎的產(chǎn)品。

　　1. 核心玩法、美術(shù)設(shè)定

　　核心玩法，是游戲中最重要部分;美術(shù)，作為游戲第一眼的印象，對(duì)于游戲產(chǎn)品的成功也是至關(guān)重要。

　　很多時(shí)候我們?cè)谡f(shuō)這個(gè)核心玩法好不好玩，美術(shù)效果好不好的時(shí)候，有沒(méi)有考慮過(guò)這樣一個(gè)問(wèn)題：到底是誰(shuí)覺(jué)得好或者不好?是你覺(jué)得呢?還是玩家覺(jué)得?還是你想象當(dāng)中的玩家，應(yīng)該這樣覺(jué)得?

　　其實(shí)很多時(shí)候我們會(huì)都把自己當(dāng)成所有目標(biāo)用戶來(lái)進(jìn)行決策，一旦決策錯(cuò)誤需要返工的話，核心玩法意味著游戲推倒重來(lái)，美術(shù)意味著巨大的重新制作或外包成本，這都是一個(gè)公司不愿意去承受的成本。

　　那么如何讓玩家來(lái)盡早提供對(duì)核心玩法和美術(shù)設(shè)定的反饋呢?

　　我們可以從游戲項(xiàng)目概念階段開始，就逐步進(jìn)行美術(shù)和核心玩法的測(cè)試。例如，美術(shù)設(shè)定，直接可以從游戲ICON和游戲截圖中體現(xiàn)，通過(guò)廣告進(jìn)行買量測(cè)試，從而來(lái)識(shí)別玩家對(duì)于哪種美術(shù)設(shè)定更加接受;核心玩法可以使用前面講過(guò)的MVP的方法，快速構(gòu)建最簡(jiǎn)化可實(shí)行產(chǎn)品，然后進(jìn)行買量測(cè)試，收集玩家數(shù)據(jù)，逐漸完善游戲功能。

　　這樣的用戶測(cè)試，需要在項(xiàng)目初期和開發(fā)中，不斷的進(jìn)行廣告投入，但這個(gè)費(fèi)用比項(xiàng)目上線后，再去進(jìn)行大范圍的修改，成本遠(yuǎn)遠(yuǎn)低的多!特別當(dāng)你的游戲產(chǎn)品可能有爆發(fā)性用戶增長(zhǎng)的時(shí)候(例如推薦)，先調(diào)優(yōu)再上線，這點(diǎn)特別重要。

　　2. 游戲運(yùn)營(yíng)、版本更新

　　運(yùn)營(yíng)數(shù)據(jù)，通過(guò)事件跟蹤SDK在游戲內(nèi)打點(diǎn)后，我們可以很容易得到游戲的運(yùn)營(yíng)數(shù)據(jù)，例如：DAU, D1, D7, D30, Conversion rate, Session duration 等等，這在游戲行業(yè)已經(jīng)是非常成熟的模式了。通過(guò)持續(xù)的運(yùn)營(yíng)數(shù)據(jù)跟蹤，關(guān)聯(lián)到各個(gè)版本之間的內(nèi)容改動(dòng)，我們可以從大量數(shù)據(jù)中得到規(guī)律性的東西，什么是玩家真正喜聞樂(lè)見(jiàn)的，從而更好的指導(dǎo)游戲開發(fā)。

　　版本更新，相當(dāng)于是向玩家交付新的內(nèi)容。這里可以考慮進(jìn)行灰度發(fā)布，也就是讓一小部分玩家先試用起來(lái)，效果好了之后再進(jìn)行全服更新。

　　那么問(wèn)題來(lái)了，App Store里發(fā)布App是無(wú)法進(jìn)行灰度發(fā)布的，Google Play當(dāng)中倒是可以進(jìn)行A/B Testing。對(duì)于App Store可以考慮選擇一個(gè)小的地區(qū)，例如港澳臺(tái)單獨(dú)發(fā)布測(cè)試，數(shù)據(jù)好了之后再發(fā)布大陸，可能會(huì)有一定幫助。另外是否可以利用游戲內(nèi)熱更新，進(jìn)行部分的灰度發(fā)布，這點(diǎn)應(yīng)該是可以去嘗試的。

　　3. 策劃和開發(fā)的測(cè)試

　　對(duì)于策劃和開發(fā)來(lái)說(shuō)，也應(yīng)該考慮如何更好的測(cè)試，在整個(gè)項(xiàng)目過(guò)程中，盡早持續(xù)的去準(zhǔn)備和進(jìn)行測(cè)試。

　　策劃階段，會(huì)對(duì)產(chǎn)品的功能進(jìn)行細(xì)化，形成一份可供游戲?qū)崿F(xiàn)的詳細(xì)設(shè)計(jì)方案。對(duì)于策劃來(lái)說(shuō)，測(cè)試標(biāo)準(zhǔn)除了市場(chǎng)和玩家的反饋，也應(yīng)該考慮到是否好分解、是否好實(shí)現(xiàn)、是否好測(cè)試，從設(shè)計(jì)角度去規(guī)避高風(fēng)險(xiǎn)難測(cè)試功能。有句話叫做：好的質(zhì)量是設(shè)計(jì)出來(lái)的。

　≠個(gè)例子，一個(gè)游戲里A、B、C、D這樣4個(gè)系統(tǒng)。以左圖為例，隨著系統(tǒng)的增加，系統(tǒng)之間的交互快速增加，越到后面復(fù)雜度就越高，這樣的設(shè)計(jì)越到后期，問(wèn)題就越多，開發(fā)速度就越慢。反過(guò)來(lái)看右圖，一些細(xì)節(jié)被合理的放在系統(tǒng)內(nèi)容，從而大大降低了系統(tǒng)之間的交互。我們可以看到，隨著系統(tǒng)的增加，復(fù)雜度基本保持穩(wěn)定，實(shí)現(xiàn)起來(lái)的速度也會(huì)相對(duì)較快。

　　Design

　　對(duì)于開發(fā)而言，有2點(diǎn)可以特別關(guān)注：

　　首先，對(duì)于“工作完成” (Definition of Done) 的認(rèn)識(shí)。代碼完成不等于工作完成，只有當(dāng)所有規(guī)定的開發(fā)要求達(dá)成之后(例如文檔、單元測(cè)試等)，才能稱之為工作完成。小型團(tuán)隊(duì)對(duì)于質(zhì)量難以去把控，特別要加強(qiáng)工作完成的共同理解，強(qiáng)化質(zhì)量意識(shí)。開發(fā)進(jìn)行任何修改都需要進(jìn)行測(cè)試，開發(fā)應(yīng)該要主動(dòng)告知測(cè)試修改的內(nèi)容，可能的潛在影響，從而進(jìn)行全面測(cè)試。

　　其次，開發(fā)出來(lái)的功能是不是好測(cè)試?某些功能只有在特定條件、特定等級(jí)下才能使用，那么測(cè)試是否可以比較容易的達(dá)到這樣的條件和等級(jí)，來(lái)進(jìn)行測(cè)試?還是切記一點(diǎn)，開發(fā)不是只寫完代碼就完事了，一些有助于進(jìn)行測(cè)試的功能開發(fā)也要考慮進(jìn)去。只有當(dāng)功能測(cè)試完畢正式交付之后，才能說(shuō)這個(gè)階段的開發(fā)工作全部完成了。

　　實(shí)施敏捷的難點(diǎn)

　　1. 思維方式的轉(zhuǎn)變

　　人的思維方式，是最難改變的，要通過(guò)不斷地輔導(dǎo)和實(shí)踐來(lái)進(jìn)行轉(zhuǎn)變;

　　實(shí)施敏捷可以分成幾個(gè)階段逐步實(shí)施，讓團(tuán)隊(duì)慢慢適應(yīng)敏捷開發(fā);

　　鼓勵(lì)大家提出好的方法和流程，來(lái)完善敏捷方法，真正提高效率;

　　一旦敏捷團(tuán)隊(duì)形成后，要保證團(tuán)隊(duì)穩(wěn)定，這樣即便有新人加入，也會(huì)很快習(xí)慣敏捷方法。

　　2. 缺乏自動(dòng)化測(cè)試環(huán)境

　　從技術(shù)上考慮敏捷的實(shí)現(xiàn)，最大的難點(diǎn)就是自動(dòng)化測(cè)試 AT (Automation Test)。在我目前所處的環(huán)境中，并沒(méi)有接觸到任何自動(dòng)化測(cè)試。如果要去快速、頻繁的交付，必定需要完善的自動(dòng)化測(cè)試環(huán)境。光靠人力的話，一是容易產(chǎn)生倦怠導(dǎo)致測(cè)試效果降低;二是在人員配置較少的情況下，測(cè)試覆蓋度無(wú)法保證。

　　網(wǎng)上可以找到 Riot Games 公司進(jìn)行 LoL 自動(dòng)化測(cè)試的一些資料，也看到有一些 的公司和個(gè)人在往這個(gè)方向上努力，希望能夠早日看到一些通用的解決方案，從而使整個(gè)行業(yè)的開發(fā)質(zhì)量有著明顯提升。

　　寫在最后

　　Scrum、極限編程 (XP)、精益 (Lean) 等敏捷方法中，還有很多 的方法，可以結(jié)合實(shí)際工作進(jìn)行取舍。任何一個(gè)方法，只要是適應(yīng)團(tuán)隊(duì)的、能夠真正提高效率的，那就是一個(gè)好方法!

   投稿郵箱：chuanbeiol@163.com   詳情請(qǐng)?jiān)L問(wèn)川北在線：http://m.sanmuled.cn/