Agile . since Jun 23 . Index . DOCs TOP TOC

Agile Inspektionen

Agile Inspektionen wurden von Tom Gilb im Jahr 2005 vorgestellt [1] und werden auch   „Extreme Inspections“ oder „Agile Specification Quality Control (SQC)“ [5] genannt. Agile Inspektionen sind besonders in Wasserfall-Projekten nützlich, weil es dort keine kurzen Feedback-Schleifen (z.B. in Form von Iterationen) gibt.

Ausgangspunkt für Agile Inspektionen sind Beobachtungen, die beim Einsatz von klassischen Inspektionen gemacht wurden. Bei klassischen Inspektionen kommt es manchmal vor, dass die Autoren aufgrund der Review-Erfahrungen beginnen, deutlich fehlerfreier zu arbeiten. Es gibt mehrere Beispiele solcher Lernkurven, in denen es den Autoren gelungen ist, nach einiger Zeit ungefähr 10 Mal weniger Major Defects pro Seite zu machen als vorher (was den Rework-Anteil im Projekt um Faktor 10 sinken lässt). Der Lernprozess dauerte wenige Monate und die Autoren nahmen während dieser Zeit an ca. fünf bis sieben Inspektionen teil.

Aus diesen Beobachtungen entstand die Grundidee der Agilen Inspektionen: Der Schwerpunkt der Inspektionen wird verschoben weg vom frühzeitigen Fehler finden und korrigieren („cleanup“-Modus) hin zum Schätzen der Fehlerdichte der Dokumente, um die Entwickler zu motivieren, zu lernen wie man von vorne herein fehlerfreier arbeitet.

Dadurch sinken die Kosten für Inspektionen enorm: es müssen nicht mehr alle Seiten aller Dokumente geprüft werden, sondern Stichproben reichen aus.

Das Hauptziel der Agilen Inspektionen ist es also, die Entwickler zu motivieren, ihre Fehlerrate zu senken. Zusätzliche Ziele sind, genauso wie bei klassischen Inspektionen: verhindern, dass zu fehlerhafte Dokumente in die folgenden Software-Entwicklungsphasen gelangen (Terminverzögerungen und Qualitätsprobleme wären sonst die Folge). Zudem werden gültige Prozess-Standards durchgesetzt und gelehrt.

Agile Inspektionen laufen nach den folgenden allgemeinen Prinzipien ab:

- Wenige Seiten auf einmal werden geprüft, beispielsweise ein bis drei Seiten.

- Eventuell wird sehr frühzeitig geprüft, zum Beispiel schon wenn die ersten 5 % eines großen Dokuments fertig sind.

- Es wird kontinuierlich geprüft (z.B. jede Woche), bis die Arbeit fertig ist.

- Die Dokumente jedes Entwicklers werden geprüft, denn jeder einzelne Autor muss persönlich motiviert und trainiert werden.

Ablauf einer Agilen Inspektion

Eine Stichprobe wird ausgewählt (z.B. eine Seite) und gegen ca. drei bis sieben Regeln geprüft. Beispiele für Regeln: 1. Clarity („clear enough to test“), 2. Unambiguous („to the intended readership“), 3. Consistent („with other statements in the same or related documents“). Die Reviewer sollen alle Abweichungen von diesen Regeln identifizieren und nach Major oder Minor Defect klassifizieren. Die Major Defects werden an den Moderator berichtet.

An der Prüfsitzung nehmen beispielsweise zwei Reviewer teil, also eher weniger als bei einer klassischen Inspektion. Die Sitzung dauert ca. 30-60 Minuten. Geprüft wird mit optimaler Inspektionsrate, typischerweise eine bis höchstens zwei Seiten pro Stunde. Ein trainierter Moderator ist anwesend und leitet den Prozess.

Nach der Prüfung wird die geschätzte Anzahl der tatsächlich vorhandenen Fehler aus der Gesamtzahl der gefundenen Fehler berechnet. (Berechnungsgrundlage: typischerweise findet das Team in diesem Setting ein Drittel der vorhandenen Fehler.) Als Exit-Kriterium der Inspektion wird anfangs ein Wert wie beispielsweise „maximal 10 Major Defects pro Seite“ angesetzt. Nach ein paar Monaten „Kulturänderung“ sollte man das Limit eher bei „1 Major Defect pro Seite“ ansetzen.

Abhängig von der Fehlerdichte legt das Reviewteam weitere Maßnahmen fest. Wenn die Fehlerdichte sehr hoch ist (z.B. 10 Major Defects pro Seite oder mehr), wäre es unökonomisch, die anderen Seiten des Dokuments zu prüfen, um „alle Fehler“ zu finden. Und es würde auch nicht viel nützen, die bisher gefundenen Fehler zu korrigieren. Es würden trotzdem zu viele Major Defects unentdeckt bleiben. Die beste Alternative ist, das Dokument durch den Autor oder jemand anderen neu schreiben zu lassen. (Hier sieht man, dass eine frühzeitige Agile Inspektion Sinn macht, beispielsweise wenn 5 % des Dokuments fertig sind.)

Bemerkungen

Eine Eigenheit der Agilen Inspektionen ist, dass im Gegensatz zu klassischen Inspektionen das Dokument nicht gegen die Vorgängerdokumente geprüft wird, sondern nur gegen das Wissen der Reviewer. Dadurch wird die Prüfung beschleunigt, allerdings ist das Ergebnis ungenauer.

Gilb vollzieht mit den Agilen Inspektionen einen Paradigmenwechsel, der nicht nur für Qualitätssicherer sehr überraschend ist. Die unmittelbare Lösung gegen hohe Fehlerdichten ist nicht, die gefundenen Fehler aus dem Dokument zu entfernen, und ist nicht, den Softwareentwicklungsprozess zu ändern! Die effektivste praktikable Lösung ist: Sicherstellen, dass jeder Autor das Exit-Kriterium der maximalen Fehlerdichte ernst nimmt. Das ist erreichbar, denn im Durchschnitt sollte nach jeder Agilen Inspektion die Fehlerrate eines Autors um ca. 50 % sinken.