来自“主流”软件行业的六个教训 - 彭博社

总体而言，游戏行业在“成熟开发流程”方面一直落后于其他软件开发领域。政府和企业软件客户通常需要有关开发者成熟度水平的信息，例如 CMMI（能力成熟度模型集成）认证。

这种差异中的一些是有用的，因为它允许游戏开发中的更多创造力和市场灵活性。我们不应该自欺欺人。大多数发生在游戏行业之外的软件开发也存在时间和预算超支的问题。然而，我们可以从对传统软件开发的广泛研究中学到一些教训：

1. 从幻想转向项目规划

研究表明，程序员在估算编程任务方面实际上相当不错。问题在于他们试图调整自己的估算以适应时间表（或仅仅是“激进调度”的文化）时，他们会让自己和整个项目陷入麻烦。

请你的程序员提供现实的估算，并削减不合适的功能。我们大多数人之所以进入这个行业，是因为我们热爱这项工作。这意味着通过制定现实的时间表并在时间允许时添加功能（而不是拥有“激进的时间表”并在整个开发周期中落后），你可以获得更好的整体生产力。

2. 使用迭代开发流程

这里有太多的开发方法论无法一一列举：螺旋模型；瀑布模型；增量模型；原型开发；分阶段交付；极限编程。它们通常分为两种类型：线性和迭代。线性方法在开始时规划整个项目，然后继续进行。游戏在接近结束时才会以任何有意义的方式“结合在一起”。

迭代方法专注于在开发的早期阶段让软件的某个版本能够运行，然后评估项目及其风险，再修订计划并重新投入工程。

这对游戏有两个主要的优势。第一个是提高可见性。任何伟大的游戏都需要一定程度的创新。这意味着设计师、制作人、市场营销人员和管理者需要尽早看到游戏的可运行版本，以便充分理解它。无论你的设计文档多么详细，质量保证团队总能从一个可运行的游戏中编写出更有用的测试用例。

第二个是灵活性和质量。迭代让你可以决定游戏的某些部分是否感觉不对，需要重新设计。你可以在中间调整资源，而不是试图在最后重新修改所有内容。

迭代模型还可以抵消时间表超支的自然倾向。如果你在时间表的前半段无法让游戏的某种形式运行，你可能就无法按时完成。

3. 清除问题程序员

有充分的文献记录表明，在小型项目中，最佳程序员与最差程序员之间的生产力差异至少为10比1。在大型项目中，一些程序员实际上对项目产生负面影响。

“问题程序员”并不难以识别。如果你的团队中有一个或多个，其他程序员几乎肯定知道他们是谁：

a) 问题程序员更关心看起来聪明，而不是向其他程序员学习。他们通过拒绝记录代码或解释他们的过程来掩盖自己的弱点。

b) 问题程序员是有领土意识的，常常长时间独占代码——这会减缓其他程序员的进度。

c) 问题程序员在事后抱怨管理选择。不愿意为开发问题分担责任，他们宁愿重新审视已经解决的问题。

你可能会担心如果解雇一名程序员会落后。但糟糕的编程习惯几乎总是由糟糕的态度造成，而不是低智商。如果你无法改变态度，你需要通过移除问题程序员来帮助其他团队成员。我从未见过有人后悔将某人从团队中移除；但我见过几种情况，某些本该被移除的人却没有被移除。

在你为一个项目添加程序员之前，看看是否可以通过移除一名程序员来提高生产力。你的技术负责人应该已经知道这是否是一个需要解决的领域；他们只是并不总是愿意提出这个问题。

4. 代码属于项目

如果我每听到程序员说“不要碰我的代码”就能得到一个五分镍币……

游戏行业充满了谈论“我的代码”的程序员。它也有很高的人员流动率。这是一个糟糕的组合。出于这个简单的原因，你需要确保至少有两名程序员理解每一段代码。有不同的方法可以实现这一点，从代码审查到“团队编程”。无论具体方法如何，你还会更早发现错误（当修复成本较低时），因为解释或注释代码的简单行为可以在代码被提交之前发现错误。

大多数编程工作都是用来修复错误，而不是编写代码。大多数程序员都知道这一点——他们只需要一个鼓励良好实践的团队环境，比如伪代码和命名约定。

如果你正在处理难以理解的代码（即使你不是写这段代码的人），请对该部分进行文档记录，以便下一个程序员知道发生了什么。包括你的姓名首字母和日期是很有帮助的。例如，如果你错误地评论了其他人的代码，原始程序员可以与你讨论并澄清任何误解。

5. 没有银弹

一位顾问曾建议我将我们的整个代码库从C转换为C++，仅仅因为“C++是一个更好的平台。”工具对你的项目的帮助程度与它已经多大程度上定制以适应你的需求相关。新的编程语言不会帮助你解决特定于你的游戏标题的问题。

这对于艺术工具、源代码控制等也是如此。我听说过这样的说法：从Visual Source Safe切换到Perforce将减少20%的开发时间。在将整个项目投入到最新的“银弹”之前，请确保你内部调查所有工具。

没有任何开发工具可以替代良好的开发实践。与其强迫你的团队学习新工具，不如帮助他们学习更好的实践。

6. 早期捕捉错误

从一开始就让错误数据库运行起来（不要等到Beta）。这让团队中的每个人都可以正式提交错误报告和建议。它还为你提供了整个产品周期，以开发最佳的错误分类和报告系统。如果QA和开发已经合作超过一年，他们在最后几周不会因为什么真正构成“A级”错误而争吵。

这意味着，您委托“确保”软件质量的QA人员应该有权这样做。将您经验最少的员工集中在另一栋建筑里，并要求他们“玩游戏”，在下一代游戏中是行不通的。

最后的话：这篇文章略过了很多内容，从项目规划到编程再到人员。谷歌搜索这篇文章中的关键词是寻找更多信息的好地方。