2. The participants may have different
understandings. The terms "review",
"inspection", and "walkthrough" are often used
interchangeably, although they are not the
same.
Indeed the solution should be trainings, but the
duration of that trainings depends on the
experience of each person.
The group should adopt some written
procedures for how reviews are to be
conducted.
3. When a review is in progress, attention should
be on the product, not on the producer.
Some comments could make the producer feel
defensive, beaten up.
The solution should be trying to direct
comments and criticisms to the product itself,
rather than pointing out places the author
made an error .
4. Reviews are important because there are found
defects in a software work product.
If the review is not planned, the team may not
have time to prepare and the reviewers may
not have time to attend.
The solution is to take the time needed to
prepare the reviews and plan it in advance.
5. Reviews should focus on finding defects, but
too often an interesting defect triggers a
spirited discussion about how it ought to be
fixed.
If the solution can be found in less than a
minute, then it could be discussed in the
review meeting.
The solution is focusing on the purpose of the
meeting.
6. Preparation for a review meeting takes time
If the review is not prepared, then it’s just a
waste of time.
Preparation means time and documents, and of
course focus.
7. If the participants in a review do not have
appropriate skills and knowledge to find
defects, their review contributions are minimal.
To be effective, the number of participants
should be between 3 and 7 and they should
have the knowledge needed for the specific
review.
8. Indeed the reviewers focus on style, not the
substance, and that is not the purpose of the
review, criticizing the bad grammar of
somebody.
The solution should be controlling the style
distraction by adopting standard templates for
project documents and coding standards or
guidelines.