【雷火UX数据产品】Scrum与游戏产品

Scrum，一个被应用在越来越多领域的概念，如今已成为了科技领域各个公司普遍使用的一套工作管理框架，游戏公司也不例外。区别于传统的项目管理，敏捷管理采用迭代的方式积极拥抱变化，迅速相应需求。如何打造更高效的团队，如何加快产品开发进程，如何有条理的管理工作日程，是每个游戏产品团队在不停探索的。

一

什么是Scrum

“Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.”

Scrum 是用于开发、交付和持续支持复杂产品的一个简单易用的框架，是一个增量的、迭代的开发过程，帮助团队和组织拆解复杂的问题从而更好产出工作成果。

Sprint

整个开发过程由若干个短的迭代周期组成，一个迭代周期称为一个Sprint。

一个Sprint 的长度一般控制在一个月以内，且周期定好了之后需要固定。若Sprint时间太长，对要构建的东西的定义就有可能会改变，同时复杂性也会上升，风险就有可能会增加。另一方面，一个固定的迭代周期能帮助团队更好的复盘工作，发现问题，并及时调整。Sprint 通过确保至少每月一次对达成目标的进度进行检视和适应，来实现可预测性，同时也把风险限制在一个月的成本上。整个Scrum团队必须在每个Sprint中创造出有价值且有实用性的迭代。对于游戏而言，Sprint周期的选择就是开发效率与响应速度之间的一个平衡。

Product Backlog

产品待办列表，记录了团队需要完成的需求。每个Sprint都需要从中挑选最高优先级的需求进行开发，挑选的需求在计划会议(Sprint Planning Meeting)经过讨论、分析和估算得到相应的任务列表，称之为Sprint backlog，这些需求在Sprint结束时必须交付。通常，挑选的任务优先级产品负责人（Product Owner）有最终决定权。

Sprint需求会议 (Sprint Planning Meeting)

讨论、分析需求的会议，并要从中选择优先级最高的需求作为当下Sprint的工作内容。

每日站会 (Daily Scrum Meeting)

由团队中Developers参与的每天的15分钟会议，通常在同一时间同一地点举行。如果PO和SM需要积极参与到这个Sprint中任务，则他们也需要参与会议。会议的目的在于推进进程，安排下一天/当天的工作，对于存在的问题做出积极响应。

Sprint评审会议 (Sprint Review Meeting)

每个Sprint的一个非正式的会议，团队将展示所作的产品或工作产出，并对展示成果做出评价提出想法。这个会议是围绕着产品进行的。

Sprint回顾会议 (Sprint Retrospective Meeting)

每个Sprint结束时的复盘会议。区别于Review，会议将讨论当前结束的Sprint中的人员以及团队的工作情况，对于当前工作状态中存在的问题进行讨论，并提出改进建议和措施。该会议是Scrum框架的重要组成部分，帮助更有效地构建、交付、管理复杂的项目。

Scrum简易流程如下所示：

二

Scrum团队

Scrum团队需要存在三个必要角色：一名Scrum Master，一名Product Owner（PO），和多名Developers。注意在这个团队中，不存在分支团队或是层级关系，整个队伍专注于同一个目标，也就是Product Goal。通常情况下，一个Scrum团队需要控制在不超过10个人的规模——既足够小来维持敏捷性，又足够大来完成每个Sprint所有重要工作。

产品负责人(Product Owner)

一般由制作人、主策或专门的助理担任，负责从Scrum团队的工作中最大化产品以及开发团队工作的价值，同时负责有效的Backlog管理，包括但不限于：

建立并于团队有效沟通产品目标（Product Goal）；
创建并清晰地表达产品待办列表项（Product Backlog）中的每一项任务；
给产品待办列表项（Product Backlog）中的任务合理排序；

确保Product Backlog是公开透明清晰，且可以被团队成员所充分理解的；
确认新功能的开发、BUG的修复。

开发人员 (Developers)

由多种掌握不同技术的人员组成的团队，跨越多个岗位，致力于完成每一次Sprint中的各项工作。以游戏为例，团队成员包括但不限于：

