对游戏研发敏捷之路的一点分享

去年有个机会和游戏业内的某位研发管理李经理聊到游戏研发项目的现状，他感叹道：“游戏越来越复杂，团队的规模越来越大，而人员的流失却相当严重，仅以调整工资来留住人才显然不是应对之策。”

2006年，公司刚刚成立时，李经理就加入了，他们有几千万的天使资金，人数在三年内扩充到二百多人。但在团队不断壮大的过程中，人员流失也非常严重，甚至连主策划都被挖走了。这就给公司管理带来了一系列问题，例如在事务中需求不断地变更，对需求理解的错误及沟通的不通畅等，使得埋怨之声不绝于耳。他的团队对新人的培训和内部协调花掉相当多的时间，但成效不佳。聊天时我们从各个不同的角度，诸如公司管理制度及文化、研发方法和研发工具等，彼此交换了意见。

冰冻三尺非一日之寒，这复杂的问题也不可能轻易就有个完美的解答。单就从软件工程的角度来看，合适的研发方法和工具结合可以相当大程度的增加生产力，并降低人员流失所造成的损失。讨论之后我们觉得这些要点具有共性，可供大家参考，就把要点整理并补充了一下。虽然这不像学术研究那般地严谨，但仍提供了大家在实际操作时一些思考的方向。让我们从一个典型的游戏研发团队所具有下列特点说起。大致上它有下列几点：

一、     需求变化多且快 –需求的变化是不可避免的。更甚者是游戏好玩与否很大程度是由玩家决定的。所以，需求的重要性很难确定。需求的变更可以直接冲击产品交付时间，因而很容易便引起大家相互的指责。

二、     协作不容易 - 典型的游戏的开发团队里有策划、美工（2D、3D）、程序、测试等角色。由于人员较多，沟通协调都不容易。举例来说，某个流程改变了，相关的人又需要一段时间才能适应这新流程。当某个需求变更时，可能策划、美工（2D、3D）、程序、测试等人员又要沟通并返工。

三、     资源调度难度大 - 团队里常会有某些人（如程序员）在等待其他人（如策划）的情况。通常管理人员对这些情况并不能掌握得很好，这使得资源在无形中浪费了。

为了要应付游戏研发过程中需求变化快的特性，越来越多的团队已使用或正在考虑使用敏捷方法。（有些人可能不知道其团队已在使用较简单的敏捷操作，如每日站立会议等。）实践已证明敏捷方法有下列优点：缩短产品开发时间、提高软件品质、项目较为可控、成员自主能力提高并显著地提高其生产力。在诸多敏捷方法论中，Scrum似乎特别受到青睐。而敏捷方法也并非是互不相容的。比如，有些团队会以Scrum的方式管理，以XP的方式操作。

由于传统文化等因素，有些人认为Scrum未必能很容易地被中国研发团队接受。Scrum团队鼓励每个成员都参与并发表意见。但由于中国的传统教育方式并不刻意鼓励学生发言，大多数的中国研发人员未必能习惯敏捷的思维及操作。举例来说，Scrum Master组织每日立会并负责清除在这些会议上反映出来的那些障碍。它的角色更像是团队协调人。但由于Scrum Master这个角色一般由团队技术主管或项目经理担任，团队成员会揣摩并附和他的意见。还有，在团队中进行讨论时是对事不对人的。在会中有些意见被采纳，有些被否决，这本是很正常的事。但这操作也有它的困难。我曾经参与一个较技术性的讨论会，在会中有个很优秀的女孩提出了她的建议，但没被接纳。她觉得这是个耻辱，居然就站起来走出了会议室。

并非所有的团队和项目都适合采用敏捷方法的。大致上来说，适合使用敏捷方法的团队和项目具有下列特性：

一、    团队有能力引进自下而上的管理模式。传统的管理模式是自上而下的，在经理把项目理解后拆分成几个任务，再将这些任务分配给个人。敏捷方法对团队成员的要求较高，不但成员的性格需要较为独立开放，技术能力和对整体项目的理解也都要到达一定水平。

二、    团队人员不宜太多。团队协调和资源调度在七到十人的团队里还是游刃有余的。但一旦人数再增加，团队协调和资源调度的难度都呈等比级数增加。当团队变大时，需要有工具支持以保证项目的可控性。

三、    需求变化多且快。敏捷方法就是为拥抱需求变化而设计的。如果能保证项目的可预见性（Visibility）和可控性，那需求的变化就不是太大的问题。

四、    团队成员最好能在同一处工作。由于沟通的频繁，分布式团队是较不适宜使用敏捷方法的。但当然，若成员必须在异地工作，那工具多少可以帮上些忙。

当团队人数增加到十人以上，团队协调和资源调度的难度都呈等比级数增加。在这情况下，引入适当的工具是必要的。在选取敏捷研发管理工具时，我们应考虑下列特点：

一、      整合的平台（Integrated Platform）- 这平台要能做项目计划并管理需求、代码、测试、发布。它是策划、美工（2D、3D）、程序、测试等人员的协同及沟通平台。或许在开始选工具时我们要的只是这其中的一部分，如需求管理，但依然我们需要预先考虑将来会扩展到对整个软件生命周期的管理。这些工具模块之间的数据要能相通。

二、      量化程度高（Quantification） - 它必须能在以下几方面做量化：需求、人力资源及费用等。这些数据将为未来的改进提供依据。需求的量化对整个项目的管理有着重大的意义。它意谓着需求可以被分割成足够小的单位（大约是一到几个工作人天），这些小单位可以恰当地被分配给程序员或测试员，每个成员的工作量可以被合理地分配，每个迭代的长短被控制得恰当，当需求变更时一切仍然可控。

三、      可追溯性高（Traceability） – 理想上，项目成员应可将相关的文档（包括需求及参考资料等）、测试用例、及代码等链接，并从其一追溯到其他的。如果生命周期管理系统的各个子系统不是整合的，那这种追溯事实上是不可能完善的。在实务中最常发生的例子可能是，研发人员要修复某个缺陷，他常常会需要找出原本的设计文档及历史上相关缺陷修复的状况。知道了来龙去脉后，他便可以很准确地完成他的工作。

四、      可扩展性(Scalability)高 - 可扩展性至少表现在二方面：（1）人员的可扩展和（2）地域的可扩展（分布式团队）。当团队扩展到十人以上时产生的第一个问题是沟通变得不通畅，每日例会不易举行。由于知识量太大，成员已难以掌握全貌。一个可能的做法是将团队分成几个小组，每个小组各自开会。工具的作用在于将所有的知识及数据间的链接保存妥当。团队成员可以在任何时刻拿到自个儿小组的、别个小组的及整个团队的知识。如此，就算团队增长到百人，项目全貌仍旧可以掌控。

大约半年过去了。最近我和李经理再次联系时，他告诉我：“埋怨之声少多了，但傍晚自动留下用公司晚餐的人却多了。”我说：“哦！我明白了。敏捷方法所造成的另一个问题就是公司付出的晚餐费用会大大的增加。”我们都笑了。