Page 237 -
P. 237

208           PART TWO  MANAGING SOFTWARE PROJECTS


                         2. Set an agenda and maintain it. One of the key maladies of meetings of all
                            types is drift. An FTR must be kept on track and on schedule. The review
                            leader is chartered with the responsibility for maintaining the meeting sched-
                            ule and should not be afraid to nudge people when drift sets in.
                         3. Limit debate and rebuttal. When an issue is raised by a reviewer, there may
                            not be universal agreement on its impact. Rather than spending time debat-
                            ing the question, the issue should be recorded for further discussion off-line.
                         4. Enunciate problem areas, but don't attempt to solve every problem noted. A
                            review is not a problem-solving session. The solution of a problem can often
         "It is one of the most  be accomplished by the producer alone or with the help of only one other
          beautiful         individual. Problem solving should be postponed until after the review meet-
          compensations of
          life, that no man can  ing.
          sincerely try to help  5. Take written notes. It is sometimes a good idea for the recorder to make notes
          another without   on a wall board, so that wording and priorities can be assessed by other
          helping himself."
                            reviewers as information is recorded.
          Ralph Waldo
          Emerson        6. Limit the number of participants and insist upon advance preparation. Two
                            heads are better than one, but 14 are not necessarily better than 4. Keep the
                            number of people involved to the necessary minimum. However, all review
                            team members must prepare in advance. Written comments should be
                            solicited by the review leader (providing an indication that the reviewer has
                            reviewed the material).
                         7. Develop a checklist for each product that is likely to be reviewed. A checklist
                            helps the review leader to structure the FTR meeting and helps each reviewer
                            to focus on important issues. Checklists should be developed for analysis,
                            design, code, and even test documents.
            FTR Checklists
                         8. Allocate resources and schedule time for FTRs. For reviews to be effective, they
                            should be scheduled as a task during the software engineering process. In
                            addition, time should be scheduled for the inevitable modifications that will
                            occur as the result of an FTR.
                         9. Conduct meaningful training for all reviewers. To be effective all review partici-
                            pants should receive some formal training. The training should stress both
                            process-related issues and the human psychological side of reviews. Freed-
                            man and Weinberg [FRE90] estimate a one-month learning curve for every 20
                            people who are to participate effectively in reviews.
                        10. Review your early reviews. Debriefing can be beneficial in uncovering prob-
                            lems with the review process itself. The very first product to be reviewed
                            should be the review guidelines themselves.
                          Because many variables (e.g., number of participants, type of work products, tim-
                       ing and length, specific review approach) have an impact on a successful review, a
   232   233   234   235   236   237   238   239   240   241   242