作者：Harvard Bonin

最近我们在网上经常会看到许多在一般软件开发时很受欢迎的项目管理技术，但它们却很少用于游戏创造中。尽管Scrum已经有力地推动了游戏制作，但是还有许多技术仍然被忽视。这是一种不幸的情况，因为来自传统和敏捷方法的其它方法也能够应用于我们的产业中，并帮助我们创造出一些正面的结果。

在本文，我并不会详细解释精益六西格玛。相反地，我将专注于精益六西格玛的核心原则并分析如何将其应用于我们每日的游戏开发中。

精益六西格玛

精益六西格玛是名为“精益”和“六西格玛”的两种项目管理技术的结合。

精益：专注于在所有活动中有效地传递消费者的价值。任何不能为消费者添加价值的活动都必须果断删除。

六西格玛：专注于从过程中删除所有瑕疵和变量。

换句话说，这两者都是为了消除一些“浪费”。在精益六西格玛中，浪费被定义为“muda”。这是一个日文单词，意味着“无价值的；无用的；闲置的；多余的；废弃的；消耗的；浪费的。”浪费可以以任何方式出现。停工时间，重做，不匹配的功能需求，过度交流等等。精益六西格玛明确了8种类型的浪费（有时候是7种）。

精益六西格玛中存在许多潜在的理念。完整的开发项目是围绕着这一框架中的技术，等式和工具而尽心，但是因为内容太泛了，我们难以在本文中进行探索。如果你进一步探索的话可能会注意到许多理念直接应用于制造业中。同时其核心原则也对游戏制作带有直接且正面的影响。

为什么会出现浪费问题

根据我的经验，浪费元素是团队最大的焦虑来源。最重要的便是浪费时间。在所有领域中努力清除浪费是制作人和项目管理者必须拥有的一种心态。许多制作人认为他们的主要角色便是领导整个项目。他们认为自己就像骑着马位于军队最前方的将军一般，朝着敌军方向挥舞着剑并高喊“冲啊”！也许他们的角色带有这样的元素，但这却是非常有限的。一支带有经验的团队可能已经知道如何有效工作，而制作人如果想有效利用时间就必须专注于如何避免浪费而不是引导着团队朝目标盲目前进。有时候制作人必须让团队做其最擅长的事并花时间去消除阻碍发展的内容。

两大不可饶恕的罪行

在我的职业生涯中，我曾经遇到许多充斥着问题的项目。实际上，我的所有项目都是困难重重。当完成这些项目时，团队经常会转向事后检查并照亮制作过程中引起的许多问题。最频繁且最具影响的关注点通常是围绕着“交流问题”和“偏差的期望”。

交流问题：团队经常会抱怨他们不知道项目的目标，日期，各部门的任务或管理者的期望。这一问题似乎会出现在每一个项目中。幸运的是我们能够通过纪律，技术和透明度承诺轻松解决它。最重要的是，制作人和项目管理者必须清楚这一问题，因为这是浪费时间的主要根源。

偏差的期望：当创造功能，图像，代码等等内容时，在“完成”的定义方面，管理层和内容创造者总是不能实现同步。这种矛盾将导致更频繁的重复劳作。产品拥有者，利益相关者和所有者（游戏邦注：创造性控制的唯一来源）都必须清楚地与所有内容创造者进行沟通。

这两个问题间的共性就是“浪费”。它们都有可能导致时间的浪费。时间是产品开发中最有价值的资源。因为精益六西马格是关于消除浪费，所以它将能够有效应用于游戏开发中。

TIM WOODS：8种类型的浪费

在精益六西格玛中有8种类型的浪费。

以下是一些学术定义：

T—-转移：移动人们，产品和信息

I—-库存：储存零部件，组块，需求文件

M—-动作：弯曲，转向，触及，提升

W—-等待：为了零部件，信息，只是和设备而等待

O—-生产过剩：创造出超过需求的内容

