原文转自巴哈姆特新闻 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》的重点是战斗中带给 玩家的挑战，若是武器设计地太强，後面关卡躺着也可以过的话，就违背游戏本身的主轴 ，也会降低游戏体验。 　　钟志远认为尊重专业看起来很简单，但其实很难。大部分的问题都像冰山，真正浮出 抬面被检视到的不多，只有在做事的人才能发现冰山下面较难被发现的东西。 　　因此钟志远认为，尊重专业不是了解到「我要尊重」而以，而是要深深地输入到潜意 识中才行。 -- 专业没办法接纳来自非专业的看法 以上的影片是《Implosion》最早针对 Xbox 平台所打造的版本，虽然画面不错，但与厂 商交涉的过程不是那麽顺利。就在当时，团队也刚好经历手机游戏崛起的时间点，因此制 作人便提出想要改成在手机上制作的想法。 　　但当时担任主程式的钟志远认为两个平台特性相差太多，这样的作法根本不可行，便 强力否决掉这项提议。为了改变钟志远的成见，团队中的主美术 QQ 利用手头上仅有的资 源，打造了一个在手机上运行的 Demo，证明即使在手机上也可以呈现不错的效果，也因 此让钟志远发现自己下的决定太过武断，狠狠地被打脸。现在回头，钟志远非常感谢有了 QQ 的建议，否则便不会有手机版《Implosion》的诞生。 以刚才的例子来说，钟志远认为当初在讨论的时候应该好好去分析前因後果，而不是依赖 直觉去下决定，这样容易产生盲点。很多人常常说专业是如何地不被尊重，但其实专业也 是有盲点，检讨自己也最困难。 　　另外一个导致专业无法运作的，则是太过专注会导致专业人员无法接受或了解外来的 有效建议，或是无法做出比眼前结果更好的决定。以下图来解释的话，若是从起点开始往 右，若是只专注在局部，那最多可能只能停留在 A 点，而无法更上层楼至更高的 B 点。 企划、美术与程式都有各自想要追求的东西，钟志远认为这就是所谓的「局部最佳问题」 。他认为一款好的游戏不一定要在每个环节都追求到极致。但当专精不同领域的成员在讨 论一件事情的时候，彼此之间提出的问题却可能会激怒对方，衍生出「专业 vs 非专业」 的状况。 　　这时为了找到平衡点，了解到什麽样的问题「我」才能够提出建议？钟志远认为团队 成员应该要有共识，了解到「当非专业的人发现你的问题时，并不是因为他们比你厉害， 而是因为你正在解决眼前正前方的问题，你把背後留给他们掩护」。有了这样的信任，团 队才能启动改进的循环，让团队愈来愈好。 总结 　　一个优秀的团队并不是遵守 Scrum 的教条与规则就好，而是需要可以不停地改进自 身运作效率，一切都操之在团队的手中。 游戏开发没有真理，钟志远表示只要能让游戏变得更好，任何方法他都愿意去尝试。同时 他也希望藉由这次的分享，让更多的台湾团队在下周为自己的专案所努力的时候，可以思 考改进的方法，进而让台湾游戏产业更加进步。 ------------------------------------------------------------------------------ Nothing is truth. Everything is permitted. 没有什麽是真理。为了进步和改进，一切都是允许的。 -- 这世界并不美丽， 正因此而美丽无比。 "The world is not beautiful,~~ ~~therefore, it is!!" --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 1.160.8.244 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Rayark/M.1437921004.A.5A7.html ※ 编辑: wind3434 (1.160.8.244), 07/26/2015 22:30:29 ※ 编辑: wind3434 (1.160.8.244), 07/26/2015 22:30:56