This chapter is from the book
This chapter is from the book
This chapter is from the book
Planning for Reviews
If you don't plan reviews as project tasks and allocate resources to them, they can appear to slow the project down, as does any unanticipated work. Your team can hold informal, ad hoc reviews whenever someone desires constructive input from coworkers. However, frequent unplanned reviews will drain time from the reviewers, who might be less likely to request or participate in these informal reviews.
Incorporate formal reviews into the project's schedule or work breakdown structure. A well-defined software development life cycle itemizes specific exit criteria for key phase deliverables, including passing an appropriate peer review. Some teams use planning checklists of the tasks required for common project activities, such as implementing a module or an object class. Include reviews on such checklists. Also conduct interim reviews of major deliverables prior to completion to ensure they are meeting their quality goals. Informal reviews can let you judge whether a deliverable is ready for inspection and can serve as quick quality filters from an outside viewpoint.
The effort you devote to peer reviews might seem like extra overhead, but it is not really additional time in your project schedule. Think of it as a reallocation of effort you would otherwise spend on testing and the pervasive rework of debugging, patching in missed requirements, and so on. Keeping records of reviews and their benefits will help you judge the appropriate level of investment needed to meet your project's quality goals.
Project planners sometimes treat reviews as milestones, as shown in Figure 2–3. However, in project-planning terms, a milestone is a state, not an activity. Milestones have a duration of zero time and consume no resources, so treating reviews as tasks in your plan, as Figure 2–4 illustrates, is more accurate. The milestone is reached when you deem that the deliverable has passed the review. If you treat reviews as milestones, the project schedule can appear to slip when you perform reviews, because the effort they require was not anticipated. Depending on the kind of reviews you hold, review tasks will include effort for individual preparation, review meetings, or both. You should also plan to perform rework after every quality control activity, but your team will spend less time on rework as its development practices improve.
){kind=link}
){kind=link}
Figure 2–3. WRONG: Review treated as a milestone
Figure 2–4. RIGHT: Review and rework treated as tasks
How can you estimate how much time to plan for preparation, review meetings, and rework? If you keep even simple records of the time your team members actually spend on these activities, you can make better estimates for future reviews. Data on the most effective rates of coverage of material during preparation and in review meetings will help you judge the time needed for these review stages (see Chapter 5). Without such data, you are never estimating—you're guessing.