Reviews

1. Reviews Chapter 5 Applied Software Project Management, Stellman & Greene See also: http://www.oreilly.com/catalog/appliedprojectmgmt

2. Inspections • To get approval for completion of a work product • To prevent defects • “... it costs more to not do inspections than it does to do them.” report from Software Engineering Institute • Goals: • For team to reach consensus and approve/understand each work product • Repair known defects early in the process • See paragraph 3, p. 75 • Choice of moderator is important • Objective • Time conscious • Understands issues • Prepares author and inspectors to critique work (not criticize) and come up with solutions

3. Inspecting the work product • Process • Preparation – each inspector marks defects; perhaps each submits a list of defects before the meeting • Overview – if someone is not prepared, meeting is rescheduled • Page-by-page review – team identifies new wording • If not resolved, logged as open and assigned to inspector who raised the issue • Rework – changes are made in the inspection log • Follow-up – moderator sends revision and asks for approval of inspectors • Approval – moderator gets signatures

4. Managing the author’s expectations • Nobody likes to have their work criticized • Purpose of discussions is not to teach inspectors about the project, but to change the document so that all will approve • If an inspector did not understand something in the document, the document should most likely be revised • It is tempting for the author to get defensive, but must remember the goal is to clear up ambiguity • One way to sidestep this issue is to have all defects sent to moderator. Thus author is prepared to respond appropriately. • Sometimes the author is excluded from the meeting or asked to not talk

5. Standard objections to inspections • Inspections take too long • In fact may take about 2 hours • Authors don’t like others criticizing their work • Note that all make mistakes • Author may not have enough information • Author will feel worse when defects are caught later • People are protective of their work

6. Deskchecks • Less formal than a full inspection; often used for vision and scope documents • Sent to selected team members • Does not produce written logs • May be done as a preliminary to inspection

7. Walkthroughs • Author calls meeting of users, stakeholders, engineers, managers, etc., solicits comments, ensures that all present understand the work product (set of slides perhaps) • Good for brainstorming new or alternative ideas • Guidelines: • Verify that all who need to review the work product are present • Verify that all present understand the purpose of the walkthrough • Describe each section of material to be covered • Present material in each section, ensuring that all understand • Lead a discussion to identify any missing sections or material • Document all issues raised • Follow up as needed

8. Code Reviews • Team examines a section of code and fixes defects • Code that doesn’t properly implement requirements • Code that doesn’t function as programmer intended, or • Code that is not wrong, but could be improved • Only a subset of carefully chosen code is used • One estimate ~2 hours to review 400 loc • Tricky code, difficult environment, novice programmer? • Process • There is a knowledgeable code reader who briefly describes purpose of code blocks and sets pace • Author may respond to questions • If defect is found, fix is made if easy to do so • Good to switch readers

9. Pair Programming • Like tennis doubles, but much more fun • Two work together at a single computer and continuously review each other’s work • Ensures that at least two people know the product • Junior-level and senior-level can work together • People may be more thorough with someone reading their work, or more energized working together

10. Other... • Use inspections to manage commitments • Diagnosing review problems • Defects are likely introduced long before any code is written • Problems found too late … when QA finds problem • Big, useless meetings when a project went sour • The indispensable “hero” is tough to schedule and over allocated and the only one who seems to know what is going on • Code reviews and pair programming can alleviate dependence on a hero