Getting Started
What are reviews and why use them
Reviews can be conducted in person, by web conference or offline. In an offline review, the reviewers
perform their review in their own time and send comments by email or some other collaborative tool. Reviews help
organizations deliver quality products, identify problems early and help build an image of the product for team
members. When implemented across teams, reviews also provide opportunities for people to discover
design and code from other groups, and increase the chances of detecting common source code, reuse opportunities, and
opportunities for generalization. Reviews also provide a way to coordinate the architectural style among various
groups. The three types of reviews are:
Review Presentation
A meeting at which a work product, or a set of work products are presented to the user, customer, or other interested
parties for comments and approval.
Inspection
An evaluation technique in which work products are examined in detail by a person or group other than the author to
detect errors, violations of development standards, and other problems. While using this method, confine
attention to at most two aspects.
Walkthrough
A review process in which the review coordinator, in this case also a developer, leads one or more reviewers,
possibly members of the development team, through a segment of a work product that he or she has written while the
other members ask questions and make comments about technique, style, possible error, violation of development
standards, and other problems.
When to perform a review
Review Presentation:
-
Evaluating project progress or project-level plan
-
Monitoring the status of schedules and progress regards to schedule
-
To determine if a product meets specifications and complies to the design
Inspection:
-
Used to identify specific errors or problems
Walkthrough
-
Used to find anomalies
-
Effective form of educating the reviewers, that is, team members and stakeholders
How often are reviews performed
In general, the review process follows a repetitive cycle:
-
An issue is raised by a reviewer.
-
The issue is discussed, and potentially confirmed.
-
A defect is identified (something is identified as needing to be addressed).
-
Continue until no more issues are identified.
In order for this to work effectively, everyone must understand that the goal of a review is to improve the quality of
the reviewed work product. The work products should be reviewed with a critical eye to finding problems. Doing this can
be difficult, so all reviewers must constantly remind themselves to focus on identifying issues (we are all natural
problem solvers, but as reviewers we must put that aside).
We all have strong ownership of our work; it is often difficult to accept criticism, even when it is constructive. As a
result, we must work even harder to focus on the goals of the review: to make that work better.
Formality of reviews
Review Levels
|
Explanation
|
Comments
|
Formal-External
|
This work product is part of the delivery at a specific milestone and requires some form of approval by
the customer, the sponsor or some other external stakeholder.
|
The review record is configuration managed along with the work product.
For example, the Vision and the Business Case are work products that normally have to be reviewed
by stakeholders.
|
Formal-Internal
|
This work product is formally reviewed internally by the project.
|
The review record is configuration managed along with the work product.
For example, the interfaces of design subsystems usually have to be reviewed and approved by
several members of the project.
|
Informal
|
This work product is reviewed, but not formally approved.
|
The work product is developed and maintained. It is normally not discarded after the project is
complete and there isn't any review record. For example, individual design classes and low-level source
code may not be formally reviewed. This can still mean that someone, perhaps a peer, will review
it.
|
None
|
This work product does not need to be reviewed or approved.
|
The work product is created as work information. It is often a temporary work product that is discarded
after the project is complete.
|
Common Pitfalls
One of the major reasons why review meetings fail to achieve their intended results is that they have a tendency to
degenerate into discussions of how a problem should be fixed. Fixing problems usually requires investigation and
reflection; the format of the review is not an effective medium for this kind of discussion. Once the issue is
identified, determine if it is a defect that must be resolved, and then assign it to someone to investigate and
resolve. The review meeting should focus on identification only.
If the issue requires further discussion among a group of people, form a separate meeting to focus on that topic.
Typically this meeting will require some investigation and preparation, and people with the right skills will need to
be involved. The review should remain focused on identifying other issues. The moderator will often need to exert
considerable will to keep the review meeting focused on this.
|