原文转自巴哈姆特新闻
http://gnn.gamer.com.tw/5/118415.html
《Implosion》首席工程师
以“别太敏捷游戏开发”为题
阐述团队不断进化的心路历程
（GNN 记者 Jerry 报导） 2015-07-24 23:59:35
邀请国内外知名开发者分享自身经验的“台北游戏开发者论坛（Taipei Game
Developers Forum，简称 TGDF）”今（24）日进入最后一天，雷亚游戏技术长兼共同创
办人钟志远在本日下午以自身开发《Implosion》的经验为例，透过“别太敏捷游戏开发
”这样的主题，分享了他一路走来的心得与想法。
钟志远在《Implosion》中主要负责的是程式面的工作，这款以科幻题材为背景的 3D 动
作 RPG，可是花费了 3 年半的时间才正式完工，远远高于一般手机游戏的研发时程。
《Implosion》主美术 QQ 的小孩也从婴儿成长到要上幼稚园了
钟志远坦言一开始本来以为做游戏只要一点企划，再加上多一点的程式以及大量的美
术就可以搞定了，但实际经历过后便发现事情其实并不单纯。往往企划赶不上变化，程式
写好了也常常要修正，连带影响美术量产的格式也需要一改再改，如此一来便导致游戏发
售日期无止尽地往后延后。台大电机系毕业的他，从中了解到开发游戏与一般的软件研发
非常不同，钟志远认为游戏可说是艺术与工程的结合，是一门高深的学问。
由于经验的不足，最初开发团队使用了免费的 Google 表格来追踪每个成员的工作进度，
但由于过程实在太不严谨，导致许多成员常常故意“忘记”去填表，导致工作效率低落，
每日工作进度与每周工作进度无异，专案推展的进度也总是快不起来。
而当雷亚游戏正式成立并开始执行《Cytus》与《Implosion》的研发专案后，钟志远
发现随着专案与团队的规模愈来愈大，采用旧的方法已经不是一个好的选项，因此便采用
了知名的“敏捷开发（Scrum）”作为公司管理专案的方法与系统。
Scrum 是一种从 1990 年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对
快速变化的需求所设计出来的管理模型。Scrum 注重团队之间的紧密协作、面对面的沟通
，以及频繁交付新的软件版本等。
在最一开始，钟志远仅单纯依靠书中学来的方法来学习在团队中使用 Scrum 管理团
队专案的进度，如此一来比起以往，团队成员终于有了一个专门的时间来好好坐下来讨论
计画，也清楚接下来该做些什么。团队开始有了清楚的目标去执行，每两个礼拜也有会成
果的 Demo 展示，让产品经理能够确实掌握大家的进度。
但事实上，一切并没有那么顺利，在团队跑了半年 Scrum 之后，种种问题也开始浮
出抬面。
此时钟志远开始检讨是不是自己对于 Scrum 不够了解，一定是什么地方错了，因此
便去报名上了认证课程。并学习了更多以往不知道可以运用的 Scrum 工具回来。虽然部
分工具确实帮助了团队的专案推展，但钟志远发现也有许多部分，为团队带来更多的困扰
。
以“Planning Poker”来说，这代表每个成员可以轮流举排，显示自己对某项工作所认定
的工作量需要多少点数，若是成员间所认为的点数大小差距过大，就需要说明原因。虽然
这项工具的立意看似良好，但实际上要执行却会碰到许多难题。若以要制作一个可卷动的
UI 文件为例，程式可能会认为要 20 点，但美术会觉得这不是很简单吗？应该只要 3
点就好。
钟志远认为，因为团队成员彼此之间，对于彼此领域的认知并不熟悉，因此常常会导
致各说各话，无法准确沟通的状况。也因此，Planning Poker 针对每项工作产出的点数
往往就像掷骰子一样，准不准得靠运气。
一般来说，Scrum 可以借由各项被量化的数字来估算出一个专案可能需要耗费的时间
，如图下所示。但就如同上述 Planning Poker 的例子，在团队成员专业领域差异颇大得
状况下，很多时候这些数字无法准确反映现况，也导致专案时间根本无法精算出来。
另外一个例子，是 Scrum 里面所使用到的“检讨会议（Retrospective）”，好好使用的
话可以透过团队成员来提出改善流程的方法，进而增加团队效率。但实际实行起来，反而
大家都避重就轻，没办法直指问题核心。钟志远认为这可能是华人的民族性使然，导致大
家不擅长在台面上互相检讨。
究竟是什么原因，导致 Scrum 无法如同书本上所说的套用在雷亚的团队上？在寻找
许多现实中的案例及方法后，钟志远发现 Scrum 并不是如同刻在石板上的真理，或是设
计良好的机械，只要照着说明书去操作，把时间和钱丢进去就能够生出成果。
最终钟志远得到一个理论，Scrum 是一个成熟的敏捷开发团队典范，但却不是一个完全照
著走就能成功的教战手册。团队学习 Scrum 运作就很像阅读伟人传记，从中读者并无法
借由模仿书中案例来迈向成功人生。钟志远认为团队应该要借由 Scrum 的作法发展出独
特的工作模式，而不是直接拷贝，因为人是独一无二的，所以人组成的团队也是独一无二
的。
从这个阶段开始，钟志远便从 Scrum 的守则中取出适合的工具，再经过调整来针对
雷亚内部团队来使用。例如让团队成员间彼此分享资讯，互相沟通的每日会议（Daily
Meeting），或是让大家有个共同目标，定下短期目标的 Planning 会议。
在游戏开发的过程中，制作人当然也会希望检视开发进度与成果，辛苦工作的成员也会希
望自己努力的结晶被看到，因此就有了 Review 检视会议。
而优秀的制作人看到成果之后，当然也会想要修改、调整，让游戏变得更好，这就是
游戏产业人员最害怕看到的“更改部分规格”。这近似打掉重做的过程，常常会导致团队
士气受挫，为了避免这样的状况太常发生，团队便决定要执行更多次的 Planning 与
Review 会议，其中又尽量不更动内容，这样的过程便是 Scrum 中常用的
冲刺（Sprint）。
钟志远认为，假设一个团队没有经过反复试错的过程，便直接采用上述的作法，便容易有
水土不服的状况发生。就像学生不会因为看了励志读物，就变成人生胜利组。但管理者常
常有这样的错觉，一般来说管理者会相信只要采用了一套标准步骤，团队的效率就会突然
一飞冲天。
但事实上团队的每个人都要有这样的想法，才能持续地提升效率。若是只有团队的领
导者认同这样的作法，那就没有意义。
钟志远觉得这样的作法，需要管理职很谨慎的看待，因为团队中的被管理者，很有可
能会与管理者产生距离，像是成员若是没办法吐露真心话的话，就会导致即使团队发生问
题也收不到任何回馈的状况。钟志远以自身的经验为例，表示身为产品经理，就算只是一
个小小的指责都可能会让团队士气涣散。像是之前曾经有成员提了想法，但却马上被他打
枪。但后来才发现自己其实没有考量到企划、程式等等连带影响的状况，导致自己做了错
误的判断，让团队很有挫折感。
每个成员若是都可以观察、找出问题并提出改变的建议，进而调整团队。此时若是每个成
员也都相信改变的力量，最终便能形成正向的循环，成为一个符合 Scrum 敏捷开发的团
队
钟志远同时也以动画《闪电霹雳车》为例，表示人需要的是如同阿斯拉般，可以与主
角一起进化的系统，而不是天才也无法完全驾驭的凰呀。
此外为了克服合作以及沟通的问题，然后启动改进的循环，钟志远认为建立两好的团
队文化非常重要，因为游戏开发大多时候的过程都会需要人与人的互动，文化才是真正能
影响人与人之间的东西。而若是要建立成功的文化，则必须让团队中的每个成员，都必须
对以下两个问题非常了解，而且具备自我省思的能力。
1. 专业没有被尊重
2. 专业没有办法接纳来自非专业的看法
专业没有被尊重
以第一点来说，当程式企划彼此信任不够，便会给出似是而非的建议。身为专业的人
知道这些建议不是那么好，但当下无法反驳，其中也可能是因为职位差距的问题，但是如
此一来团队之间便会产生某些负面的刻版印象，例如“制作人就是喜欢用抄的，程式就是
喜欢用旧的，怕麻烦不爱用新引擎”，如此一来便会影响团队的速度与品质。
钟志远以《Implosion》为例，表示游戏中的装备可分为普通、进阶与卓越三个等级
。在游戏的开发过程中，就曾有人反映最高级的武器应该可以让主角有着超越超级赛亚人
3 的强度，砍敌人就像砍菜一样，这样才合理。
虽然说这样的建议听起来很合理，但由于游戏关卡有限，没有那么多空间将拿到卓越装备
的角色，在破关的过程中拉回适当的难度。此外由于《Implosion》的重点是战斗中带给
玩家的挑战，若是武器设计地太强，后面关卡躺着也可以过的话，就违背游戏本身的主轴
，也会降低游戏体验。
钟志远认为尊重专业看起来很简单，但其实很难。大部分的问题都像冰山，真正浮出
抬面被检视到的不多，只有在做事的人才能发现冰山下面较难被发现的东西。
因此钟志远认为，尊重专业不是了解到“我要尊重”而以，而是要深深地输入到潜意
识中才行。