作者：Rob Galanakis

敏捷游戏开发很困难

我花了数周时间写了一篇关于游戏敏捷开发为何比其他软件更困难的博文。我搜索了一些基本原因，例如游戏是艺术作品，或者游戏具有娱乐性，或者游戏更难测试，或者任何关于其独特天性令游戏开发不同于其他软件开发的原因。

我还是找不到一个合理的解释。相反，我想出了一些依情况而定，扎根于商业模式和开发环境的原因。遗憾的是，这正是我们所处的情况；所幸的是，我们可以改变它。

Agile game dev(from bowling-bash.blogspot)

敏捷游戏开发很棘手的4个原因

第一：基于盒装游戏的疯狂商业模式。连续数年开发一款游戏，然后推广、发售、获利，如此反复。加班加点是家常便饭，破产情况也时有发生。每年越来越少的游戏在争取更大的市场份额，开发预算也攀升至成百上千万美元，以便维持这一模式。这真是太疯狂了，所以那些更为理智的开发方法，例如基于敏捷原理的方法就无法兴盛了。通常它们甚至难以立足。不要低估这个问题的深度。我们已经有了一代只知道这种模式的高管和营销人员（以及开发者），试图向他们解释你究竟有多需要发布的灵活性和迭代性，以且在测试中进行开发，无异于对牛弹琴。

第二：我们将Scrum等同于敏捷方法。敏捷方法包括一系列原则，但我们已经将这些原则等同于一系列（有限的）工具：Scrum项目管理方法（在之前的例子中你可以用Lean和Six Sigma取而代之，这并非游戏独有的现象）。如果你试图向一个美术团队实施Scrum方法，你就可以看到有多悲剧了。我们不是选择敏捷或Lean原则并提问“还有什么看重这些原则的好方法吗？”，而是制定了一些Scrum形式。我见过许多人因Scrum方法失败而鄙视敏捷方法，这真令人遗憾。像Scrum一样，我还看到一些毫无灵气的看板法（Kanban）执行方式（因为它不支持看板法的原则，例如限制工作和进程，管理流，以及理解约束条件）。

第三：游戏开发过晚引进敏捷方法。商业和消费者应用、网站等软件已经有15年应用敏捷方法的历史。虽然游戏中已经出现“松驰的Scrum方法”，这也是最近才出现的情况，再加上在这个所谓的“敏捷”工厂的多年开发循环，行业还没有足够支持敏捷方法的经验和反思。除此之外，敏捷方法现在正处于成熟阶段，并且正被项目管理所挪用，所以在方法领域很难创新获得替代类似于eXtreme Programming这种运用于游戏开发的方法。

第四个原因很有趣：游戏续作并非迭代产品。现在因发布一款游戏而负债累累，之后就弃之不顾并因续作而重写原代码的情况极为普遍。这种方法之所以可行是因为续作通常更具分裂性而非创新性，所以具有更多重写的可能。这一点我们可以想想从1993年至2006年，微软Office UI几乎保持原样的情况。随着现在的游戏进入了一个松散定义的“软件即服务”模式，我们的开发重心也应该有所变化。我们应该在相同的代码库上进行月复一月的迭代，并推动项目进展。这是我们必须开发的一系列新技能。

这里有一系列更小且较不重要，但仍然需要指出的注意情况：

*游戏开发尚未接受开源方式，并且它是在Windows平台完成。我所遇到的许多开发者和高管不信任OSS（开源软件），并且多数游戏开发是在Windows平台展开。敏捷方法深深扎根于OSS和Linux，所以除了两个社区间的文化差异（这一点不可低估），Windows平台的游戏开发者和Linux平台上的敏捷开发倡导者之间缺乏互动。

*游戏开发重复工作。许多出色的开源中间件已经让非游戏开发者占据上风，关注自己的核心产品即可。如果你得开发自己的产品和网络服务器，你就不仅仅会遭遇因分散关注点而产生的开发成本。游戏开发传统上对中间件的使用并不充分，并且经常白费力气做重复工作。这通常是由于开发者希望最大化运行表现的心理，以及荒唐的截目上日期和商业模式所致。有了更多的硬件，我想这种情况会发生变化，我们也将看到诸如HTTP等东西而非定制RPC栈使用于客户端/服务器之间。

敏捷游戏开发并不麻烦的理由

最后，这里还有一系列我考虑过并否决的争论，其中包括：

*游戏是艺术，而艺术无法像其他软件一样进行迭代。

*游戏需要太多“基础设施”令一切具有可玩性。

*游戏想让用户花时间而非节省时间。

*游戏是几乎不可能，或者至少是难以测试的东西。

*难以分配多功能客户端。

*频繁的发布会让传统上具有大量内容的游戏令人困惑。

行动号召

