August 14-15 2006

Agile Game Development:Tales from the Trenches

Noel LlopisSenior ArchitectHigh Moon Studios

August 14-15 2006

Coming upAgile Development

Organization Agile Techniques

Programming Agile Techniques

Lessons Learned

August 14-15 2006

PART 1: Agile Development

August 14-15 2006

MotivationUnknown technical constraints

Changing requirements

Finding the fun factor

August 14-15 2006

What is Agile Development?

Maximize work not done

Just-in-time decisions

Adapt to change

August 14-15 2006

Scrum

August 14-15 2006

Extreme Programming (XP)

August 14-15 2006

OthersEvo

RUP

...

August 14-15 2006

PART 2: Organization Agile Techniques

August 14-15 2006

Short IterationsScrum suggests 30 days; XP 2 weeks.

We tried both, and we're doing 2-week iterations.

Each iteration attempts to create a true vertical slice.

Use results to feed into next iteration.

Yes, you can do a lot of work in 2 weeks (hard to believe at first).

August 14-15 2006

August 14-15 2006

SchedulingCustomer == Person who cares about the ultimate outcome of what the team produces.

Customers come up with priorities.

Team estimates how long things will take and signs up for most important tasks in available time.

Conversation between customer and team.

August 14-15 2006

August 14-15 2006

Team CompositionSmall teams (8-12 people).

Collocated in open work environment. This is huge for quick discussions and communication.

Originally only programmers; now, totally cross-functional.

Scrum of scrums to scale to larger team sizes.

August 14-15 2006

Who Does WhatTasks are created and estimated by team

People pick whatever task they want to work on

Great for morale and spreading knowledge

Careful how to deal with domain experts

August 14-15 2006

Long-Term ViewWe create working software instead of documents.

Important to be in total agreement with publisher.

Try your publisher. They may resist change at first, but then they realize they get to have more say in your project.

Backlog

Long-term planning; three-month release cycles.

August 14-15 2006

August 14-15 2006

PART 3: Programming Agile Techniques

August 14-15 2006

Pair Programming

August 14-15 2006

Pair ProgrammingIs output 2× of what one programmer can do? Not quite.

It's a bit less (1.6 - 1.8×), but it also has other huge benefits:

Much higher quality

Spreads knowledge & philosophy

Promotes team spirit

In the long term, it is a huge win

August 14-15 2006

Pair ProgrammingNot everybody likes it, but a very large number of programmers do.

Some teams use it almost all the time; some other teams not as much.

Another benefit: Intensity and concentration. You never have low moments, little breaks, or anything. You work 8 hours and you end up exhausted!

August 14-15 2006

August 14-15 2006

Test-Driven Development

Check inCheck in

Writetest

Writecode

Refactor

August 14-15 2006

Test-Driven DevelopmentQuick idea: test-code-refactor cycle

All code unit-tested; written by programmers

Design methodology

Much easier to refactor/optimize

August 14-15 2006

Test-Driven DevelopmentUnit tests are:

Small

Self-contained

Fast

Code doesn't have to be written with the future in mind.

Instead, we can change when/if the time comes. Huge win!

Never refactor for its own sake; always because we want to do something.

August 14-15 2006

Test-Driven DevelopmentGet a unit-test framework (UnitTest++)

Running on the Xbox 360 is a bit more challenging, but do-able.

Need to be able to run a program, capture its output, and return code.

Xbrun should really do it.

August 14-15 2006

Continuous IntegrationMany small, very frequent check-ins (maybe every 3-5 minutes)

As soon as any code is checked-in, build is triggered

People are notified right away of any failed builds

Unit tests are very useful for keeping things stable

We use CruiseControl.Net—it's great!

August 14-15 2006

August 14-15 2006

Continuous IntegrationHouse rule: Nobody leaves without making sure his last check-in resulted in a successful build.

The faster your builds, the better; so, pay attention to logical and physical dependencies (feedback time for normal checkins is around 10-20 seconds).

Much slower for Unreal projects.

August 14-15 2006

Collective Code OwnershipReally means collective code ownership, not "no code ownership".

Anybody is free to modify any code as long as it's because they're working on it.

Really relies on unit tests and shared knowledge.

August 14-15 2006

Sustainable PaceWhat's one of the big problems in the industry? Crunch time.

Work as hard as you can, thinking of the long term. That means about 40-hour work weeks. Intense 40 hours, though!

People come back refreshed and ready to do work.

They also have the time to learn things outside of work and feed that knowledge back into work.

August 14-15 2006

Automated TestsUnit tests from TDD are huge, but only part of all the automated tests.

Functional tests: Test whole program or parts of it.

Fully automated. Run them on the build server at least once a day. (We have them running every couple of hours.)

Run them on your target platforms as well.

Great for testing systems involving multiple threads

August 14-15 2006

PART 4: Lessons Learned

August 14-15 2006

How Is It Working?We're discovering the important stuff first

Much-improved code quality

More robust builds

People are really happy

August 14-15 2006

What Can Be Improved?Team composition

How many resources are shared

How to fully integrate people with different ways of working and thinking (programmers, artists, designers)

August 14-15 2006

What Can Be Improved?Team self-organization

Big goal of scrum. We’ve made lot of progress, but it can be taken a step beyond.

Team needs to realize they're empowered to do whatever it takes to get their tasks done.

Sometimes some leadership will still be needed

August 14-15 2006

What Can be Improved?Non-productive time

Scrum recommends 1 day for reviews and 1 day for planning.

That's 2 days out of 10 “wasted”; even worse with multiple teams.

We recently changed things to minimize down time, and we do reviews and planning on the same day.

August 14-15 2006

Adopting Agile Development

We have customized a lot of the standard scrum rules to fit game development.

However, it's best to start with the default rules, try them in earnest, and go from there.

Tweaking too many rules from the start can lead to wasted time and failed attempts.

XP was easy to adopt without any major changes.

August 14-15 2006

Resources

Games from Withinhttp://www.gamesfromwithin.com

Agile Game Development http://www.agilegamedevelopment.com

Questions?

© 2006 © 2006 MicrosoftMicrosoft Corporation. All rights reserved. Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

DirectX Developer CenterDirectX Developer Centerhttp://msdn.microsoft.com/directx

Game Development MSDN ForumsGame Development MSDN Forumshttp://forums.microsoft.com/msdn

Xbox 360 CentralXbox 360 Centralhttp://xds.xbox.com/

XNA Web siteXNA Web sitehttp://www.microsoft.com/xna