Lazea RamonaAn I, master TI, UPT

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.

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 .

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.

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.

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.

 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.

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.