这些问题都有相应的解决方案，但它需要向敏捷原则的核心，甚至是更为基础的Lean原则取经。游戏开发所需要的是一系列更适合我们的技术问题，履行相同原则，并且能够修复，以及同现有的敏捷做法和方法匹配的一系列新做法和工具。我们将在未来博文中探索这些话题或理念。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Agile Game Development is Hard

Rob Galanakis

I’ve spent the last few weeks trying to write a blog post about why Agile software development is inherently more difficult for games than other software. I searched for some fundamental reason, such as games being works of art, or being entertainment, or being more difficult to test, or anything about their very nature that makes game development different from other types of software development.

I couldn’t find one. Instead, I came up with reasons that are purely circumstantial, rooted in business models and development environments. Nonetheless, it is the situation we are in; the good news is, we can change it.

4+ Reasons Agile Game Dev is Tricky

Number one: the insane business model based on packaged games. Develop a game for years, market the hell out of it, ship it, profit, repeat. Crunching hard is probably in there, as is going bankrupt. Each year fewer and fewer games garner a larger share of the sales, and budgets are often reaching into the hundreds of millions of dollars to continue this model. This is pure insanity, so development methodologies of greater sanity, like those based on Agile principles, simply cannot thrive. Often they struggle to even take hold. Don’t underestimate the depth of this problem. We have a generation of executives and marketers (and developers) who know only this model, and trying to explain to them how you need to be flexible and iterative with releases and develop with tests can feel like a losing battle.

Number two: We’ve equated Scrum with Agile. Agile embodies a set of principles, but we’ve equated those principles with a (limited) set of tools: the Scrum project management methodology (you can substitute Lean and Six Sigma in the previous example; this phenomenon is not unique to games). If you’re ever tried to impose Scrum on an art team, you can see how much of a disaster it is. Rather than take Agile or Lean principles and ask “what is a good way to work that values these principles?”, we just institute some form of Scrum. I’ve seen many people dismiss Agile because Scrum failed, which is a shame. And like Scrum, I’ve also seen forms of soulless Kanban implemented (soulless because it doesn’t support the principles of Kanban, like limiting work and progress, managing flow, and understanding constraints).

Number three: Game development was late to the Agile party. Software has had about 15 years to figure out how to apply Agile to business and consumer applications and websites. While “flaccid Scrum” now seems common in games, that’s relatively recent; combined with multi-year development cycles in these so-called “Agile” shops, there hasn’t been much of the learning and reflection that underpins Agile. On top of this, Agile is in a period of maturity right now and is being appropriated by project management, so it is difficult to innovate in the methodology space to come up with an alternative to something like eXtreme Programming that works in game development.

Number four is pretty interesting: Game sequels are not iterations. It is very common to build up mountains of debt to ship a game, and then throw away and rewrite those mountains for the sequel. This worked okay because sequels were usually much more disruptive than innovative so there were more opportunities for rewrites. In contrast, consider that the MS Office UI stayed basically the same from 1993 to 2006. Now as games are entering a loosely defined “software as a service” model, our development priorities must change. We need to be able to iterate month-by-month on the same codebase and pull things forward. This is a new set of skills we need to develop.

There are a number of smaller items that are less important but still should be pointed out:

Game development hasn’t embraced open source and is on Windows. Many developers and executives I’ve met have a distrust of OSS (CCP’s use and support of Python and other OSS is a source of pride for me and others here) and the majority of game development is on Windows. The Agile movement has strong roots in OSS and Linux, so aside from the cultural differences between the two communities (which should not be underestimated), there was just a lack of engagement between game developers on Windows and Agile evangelists on Linux.

Game development reinvent wheels. The availability of lots of excellent open source middleware has given non-game developers a leg up on focusing on their core product. If you had to develop your product and webserver, you’d incur not just the cost of developing both but of splitting focus. Game development has historically done a poor job of using middleware and has often reinvented the wheel; this has probably historically been due to the desire for maximum performance and ridiculous deadlines and business models. With more hardware to spare, I suspect this will change and we’ll see things like HTTP used between client/server instead of custom RPC stacks.

Reasons Agile Game Dev is not Tricky

Finally, there are a number of arguments I have thought over and rejected, including:

Games are art and art cannot be iterated on like other software.

Games require too much ‘infrastructure’ to make anything playable.

Games want users to spend time, not save time.

Games are impossible, or at least significantly more difficult, to test.

Fat clients are difficult to distribute.

Frequent releases are confusing for games, which are traditionally content-heavy.

Call to Action

There are solutions to all of these problems, but it requires getting to the core of Agile’s principles, and even more importantly, the Lean principles those are based on. What game development needs is a new set of practices and tools, better suited to our technological problems, that fulfill the same principles and can be mixed and matched with existing Agile practices and methodologies. Some ideas or topics for discussion in future posts.（source：altdevblogaday）