Slashdot Mirror
Using Agile Methodologies To Make Games?
simoniker writes "Using Agile methodologies for programming is a concept that's been around for a while now, but some firms are now applying the concept to video game development." There has been a lot of talk lately about what the 'next big thing' in development will be. Could this be it? Or is this just another step along the way? From the article: "Agile puts the emphasis on producing demonstrable iterations of a game almost immediately into production, creating prioritized vertical slices that iterate on the most critical elements and features. The method also puts great emphasis on the organization of teams and the relationships therein, as well as the cycles in which teams must plan and carry out their project objectives."
And so started a cycle of hatred towards methodologies about how to be productive in application development.
To me, the wild wild web is still here. I still get my kicks from coding without set in stone documentation and I still hate schedules.
I've always had the view that every project was a wild animal. Worse yet, it's a wild animal in sheep's clothing. And you approach the sheep with a shepherd's hook. When the veil is lifted and you see man eating marsupial with alligator teeth and a scorpion's tail, you have no choice but to throw the shepherd's hook at them and give it all you've got.
And this is how I approach managing a development project. You remember prior projects and throw together a bag of tools that have worked before and then you set to taming the beast. If you tell yourself "Waterfall works every time" then you're just going to find yourself with a shepherd's hook facing a lion or a bear.
Instead, you learn to adapt to every situation and that's the important thing. The rules are few and loose. The customer has the power to destroy everything and you have to deal with it. The best development is done on the fly with just enough documentation to convey the big idea of what's going on and keep everyone on that page. Given real life schedules and timed deadlines, there is such a thing as too much documentation.
Agile development is better in that it allows you more play and doesn't inhibit spur of the moment innovation. I think some of my most demoralizing moments have been when I realized some great new possibility for a project only to have my manager tell me that so much documentation would have to change that "maybe we'll put that in next year's scope." I find this to be ridiculous.
What was happening was people were starting to assume that waterfall was the silver bullet for project management. "What kind of project is it?" "I don't care, we're using the waterfall." And the big problem is that the waterfall is only considered 'adaptable' if you're ok with reworking everything from step one. Is this really necessary for every project though?
Another new thing we have these days is a "framework" that fits a specific type of problem well. You can throw these together on the fly and have very little documentation because the framework provides a well known implementation strategy (see Spring's MVC).
It is my opinion that using an incremental deliverable approach with frequent customer meetings and executive power at any point in the project is the most successful strategy. The "rules" you have to adhere to are up to you and should be purely a case by case basis.
Why do we constantly look for the "next big thing" when the "big thing" is simply experience?
My work here is dung.
But can I synergize with my results-driven knowledge base while partnering with self-managed teams, increasing single-source responsibility while undergoing a complete paradigm shift?
I didn't think so.
Working at a major game company, here's what happened when someone here raised XP:
The guy who suggested it, "It's an itterative development model. We identify core features, develop those features, refine those features with the customer, then add the next layer, repeating as we go. We gain much better code as every component meets the customer's need as it is developed, challenging the customer to think about it in context, and allowing us to add additional itterations if needed."
Management, "So, we can identify additional features throughout development?"
"Absolutely. You just have to assign additional resources (time/people) to account for those extra features. But, by identifying them as they come up, you end up with a much better system that really does everything right."
Over the next few months, features kept getting added, developers dutifully updated schedules. All was happy. Followed by...
Management, "This was supposed to ship before thanksgiving. It's now slated to ship in the new year. We'll entirely miss the holiday season."
Rapidly realizing his mistake for suggesting it guy, "Yes. But you kept coming up with new features. And they are great new features. Think how much better the product is for it."
"If we miss the holiday season market, we lose money. This has to ship 'on time'."
"But on time is a function of how much you add. We're developing everything to schedule. You've just increased the features so increased the schedule."
"The schedule can't move."
"So you'll have to lose some of the remaining itteration milestones. You'll have to drop features."
"But we like all the features we've come up with."
"But adding features adds time. You've known that since the beginning."
"We've known this has to ship for the holiday season and you promised us we could have extra features. You're just going to have to work more overtime. Fortunately you're overtime exempt so that won't cost us anything to get this project back on schedule."
"It is on schedule. You just changed the schedule by adding features that were identified along the way."
"You told us your wonderful "XP" model would let us do that. We gave you the chance to try this new method under the understanding we got these benefits."
"And you do."
"Good. Then make your schedule."
"We are mak-"
"No arguments. This discussion is over. You promised you could deliver the extra features. You're now behind schedule for the holiday season. You're just going to have to crunch. End of discussion."
Yeah, thanks XP.
Never, ever, raise exciting new methodologies to management. They will hear all of the advantages and expect every last one of them as though it was the perfect implementation of the method whilst completely failing to hear (and certainly refusing to act on or implement if they do hear) any of the trade-offs that have to be made to enable those gains.
"Can someone tell me what this means?"
Some systems analyst draws some connectors and boxes and you get to sit up till 4:00 am writing the code.
davecb5620@gmail.com
I'd like to, but it's really not on my deliverables for this quarter. If we could interface sometime during the next iteration, I feel like we can drill down this action item further and really bring this to manifest. I look forward to addressing your critical concerns and reaching some new plateu in our correspondence.
In Soviet Russia these Soviet Russia jokes aren't considered the least bit amusing...
"creating prioritized vertical slices that iterate on the most critical elements and features"
Can someone tell me what this means?
Sure. It means get something simple working as quickly as possible and improving it over and over.
prioritized - Pick your most important features and implement them first. For example, if you're writing a word processor the ability to save a file probably has a higher proiority than a spell checker.
vertical - This means "specific" as opposed to "general" (also called horizontal). So you work on specific features (like the saving of a file mentioned above) rather than more general ones (like optimiztion).
iterate - You're not going to do things all at once. As an example, perhaps your first iteration of saving a file only saves text and no formating information. You're second may add formatting, your third may add additional formats.