策划、运营、程序、美术、音效、测试等；
开发团队由组织组建并授权，团队需负责和管理他们自己的工作。

流程管理员 (Scrum Master)

既服务于PO又服务于Developers，旨在帮助团队在进行Scrum时提供解决问题的方法，扫清阻碍，让团队朝着正确的方向前进，起到一个协调者、秩序维护者、兼管理者的作用。因此一般由团队内较有威望并有深厚经验积累的人来担任。但区别于传统的PM，Developers自己负责管理自己的工作，并非由SM来监督。

三

一个Scrum团队的延伸

——SoS

随着游戏产品的一步步推进，项目组的成员会不断增多，团队规模不断升级。此时一个Scrum团队显示已不能满足需求，这时就需要拆分团队，采用Scrum of Scrums的框架。

SoS指每个团队的Scrum Master又组成了一个小组用来共享各个团队的状况，及时响应团队与团队之间的潜在问题。SoS团队让所有相关人员了解系统中其他团队发生了什么，确定什么条件下团队之间需要互相帮助，确定什么条件下团队之间需要进行协调，保证所有人员对于一个共同的产品目标有相同的理解。

SoS架构图如下所示：

四

游戏产品与Scrum

互联网时代下，变化是游戏生存之本。一个更新频率缓慢的游戏就很有可能短时间内流失大量玩家。追逐玩家们不断变化的口味，引领游戏圈的新潮流，创造更高的吸金效率，这些都是以不断的变化为基础的。

然而，没有计划和规划，过于频繁的改变对于软件开发而言是极度不友善的——变更会导致大量的重复工作，影响开发进度或是会对已完成的所有工作产生冲击与影响，带来预期之外的诸多工作。最差的后果则是因为变动问题的意见争执而产生的内部矛盾影响了产品的整体开发进度。

若根据改动需求是否会对当前开发工作产生影响来分类，大致能够分为对产生直接影响和不产生直接影响两类。前者是指正在被开发、测试、或相关开发人员处理，或者进入到当前迭代周期内待处理的工作。后者则是这个需求相关内容目前还在策划阶段，还没有送到开发人员的手中，此时的改动并不对当前的工作产生大的影响。而开发人员反对的大多都会是前者。因此，Scrum的管理模式在这个情境下非常有效——以Sprint为一个周期，所有已经在当前Sprint里的工作，无论是正在处理还是待完成的，都不允许再发生改动。若一定需要变动，那么只能中断目前工作，将该需求从开发列表中移除，修改好后，再重新放到下一轮Sprint中。若在开发完成后提出修改需求，则将其视作一个新需求，同样排期在未来的Sprint中。

随着开发成本的不断提高，对游戏公司而言提高效率将成为关键。大多公司已经不能为那些游戏开发中最后不会用到的业务模型买单了，且不能等到项目的最后再来看某个东西是否有价值，那个时候已经为时过晚，沉没成本将非常之大。而Scrum主要作用就是去掉浪费工作量的瓶颈。

另一方面，由于Scrum强调团队之间的交流协作以及快速响应，将QA纳入团队之中对于开发人员和玩家来说是双赢的局面，且QA的负荷会相较以往减少，避免了堆积的情况。如此一来，每一个bug都会被及时修正，从而提升了内容开发的速度。

当然，当公司或者一个团队决定采用Scrum的敏捷管理方式，必然也面对着一些新的挑战。

从上到下的层级管理文化转变为团队制的迭代文化——管理模式的改变比如开头是困难的，对于第一次用Scrum来开发产品的团队来说，如何扮演好自己的角色是一个挑战，要习惯按照一个Sprint的短周期进行反思和调整也是一个重大改变。

从分配监督工作转变为自发管理工作——Scrum鼓励团队进行自我管理，这种软管理模式下，每个团队成员的自发性和自律能力尤为重要，并且需要有一个共同的目标以及对其一致的理解。这也需要PO和SM的共同协作，尤其是SM，需要掌握主导权。

总结来说，Scrum归根结底只是一个框架，不同的团队，不同的Scrum Master，不同的Product Owner，都应该根据自己和产品的实际情况去制定目标管理工作，找到一个最适宜最平衡的敏捷管理模式。