Requirements Retrospective
| When you finish your requirements specification, you usually face pressure to get on with the rest of the project. But before you leave your requirements process, stop and give yourself a chance to learn from what you have done. A retrospective is a tool for gathering the wealth of experience that might otherwise be lostan expensive loss when a day or two's effort retains it for all time. The result of the retrospective is a written summary explaining what you learned from your project and how you think other people might gain from your experience.
What to Look ForFocus on reviewing the effectiveness of the way you gathered and specified your requirements. Look at each part of the process you followed, and iden-tify which parts worked well and which parts did not. Find the major mistakes, but don't assign blame. The retrospective cannot be used as a witch-hunt. If project members suspect that management will punish them for making mistakes, then they will naturally cover up those mistakes. You can really be effective only in an organization free from fear. Find the major successes, but don't dole out rewards. This practice encourages people to highlight anything they did in the hope of being rewarded rather than prompting them to look at the project dispassionately. The retrospective process has to be kept completely separate from the personnel reward system. The main question to ask in the retrospective is this: "If you had to do it again, how would you do it and why?"
The Volere Requirements Process model in appendix A contains a detailed procedure for retrospectives and writing reports. Refer running to Process 6, "Do Requirements Retrospective." Running the RetrospectiveThe way you run the retrospective depends on how many people are involved. Your aim is to get input from everyone who contributed to the requirements specification; there are a number of ways to do this. Figure 15.6 illustrates a retrospective process. Figure 15.6.Your retrospective should seek input from everyone who was involved in producing the specification. The best advice that we can give you is to appoint a facilitator. A facilitator is someone who has no vested interest in the project and no self-interest in the outcome of the retrospective. His task is to gather the project experience. The facilitator encourages each member of the project team (manager, technical staff, client) to share his own observations about the requirements. These individual comments are usually gathered via interviews, but can be collected anonymously. Responses by individual project members are not publicized, as confidentiality encourages people to speak more freely. Separate meetings are arranged by the retrospective facilitator, with homogenous groups of people involved in requirementsproject management, project technical staff, and stakeholders. Each group considers the specification process from its own perspective and gives the facilitator issues to add to the list. The facilitator brings up points from his private contact with team members for clarification and concurrence. Each group isoffered the chance to add or change the issues. Now the facilitator, armed with some insights into the project and its participants, looks at the facts. For example, the facilitator might review the project plans and assess how the deliverables tracked to it, or count the changes to the specification after initial acceptance. The purpose of this research is to quantify the issues raised by the project members and to gain more insights into why things happened the way they did. The facilitator can hold a full project retrospective meeting that brings together all personnel involved in earlier stages of the retrospective. At this time managers, technical staff, and clients hear the findings described by the facilitator and discuss each. Retrospective ReportIf no follow-on research is required from the full retrospective meeting, the facilitator writes the final retrospective report, often with the assistance of project members. The report, which is made available to everyone in the organization to review, includes contact names for further discussion on any issues. It outlines recommended procedures and tools, describes problems found and possible solutions to take, and details any project disappointments or failures. The purpose of the report is to pass on experience, by making it as concise as possible. It also helps if it has an interesting table of contents: Requirements Retrospective ReportOur requirements specification had successes and failures. This report shares our experiences so that you can profit from the successes and avoid the mistakes that caused the failures. Contents
|
EAN: 2147483647
Pages: 371