O—-国度加工：更严格的容差或更高级的材料（超过标准）

D—-瑕疵：重做，废弃，错误的文件

S—-技术：未充分使用的功能，删除未充分训练的功能

来源：http://www.isixsigma.com/dictionary/8-wastes-of-lean/

想想你自己的每日游戏开发体验。这些对于浪费类型的定义是否能够帮助你揭露项目的低效能？以下是一些例子：

转移：资产转移是否花了太长时间？是否存在创造时间太过冗长且带有瑕疵？

库存：是否投入了太多时间于隔天就会改变的冗长的设计文件中？是否存在太多范围外且会导致团队分心的未修剪理念？

动作：环境的设置是否会阻碍交流？致力于高度迭代功能的人们是否坐在一起？工具是否容易使用且有效？他们的工作空间是否有利于高效工作？

等待：团队是否不断地等待着其它部门完成工作？他们是否经常出现空闲？

生产过剩：美术师是否创造出不符合最终要求的资产？这些资产是否有用？在明确要求前某些部门是否早已赶超其他人？

过度加工：是否创造出比要求更加详细的资产？他们是否过度优化那些对消费者没有多少意义的功能？

瑕疵：代码是否伴随着漏洞？是否是可扩展的？最终工作是否与预期相匹配？资产的创造是否匹配引擎功能？他们的工作是否符合预期标准？

技术：任务是否与团队成功的技能组合相违背？PHD是否致力于GED能够完成的任务？或者相反？

TIM WOODS：应用

理论和概念很棒，但是它们没有多少好处，除非能够应用于开发过程中的实际活动中。以下是我的特定游戏列表（未完成的），团队们可以将精益六西格玛整合到其中并尝试着去消除浪费。没有任何方法能够解决所有的项目问题，但是如果将其全部整合在一起便能带给开发团队巨大的帮助。当然了你也可以添加更多内容。

进行每日站立会议：尽可能简短，10至15分钟的站立式会议非常有用。这能够促进成员间频繁的面对面交流，并且不需要耗费太多时间。较少且不准确的交流便是一种浪费。

用风险会议取代每周制作人状态审查会：在每周的状态审查会中，所有人将围绕着一间屋子提供一些更新内容，这是一点帮助都没有的。在定期的交流和报告中，成员们已经了解了相关信息。我们需要的会议是每个制作人能够提出他们的前三个项目风险并向群组请求指导。无用的会议是一种浪费。

在实体项目空间突出张贴目标/日期/价值等内容：渗透式交流能够确保所有团队成员都能够清楚项目的宏观目标。通过贴海报等方式去帮助团队成员牢记目标。面对面的交流是最有效的迭代方式。制作人必须采取任何机会向团队成员和利益相关者传达目标期待。不统一的团队成员会创造浪费。

坐在附近的人能够致力于高度迭代且相互协作的功能：团队成员致力于统一的功能，特别是未知且具有探索性的功能对于他们的成功很重要。避免他们无需走太多路便能够与同事进行沟通。功能越陌生，他们越能近距离共事。较少的交流将会创造浪费。

面对面频繁地交流转折点和项目目标：在墙上张贴目标和价值虽然很有帮助，但面对面的交流更加重要。为了得到一封电子邮件的回复可能需要花费1天以上的时间，但面对面讨论将是实时进行的。制作人和产品拥有者必须把握任何可能的机会向团队成员和利益相关者传达目标期待。通过电子邮件或聊天工具而造成的交流延迟便是一种浪费。

频繁地交流创造性目标：与截止日期一样，我们必须持续地分享创造性目标。通常情况下，“完成标准”是取决于创意总监或产品拥有者。他们必须频繁分享自己的要求。误解创造性目标将会创造浪费。

