|
|
SM/ASM 2003: The Power of Retrospectives This paper discusses and explains the differences between post project reviews and retrospectives. Three retrospective case studies are also detailed.
|
Esther Derby, Esther Derby Associates Inc
|
|
|
Bulletproof your Review Program! In this article, the author explains how to bulletproof your review program by avoiding traps that typically kill technical review programs. She also details four common reasons why review programs fail and what you can do to successfully implement one for your team.
|
Esther Derby, Esther Derby Associates Inc
|
|
|
Introduce and Sustain a Worldwide Software Inspection Process In this presentation you will discover how to: understand the benefits that come with implementing inspections, understand the steps to rollout an effective inspection process, how to anticipate the problems that can be
encountered during an inspection rollout, and learn the importance of monitoring to maintain effective inspections. This paper also details system inspection definitions.
|
Marc Rene, GTECH Corporation
|
|
|
Traps That Can Kill a Review Program (And How to Avoid Them) Technical reviews have been around for a long time, and they're generally recognized as a "good thing" for building quality software and reducing the cost of rework. Yet many software companies start to do reviews only to have the review program falter. So the question remains: How can you succeed with a review program? Management support and good training for review leaders is a good place to start. But it's the details of implementation that truly determine whether reviews will stick, or they'll fall by the wayside. Esther Derby offers her insights based on observations from both successful and failed review programs.
|
Esther Derby, Esther Derby Associates Inc
|
|
|
STAREAST 2000: How Testers Can Contribute to Reviews Brian Lawrence begins his presentation with a brief overview of what a review is and how it works in software organizations. Although testers may or may not understand source code, they can still contribute considerable value in reviews. Learn how to devise tests as a review preparation technique that can identify potential defects and serve as a basis for test planning and design.
|
Brian Lawrence, Coyote Valley Software
|
|
|
Retrospectives: They're Not Just For Developers Anymore Traditional methods for improving testing include training, hiring, adding new processes, building infrastructure, and buying new tools. But what about increasing the capability of the team? Author Aldous Huxley said, "Experience is not what happens to a man; it is what a man does with what happens to him." The same is true for software teams: It's what we do with our experience that matters. Too often, we don't do much-if anything-to squeeze learning out of our experience. Retrospectives are a way to take the "what happened" during a software project and use it to build understanding. Testing borrows a page from adult learning theory and project reviews to increase team capability through Testing Retrospectives, and determines how to do more of what worked and less of what didn't.
|
Esther Derby, Esther Derby Associates Inc
|
|
|
Applying Testing Expertise to the Retrospective Goldmine Digging up postmortem project data is like mining for gold. The returns can be significant and long-term because this is where your best (and worst) practices really shine. By allowing your test groups to drive the retrospective activities, improvements can finally be built into the product lifecycle model instead of rotting in a postmortem report. By improving retrospective facilitation and follow-up, you'll ultimately improve your software lifecycle process. Nick Borelli delivers a practical and proven approach to the retrospective process, and shows you how to build consensus for process improvements uncovered during retrospective analysis.
|
Nick Borelli, Microsoft Corporation
|
|
|
Software Documentation Superstitions Do you need credible evidence that disciplined document reviews (a.k.a. inspections) can keep total project costs down while helping you meet the schedule and improve quality? The project documentation we actually need should meet predetermined quality criteria, but organizations are often superstitious about writing this documentation-and they let their superstitions inhibit their efforts. This presentation dispels the superstitions and shows you how reinforcements for improving the quality of your software project documentation-such as requirements, design, and test plans/procedures-can occur through disciplined document reviews.
|
Gregory Daich, Software Technology Support Center
|
|
|
Software Inspection: A Failure Story? Even the most successful inspections can fail if team members aren't vigilant. A large financial institution has agreed to allow their story to be told (anonymously) for the purpose of illustrating how a program that was a classic success could fall into disuse. Specifically, you'll see how the company built up a very successful inspection program, and was achieving significant benefits, until four years later when inspections were no longer being done. How did this happen? Is it unique? What did they do right, and in the end what went wrong? This presentation delivers the lessons learned from this story, so you can avoid making the same mistakes.
|
Dorothy Graham, Grove Consultants
|
|
|
The Guided Inspection Technique Early detection of faults is a cost-effective technique for ensuring quality. The guided inspection technique described in this presentation uses explicit test cases to guide the inspection process rather than leaving the coverage of the model to chance. Learn how this technique systematically determines whether the model is complete, correct, and consistent. Gain an understanding of how to integrate this technique into the typical, iterative, incremental process.
|
Melissa Russ, Korson-McGregor
|
