隨著開發(fā)技術(shù)的不斷演進和玩家需求的日新月異，游戲產(chǎn)品日趨復雜。那么如何來更好的管理游戲產(chǎn)品呢?這里我們引入敏捷方法來進行更高效的產(chǎn)品交付。
敏捷(Agile)的介紹
敏捷(Agile)是一種新型軟件開發(fā)方法，以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發(fā)，可以應(yīng)對快速變化的需求。
敏捷的原則(即敏捷宣言)：
個人與交互 重于 流程和工具
∩工作的軟件 重于 完備的文檔
⊥戶協(xié)作 重于 合同談判
響應(yīng)變化 重于 按部就班
敏捷核心是價值驅(qū)動和快速迭代，是一種基于經(jīng)驗的過程控制方法，而非傳統(tǒng)項目管理中基于預測的過程控制方法。
敏捷適用的范圍：
當需求存在不確定性、對于實現(xiàn)難以達成一致意見，那么就會呈現(xiàn)出復雜系統(tǒng)的特征，例如開發(fā)一款全新的游戲產(chǎn)品。敏捷方法對于這種需要作出復雜決策的項目中是很好的選擇。
(另外，如果一個項目中大部分的細節(jié)已經(jīng)知道，很多事情大家都很容易達成之一，且具有較大的確定性，那么瀑布式方法可能是最好的選擇，例如換皮項目。)
Stacey Matrix
游戲產(chǎn)品適用敏捷方法
游戲是一種復雜的產(chǎn)品，需要融合技術(shù)、美術(shù)、音樂、數(shù)值、劇情、付費等等，玩家的需求又是多種多樣、快速變化。所以游戲項目需要復雜決策，適用敏捷方法。
大到 Activision Blizzard, Supercell 這樣的巨無霸，小到無數(shù)歐美的游戲工作室，都在一定程度上使用了敏捷方法，來提升產(chǎn)品交付的速度和價值。
結(jié)合這幾年我在手機游戲項目中的實際工作經(jīng)驗和項目上的思考，分享一些對大家有價值的敏捷方法和實踐。
產(chǎn)品管理
1. 使用 MVP 和 MMF 來構(gòu)建游戲產(chǎn)品
MVP，最簡化可實行產(chǎn)品，即用最快、最簡明的方式建立一個可用的產(chǎn)品原型，這個原型要表達出你產(chǎn)品最終想要的效果，然后通過迭代來完善細節(jié)。
MVP的幾個關(guān)鍵點
要深入挖掘用戶的最本質(zhì)需求;
每次迭代結(jié)束都有一個可行性產(chǎn)品;
切勿追求大而全，簡化任何不重要的功能，減少任何不需要的功能。
例如下圖中，用戶的初始需求是：我想要一輛汽車。深入挖掘后得到用戶的最本質(zhì)需求：我要方便出行。那么可以通過每次迭代都有一種交通工具產(chǎn)出，來滿足用戶的最本質(zhì)需求，去掉任何不相關(guān)的功能。
MVP
MMF，最猩售功能
MMF是可以給用戶增加價值的最小單位的交付物;
通過將項目拆分為若干個MMF，團隊可以專注于開發(fā)一組有價值的小功能，并迅速交付給客戶;
∩以把MVP理解為一組最核心MMF的集合。
對于一個游戲產(chǎn)品，特別新產(chǎn)品，可以去考慮：
游戲?qū)τ谕婕易畲蟮膬r值是什么?游戲最核心的玩法是什么?
基于這個核心玩法，并對其他系統(tǒng)進行簡化，從而快速構(gòu)建一個游戲產(chǎn)品;
及早、眷交付，進行買量測試、收集反饋。每次交付都應(yīng)該是一個完整的、經(jīng)過測試的、玩家可以體驗的游戲;
所有游戲功能應(yīng)該按照對玩家的價值進行：分類、排序、分解;
團隊應(yīng)該優(yōu)先關(guān)注在一組高優(yōu)先級的游戲功能上，而不是所有的功能實現(xiàn)上;
不要急于做一個大而全的游戲產(chǎn)品，一下子把攤子攤得太大。要先完成核心功能，然后逐步完善其他系統(tǒng)。
2. 使用 Product Backlog 和 Sprint Backlog 來管理需求
Scrum是敏捷方法中一種重要的軟件開發(fā)方法，Scrum包含了一套完整的項目流程的框架，如下圖所示：
Scrum
Product Backlog (產(chǎn)品待辦列表)是一個排序的列表，包含所有產(chǎn)品需要的東西，也是產(chǎn)品需求變動的 來源。產(chǎn)品負責人負責維護產(chǎn)品待辦列表的內(nèi)容、可用性和優(yōu)先級。
Sprint Backlog(迭代待辦列表)是一組為當前 Sprint (沖刺=迭代)選出的 Product Backlog，外加交付產(chǎn)品增量和實現(xiàn) Sprint 目標的計劃。Sprint Backlog是開發(fā)團隊對于哪些功能要包含在下個增量中，以及交付那些功能所需工作的預計。
在實際工作中的使用
∩以把 Product Backlog 作為產(chǎn)品的中長期目標，使用Excel來記錄產(chǎn)品的功能點、優(yōu)先級、大致工作量等，列表內(nèi)容進行持續(xù)更新、逐漸細化;
Sprint Backlog 作為產(chǎn)品的短期目標，需要撰寫詳細的策劃案，明確清晰的定義功能，并且能在迭代周期內(nèi)容按時完成;
一次迭代完成后，從Product Backlog中抽取 優(yōu)先級的功能需求，放入Sprint Backlog中，進行細化并實現(xiàn)，以此往復。
對于Product Backlog
性：作為產(chǎn)品需求 的來源，所有需求必須放入Product Backlog中進行統(tǒng)一管理;
動態(tài)性：產(chǎn)品待辦列表一直是動態(tài)的，需要持續(xù)更新，初期主要包括理解最透徹的那些產(chǎn)品需求，然后隨著產(chǎn)品及其應(yīng)用嘲的改變而不斷演進，會逐步增加新的玩法需求、玩家反饋、運營需求、系統(tǒng)優(yōu)化等等，來保持產(chǎn)品需求的適應(yīng)性、競爭力和實用性，這將貫穿于整個產(chǎn)品生命周期的始終;
漸進明細：定期進行“產(chǎn)品待辦列表細化”，主要工作內(nèi)容是為待辦列表條目補充細節(jié)描述、工作量估算(可以采用相對估算)、對大型條目進行合理拆分，必要時調(diào)整待辦列表條目的優(yōu)先級順序，始終優(yōu)先開發(fā)高價值的功能;
負責人：有專人進行定義維護Product Backlog，可以是制作人或者主策，然后讓所有項目參與者達成共識，加深對游戲發(fā)展的方向的理解，提前做好準備。Product Backlog可以作為產(chǎn)品的中長期目標。
對于Sprint Backlog
內(nèi)容：包含當前迭代的需求，也就是Product Backlog中優(yōu)先級 的需求，而且能夠在一個迭代中完成;
細化：需要進行細化，并分解為完成需求的多個具體任務(wù)，每個任務(wù)應(yīng)該能在1天內(nèi)完成;對于特別大的功能，應(yīng)該考慮進行拆分，逐步在各個Sprint里交付;或者單獨拉分支進行開發(fā);各個任務(wù)的工作量應(yīng)該進行合理評估，從而形成清晰可見的工作計劃;
工作分配：按照之前實際項目經(jīng)驗，每次迭代中，合理的工作量分布大概為：新玩法： 1/3;付費和留存改進：1/3;bug fix和系統(tǒng)優(yōu)化：1/3。所以對于每個迭代，不能完全放滿新玩法的實現(xiàn)，需要留出足夠的時間去做各方面的改進和優(yōu)化。
負責人：Sprint Backlog的內(nèi)容，可以在主策的組織下進行任務(wù)細化，形成當前版本的詳細策劃案，所有團隊成員通過評審、討論、工作量評估，完全理解策劃案的內(nèi)容。Spring Backlog可以作為產(chǎn)品的短期目標。
日常工作
1. 任務(wù)管理
通過每日站會、看板來建立一個信息透明、及時反饋的工作環(huán)境;
每日站會，15分鐘3個問題，目的讓大家分享工作成果、確定今天計劃、及早發(fā)現(xiàn)和解決問題;
〈板(Kanban)，實現(xiàn)管理的可視化，所有信息可以集成到看板中，進行統(tǒng)一管理。甚至可以用看板管理所有的需求、bug、工作中障礙，風險等等;
鼓勵每個人來積極參與，互相協(xié)作，主動去選擇工作任務(wù)，共同承擔團隊的工作。
Kanban
2. 持續(xù)集成
對于“工作完成”(Definition of Done)有著明確定義，團隊理解并能嚴格遵循;
∩以進行每日構(gòu)建 (Daily build)，及早發(fā)現(xiàn)工作中的問題;
早、頻繁交付，持續(xù)收集內(nèi)部、外部反饋，并指導下一步的工作;
保持一個恒定的工作節(jié)奏(Cadence)，更加有利于工作的持續(xù)進行，例如1個月進行1次正式發(fā)布。
3. 團隊管理
團隊集中辦公 (Co-location)，通過面對面的溝通提高工作效率;
研運一體 (DevOps)，提高協(xié)作效率，降低發(fā)布風險;
減少外部干擾，減少不必要的會議，讓團隊更加專注于工作本身;
通過項目回顧 (Retrospective)，讓團隊對工作流程和方法進行自我學習和自我完善。
4. 團隊激勵
—放和透明的環(huán)境，鼓勵嘗試，允許犯錯，提高每個人的參與度;
清晰可見的工作進展，持續(xù)不斷的驗收交付，提升個人成就感;
能夠迅速得到市場的反饋、玩家的評價，即時的外部認可、績效反映;
及時、合理的物質(zhì)激勵，和個人績效和團隊績效緊密掛鉤。合理的利益分配機制是一個公司長久發(fā)展的基石。
測試驅(qū)動
測試驅(qū)動開發(fā)TDD(Test-Driven Development)，是一種敏捷的開發(fā)實踐，是指先對軟件的驗收測試進行定義，再編寫模塊代碼，這些代碼將圍繞著通過這些測試而構(gòu)建，只要寫對代碼必然應(yīng)該通過測試。
如果宏觀的去思考測試驅(qū)動，對于任何一個游戲產(chǎn)品，最終的驗收標準都會是：是否能夠得到市場的認可、得到玩家的喜愛。如果我們圍繞著這個標準去做，盡早得到市場和玩家的反饋，從而指導游戲的設(shè)計和開發(fā)，那么可以更好的幫助我們得到一個受到市場和玩家歡迎的產(chǎn)品。
1. 核心玩法、美術(shù)設(shè)定
核心玩法，是游戲中最重要部分;美術(shù)，作為游戲第一眼的印象，對于游戲產(chǎn)品的成功也是至關(guān)重要。
很多時候我們在說這個核心玩法好不好玩，美術(shù)效果好不好的時候，有沒有考慮過這樣一個問題：到底是誰覺得好或者不好?是你覺得呢?還是玩家覺得?還是你想象當中的玩家，應(yīng)該這樣覺得?
其實很多時候我們會都把自己當成所有目標用戶來進行決策，一旦決策錯誤需要返工的話，核心玩法意味著游戲推倒重來，美術(shù)意味著巨大的重新制作或外包成本，這都是一個公司不愿意去承受的成本。
那么如何讓玩家來盡早提供對核心玩法和美術(shù)設(shè)定的反饋呢?
我們可以從游戲項目概念階段開始，就逐步進行美術(shù)和核心玩法的測試。例如，美術(shù)設(shè)定，直接可以從游戲ICON和游戲截圖中體現(xiàn)，通過廣告進行買量測試，從而來識別玩家對于哪種美術(shù)設(shè)定更加接受;核心玩法可以使用前面講過的MVP的方法，快速構(gòu)建最簡化可實行產(chǎn)品，然后進行買量測試，收集玩家數(shù)據(jù)，逐漸完善游戲功能。
這樣的用戶測試，需要在項目初期和開發(fā)中，不斷的進行廣告投入，但這個費用比項目上線后，再去進行大范圍的修改，成本遠遠低的多!特別當你的游戲產(chǎn)品可能有爆發(fā)性用戶增長的時候(例如推薦)，先調(diào)優(yōu)再上線，這點特別重要。
2. 游戲運營、版本更新
運營數(shù)據(jù)，通過事件跟蹤SDK在游戲內(nèi)打點后，我們可以很容易得到游戲的運營數(shù)據(jù)，例如：DAU, D1, D7, D30, Conversion rate, Session duration 等等，這在游戲行業(yè)已經(jīng)是非常成熟的模式了。通過持續(xù)的運營數(shù)據(jù)跟蹤，關(guān)聯(lián)到各個版本之間的內(nèi)容改動，我們可以從大量數(shù)據(jù)中得到規(guī)律性的東西，什么是玩家真正喜聞樂見的，從而更好的指導游戲開發(fā)。
版本更新，相當于是向玩家交付新的內(nèi)容。這里可以考慮進行灰度發(fā)布，也就是讓一小部分玩家先試用起來，效果好了之后再進行全服更新。
那么問題來了，App Store里發(fā)布App是無法進行灰度發(fā)布的，Google Play當中倒是可以進行A/B Testing。對于App Store可以考慮選擇一個小的地區(qū)，例如港澳臺單獨發(fā)布測試，數(shù)據(jù)好了之后再發(fā)布大陸，可能會有一定幫助。另外是否可以利用游戲內(nèi)熱更新，進行部分的灰度發(fā)布，這點應(yīng)該是可以去嘗試的。
3. 策劃和開發(fā)的測試
對于策劃和開發(fā)來說，也應(yīng)該考慮如何更好的測試，在整個項目過程中，盡早持續(xù)的去準備和進行測試。
策劃階段，會對產(chǎn)品的功能進行細化，形成一份可供游戲?qū)崿F(xiàn)的詳細設(shè)計方案。對于策劃來說，測試標準除了市場和玩家的反饋，也應(yīng)該考慮到是否好分解、是否好實現(xiàn)、是否好測試，從設(shè)計角度去規(guī)避高風險難測試功能。有句話叫做：好的質(zhì)量是設(shè)計出來的。
≠個例子，一個游戲里A、B、C、D這樣4個系統(tǒng)。以左圖為例，隨著系統(tǒng)的增加，系統(tǒng)之間的交互快速增加，越到后面復雜度就越高，這樣的設(shè)計越到后期，問題就越多，開發(fā)速度就越慢。反過來看右圖，一些細節(jié)被合理的放在系統(tǒng)內(nèi)容，從而大大降低了系統(tǒng)之間的交互。我們可以看到，隨著系統(tǒng)的增加，復雜度基本保持穩(wěn)定，實現(xiàn)起來的速度也會相對較快。
Design
對于開發(fā)而言，有2點可以特別關(guān)注：
首先，對于“工作完成” (Definition of Done) 的認識。代碼完成不等于工作完成，只有當所有規(guī)定的開發(fā)要求達成之后(例如文檔、單元測試等)，才能稱之為工作完成。小型團隊對于質(zhì)量難以去把控，特別要加強工作完成的共同理解，強化質(zhì)量意識。開發(fā)進行任何修改都需要進行測試，開發(fā)應(yīng)該要主動告知測試修改的內(nèi)容，可能的潛在影響，從而進行全面測試。
其次，開發(fā)出來的功能是不是好測試?某些功能只有在特定條件、特定等級下才能使用，那么測試是否可以比較容易的達到這樣的條件和等級，來進行測試?還是切記一點，開發(fā)不是只寫完代碼就完事了，一些有助于進行測試的功能開發(fā)也要考慮進去。只有當功能測試完畢正式交付之后，才能說這個階段的開發(fā)工作全部完成了。
實施敏捷的難點
1. 思維方式的轉(zhuǎn)變
人的思維方式，是最難改變的，要通過不斷地輔導和實踐來進行轉(zhuǎn)變;
實施敏捷可以分成幾個階段逐步實施，讓團隊慢慢適應(yīng)敏捷開發(fā);
鼓勵大家提出好的方法和流程，來完善敏捷方法，真正提高效率;
一旦敏捷團隊形成后，要保證團隊穩(wěn)定，這樣即便有新人加入，也會很快習慣敏捷方法。
2. 缺乏自動化測試環(huán)境
從技術(shù)上考慮敏捷的實現(xiàn)，最大的難點就是自動化測試 AT (Automation Test)。在我目前所處的環(huán)境中，并沒有接觸到任何自動化測試。如果要去快速、頻繁的交付，必定需要完善的自動化測試環(huán)境。光靠人力的話，一是容易產(chǎn)生倦怠導致測試效果降低;二是在人員配置較少的情況下，測試覆蓋度無法保證。
網(wǎng)上可以找到 Riot Games 公司進行 LoL 自動化測試的一些資料，也看到有一些 的公司和個人在往這個方向上努力，希望能夠早日看到一些通用的解決方案，從而使整個行業(yè)的開發(fā)質(zhì)量有著明顯提升。
寫在最后
Scrum、極限編程 (XP)、精益 (Lean) 等敏捷方法中，還有很多 的方法，可以結(jié)合實際工作進行取舍。任何一個方法，只要是適應(yīng)團隊的、能夠真正提高效率的，那就是一個好方法!
投稿郵箱：chuanbeiol@163.com 詳情請訪問川北在線：http://sanmuled.cn/