确保所有内容创造者都清楚完成标准：产品拥有者的一个主要角色便是传达他们对于功能的创造性要求和指令的期待。更快地做出慎重的决策很重要。我始终都坚信着美国海军陆战队的：70%规则。如果你认为你的计划拥有70%的可行性，你就必须尽快地去执行它。如果它是错的，你则可以不断地调整它。我曾与许多不断等待着“完美”计划的创意总监合作过。纸上谈兵只会创造出浪费。

在所有相关项目中推动透明交流的价值非常重要：我曾经待在一些牢牢握着项目核心数据的公司。他们总是认为团队不能处理坏消息或者他们会失去一些人员。但是公开与诚实不仅是一种道德，同时也是一种良好的商业意识。团队必须获得最佳信息才能帮助自己更好地朝着目标前进。在大多数情况下保持秘密是一种错误的做法，将有可能引起团队的反抗。糟糕且极少的交流会创造浪费。

优化价值流：项目管道可能是项目中最大浪费的创造者。内容创造者必须能够尽快地回顾并迭代他们的工作。破损的结构，较长的资产转移都有可能限制团队完成工作的能力。较长且破损的价值流可能创造浪费。

鼓励内容创造者去呈现临时工作：没有人喜欢呈现未完成的工作。他们会认为评论者不会理解它最终会变成怎样活着他们会因为一些不相干的问题受批评。创造者和评论中必须创造这种信任。频繁地评论迭代工作将能够消除重做（浪费）。呈现临时工作也能够避免浪费时间。等到工作完成后在呈现出来将会创造浪费。

尝试着消除创造性评论会议所创造的重做：这一点与前一点相似，然而理想的情况是没有任何来自“官方”创造性评论会议的重做。这些工作应该在评论会议前便接受过评论和修改。评论会议应该是官方的“许可证”，而不是探索创意总监全新理念的会议。在我所致力的每一个项目中，内容创造者都会抱怨工作的评论时间太长了。这不仅会创造时间的浪费和重做，这对于所有参与者来说也是一大挫折。产品拥有者必须删除评论，真正相信团队成员。为了这么做，他们必须能够清楚传达要求和他们的期待。源自少有的创造性评论的重做将会导致浪费。

流线型化或删除会议：如果你的团队觉得会议无用，有可能是你未能有效地组织会议。你可以找到许多关于如何有效运行会议的内容。你必须准备好适当的会议议程，特定问题等等内容。人们都不是很喜欢会议并觉得它们只是在浪费时间。制作人必须学习各种关于组织有效会议的方法。会议应该是关于解决方法的集合，而不是重申所有人都清楚的内容。无效的会议只会创造浪费。

适当的环境下使用反挖掘代码是有帮助的：并不是代码的每一部分都必须带有完美的架构。有时候团队将通过亲身体验一个功能获得更多好处，即使潜在的代码很混乱。玩家经常在敏捷的状态下遭遇失败。这意味着团队必须快速创造原因，如此他们便能够尽快地进行迭代。反挖掘代码将能够帮助你更快地获得一个实例功能。在功能被熟知前进行过度的设计和大量的系统创造可能导致浪费。

追踪并解决开放式问题：团队必须不断追踪围绕着项目的开放式问题。应该优先解决带有最重要引擎和期望值的问题。消费者最期待的功能应该被放置在最前方。开放是问题是项目的风险来源。

专注于消费者的需求：团队必须保证他们是在为消费者创造功能，而不是自己。未能与消费者需求相关联的活动必须被删掉。有时候人们会喜欢致力于自己所喜欢的项目，而不管终端用户的价值。致力于与项目最终目标无关的功能只会创造浪费。

KAIZEN（改善）

最后，制作人的最大责任便是继续探索保证项目顺畅运行的方式。Kaizen也是一个日语单词，即关于持续完善内容。制作人，产品管理者，利益相关者和内容创造者都必须不断寻找完善他们工作工程的各种方法。这必须实践于所有项目中，如此结果才会在不断的迭代中得到完善。

结论

