Game Development Reference
In-Depth Information
follow up by checking that the issues were indeed closed before any work was done
based on the material that was walked through and that the notes were distributed to
the participants.
Reviews
Reviews are a little more intimate than walkthroughs. Fewer people are involved—
typically 4 to 6—and the bulk of time is spent on the reviewers' comments.
Reviewers are expected to prepare their comments prior to the review meeting and
submit them to the review leader so that they can be consolidated prior to the actual
meeting. Comments sent electronically are easier to compile and understand. Be sure
to let the review leader know when you are going to submit a pen-and-paper markup
instead of an electronic file. The review leader may or may not be the author of the
material being reviewed.
The review itself can be an in-person meeting between the author and reviewers or
simply a review of the comments by the author alone who contacts individual review-
ers if he has any questions about their issues. An in-between approach is for the
author to look over the reviewer comments prior to the review meeting and limit the
meeting time to discussions over the few issues that the author disagrees with or has
questions about. This meeting can also take place virtually using network meeting
software and phone headsets. That is especially useful for projects distributed across
studios that are separated in space and time.
During the meeting, someone—usually the review leader—must take notes and pub-
lish the resolution of each item to the team. If the opinions of a reviewer differ from
what the author believes should be done, decisions on technical matters are left to the
author whereas procedural matters can be resolved by QA.
Checklist-based Reviews
Another form of review takes place between only two people: the author and a reviewer.
In this case, the reviewer follows a checklist to look for mistakes or omissions in the
author's work. The checklist should be thorough and based on specific mistakes that
are common for the type of work being reviewed. Requirements, code, and test
reviews of this type would each use different checklists. At times it would even be
appropriate to have checklists specific to a game project. These checklists should con-
stantly evolve to include new types of mistakes that start to show up. Mistakes found
during the checklist review that were not on the checklist should be recorded and con-
sidered for use in the next version. Technology, personnel, and methodology changes
could all lead to new items being added to the checklist.
