你好,欢迎来到川北在线
微信
腾讯微博
新浪微博
在游戏产品中使用敏捷方法
时间:2017-05-19 09:24   来源:GameRes游资网   责任编辑:毛青青

川北在线核心提示:随着开发技术的不断演进和玩家需求的日新月异,游戏产品日趋复杂。那么如何来更好的管理游戏产品呢?这里我们引入敏捷方法来进行更高效的产品交付。 敏捷(Agile)的介绍 敏捷(Agile)是一种新型软件开发方法,以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开


  随着开发技术的不断演进和玩家需求的日新月异,游戏产品日趋复杂。那么如何来更好的管理游戏产品呢?这里我们引入敏捷方法来进行更高效的产品交付。

  敏捷(Agile)的介绍

  敏捷(Agile)是一种新型软件开发方法,以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发,可以应对快速变化的需求。

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

  个人与交互 重于 流程和工具

 ∩工作的软件 重于 完备的文档

 ⊥户协作 重于 合同谈判

  响应变化 重于 按部就班

  敏捷核心是价值驱动和快速迭代,是一种基于经验的过程控制方法,而非传统项目管理中基于预测的过程控制方法。

  敏捷适用的范围:

  当需求存在不确定性、对于实现难以达成一致意见,那么就会呈现出复杂系统的特征,例如开发一款全新的游戏产品。敏捷方法对于这种需要作出复杂决策的项目中是很好的选择。

  (另外,如果一个项目中大部分的细节已经知道,很多事情大家都很容易达成之一,且具有较大的确定性,那么瀑布式方法可能是最好的选择,例如换皮项目。)

  

  Stacey Matrix

  游戏产品适用敏捷方法

  游戏是一种复杂的产品,需要融合技术、美术、音乐、数值、剧情、付费等等,玩家的需求又是多种多样、快速变化。所以游戏项目需要复杂决策,适用敏捷方法。

  大到 Activision Blizzard, Supercell 这样的巨无霸,小到无数欧美的游戏工作室,都在一定程度上使用了敏捷方法,来提升产品交付的速度和价值。

  结合这几年我在手机游戏项目中的实际工作经验和项目上的思考,分享一些对大家有价值的敏捷方法和实践。

  产品管理

  1. 使用 MVP 和 MMF 来构建游戏产品

  MVP,最简化可实行产品,即用最快、最简明的方式建立一个可用的产品原型,这个原型要表达出你产品最终想要的效果,然后通过迭代来完善细节。

  MVP的几个关键点

  要深入挖掘用户的最本质需求;

  每次迭代结束都有一个可行性产品;

  切勿追求大而全,简化任何不重要的功能,减少任何不需要的功能。

  例如下图中,用户的初始需求是:我想要一辆汽车。深入挖掘后得到用户的最本质需求:我要方便出行。那么可以通过每次迭代都有一种交通工具产出,来满足用户的最本质需求,去掉任何不相关的功能。

  MVP

  MMF,最猩售功能

  MMF是可以给用户增加价值的最小单位的交付物;

  通过将项目拆分为若干个MMF,团队可以专注于开发一组有价值的小功能,并迅速交付给客户;

 ∩以把MVP理解为一组最核心MMF的集合。

  对于一个游戏产品,特别新产品,可以去考虑:

  游戏对于玩家最大的价值是什么?游戏最核心的玩法是什么?

  基于这个核心玩法,并对其他系统进行简化,从而快速构建一个游戏产品;

  及早、眷交付,进行买量测试、收集反馈。每次交付都应该是一个完整的、经过测试的、玩家可以体验的游戏;

  所有游戏功能应该按照对玩家的价值进行:分类、排序、分解;

  团队应该优先关注在一组高优先级的游戏功能上,而不是所有的功能实现上;

  不要急于做一个大而全的游戏产品,一下子把摊子摊得太大。要先完成核心功能,然后逐步完善其他系统。

  2. 使用 Product Backlog 和 Sprint Backlog 来管理需求

  Scrum是敏捷方法中一种重要的软件开发方法,Scrum包含了一套完整的项目流程的框架,如下图所示:

  Scrum

  Product Backlog (产品待办列表)是一个排序的列表,包含所有产品需要的东西,也是产品需求变动的唯一来源。产品负责人负责维护产品待办列表的内容、可用性和优先级。

  Sprint Backlog(迭代待办列表)是一组为当前 Sprint (冲刺=迭代)选出的 Product Backlog,外加交付产品增量和实现 Sprint 目标的计划。Sprint Backlog是开发团队对于哪些功能要包含在下个增量中,以及交付那些功能所需工作的预计。

  在实际工作中的使用

 ∩以把 Product Backlog 作为产品的中长期目标,使用Excel来记录产品的功能点、优先级、大致工作量等,列表内容进行持续更新、逐渐细化;

  Sprint Backlog 作为产品的短期目标,需要撰写详细的策划案,明确清晰的定义功能,并且能在迭代周期内容按时完成;

  一次迭代完成后,从Product Backlog中抽取最高优先级的功能需求,放入Sprint Backlog中,进行细化并实现,以此往复。

  对于Product Backlog

  唯一性:作为产品需求唯一的来源,所有需求必须放入Product Backlog中进行统一管理;

  动态性:产品待办列表一直是动态的,需要持续更新,初期主要包括理解最透彻的那些产品需求,然后随着产品及其应用嘲的改变而不断演进,会逐步增加新的玩法需求、玩家反馈、运营需求、系统优化等等,来保持产品需求的适应性、竞争力和实用性,这将贯穿于整个产品生命周期的始终;

  渐进明细:定期进行“产品待办列表细化”,主要工作内容是为待办列表条目补充细节描述、工作量估算(可以采用相对估算)、对大型条目进行合理拆分,必要时调整待办列表条目的优先级顺序,始终优先开发高价值的功能;

  负责人:有专人进行定义维护Product Backlog,可以是制作人或者主策,然后让所有项目参与者达成共识,加深对游戏发展的方向的理解,提前做好准备。Product Backlog可以作为产品的中长期目标。

  对于Sprint Backlog

  内容:包含当前迭代的需求,也就是Product Backlog中优先级最高的需求,而且能够在一个迭代中完成;

  细化:需要进行细化,并分解为完成需求的多个具体任务,每个任务应该能在1天内完成;对于特别大的功能,应该考虑进行拆分,逐步在各个Sprint里交付;或者单独拉分支进行开发;各个任务的工作量应该进行合理评估,从而形成清晰可见的工作计划;

  工作分配:按照之前实际项目经验,每次迭代中,合理的工作量分布大概为:新玩法: 1/3;付费和留存改进:1/3;bug fix和系统优化:1/3。所以对于每个迭代,不能完全放满新玩法的实现,需要留出足够的时间去做各方面的改进和优化。

  负责人:Sprint Backlog的内容,可以在主策的组织下进行任务细化,形成当前版本的详细策划案,所有团队成员通过评审、讨论、工作量评估,完全理解策划案的内容。Spring Backlog可以作为产品的短期目标。

  日常工作

  1. 任务管理

  通过每日站会、看板来建立一个信息透明、及时反馈的工作环境;

  每日站会,15分钟3个问题,目的让大家分享工作成果、确定今天计划、及早发现和解决问题;

 〈板(Kanban),实现管理的可视化,所有信息可以集成到看板中,进行统一管理。甚至可以用看板管理所有的需求、bug、工作中障碍,风险等等;

  鼓励每个人来积极参与,互相协作,主动去选择工作任务,共同承担团队的工作。

  Kanban

  2. 持续集成

  对于“工作完成”(Definition of Done)有着明确定义,团队理解并能严格遵循;

 ∩以进行每日构建 (Daily build),及早发现工作中的问题;

  早、频繁交付,持续收集内部、外部反馈,并指导下一步的工作;

  保持一个恒定的工作节奏(Cadence),更加有利于工作的持续进行,例如1个月进行1次正式发布。

  3. 团队管理

  团队集中办公 (Co-location),通过面对面的沟通提高工作效率;

  研运一体 (DevOps),提高协作效率,降低发布风险;

  减少外部干扰,减少不必要的会议,让团队更加专注于工作本身;

  通过项目回顾 (Retrospective),让团队对工作流程和方法进行自我学习和自我完善。

  4. 团队激励

 —放和透明的环境,鼓励尝试,允许犯错,提高每个人的参与度;

  清晰可见的工作进展,持续不断的验收交付,提升个人成就感;

  能够迅速得到市场的反馈、玩家的评价,即时的外部认可、绩效反映;

  及时、合理的物质激励,和个人绩效和团队绩效紧密挂钩。合理的利益分配机制是一个公司长久发展的基石。

  测试驱动

  测试驱动开发TDD(Test-Driven Development),是一种敏捷的开发实践,是指先对软件的验收测试进行定义,再编写模块代码,这些代码将围绕着通过这些测试而构建,只要写对代码必然应该通过测试。

  如果宏观的去思考测试驱动,对于任何一个游戏产品,最终的验收标准都会是:是否能够得到市场的认可、得到玩家的喜爱。如果我们围绕着这个标准去做,尽早得到市场和玩家的反馈,从而指导游戏的设计和开发,那么可以更好的帮助我们得到一个受到市场和玩家欢迎的产品。

  1. 核心玩法、美术设定

  核心玩法,是游戏中最重要部分;美术,作为游戏第一眼的印象,对于游戏产品的成功也是至关重要。

  很多时候我们在说这个核心玩法好不好玩,美术效果好不好的时候,有没有考虑过这样一个问题:到底是谁觉得好或者不好?是你觉得呢?还是玩家觉得?还是你想象当中的玩家,应该这样觉得?

  其实很多时候我们会都把自己当成所有目标用户来进行决策,一旦决策错误需要返工的话,核心玩法意味着游戏推倒重来,美术意味着巨大的重新制作或外包成本,这都是一个公司不愿意去承受的成本。

  那么如何让玩家来尽早提供对核心玩法和美术设定的反馈呢?

  我们可以从游戏项目概念阶段开始,就逐步进行美术和核心玩法的测试。例如,美术设定,直接可以从游戏ICON和游戏截图中体现,通过广告进行买量测试,从而来识别玩家对于哪种美术设定更加接受;核心玩法可以使用前面讲过的MVP的方法,快速构建最简化可实行产品,然后进行买量测试,收集玩家数据,逐渐完善游戏功能。

  这样的用户测试,需要在项目初期和开发中,不断的进行广告投入,但这个费用比项目上线后,再去进行大范围的修改,成本远远低的多!特别当你的游戏产品可能有爆发性用户增长的时候(例如推荐),先调优再上线,这点特别重要。

  2. 游戏运营、版本更新

  运营数据,通过事件跟踪SDK在游戏内打点后,我们可以很容易得到游戏的运营数据,例如:DAU, D1, D7, D30, Conversion rate, Session duration 等等,这在游戏行业已经是非常成熟的模式了。通过持续的运营数据跟踪,关联到各个版本之间的内容改动,我们可以从大量数据中得到规律性的东西,什么是玩家真正喜闻乐见的,从而更好的指导游戏开发。

  版本更新,相当于是向玩家交付新的内容。这里可以考虑进行灰度发布,也就是让一小部分玩家先试用起来,效果好了之后再进行全服更新。

  那么问题来了,App Store里发布App是无法进行灰度发布的,Google Play当中倒是可以进行A/B Testing。对于App Store可以考虑选择一个小的地区,例如港澳台单独发布测试,数据好了之后再发布大陆,可能会有一定帮助。另外是否可以利用游戏内热更新,进行部分的灰度发布,这点应该是可以去尝试的。

  3. 策划和开发的测试

  对于策划和开发来说,也应该考虑如何更好的测试,在整个项目过程中,尽早持续的去准备和进行测试。

  策划阶段,会对产品的功能进行细化,形成一份可供游戏实现的详细设计方案。对于策划来说,测试标准除了市场和玩家的反馈,也应该考虑到是否好分解、是否好实现、是否好测试,从设计角度去规避高风险难测试功能。有句话叫做:好的质量是设计出来的。

 ≠个例子,一个游戏里A、B、C、D这样4个系统。以左图为例,随着系统的增加,系统之间的交互快速增加,越到后面复杂度就越高,这样的设计越到后期,问题就越多,开发速度就越慢。反过来看右图,一些细节被合理的放在系统内容,从而大大降低了系统之间的交互。我们可以看到,随着系统的增加,复杂度基本保持稳定,实现起来的速度也会相对较快。

  Design

  对于开发而言,有2点可以特别关注:

  首先,对于“工作完成” (Definition of Done) 的认识。代码完成不等于工作完成,只有当所有规定的开发要求达成之后(例如文档、单元测试等),才能称之为工作完成。小型团队对于质量难以去把控,特别要加强工作完成的共同理解,强化质量意识。开发进行任何修改都需要进行测试,开发应该要主动告知测试修改的内容,可能的潜在影响,从而进行全面测试。

  其次,开发出来的功能是不是好测试?某些功能只有在特定条件、特定等级下才能使用,那么测试是否可以比较容易的达到这样的条件和等级,来进行测试?还是切记一点,开发不是只写完代码就完事了,一些有助于进行测试的功能开发也要考虑进去。只有当功能测试完毕正式交付之后,才能说这个阶段的开发工作全部完成了。

  实施敏捷的难点

  1. 思维方式的转变

  人的思维方式,是最难改变的,要通过不断地辅导和实践来进行转变;

  实施敏捷可以分成几个阶段逐步实施,让团队慢慢适应敏捷开发;

  鼓励大家提出好的方法和流程,来完善敏捷方法,真正提高效率;

  一旦敏捷团队形成后,要保证团队稳定,这样即便有新人加入,也会很快习惯敏捷方法。

  2. 缺乏自动化测试环境

  从技术上考虑敏捷的实现,最大的难点就是自动化测试 AT (Automation Test)。在我目前所处的环境中,并没有接触到任何自动化测试。如果要去快速、频繁的交付,必定需要完善的自动化测试环境。光靠人力的话,一是容易产生倦怠导致测试效果降低;二是在人员配置较少的情况下,测试覆盖度无法保证。

  网上可以找到 Riot Games 公司进行 LoL 自动化测试的一些资料,也看到有一些优秀的公司和个人在往这个方向上努力,希望能够早日看到一些通用的解决方案,从而使整个行业的开发质量有着明显提升。

  写在最后

  Scrum、极限编程 (XP)、精益 (Lean) 等敏捷方法中,还有很多优秀的方法,可以结合实际工作进行取舍。任何一个方法,只要是适应团队的、能够真正提高效率的,那就是一个好方法!

   投稿邮箱:chuanbeiol@163.com   详情请访问川北在线:http://www.guangyuanol.cn


>>相关文章
川北在线-川北全搜索版权与免责声明
①凡注明"来源:XXX(非在线)"的作品,均转载自其它媒体,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责,本网不承担此类稿件侵权行为的连带责任。
②本站所载之信息仅为网民提供参考之用,不构成任何投资建议,文章观点不代表本站立场,其真实性由作者或稿源方负责,本站信息接受广大网民的监督、投诉、批评。
③本站转载纯粹出于为网民传递更多信息之目的,本站不原创、不存储视频,所有视频均分享自其他视频分享网站,如涉及到您的版权问题,请与本网联系,我站将及时进行删除处理。



图库
合作媒体
360传媒
电影网
爱卡汽车
法律顾问:ITLAW-庄毅雄律师