My Message close
GAME JOBS
Latest Jobs
spacer View All     Post a Job     RSS spacer
 
May 23, 2013
 
2K Games
Tools Programmer - 2K Games
 
2K Games
Graphics Programmer - 2K Games
 
2K Games
Engine Programmer - 2K Games
 
GREE International
Senior Product Manager, Growth and Revenue
 
GREE International
Business Intelligence Data Analyst
 
Synergy Blue
3D Artist / Animator
spacer
Blogs

  New School Blues Dev. Diary #8: Project Management Part 2
by Mike Doucet on 01/25/13 12:18:00 pm
Post A Comment Share on Twitter Share on Facebook RSS
 
 
The following blog was, unless otherwise noted, independently written by a member of Gamasutra's game development community. The thoughts and opinions expressed here are not necessarily those of Gamasutra or its parent company.

Want to write your own blog post on Gamasutra? It's easy! Click here to get started. Your post could be featured on Gamasutra's home page, right alongside our award-winning articles and news stories.
 

Developer Diary #8: Project Management Styles Part 2

So we know Waterfall is good at planning, but not so good with iterating.  With such a short project completion time then, we knew we couldn’t take a strict Waterfall stance on things.  While there was some design and planning typical of Waterfall based projects, as you can tell by earlier diary entries we’ve already made tons of iterations, meaning YoyoBolo’s project management style is a mix of Waterfall AND a little something called Agile.

Agile is a type of project management that works on the principle of starting with a basic design or prototype, and updating that prototype over the course of a few weeks.  Each new prototype is then refined, culminating in a finished product that reflects needed design changes.  Since more time is spent seeing the game (however primitive) in action we can make modifications and experiment much more quickly.  It allows for way more flexibility.

Agile = Ninja.  That’s how my brain works.  Don’t look for a joke here because there isn’t one, sorry.

Agile isn’t all roses though.  It’s main drawback is that it doesn’t scale well.  Let’s say you’re producing a massive project - say for example, a blockbuster movie or video game.  It would be impossible to build a prototype able to encapsulate all initial design decisions.  The project is too big to get a bite-size chunk that will truly represent the experience it intends to deliver.  Also changing any of those decisions would mean altering the structure of this massive operation.  Reorganization like that costs a lot of money and time.

Fortunately we are a small operation working on a small game, so Agile fits us just fine.  Every two weeks a prototype is due, each new prototype more polished then the last, culminating with a final version that has all assets included which is then tested so as to become the actual product shipped.  That’s it for now, but next time we’ll get more into milestones, what tasks were required, and how scheduling them in the correct order is crucial.

 
 
Comments


none
 
Comment:
 




 
UBM Tech