就像之前所提到的，精益六西格玛是包含图表，等式，方法和技术的一个综合型框架。团队只需要理解获得利益的原则便可。这不只是一个框架，还是一种心态。浪费是项目杀手。寻找方法去消除浪费是所有团队都必须具有的一种心态。

（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转功，如需转载请联系：游戏邦）

The Elimination of Waste: Lean Six Sigma applied toward Game Development

by Harvard Bonin

These days one must only search online to find many project management techniques that are prevalent within general software development but are not utilized often in game creation. While Scrum has made a strong push into game production, many other techniques remain on the sidelines. This is unfortunate since other methods from Traditional and Agile methodologies can be applied to our industry and could help yield positive results.

In this article I will not explain Lean Six Sigma in detail. There are plenty of materials available if you’re interested in pursuing further. Instead, I will focus on the core principles of Lean Six Sigma and show how it can apply to everyday game development.

LEAN SIX SIGMA PRIMER

Lean Six Sigma is a combination of two project management techniques called “Lean” and “Six Sigma”.

Lean: Focuses on delivering customer value efficiently above all other activities. Any activity that does not add value for the customer is removed from the process.

Six Sigma: Focuses on removing all defects and variation from the process.

In other words, both are seeking to eliminate “waste”. In Lean Six Sigma terms this waste is defined as “muda”. This is a Japanese term popularized by Toyota and means specifically “futility; uselessness; idleness; superfluity; waste; wastage; wastefulness”. Waste can appear in many ways. Idle time, rework, mismatched feature requirements, under and over communication, etc. Lean Six Sigma identifies eight (sometimes seven) types of waste.

There are many concepts underlying Lean Six Sigma. Entire development projects have been built around the techniques, equations and tools available within this framework but they are much too involved to explore in this short article. If you explore further you may notice that many of the concepts apply most directly to manufacturing. While this is true the core principles can still have a direct, positive impact on game production.

WHY WASTE MATTERS

In my experience, wasted opportunities are the single largest source of angst on teams. Wasted time, most of all. Continually striving to remove waste in all areas is a mindset that producers and project managers must develop and embrace. Many producers think that their main role is to lead projects through guidance, task-forcing and sheparding. They believe that they are like a general on a horse in front of an army, pointing their sword towards the enemy and yelling “charge!” While the role can have these elements, it’s shortsighted and limited. An experienced team probably already knows how to work well and the producer’s best use of time might be to focus on waste rather than march them toward a goal. Sometimes producers must let the team do what it does best and spend their own time bulldogging the blockers out of the process.

THE TWO DEADLY SINS

Throughout my career I’ve experienced many problem ridden projects. In fact, all my projects have been difficult. When they are completed the team usually turns to the post mortem to help shine a light on the many issues the production experienced. The the most frequent and impactful concerns often revolve around “communication problems” and “misaligned expectations”.

Communication Problems: Teams often complain that they weren’t aware of the project goals, dates, inter-departmental tasks or management expectations. This issue seems to arise on every project. Fortunately, it’s one that is the most easily fixed through discipline, techniques and a commitment to transparency from all involved. Most of all, producers and project managers must be acutely aware of this issue since it’s a main source of wasted time.

Misaligned Expectations: Often management and content creators are not in sync regarding the definition of “done” when creating features, art, code, etc. This misalignment leads to more rework on titles than most any other issue. The product owner, stakeholder, owner, etc. (whoever is the single source of creative control) must be clear in this communication to all content creators.

The commonality between these two issues is “waste.” Both issues are instrumental in creating wasted time. Time is the single most valuable resource available to product development. Since Lean Six Sigma focuses on waste removal (time creation) it’s particularly useful when applied to game development.

TIM WOODS: THE EIGHT KINDS OF WASTE

There are eight kinds of waste defined in Lean Six Sigma. An easy mnemonic to recall these is “TIM WOODS”.

Here is the academic definition.

T Transport: Moving people, products & information

I Inventory: Storing parts, pieces, documentation ahead of requirements

