     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
The Secret's in the Schedule: The Mythical Man-Month is a seminal work on not just software engineering but the psychology of human interaction inside a team environment. Nearly everyone in our industry is familiar with the name of the book and most have a cursory understanding of its central tenets. However, significantly fewer people have ever actually read the book or have a deep understanding of it beyond some well-known quotes that have become platitudes. This lack of deep understanding leads to two problems. First, people don't prevent actions that go against the very pretense of the book, which means they make mistakes that were identified as mistakes nearly 30 years ago. The second problem is people rely on an overly simplified understanding of the book and therefore are unable to conceive how its fundamental rules can be bent and twisted to allow that which seems impossible. Obviously I recommend everyone put this book in his or her personal reading queue and get to it soon. Rather than rehashing the book's contents, the focus of this article is on ways to bend and stretch The Mythical Man-Month to its extremes; to help reduce restrictions of progress due to communication breakdowns and interdependencies. The author of The Mythical Man-Month, Frederick P. Brooks, Jr., puts forth an idea that probably isn't too shocking to most of us. He believes software engineering is radically different from all other forms of engineering primarily because there is no physical representation for our product. He argues that while studying the organization of other engineering fields can be useful, it cannot completely govern our particular craft. I'll extend this idea even further with another not-so-ground-breaking declaration: computer game engineering is by far the most esoteric of all software engineering, because at its essence is the difficulty of developing the all-important fun-factor. About Schedules The two primary ways to control the inherent limitations imposed by The Mythical Man-Month are through schedule and process. While the scope of this article is on scheduling, a complementary feature covering the process side will be given in part 2. The Mythical Man-Month states that adding people to a project experiences a law of diminishing returns until a point where growing the team actually creates a net loss in progress. The essence of this idea lies in the complexity of software engineering, where each team member works on a virtual object with a significant amount of attachment to other pieces. All of these separate pieces must line up correctly for the final product to succeed, so communication among people becomes an exponentially tightening bottleneck as the team expands. Translation: more of your day is being spent in meetings. This is especially true as the project gets closer to the end and the volume of history knowledge reaches its peak. However, while this general tenet is true, the rate of decline and the transition where the new person added causes a net loss in productivity is variable. The best way to control these variables is through knowledge of your project's scope and resources, especially the team's manpower. And this understanding must go beyond simple head counts and reach a true understanding that your team is made up of very different people who need to be managed in very different ways. An effective management strategy including schedule and process can pull significantly more productivity out of a given team and thus stretch The Mythical Man-Month to its limit.
All successful projects must start with a schedule to understand the scope of the undertaking, no matter their timeframe. If you believe you don't have time to schedule, then I counter you don't have time not to. A schedule is your first line of defense against the communication breakdowns that kill a project's deadlines. Amazingly, I still encounter teams with extremely poor or even nonexistent schedules. In my early years in the business, I worked on three games called Esoteria, Tube Racer, and Beneath. Never heard of them? Exactly. The first was barely released and probably only sold a couple hundred units and the next two were both canceled after numerous schedule overruns. All suffered endlessly from a lack of proper scheduling. Since then, I have shipped every game I have led on time, mainly due to great schedules which gave me the information I needed to mutate my team when new problems arose. In my last year at Microsoft publishing, I've seen many games ship and many games killed: a constant theme running through them all is that poor scheduling leads to canceled projects. Project Life Stages To understand scheduling a game you must first understand the phases of existence that all projects go through. While the absolute time of each phase fluctuates based on the overall project length, there are common ratios of time between them. The first stage is concept development. You are in a creative period when blue-sky brainstorming is the goal. At this point, you have no need for real schedules beyond simply setting a deadline for finishing these initial meetings. Upon completion of this phase, you should have a well-defined design document with discussion of not just the gameplay but also art and engineering-centric sections as well. This should take approximately 1/8 of the total timeline or about three months from a 24-month project. The next stage is your prototype where you prove out the major unknowns, the foremost being the fun factor. This section is scheduled much like the whole game, only with an abbreviated timeframe, normally around 1/8 of the total project but sometimes growing depending on initial technology. Obviously, the more stable the tool set and engine you start with, the more likely the prototype would fall within the three-month estimate. If the prototype is successful, you should leave this phase with a strong understanding of what will make the game fun and an example program that conveys this idea. Along with this will also be a system-level task list with estimated time allocations for designing these new systems. In other words, all the major systems might not be done but you should know what they are and have a rough guess as to the manpower needed to complete their first pass. This is the phase when independent developers should begin shopping around to publishers. While some development houses are lucky enough to get signed with only paper presentations, showing up with a working prototype goes significantly further when trying to secure a deal. Your next stage is preproduction, which is when the team tackles the remaining uncompleted systems through at least the first implementation. For example, your new experimental lighting system with dynamic shadows should be up and running along with the decision to continue work on it or cut it due to problems. You should also have your first couple of levels completed to alpha quality to extrapolate the effort needed to complete the remaining levels. The first level always takes the longest and usually ends up being the worst because your team is getting used to the process and the new game you're making. So you must complete two or three levels so the team begins approaching what the real world manpower per level will be. Once you've done this, you'll be able to map out the rest of the time frame and know if you need to reduce the level count immediately. This stage should take about six months from a 24-month project or 1/4 of the total project. Now you enter full production, which is normally when your team hits its maximum size (without the extras needed for test, which normally comes on later). At this stage, the game should be fun and its entirety should be known. This is where your system level task list is constantly being refined into smaller and smaller resolutions. The process is becoming mechanical now as opposed to the freeform conceptual stages in the beginning. Your schedule is now the end-all be-all of the project's existence. You should expect this time to last about nine months or a full 3/8 of the project making it the longest stage. This section of development ends with code and content complete meaning everything is in the game the way it was originally planned. It doesn't mean the game has to be completely locked down as final changes can still be made well into alpha as long as proposed changes significantly improve the overall quality of the game with limited risk. And now we're brought to the end, the final stage. It's here that you've reached alpha and beta, also known respectively at Microsoft as code/content complete and zero-bug release (ZBR). These stages are mostly defined by long crunch times. Programming is focused on bug fixing, the art department on final polish, and the test team ramps up to full capacity. The schedule is becoming less structured and instead the team is being driven by daily and hourly updates derived from the test team along with oversight from the departmental leads and producer. Your bug-tracking software essentially becomes your schedule as you make your final sprint, which normally lasts about three months out of 24 or 1/8 the total. Once you understand these stages of development, you'll be better able to schedule them. One important point is that these fractions are meant to be guidelines, not strict rules. All projects expand and shrink these stages as they need them. While one project needs more time for prototyping, another needs less for production. Or perhaps your project is a simultaneous three-console release that will probably increase your absolute time spent in the final bug push. However, these guidelines should help you identify earlier when a particular stage is grossly beyond expectations. For instance, if you worked on a prototype for nine months, you shouldn't expect to complete the game in the next year. Your team obviously created lots of new technology and gameplay if it took nine months for a prototype, so ramp-up time alone when building the full game will prevent your team from finishing in the coming year. Working at Microsoft publishing has shown these time ratios to work successfully for many projects including Counter-Strike for Xbox, which was essentially a five-month project, and Whacked, which was a two-year one. These two projects had completely different absolute times but similar ratios between segments.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Introduction
Features
|
|
|