你好,歡迎來到川北在線
微信
騰訊微博
新浪微博
在游戲產(chǎn)品中使用敏捷方法
時間:2017-05-19 09:24   來源:GameRes游資網(wǎng)   責任編輯:毛青青

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

  敏捷(Agile)的介紹

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

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

  個人與交互 重于 流程和工具

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

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

  響應變化 重于 按部就班

  敏捷核心是價值驅(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)品;

  及早、眷交付,進行買量測試、收集反饋。每次交付都應該是一個完整的、經(jī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)品及其應用嘲的改變而不斷演進,會逐步增加新的玩法需求、玩家反饋、運營需求、系統(tǒng)優(yōu)化等等,來保持產(chǎn)品需求的適應性、競爭力和實用性,這將貫穿于整個產(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ù)應該能在1天內(nèi)完成;對于特別大的功能,應該考慮進行拆分,逐步在各個Sprint里交付;或者單獨拉分支進行開發(fā);各個任務(wù)的工作量應該進行合理評估,從而形成清晰可見的工作計劃;

  工作分配:按照之前實際項目經(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)建,只要寫對代碼必然應該通過測試。

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

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

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

  很多時候我們在說這個核心玩法好不好玩,美術(shù)效果好不好的時候,有沒有考慮過這樣一個問題:到底是誰覺得好或者不好?是你覺得呢?還是玩家覺得?還是你想象當中的玩家,應該這樣覺得?

  其實很多時候我們會都把自己當成所有目標用戶來進行決策,一旦決策錯誤需要返工的話,核心玩法意味著游戲推倒重來,美術(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ā)布,這點應該是可以去嘗試的。

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

  對于策劃和開發(fā)來說,也應該考慮如何更好的測試,在整個項目過程中,盡早持續(xù)的去準備和進行測試。

  策劃階段,會對產(chǎn)品的功能進行細化,形成一份可供游戲?qū)崿F(xiàn)的詳細設(shè)計方案。對于策劃來說,測試標準除了市場和玩家的反饋,也應該考慮到是否好分解、是否好實現(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ā)應該要主動告知測試修改的內(nèi)容,可能的潛在影響,從而進行全面測試。

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

  實施敏捷的難點

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

  人的思維方式,是最難改變的,要通過不斷地輔導和實踐來進行轉(zhuǎn)變;

  實施敏捷可以分成幾個階段逐步實施,讓團隊慢慢適應敏捷開發(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é)合實際工作進行取舍。任何一個方法,只要是適應團隊的、能夠真正提高效率的,那就是一個好方法!

   投稿郵箱:chuanbeiol@163.com   詳情請訪問川北在線:http://dstuf.com/

川北在線-川北全搜索版權(quán)與免責聲明
①凡注明"來源:XXX(非在線)"的作品,均轉(zhuǎn)載自其它媒體,轉(zhuǎn)載目的在于傳遞更多信息,并不代表本網(wǎng)贊同其觀點和對其真實性負責,本網(wǎng)不承擔此類稿件侵權(quán)行為的連帶責任。
②本站所載之信息僅為網(wǎng)民提供參考之用,不構(gòu)成任何投資建議,文章觀點不代表本站立場,其真實性由作者或稿源方負責,本站信息接受廣大網(wǎng)民的監(jiān)督、投訴、批評。
③本站轉(zhuǎn)載純粹出于為網(wǎng)民傳遞更多信息之目的,本站不原創(chuàng)、不存儲視頻,所有視頻均分享自其他視頻分享網(wǎng)站,如涉及到您的版權(quán)問題,請與本網(wǎng)聯(lián)系,我站將及時進行刪除處理。



圖庫
合作媒體
金寵物 綠植迷 女邦網(wǎng) IT人
法律顧問:ITLAW-莊毅雄律師