M Motion: Bending, turning, reaching, lifting

W Waiting: For parts, information, instructions, equipment

O Overproduction: Making more than is immediately required

O Over processing: Tighter tolerances or higher grade materials than are necessary

D Defects: Rework, scrap, incorrect documentation

S Skills: Underutilizing capabilities, delegating tasks with inadequate training

source: http://www.isixsigma.com/dictionary/8-wastes-of-lean/

Consider your own daily game development experience. How may these types of waste definitions can be applied to help uncover your project’s inefficiencies? Here are some examples:

Transport: Does the transfer of assets take too long? Are build times lengthy and defect ridden?

Inventory: Is too much time invested on lengthy design documents that change the next day? Are there too many unpruned ideas out of scope that distract the team?

Motion: Is the environment set up to hamper communication? Are people working on highly iterative features physically sitting together? Are the tools accessible and effective? Is their workspace conducive to doing effective work?

Waiting: Is the team continually waiting for other departments to complete their work? Are they often idle?

Overproduction: Are the artists creating assets without confirmation of the end requirements? Will the assets be used? Are departments running ahead of others before requirements are specified?

Over processing: Are people making assets that are too highly detailed than what is required? Are they “gold plating” and polishing features that are the least impactful or important to the customer?

Defects: Is the code ridden with bugs? Is it extendable? Does the resulting work align with the expected work? Do the assets created align with the engine capabilities? Does the work match the expected grade?

Skills: Are tasks mismatched with the skillset of the team member? Are PHDs working on tasks a GED could accomplish? Or vice versa?

TIM WOODS: APPLIED

Theory and concepts are fine but they have little benefit unless they are applied toward tangible activities during development. Below you’ll find my game specific (incomplete) list of actions teams can perform to embrace Lean Six Sigma thinking and try to eliminate waste. None solve all project issues alone but taken collectively they may help teams significantly. No doubt you can add many more.

Conduct daily stand-ups: Short, ten to fifteen minute, well run Scrum stand-ups are useful. They promote face to face communication on a frequent basis and don’t require a large time investment. Infrequent and inaccurate communication is wasteful.

Replace weekly producer status meetings with risk meetings: Conducting a weekly status meeting where everyone goes around the room to provide updates are generally useless. The information should have already been known through regular communication and reports. Focused weekly meetings where each producer brings up their top three project risks and asks for guidance from the group can be very useful. Useless meetings are wasteful.

Prominently post goals/dates/values within the physical project space: Osmotic communication envelopes the team to ensure that no team member is confused about the macro goals. Put up posters, monitors, etc. to help keep the goals on the forefront of the team’s mind. Face to face, personal communication is best and the most iterative. Producers must take all opportunities to communicate the goal expectations to the team and stakeholders. Uniformed team members create waste.

Seat people working on highly iterative and collaborative features near each other: Team members working on the same feature, especially if it’s unknown and exploratory is critical to their success. Eliminate as much walking as possible and ease collaboration. The more unknown the feature, the closer they should be. Infrequent communication toward a focused goal creates waste.

Frequently communicate sprint, milestone and project goals face to face: While posting goals and values on the surrounding team walls is supportive, personal communication is best. It is the most iterative. An email may take a day or more for a response but face to face discussion iterates in real time. Producers and Product Owners must take all opportunities to communicate the goal expectations to the team and stakeholders. Communication delays via email or chat is waste.

Frequently communicate creative goals: As with due dates, the creative expectations must be shared continually. Generally, the “definition of done” lies with the Creative Director or Product Owner. They must be vigilant in sharing their requirements…often. Misunderstood creative goals create waste.

Make sure the definition of “Done” is clear to all content creators: One of the main roles of the Product Owner is to communicate their expectations surrounding a feature’s creative requirement and quality. Fast, measured decision making is vital. My continued belief (which is supported by Lean Six Sigma) is to follow the United States Marine’s “70% Rule”. If you think your plan has a 70% chance of working you must execute as quickly as possible. You can always adjust if it’s wrong. I’ve worked with too many creative directors that wait for the “perfect” plan. Navel-gazing creates waste.

