在游戏产品中使用敏捷方法

always_fly

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

敏捷(Agile)的介绍

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

** 敏捷的原则（即敏捷宣言）：**

个人与交互 重于 流程和工具
可工作的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 按部就班
敏捷核心是价值驱动和快速迭代，是一种基于经验的过程控制方法，而非传统项目管理中基于预测的过程控制方法。

** 敏捷适用的范围：**

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

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

** 游戏产品适用敏捷方法 **

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

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

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

产品管理

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

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

** MVP的几个关键点**

要深入挖掘用户的最本质需求；
每次迭代结束都有一个可行性产品；
切勿追求大而全，简化任何不重要的功能，减少任何不需要的功能。
例如下图中，用户的初始需求是：我想要一辆汽车。深入挖掘后得到用户的最本质需求：我要方便出行。那么可
以通过每次迭代都有一种交通工具产出，来满足用户的最本质需求，去掉任何不相关的功能。（图片来源：谭
小超，独立面对一款新产品时，应该如何下手？）
MVP
** MMF，最小可售功能 **

MMF是可以给用户增加价值的最小单位的交付物；
通过将项目拆分为若干个MMF，团队可以专注于开发一组有价值的小功能，并迅速交付给客户；
可以把MVP理解为一组最核心MMF的集合。
** 对于一个游戏产品，特别新产品，可以去考虑 **

游戏对于玩家最大的价值是什么？游戏最核心的玩法是什么？
基于这个核心玩法，并对其他系统进行简化，从而快速构建一个游戏产品；
及早、尽快交付，进行买量测试、收集反馈。每次交付都应该是一个完整的、经过测试的、玩家可以体验的游戏；
所有游戏功能应该按照对玩家的价值进行：分类、排序、分解；
团队应该优先关注在一组高优先级的游戏功能上，而不是所有的功能实现上；
不要急于做一个大而全的游戏产品，一下子把摊子摊得太大。要先完成核心功能，然后逐步完善其他系统。
** 2. 使用 Product Backlog 和 Sprint Backlog 来管理需求 **

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、工作中障碍，风险等等；
鼓励每个人来积极参与，互相协作，主动去选择工作任务，共同承担团队的工作。

** 2. 持续集成 **

对于“工作完成”(Definition of Done)有着明确定义，团队理解并能严格遵循；
可以进行每日构建 (Daily build)，及早发现工作中的问题；
尽早、频繁交付，持续收集内部、外部反馈，并指导下一步的工作；
保持一个恒定的工作节奏(Cadence)，更加有利于工作的持续进行，例如1个月进行1次正式发布。
** 3. 团队管理 **

团队集中办公 (Co-location)，通过面对面的沟通提高工作效率；
研运一体 (DevOps)，提高协作效率，降低发布风险；
减少外部干扰，减少不必要的会议，让团队更加专注于工作本身；
通过项目回顾 (Retrospective)，让团队对工作流程和方法进行自我学习和自我完善。
** 4. 团队激励 **

开放和透明的环境，鼓励尝试，允许犯错，提高每个人的参与度；
清晰可见的工作进展，持续不断的验收交付，提升个人成就感；
能够迅速得到市场的反馈、玩家的评价，即时的外部认可、绩效反映；
及时、合理的物质激励，和个人绩效和团队绩效紧密挂钩。合理的利益分配机制是一个公司长久发展的基石。
** Build projects around motivated individuals! **
测试驱动

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

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

always_fly

** 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个系统。以左图为例，随着系统的增加，系统之间的交互快速增加
，越到后面复杂度就越高，这样的设计越到后期，问题就越多，开发速度就越慢。反过来看右图，一些细节
被合理的放在系统内容，从而大大降低了系统之间的交互。我们可以看到，随着系统的增加，复杂度基本保
持稳定，实现起来的速度也会相对较快。


对于开发而言，有2点可以特别关注：

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

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

实施敏捷的难点

** 1. 思维方式的转变**

人的思维方式，是最难改变的，要通过不断地辅导和实践来进行转变；
实施敏捷可以分成几个阶段逐步实施，让团队慢慢适应敏捷开发；
鼓励大家提出好的方法和流程，来完善敏捷方法，真正提高效率；
一旦敏捷团队形成后，要保证团队稳定，这样即便有新人加入，也会很快习惯敏捷方法。
** 2. 缺乏自动化测试环境 **

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

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

** 写在最后 **

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