Awhile back I came across an article on gamasutra about game design software methodologies; I thought it was a useful read.
The article gives a brief introduction to Scrum as a game design methodology. While I don't think Scrum as a whole is what we need (daily meetings are overkill, for example), some of its elements would be great for our project. Things like emphasis on the entire team working together, "vertical slices" as intermediate deliverables, frequent customer meetings for feedback, short work cycles, and the fact that it's an iterative process could be easily worked into a methodology.
I'm not entirely sure we're supposed to have a formalized methodology (although I seem to remember hearing that we're supposed to stick to a methodology at some point), and I'm not sure whose job it would be to run it (probably Amanda's, but again I don't know). Just throwing this one out there in case.
Subscribe to:
Post Comments (Atom)
3 comments:
I like this Scrum methodology. For daily meeting, I guess we can alway post updated to the blog or e-mail. They mentioned the Sprints, should we come up with Sprints now and see how many of those we have to do...
I like the Scrum methodology too. To me, a methodology is more of an attitude that the group would adopt rather than a strict schedule. I like Scrum because it focuses on work in groups. I don't know what goals each person has for the project but one of mine is to be able to help with all of the different parts. I like programming in pairs/groups and I also think design and graphics can be a multiple person thing. And I think groups working on specific parts can (and probably should) change when we feel like it. Kien is right, updating the blog is a good idea instead of daily meetings. And Dr. Patton would be happy with frequent updates-even if it's just some new graphics. I think this methodology would work well with the small size of our small group.
^ Amanda
Post a Comment