PROJECT MANAGEMENT
M
ETHODS
In This Chapter
• Pros and Cons
• Personal Software Process (PSP)
• Scrum
• Project Management Institute (PMI)
3.1 I
NTRODUCTION
G
ame developers tend to shy away from using a formal software engi-
neering process (perhaps because they are afraid of stifling the creative
energy on the team) and instead jump right into production without
making a clear decision on how to manage the development cycle. This worked
fine 25 years ago when the teams were small and everyone clearly understood
their development responsibilities. The games were also much simpler to
create—fewer assets, fewer lines of code, and fewer features. Today, teams
are larger; games are more complex; and games are simultaneously released
on multiple platforms and in multiple languages. Developers are now realizing
they must find better ways to manage the development cycle. In order to do
this, they are looking at how software engineering processes are managed in
other industries and finding ways to adapt these to game development.
Personal Software Process (PSP) and an Agile Methodology known as Scrum
are two software development processes that have been successfully used by
Chapter 3Chapter 3
42 THE GAME PRODUCTION HANDBOOK, 2/E
game developers in recent years. Other software processes can also be adapted
to game development; which one you choose depends on the type of game, the
constraints, and the available resources. There are pros and cons of using any
type of process, so take this into account when researching which one will be
best for your development team.
Formal production processes are a large topic and to discuss them in detail is
beyond the scope of this book. However, this chapter presents general informa-
tion about the pros and cons of using a formal process, how two studios success-
fully implemented PSP and Scrum, and the benefits of the Project Management
Institute (PMI).
3.2 PROS AND CONS
Because many game developers are not trained in project management pro-
cesses, no common terminology or method is used from project to project. This
makes it difficult for teams to understand how their tasks fit into the develop-
ment process and impact the work of others. For example, a designer cannot
script a level until the artist has built it, or an artist can’t add lighting to a level
until the lighting tool is coded. It is important for the team to be aware of these
dependencies, so they can schedule their work accordingly. When the work is
not properly scheduled, the critical path becomes overloaded, and bottlenecks
develop in the workflow, putting the project at risk. Using a formal software en-
gineering process can alleviate some of these issues.
Many software engineering processes, such as PSP and Scrum, require the
team to be involved in determining what tasks need to be done, estimating how
long the tasks will take, and tracking the progress of these tasks. This level of
team involvement gives people more ownership of their work. Morale increases
because people directly control their tasks, which means they can have a direct
effect on the success (or failure) of the project.
When people see that the game production is under control, they are more
confident in the game’s success. A formal process allows the team to clearly see
tangible progress, which motivates them to move forward in their work. For
example, Scrum uses burn-down charts to show the progress the team is mak-
ing. These charts allow teams to see when they are ahead of schedule, behind
schedule, and right on schedule. If they are behind schedule, they can see this
sooner rather than later and correct the timing before it becomes a problem that
puts the project at risk.
Another benefit of using formal software engineering processes is that proj-
ect metrics can be generated on how long it takes to do a task, and this informa-
tion can be used when estimating similar tasks on future projects. Overall, this
allows the producer and the team to generate more accurate task estimates.
PROJECT MANAGEMENT METHODS 43
The more accurate these estimates are, the easier it is for a team to plan the
production cycle, decide which features and assets can be implemented, and
determine more confidently when the game will be finished. For example, if
an artist accurately tracks how long it takes to create a 200 m × 200 m level,
this information can be recorded and then used to estimate this same task on
another project.
The producer and leads greatly benefit from using a formal process. When
a standard process is in place, it is easier to bring in new team members and get
them quickly up to speed on the game’s development progress. New people
joining the team can get to work right away, instead of having to spend a few days
figuring out what they are supposed to be doing. Additionally, the producer and
leads can spend their time actually managing the game development process,
instead of putting out fires. Because you know exactly where the project is at any
given time, no huge surprises should sneak up on you.
There are some cons to using a formal software engineering process, but
many of these can be overcome with time, especially when people start to use,
understand, and be comfortable with the process. One issue with using pro-
cesses like Scrum or PSP for game development is that these processes are really
more suited to engineering tasks and less to design and art tasks. The processes
were originally developed for software engineering because there is often un-
certainty in how long it takes to code a feature, how long bug fixing takes, and
the scope of the work. By establishing these processes, the engineering tasks are
more controlled, and exit criteria can be established to determine when code is
completed.
People may be reluctant to try a formal process for a variety of reasons. For
some, their unfamiliarity with the process will be a deterrent, as they may be
unwilling to try something with which they have little experience. Others might
perceive this as something rigid that will stifle creativity and innovation; they
also might feel they are less involved in project decisions, rather than more in-
volved. For people who are worried that creativity will suffer, explain that there
is more time to prototype and polish the game, since the majority of their time
is now spent on implementing project features, rather than on putting out fires.
Finally, people might be concerned that the company culture will become more
corporate and less fun. Explain that this is a process to help the team, rather than
control them.
Other things to consider when using one of these processes include the cost
to train and implement. For example, with PSP everyone needs to take a two-
week training course; this is not only expensive, but having people unavailable
for two weeks impacts the project. If you are planning to spend the money to
train people, make sure that the company and the people are committed to mak-
ing the process work. Any time or money investment made in these areas will be
worth the increased efficiency and decreased project risk.
44 THE GAME PRODUCTION HANDBOOK, 2/E
PSP AND TSP
Tobi Salunier, President
1st Playable
Personal Software Process (PSP) (TM SEI CMU) is a professional training pro-
gram for software engineers designed to help an individual learn more about their
own software engineering process and ways to improve it. In particular, the train-
ing focuses on how to plan tasks and catch bugs earlier, which both result in more
accurate schedule estimates. We had just finished a big project at Vicarious Visions,
with a long crunch time, and one of the priorities of the postmortem was to findto
improve our game development process. I had heard about this process in my previ-
ous research and development (R&D) position with General Electric, through my
involvement with the quality initiative there. Since the complexity of software is one
3.3 PERSONAL SOFTWARE PROCESS (PSP)
Personal Software Process, established by the Software Engineering Institute at
Carnegie Mellon, teaches engineers to understand and improve their own pro-
cess of coding. The emphasis is on how to teach engineers to manage the quality
of their code, make commitments they can actually fulfill, improve their estimat-
ing and planning, and reduce bugs in their code. A large part of this involves
conducting code reviews at every stage in the software development cycle.
PSP is a big commitment, as engineers must go through a two-week training
course and complete 10 homework assignments. Also, in order for PSP to be
most effective, all the engineers on the team must be trained and use this process
together on a project, which can be expensive. The training costs are recouped
by having more certainty and stability in a given code deliverable. For more in-
formation, refer to Appendix C, “Resources,” for the official PSP website.
Team Software Process (TSP) is another component of PSP. TSP is when
everyone on the team, including designers and artists, applies the principles of
PSP to their work. The goal is to build self-directed teams who establish the
project goals, formulate a plan to meet these goals, and then track their progress
toward these goals. If TSP is integrated effectively into the production process,
the team is more motivated and is able to successfully complete more aggressive
project schedules—mainly because they were involved in creating the plan, fully
understand everything that must be accomplished during development, and can
quickly see where the project is getting off track much sooner than before.
PROJECT MANAGEMENT METHODS 45
of the biggest factors in long projects, it seemed that trying PSP at Vicarious Visions
could be part of the solution. But it was going to be a challenge to convince game
developers that a structured process as taught by PSP would have value for them.
Like any kind of process improvement, software process is not something you can
force people to do and like; people don’t want you to tell them that something is
good for them—instead, they want to judge for themselves.
The great thing about PSP is that the training program is designed for people
to get firsthand experience of the process and then determine whether it is some-
thing they want to use on a game development project. The training comprises two
one-week classroom training sessions, separated by a couple of months. This staging
approach lets people adopt new habits and collect their own data to validate which
techniques work for them. The training focuses on the individual, so that each per-
son has a chance to identify and improve weak areas and tailor the material to what
was most useful for each.
We decided to send all the engineers for the training program in order to get
the most benefit possible. As in any major training program, if you don’t train every-
one, the process will not be as effective; people come back from training enthusias-
tic to try something new but won’t be able to keep up the momentum if they are in
the minority. One big downside is the cost; in addition to the time allotted to it, the
course fees are also fairly expensive (for a game developer). In addition all project
managers had to schedule around the training time. However, we felt the invest-
ment would be worth it in the long run. As a company, we were only going to work
on bigger and more complex projects and even a couple of weeks delay in one of
these big projects would cost far more. Therefore, even if people did not have buy-
in for PSP before training, I was hoping they would see the value of it after training
and be willing to utilize at least some part of it.
TSP is an additional component of this professional training. TSP involves
the entire team and provides a structure to make sure that the team has the
support they need for the individuals to apply all that great process knowledge
they learned. The great side benefit of TSP is that it provides a structure for
your basic project planning process that ensures that the team all understand
and are working toward the same goals. Basically, TSP requires the team to
meet together for four solid days and create the project plan and task list in a
concentrated amount of time. This is different than the more ad hoc plan-
ning approach, which might use similar steps but perhaps involve fewer team
members for each and that is staged over a period of a few weeks. Although
it can be painful to have the whole team committed to that week of planning
(since many may still be wrapping up their prior projects), involvingthe team with
all the planning up-front is more efficient in the long-term, and the team is less
likely to forget tasks that should be included in the plan.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.