Promote the value of transparent communication on all project related matters: I’ve worked in many companies that held core data about the project closely. They often felt the team couldn’t handle bad news or they might lose people to attrition. Being open and honest is not only ethical, it’s also good business sense. Teams must be fed the best information to help them work toward their goals. Keeping secrets, in most cases, is a mistake and can fester into discontented teams. Poor, infrequent communication creates waste.

Optimize the value stream: The project pipeline can be one of the biggest waste creators on project. Content creators must be able to review and iterate on their work as fast as possible. Broken builds, long asset transfers, etc. can significantly limit the ability of the team to do their best work. Long, broken value streams create waste.

Encourage content creators to show interim work: No one likes to show work that is undone. They may think that the reviewer doesn’t understand what it will evolve into or that they’ll get critiques about irrelevant issues the creator already intends to resolve. The creator and the reviewer must develop this trust. Frequent reviews on iterative work will help eliminate rework (waste) overall. Showing interim work reduces wasted time. Waiting to show work till it’s finished creates rework…and waste.

Attempt to eliminate rework resulting from creative review meetings: This point is similar to the previous one, however the ideal situation is that NO rework comes from “official” creative review meetings. This work should have already been reviewed and altered prior to the review meeting. The review meeting should be a bureaucratic “stamp of approval”, not a meeting to explore the creative director’s lofty new ideas. On nearly every project I’ve worked on content creators have complained that they must wait far too long for their work to be reviewed. Not only does this create waste in the form of idle time and possible rework, it’s a significant frustration for all involved. The Product Owner must delegate reviews to trusted team members. To do so, their requirements must be communicated clearly and their expectations must be established. Rework from infrequent creative reviews creates waste.

Streamline or eliminate meetings: If your team finds meetings useless you are probably not conducting them properly. There are many, many sources that outline the best way to run them. Proper agendas, specific questions to be answered, etc. People generally dislike meetings and find they are a waste of their time. Producers must study the many ways to hold effective meetings. Meetings should be about collaboration on solutions, not reiterating what everyone already knows. Inefficient meetings create waste.

Hack, in the right circumstances: Not every piece of code must be beautifully architected. Sometimes the team gets more benefit from experiencing a feature hands-on, even if the underlying code is messy. An agile adage states that teams should “fail frequently”. This means the team must prototype quickly so that they may iterate toward quality as fast as possible. Hacking code can get to an example feature faster. Over designing and massive system creation before the feature(s) is well known can lead to waste.

Stalk and assassinate open questions: The team must continually stack rank the open questions surrounding the project. The questions with the most impact and expected frequency should take the highest priority. The features with the highest value for the customer (gamer) should be placed at the front of the line. Killing open questions with religious fervor steadily removes uncertainty and risk from projects. Open questions are sources of risk on a project.

Focus work on customer needs: Teams must be vigilante in making sure they are creating features for their customers, not themselves. Activities that don’t directly correlate with customer needs should be removed. Sometimes people like to work on their own pet projects despite the value for the end user. Working on personal features that don’t align with the project end goals creates waste.

KAIZEN

At the end of the day the producer’s foremost responsibility is to continually search for ways to make the project run more smoothly. “Kaizen” is a Japanese term from Toyota that evangelizes continuous improvement. Producers, Product Managers, Stakeholders and Content Creators must always be on the hunt for ways to improve their work process. It’s a mindset that must be practiced on all projects so that results can improve over iterations.

IN CONCLUSION

Lean Six Sigma, as noted earlier, is a very involved framework that includes graphs, equations, methods and techniques that are very involved. Teams may only need to understand the principles to gain benefit. More than a framework, it is a mindset. Waste is a project killer. The practice of finding and eliminating it is a mindset that all teams should embrace.(source:gamasutra)