作者：Paolo Gambardella

引言

本文并非解释SCRUM的工作原理，毕竟你可以在网络上找到比我们解释得更好的许多免费资源。本文主旨是分享我们小型团队的执行方法，在我们看来，这个方法的最棒之处在于：

1.每个团队成员都能对项目负责

2.你可以获得比游戏本身更多的知识

这些原则可以让你轻松发现游戏开发对于团队来说是否很重要。我们都知道优秀的游戏有可能获得成功，而糟糕的游戏当然与此无缘。最重要的是，公司仍然有团队，并且它会随着经验的增长而成长。无论项目结果如何，团队都应该从中汲取大量经验，获得最大化的好处。我们应该鼓励成员的责任心和学习行为，而SCRUM正好完美结合了这一原则。

人物角色（Personas）

我们的工作流程始于人物角色，它是潜在玩家的描述。我们必须先从一些假设入手，因为我们还没有任何玩家。写下我们未来玩家的想象资料，有助于我们推动瞄准他们的设计：这意味着更好的粘性和留存率。以下是人物角色的一个例子：

John，来自美国的28岁汽车机械师

他希望有时间玩游戏，但却总腾不出时间。他有一部诺基亚Lumia 520手机，并在上班时间下载体验免费游戏。他不能在游戏上花太多时间，更愿意在工作间歇玩游戏。他有一些Facebook好友，并且从未在免费游戏上花一文钱。

目标：

*清晰的目标

*较少的控制

*社交游戏

*短暂的游戏回合

当游戏发布后，人物角色就会变成“游戏角色”，我们将通过追踪和直接的反馈获得关于其行为的准确概念。

故事（Stories）

我们根据人物角色定下了生成玩家故事的概念文档：这是一个将问题划分成次问题的好方法，有助于构思每个团队成员应该解决的任务。以下就是故事的一些例子：

我们可以将玩家分为3种类型：

1.新人：第一天的玩家

2.休闲玩家：拥有正常留存率和低粘性的玩家

3.高级玩家：拥有高留存率和粘性的玩家

每个Sprint都有解决一系列故事的目标，而这些故事是从产品储备中选择出来的，并且要迎合基本的Sprint目标：开发一款具有发行潜力的游戏。每个故事都有一系列需要追踪的参数，我们使用的是本文所建议划分的玩家类型。

信号系统（Kanban）

针对我们的信号系统，我们使用了四个栏目：

*去做：还没有被任何人接手的任务

*在做：正处于当前开发状态的任务

*测试：团队中已经完成并需要修正的任务

*完成：可以视为结束的任务

你很容易发现，最后一点相当有歧义。事实上，如果你低估了这一点，它可能就会成为你工作流中的问题。为避免这一点，团队在Sprint计划会议中要腾出一些精力关注作品以及对于“完成定义”的维护工作。

在Thousand Gears，我们有一个小型团队针对诺基亚AppCampus开发一款游戏，为保持目标清晰和可控性，我们选择了短小的迭代（Sprints）。通常每个Sprint阶段持续1周左右。我们通过图表追踪团队的速度，这样我们才能发现团队在Sprint计划会议中能够评估60%的实际时间。

里程碑

我们每周都会推出一款具有潜在发行可能的产品，想象我们将用它来参加游戏竞赛。在每个里程碑尾声时，我们会为自己的游戏生成一个新的增量。我们的里程碑是：

1.预原型阶段：创造概念和执行极为初级的系统来展示主要循环。

2.原型阶段：确定开发游戏首个基本版本的技术和工具。想象一下你将参加Ludum Dare或类似的活动。

3.样本阶段：创造关卡，美术资产并执行功能。

4.Alpha阶段：用基本的漏洞修复来优化内容和美术资产。

5.Beta阶段：最终的漏洞修复。

在每个里程碑末尾，我们都会进行测试。首个测试只在内部进行，其目标是激励团队“行动起来”的斗志。

设计该怎么办？

通常我们并不迷信制作大量文档的方法，我们更愿意创造GDD，它是游戏设计日记（Game Design Diary）的缩写：每个Sprint阶段都会写下一个新的章节并与团队分享。这样我们可以向初始理念添加细节，并保持追踪整个项目的历史。每个团队成员都可以看到开发过程中发生变化的内容及其时间，这有利于进一步分析。此外，从更小的文件入手更容易写下新故事。

总结

游戏开发并没有什么成功秘笈，整个过程就是试验->结果->学习。Scrum并不是一个方法，它是一个方法论：它是更多是关于研究技巧而非通过行动执行逻辑合理路径的哲学性思考。我们应该采用一些明确的决定，所以最好是尽量保持简单性和可衡量性。整个过程是经验性的，你必须掌握许多最佳做法并将其运用于自己的情境和文化，令其更适用于自己的团队成员。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Using SCRUM in indie game development

by Paolo Gambardella

Introduction

