 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| Game Unified Process |
|
 |
Bill Bynum Member since: 5/14/2003 From: USA |
|||
 Posted - 5/14/2003 7:24:38 PM |
||||
| Yes, GUP will work, as will a myriad of other processes. The most important element of ANY process is PROGRESS. Do NOT select processes that are painful, cumbersome, or bureaucratic. DO select processes that are relevent to your project. Not all projects will fit GUP. (New engines/technology) these are iterative, but to be ground-breaking and timely to market, MUST subscribe to the waterfall methodology. Get it out first then follow up with next generation improvements. But the benefits of GUP are obvious, and able to be tailored to most any project which will be using established technology, as are many other processes. Remember, if you have not moved forward today, you have failed. Every day should be a step forward, even if it involves rebuilding what has been already implemented, if there is a gain to be made and time allows. Every day your game is on YOUR system is a day less it is on the consumers. BB |
||||
|
||||
|
ThoughtBubble Member since: 7/19/2001 |
|||
|
Posted - 5/14/2003 7:49:12 PM |
||||
| I'm sure there is a lot of reason to use these other processes. Unfortunately, there wasn't enough about what they are, or how you used them to really make any use of the article. I guess I'll just take you at your word, and if I'm ever so interested, resarch the processes myself (doubtless your intent). |
||||
|
||||
|
Shadow Mint Member since: 5/1/2000 From: Australia |
|||
|
Posted - 5/15/2003 12:28:39 AM |
||||
| Mmm... there are many many process models for building software, and the processes specific to one organisation are doubtless going to be different to those from another. I feel it is a mistake to point to XP and RUP as the brillant examples of SE processes that can be used. Both have certain uses, for certain specific tasks. Both are utterly inappropriate for other tasks. It largely depends on the nature of the product and the team. The important things we should be noting here are that: (1) - The traditional waterfall model is flawed and not generally a good model. (2) - An iterative model provides a facility for going back and making changes, which is good (even an iterative waterfall is ok). (3) - For game development especially, where the artistic "feel" of the game is so important, prototypes / milestones that give a tangible output to testers are important. But MOST important of all: (4) - You should know and have organised the development model to be used very very very early on in the development process. All the processes and resources should be in place to faciliate the model used when it is used. Starting a development cycle without defined processes is a disaster. |
||||
|
||||
|
Goldsacs Member since: 4/18/2003 From: Kinross-shire, Scotland |
|||
 Posted - 5/15/2003 3:14:07 PM |
||||
| Good article, it's food for thought and a step in the right direction. |
||||
|
||||
|
BubaDragon Member since: 7/16/2003 From: USA |
|||
|
Posted - 7/16/2003 11:13:20 AM |
||||
| The most interesting thing to point out about XP was that for it's inaugural run (Chrysler) it failed. The project was late and over budget. Don't let this fool you though XP has some very good points. The RUP is not a process, it's a product. Remember that, the model is the UP (Unified Process), as a process it has it's good points as well. The reality is that there is no "magic process" for development. Instead consider these caveats; Look for good policies and procedure. There is no substitute for sound practices, the traditional waterfall process has some things in it that work. Concepts from all the methodologies need to come together in order for the process to be successful. Involve the development team in the process definition. Ultimately the development team will make or break your process. After all these are the people who have to follow it. By involving the development team in process creation you give them ownership of the process and increase the stake they hold in the process. The alternative is to impose a methodology from the outside and incur all the emotional ramifications of that (who among us LIKES to be told how to do it?) After every iteration take a bit of time and review how the process is working now and what needs to be changed. This makes the process agile giving the PM a touch point to add processes or delete needless processes. Strive for sufficiency. Don't try to make a perfect process, get something in place that works and polish it. Meet deadlines. The surest way to loose credibility is to miss deadlines. Set milestones out for the length of the project, let everyone know that these are projections and the further out they are the greater the margin of error. Treat all short term dates (3 months) as firm. The worst thing you can do is show up on a due date and say "the date has slipped", you knew that when? Mind the process overhead. This goes with "Strive for sufficiency", what is the lightest process (in terms of overhead, notes, diagrams, doc, meetings) that works, and leaves sufficient documentation for future needs? Use that one. Remember that your methodology (little m) is part of an overall Methodology (Big M). Fit in. Some good stuff on methodology can be found among the works of Alistair Cockburn (pronounced "Co-Burn") and Kent Beck. Hope this helps. |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
