收藏
触屏版解读：如何消除游戏开发过程中的浪费
发表时间：2014-12-03
最近我们在网上经常会看到许多在一般软件开发时很受欢迎的项目管理技术，但它们却很少用于游戏创造中。尽管Scrum已经有力地推动了游戏制作，但是还有许多技术仍然被忽视。这是一种不幸的情况，因为来自传统和敏捷方法的其它方法也能够应用于我们的产业中，并帮助我们创造出一些正面的结果。
在本文，我并不会详细解释精益六西格玛。相反地，我将专注于精益六西格玛的核心原则并分析如何将其应用于我们每日的游戏开发中。
消除游戏开发过程中的浪费jpg" border="0" alt="解读：如何消除游戏开发过程中的浪费jpg" vspace="0" src="http://images76.hao139.com/upload/images/2014/12/03/1417577540248049.jpg" width="410" height="273"/>
精益六西格玛
精益六西格玛是名为“精益”和“六西格玛”的两种项目管理技术的结合。
精益：专注于在所有活动中有效地传递消费者的价值。任何不能为消费者添加价值的活动都必须果断删除。
六西格玛：专注于从过程中删除所有瑕疵和变量。
换句话说，这两者都是为了消除一些“浪费”。在精益六西格玛中，浪费被定义为“muda”。这是一个日文单词，意味着“无价值的;无用的;闲置的;多余的;废弃的;消耗的;浪费的。”浪费可以以任何方式出现。停工时间，重做，不匹配的功能需求，过度交流等等。精益六西格玛明确了8种类型的浪费(有时候是7种)。
精益六西格玛中存在许多潜在的理念。完整的开发项目是围绕着这一框架中的技术，等式和工具而尽心，但是因为内容太泛了，我们难以在本文中进行探索。如果你进一步探索的话可能会注意到许多理念直接应用于制造业中。同时其核心原则也对游戏制作带有直接且正面的影响。
为什么会出现浪费问题
根据我的经验，浪费元素是团队最大的焦虑来源。最重要的便是浪费时间。在所有领域中努力清除浪费是制作人和项目管理者必须拥有的一种心态。许多制作人认为他们的主要角色便是领导整个项目。他们认为自己就像骑着马位于军队最前方的将军一般，朝着敌军方向挥舞着剑并高喊“冲啊”!也许他们的角色带有这样的元素，但这却是非常有限的。一支带有经验的团队可能已经知道如何有效工作，而制作人如果想有效利用时间就必须专注于如何避免浪费而不是引导着团队朝目标盲目前进。有时候制作人必须让团队做其最擅长的事并花时间去消除阻碍发展的内容。
两大不可饶恕的罪行
在我的职业生涯中，我曾经遇到许多充斥着问题的项目。实际上，我的所有项目都是困难重重。当完成这些项目时，团队经常会转向事后检查并照亮制作过程中引起的许多问题。最频繁且最具影响的关注点通常是围绕着“交流问题”和“偏差的期望”。
交流问题：团队经常会抱怨他们不知道项目的目标，日期，各部门的任务或管理者的期望。这一问题似乎会出现在每一个项目中。幸运的是我们能够通过纪律，技术和透明度承诺轻松解决它。最重要的是，制作人和项目管理者必须清楚这一问题，因为这是浪费时间的主要根源。
偏差的期望：当创造功能，图像，代码等等内容时，在“完成”的定义方面，管理层和内容创造者总是不能实现同步。这种矛盾将导致更频繁的重复劳作。产品拥有者，利益相关者和所有者(注：创造性控制的唯一来源)都必须清楚地与所有内容创造者进行沟通。
这两个问题间的共性就是“浪费”。它们都有可能导致时间的浪费。时间是产品开发中最有价值的资源。因为精益六西马格是关于消除浪费，所以它将能够有效应用于游戏开发中。
TIM WOODS：8种类型的浪费
在精益六西格玛中有8种类型的浪费。
以下是一些学术定义：
T—-转移：移动人们，产品和信息
I—-库存：储存零部件，组块，需求文件
M—-动作：弯曲，转向，触及，提升
W—-等待：为了零部件，信息，只是和设备而等待
O—-生产过剩：创造出超过需求的内容
O—-国度加工：更严格的容差或更高级的材料(超过标准)
D—-瑕疵：重做，废弃，错误的文件
S—-技术：未充分使用的功能，删除未充分训练的功能
想想你自己的每日游戏开发体验。这些对于浪费类型的定义是否能够帮助你揭露项目的低效能?以下是一些例子：
转移：资产转移是否花了太长时间?是否存在创造时间太过冗长且带有瑕疵?
库存：是否投入了太多时间于隔天就会改变的冗长的设计文件中?是否存在太多范围外且会导致团队分心的未修剪理念?
动作：环境的设置是否会阻碍交流?致力于高度迭代功能的人们是否坐在一起?工具是否容易使用且有效?他们的工作空间是否有利于高效工作?
等待：团队是否不断地等待着其它部门完成工作?他们是否经常出现空闲?
生产过剩：美术师是否创造出不符合最终要求的资产?这些资产是否有用?在明确要求前某些部门是否早已赶超其他人?
过度加工：是否创造出比要求更加详细的资产?他们是否过度优化那些对消费者没有多少意义的功能?
瑕疵：代码是否伴随着漏洞?是否是可扩展的?最终工作是否与预期相匹配?资产的创造是否匹配引擎功能?他们的工作是否符合预期标准?
技术：任务是否与团队成功的技能组合相违背?PHD是否致力于GED能够完成的任务?或者相反?
TIM WOODS：应用
理论和概念很棒，但是它们没有多少好处，除非能够应用于开发过程中的实际活动中。以下是我的特定游戏列表(未完成的)，团队们可以将精益六西格玛整合到其中并尝试着去消除浪费。没有任何方法能够解决所有的项目问题，但是如果将其全部整合在一起便能带给开发团队巨大的帮助。当然了你也可以添加更多内容。
进行每日站立会议：尽可能简短，10至15分钟的站立式会议非常有用。这能够促进成员间频繁的面对面交流，并且不需要耗费太多时间。较少且不准确的交流便是一种浪费。
用风险会议取代每周制作人状态审查会：在每周的状态审查会中，所有人将围绕着一间屋子提供一些更新内容，这是一点帮助都没有的。在定期的交流和报告中，成员们已经了解了相关信息。我们需要的会议是每个制作人能够提出他们的前三个项目风险并向群组请求指导。无用的会议是一种浪费。
在实体项目空间突出张贴目标/日期/价值等内容：渗透式交流能够确保所有团队成员都能够清楚项目的宏观目标。通过贴海报等方式去帮助团队成员牢记目标。面对面的交流是最有效的迭代方式。制作人必须采取任何机会向团队成员和利益相关者传达目标期待。不统一的团队成员会创造浪费。
坐在附近的人能够致力于高度迭代且相互协作的功能：团队成员致力于统一的功能，特别是未知且具有探索性的功能对于他们的成功很重要。避免他们无需走太多路便能够与同事进行沟通。功能越陌生，他们越能近距离共事。较少的交流将会创造浪费。
面对面频繁地交流转折点和项目目标：在墙上张贴目标和价值虽然很有帮助，但面对面的交流更加重要。为了得到一封电子邮件的回复可能需要花费1天以上的时间，但面对面讨论将是实时进行的。制作人和产品拥有者必须把握任何可能的机会向团队成员和利益相关者传达目标期待。通过电子邮件或聊天工具而造成的交流延迟便是一种浪费。
频繁地交流创造性目标：与截止日期一样，我们必须持续地分享创造性目标。通常情况下，“完成标准”是取决于创意总监或产品拥有者。他们必须频繁分享自己的要求。误解创造性目标将会创造浪费。
确保所有内容创造者都清楚完成标准：产品拥有者的一个主要角色便是传达他们对于功能的创造性要求和指令的期待。更快地做出慎重的决策很重要。我始终都坚信着美国海军陆战队的：70%规则。如果你认为你的计划拥有70%的可行性，你就必须尽快地去执行它。如果它是错的，你则可以不断地调整它。我曾与许多不断等待着“完美”计划的创意总监合作过。纸上谈兵只会创造出浪费。
在所有相关项目中推动透明交流的价值非常重要：我曾经待在一些牢牢握着项目核心数据的公司。他们总是认为团队不能处理坏消息或者他们会失去一些人员。但是公开与诚实不仅是一种道德，同时也是一种良好的商业意识。团队必须获得最佳信息才能帮助自己更好地朝着目标前进。在大多数情况下保持秘密是一种错误的做法，将有可能引起团队的反抗。糟糕且极少的交流会创造浪费。
优化价值流：项目管道可能是项目中最大浪费的创造者。内容创造者必须能够尽快地回顾并迭代他们的工作。破损的结构，较长的资产转移都有可能限制团队完成工作的能力。较长且破损的价值流可能创造浪费。
鼓励内容创造者去呈现临时工作：没有人喜欢呈现未完成的工作。他们会认为评论者不会理解它最终会变成怎样活着他们会因为一些不相干的问题受批评。创造者和评论中必须创造这种信任。频繁地评论迭代工作将能够消除重做(浪费)。呈现临时工作也能够避免浪费时间。等到工作完成后在呈现出来将会创造浪费。
尝试着消除创造性评论会议所创造的重做：这一点与前一点相似，然而理想的情况是没有任何来自“官方”创造性评论会议的重做。这些工作应该在评论会议前便接受过评论和修改。评论会议应该是官方的“许可证”，而不是探索创意总监全新理念的会议。在我所致力的每一个项目中，内容创造者都会抱怨工作的评论时间太长了。这不仅会创造时间的浪费和重做，这对于所有参与者来说也是一大挫折。产品拥有者必须删除评论，真正相信团队成员。为了这么做，他们必须能够清楚传达要求和他们的期待。源自少有的创造性评论的重做将会导致浪费。
流线型化或删除会议：如果你的团队觉得会议无用，有可能是你未能有效地组织会议。你可以找到许多关于如何有效运行会议的内容。你必须准备好适当的会议议程，特定问题等等内容。人们都不是很喜欢会议并觉得它们只是在浪费时间。制作人必须学习各种关于组织有效会议的方法。会议应该是关于解决方法的集合，而不是重申所有人都清楚的内容。无效的会议只会创造浪费。
适当的环境下使用反挖掘代码是有帮助的：并不是代码的每一部分都必须带有完美的架构。有时候团队将通过亲身体验一个功能获得更多好处，即使潜在的代码很混乱。玩家经常在敏捷的状态下遭遇失败。这意味着团队必须快速创造原因，如此他们便能够尽快地进行迭代。反挖掘代码将能够帮助你更快地获得一个实例功能。在功能被熟知前进行过度的设计和大量的系统创造可能导致浪费。
追踪并解决开放式问题：团队必须不断追踪围绕着项目的开放式问题。应该优先解决带有最重要引擎和期望值的问题。消费者最期待的功能应该被放置在最前方。开放是问题是项目的风险来源。
专注于消费者的需求：团队必须保证他们是在为消费者创造功能，而不是自己。未能与消费者需求相关联的活动必须被删掉。有时候人们会喜欢致力于自己所喜欢的项目，而不管终端用户的价值。致力于与项目最终目标无关的功能只会创造浪费。
KAIZEN(改善)
最后，制作人的最大责任便是继续探索保证项目顺畅运行的方式。Kaizen也是一个日语单词，即关于持续完善内容。制作人，产品管理者，利益相关者和内容创造者都必须不断寻找完善他们工作工程的各种方法。这必须实践于所有项目中，如此结果才会在不断的迭代中得到完善。
结论
就像之前所提到的，精益六西格玛是包含图表，等式，方法和技术的一个综合型框架。团队只需要理解获得利益的原则便可。这不只是一个框架，还是一种心态。浪费是项目杀手。寻找方法去消除浪费是所有团队都必须具有的一种心态。