For Hover Cabs we choose to use the Scrum-ban methodology to manage the game development. This post is not to explain you how SCRUM actually works, since there are a lot of free sources on the Internet that will explain it better than us.This post is to share the way we implement it since there is not so much information for small teams. From our point of view the best of this methodology at the very end is:

1. each team member is responsible of the project

2. you will foster learning more than the game itself

those principles, as you can easily notice if gamedev, are criticals for every team. We all know that a good game can be successful, a bad one will surely not. At the end of the day, the team is what remains in a company, and it grows up with its experiences. In every case the team should learn a lot, to take the maximum advantage independently from results. Responsibility and learning should be strongly encouraged, and SCRUM marries this philosophy perfectly. The kanban is an enhance which gives a clear visualization of the work stages.

Personas

Our workflow starts with Personas which are descriptions of possible players. We have to start with some assumption, since we do not have any player yet. Write down imaginary profiles for our future players helps us to drive the design toward them: that means to play better with engagement and retention, design side. An example of Persona:

John, 28 years old car mechanic from U.S.A.

He wants to have the time to play games, but he hasn’t. Anyway he owns a Nokia Lumia 520 and loves to download free games to play while at job. He cannot spend too much time and he is more likely to play during pauses at work. He has friends on Facebook and doesn’t use to pay a cent to play freemium games.

Goal:

clear goals

few controls

social game

short game sessions (average)

Personas will become Play Personas once the game is released and we will get a clear idea of their behavior through tracking and direct feedback.

Stories

Basing on Personas we wrote down the concept document generating player’s stories: those are a great way to divide the problem into subproblems in order to conceive all the tasks each member of the team should satisfy to solve it. Here it is some example of story:

As a/an

I want to…

so that…

KPI

newbie

see the taxi going alone

I can focus on dodge and take passengers

engagement

casual

see my winnings in the summary: rewards, kilometers

I will have the sensation of my mastery

engagement

casual

encounter obstacles during my trip

I will have a clear challenge

engagement

newbie

use gestures to control my taxi cab

I can get the feeling of move it with my fingers

engagement

newbie

have a new track from the second time I play

I can have the feeling of variety in the game

quality

casual

have a vertical layout

I can use my phone with a single hand

engagement

newbie

choose whenever to carry a passenger or not

I can choose to run for money or for km

engagement

we use to distinguish the players in 3 categories:

1. newbie: the players in the first day

2. casual: the players with normal retention and low engagement

3. advanced: the players with high retention and engagement

Every Sprint has the goal to solve a set of stories which are chosen from the product backlog and considered to satisfy the basic Sprint goal: to develop a potentially shippable game. Each story is enriched with a class of metric that will be tracked and we use the categories suggested in this post.

The Kanban

Four our kanban we use the typical  four columns:

To Do: tasks which are not taken from anyone

Doing: tasks which are in current development

Test: tasks completed which should be verified from something other from the team

Done: tasks that can be considered ended

As you can easily notice, the last point is pretty ambiguous. In fact if you underestimate it may easily become an issue for your workflow. To avoid it, part of the efforts of the team during the Sprint Planning Meeting should be focused on the creation and the maintenance of the Definition of Done:

Here in Thousand Gears we are a small team developing a game for the Nokia AppCampus and to keep things clear and controllable we choose to have short iterations (Sprints). Each Sprint lasts 1 week, normally. We use to track the speed of the team through burndown charts; doing so we noticed that the team is capable of estimate the 60% of real hours in the Sprint planning meeting, which is consistent with the average in literature.

Milestones

Each week we release a potentially shippable product, imagining we are going to participate to jams and competitions. At the end of each milestone (a set of one of more Sprints) we produce a new increment for our game. Our milestones are:

1. Pre-prototype: concept creation and implementation of a very basic system (even with objects and paper) showing the main loop

2. Prototype: establish technology and tools to develop a first basic release of the game. Imagine that you are going to participate to a Ludum Dare or something similar.

3. Demo: Create levels, art assets and implement features.

4. Alpha: Improve the content and the art assets with a basic bug-fix

5. Beta: final bug-fix

At the end of each milestone we run playtests. The first one (pre-prototype) is the only one internal, the goal is to motivate the team to the “let’s do it!”.

From the Prototype they are public, you can see our releases here and here.

What about design?

In general we do not believe in producing a huge amount of documentation; we prefer instead to create a GDD, where the acronym stands for Game Design Diary: each Sprint a new (and lightweight) chapter for the diary is written and shared with the team. In this way we can both add details to the original concept and maintain track of the history of the whole project. It will be totally transparent for every member of the team what is changed (and when) during the development, which is good for further analisys. Plus, it is easier to write down new stories starting from smaller documents.

Conclusions

In game development there is not any magic formula for success; the whole process is trial -> result -> learn. Scrum is not a method, it is a methodology: it is a philosophical thinking on research techniques more than an implementation of a logical-rational path through action. It happens that we should take some clear decision, so the best is to keep the things as simple as possible and measurable. The whole process is empirical, you have to study a lot about best practices and then apply them to your context and culture, in order to adapt them more to the people of the team.（source：gamasutra）