August 14-15, 2006 “ WALK IN” SLIDE

Agile Game Development: Tales from the Trenches Noel Llopis Senior Architect High Moon Studios Presentation/Presenter Title Slide

Noel Llopis

Senior Architect High Moon Studios

Coming up Agile Development Organization Agile Techniques Programming Agile Techniques Lessons Learned

Agile Development

Organization Agile Techniques

Programming Agile Techniques

Lessons Learned

PART 1: Agile Development

Motivation Unknown technical constraints Changing requirements Finding the fun factor

Unknown technical constraints

Changing requirements

Finding the fun factor

What is Agile Development? Maximize work not done Just-in-time decisions Adapt to change

Maximize work not done

Just-in-time decisions

Adapt to change

Scrum

Extreme Programming (XP)

Others Evo RUP ...

Evo

RUP

...

PART 2: Organization Agile Techniques

Short Iterations Scrum 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).

Scrum 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).

Scheduling Customer == 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.

Customer == 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.

Team Composition Small 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.

Small 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.

Who Does What Tasks 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

Tasks 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

Long-Term View We 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.

We 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.

PART 3: Programming Agile Techniques

Pair Programming

Pair Programming Is 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

Is 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

Pair Programming Not 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!

Not 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!

Test-Driven Development Check in Check in Write test Write code Refactor

Test-Driven Development Quick idea: test-code-refactor cycle All code unit-tested; written by programmers Design methodology Much easier to refactor/optimize

Quick idea: test-code-refactor cycle

All code unit-tested; written by programmers

Design methodology

Much easier to refactor/optimize

Test-Driven Development Unit 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.

Unit 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.

Test-Driven Development Get 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.

Get 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.

Continuous Integration Many 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!

Many 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!

Continuous Integration House 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.

House 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.

Collective Code Ownership Really 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.

Really 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.

Sustainable Pace What'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.

What'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.

Automated Tests Unit 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

Unit 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

PART 4: Lessons Learned

How Is It Working? We're discovering the important stuff first Much-improved code quality More robust builds People are really happy

We're discovering the important stuff first

Much-improved code quality

More robust builds

People are really happy

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)

Team composition

How many resources are shared

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

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

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

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.

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.

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.

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.

Resources Games from Within http:// www.gamesfromwithin.com Agile Game Development http:// www.agilegamedevelopment.com Questions?

Games from Within

http:// www.gamesfromwithin.com

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

© 2006 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. DirectX Developer Center http://msdn.microsoft.com/directx Game Development MSDN Forums http://forums.microsoft.com/msdn Xbox 360 Central http://xds.xbox.com/ XNA Web site http://www.microsoft.com/xna End Slide August 14-15, 2006