如何减少游戏开发过程中的浪费.pdfVIP

如何减少游戏开发过程中的浪费 最近我们在网上经常会看到许多在一般软件开发时很受欢迎的项目管理技术，但它们 却很少用于游戏创造中。尽管 Scrum 已经有力地推动了游戏制作，但是还有许多技术仍然 被忽视。这是一种不幸的情况，因为来自传统和敏捷方法的其它方法也能够应用于我们的产 业中，并帮助我们创造出一些正面的结果。 在本文，我并不会详细解释精益六西格玛。相反地，我将专注于精益六西格玛的核心 原则并分析如何将其应用于我们每日的游戏开发中。 精益六西格玛 精益六西格玛是名为“精益”和“六西格玛”的两种项目管理技术的结合。 精益：专注于在所有活动中有效地传递消费者的价值。任何不能为消费者添加价值的 活动都必须果断删除。 六西格玛：专注于从过程中删除所有瑕疵和变量。 换句话说，这两者都是为了消除一些“浪费”。在精益六西格玛中，浪费被定义为 “muda”。这是一个日文单词，意味着“无价值的；无用的；闲置的；多余的；废弃的； 消耗的；浪费的。”浪费可以以任何方式出现。停工时间，重做，不匹配的功能需求，过度 交流等等。精益六西格玛明确了 8 种类型的浪费（有时候是 7 种）。 精益六西格玛中存在许多潜在的理念。完整的开发项目是围绕着这一框架中的技术， 等式和工具而尽心，但是因为内容太泛了，我们难以在本文中进行探索。如果你进一步探索 的话可能会注意到许多理念直接应用于制造业中。同时其核心原则也对游戏制作带有直接且 正面的影响。 为什么会出现浪费问题 根据我的经验，浪费元素是团队最大的焦虑来源。最重要的便是浪费时间。在所有领 域中努力清除浪费是制作人和项目管理者必须拥有的一种心态。许多制作人认为他们的主要 角色便是领导整个项目。他们认为自己就像骑着马位于军队最前方的将军一般，朝着敌军方 向挥舞着剑并高喊“冲啊”！也许他们的角色带有这样的元素，但这却是非常有限的。一支 带有经验的团队可能已经知道如何有效工作，而制作人如果想有效利用时间就必须专注于如 何避免浪费而不是引导着团队朝目标盲目前进。有时候制作人必须让团队做其最擅长的事并 花时间去消除阻碍发展的内容。 两大不可饶恕的罪行 在我的职业生涯中，我曾经遇到许多充斥着问题的项目。实际上，我的所有项目都是 困难重重。当完成这些项目时，团队经常会转向事后检查并照亮制作过程中引起的许多问题。 最频繁且最具影响的关注点通常是围绕着“交流问题”和“偏差的期望”。 交流问题：团队经常会抱怨他们不知道项目的目标，日期，各部门的任务或管理者的 期望。这一问题似乎会出现在每一个项目中。幸运的是我们能够通过纪律，技术和透明度承 诺轻松解决它。最重要的是，制作人和项目管理者必须清楚这一问题，因为这是浪费时间的 主要根源。 偏差的期望：当创造功能，图像，代码等等内容时，在“完成”的定义方面，管理层 和内容创造者总是不能实现同步。这种矛盾将导致更频繁的重复劳作。产品拥有者，利益相 关者和所有者（注：创造性控制的唯一来源）都必须清楚地与所有内容创造者进行沟通。 这两个问题间的共性就是“浪费”。它们都有可能导致时间的浪费。时间是产品开发 中最有价值的资源。因为精益六西马格是关于消除浪费，所以它将能够有效应用于游戏开发 中。 TIM WOODS：8 种类型的浪费 在精益六西格玛中有 8 种类型的浪费。 以下是一些学术定义： T—-转移：移动人们，产品和信息 I—-库存：储存零部件，组块，需求文件 M—-动作：弯曲，转向，触及，提升 W—-等待：为了零部件，信息，只是和设备而等待 O—-生产过剩：创造出超过需求的内容 O—-国度加工：更严格的容差或更高级的材料（超过标准） D—-瑕疵：重做，废弃，错误的文件 S—-技术：未充分使用的功能，删除未充分训练的功能 来源：/dictionary/8-wastes-of-lean/ 想想你自己的每日游戏开发体验。这些对于浪费类型的定义是否能够帮助你揭露项目 的低效能？以下是一些例子： 转移：资产转移是否花了太长时间？是否存在创造时间太过冗长且带有瑕疵？ 库存：是否投入了太多时间于隔天就会改变的冗长的设计文件中？是否存在太多范围 外且会导致团队分心的未修剪理念？ 动作：环境的设置是否会阻碍交流？致力于高度迭代功能的人们是否坐