SOPHIST: Hallo Herr Götz. Während Ihrer langjährigen Tätigkeit im Bereich Requirements Engineering sind Sie sicherlich schon häufig mit den unterschiedlichsten Reviewtechniken in Berührung gekommen. Welche Erfahrungen konnten Sie in Ihrer Projektarbeit hierbei sammeln? Gab es wiederkehrende Problemstellungen?

Rolf Götz: Hi! Reviews sind trotz erwiesenem Nutzen immer schwer in Organisationen so zu verankern, dass sie von selbst laufen. Wie bei allen Techniken, deren Vorteile für die Mitarbeiter nicht ersichtlich sind, schläft die Anwendung spätestens dann ein, wenn der „Champion“ der Technik die Lust verliert oder abhandenkommt. Das habe ich bei den „Extreme Inspections“ anders erlebt, weil die Mitarbeiter gesehen haben, dass sie sich unterm Strich Arbeit sparen, und außerdem noch wie Helden aussehen. Man muss das mal erlebt haben: der Fokus rückt sehr schnell weg vom „meine Fehler finden lassen“ und richtet sich auf „gleich gute Ergebnisse erzielen“.

SOPHIST: Sie haben gerade „Extreme Inspections“ als neue Reviewvariante erwähnt. Was versteht man darunter und wie läuft eine Extreme Inspection ab?

Rolf Götz: So neu ist die Variante nicht, nur nicht weit bekannt. Die Grundlagen hat Fagan gelegt, Tom Gilb hat die Methode dann weiterentwickelt. Aufgrund von Feedback aus Kundenprojekten hat er viel daran verändert. Soweit ich weiß hat er mal eine Untersuchung in Auftrag gegeben, die mehr als 30 einzelne Verbesserungen gegenüber den Fagan-Inspections ergeben hat. Ich denke die wichtigste Verbesserung ist das Stichprobenverfahren.

Extreme Inspections, oder auch „Agile/Lean Inspections“ ist eine Technik, deren Ziele mit den üblichen Zielen von Reviewtechniken wenig gemein haben.

Wichtigste Erkenntnis: Traditionelle Reviews sind ungeeignet, um die Qualität von Ergebnissen sicher zu stellen, weil sie nicht genügend Fehler aufspüren. Es ist einfach nicht effizient, zum Beispiel seitenlange Dokumente von vorne bis hinten zu lesen, oder hunderte Code-Zeilen durchzusehen. Eigentlich ist schon die Aufgabenstellung „Fehler finden“ sinnlos. Es geht doch darum, eine Aussage zur Qualität zu bekommen, und daraufhin zu entscheiden, ob Überarbeitungen nötig sind oder nicht. Und dafür, so beweisen die Extreme Inspections, reicht die Prüfung einer kleinen Stichprobe völlig aus. Wenn ich auf einer einzelnen Seite Anforderungsbeschreibung schon 40-60 Fehler finde, brauche ich den Rest nicht mehr zu lesen. Das sind übrigens sehr übliche Zahlen für Dokumente, die schon mal einen „QA passed“ Stempel bekommen haben. Erschreckend, nicht wahr?

Man sucht sich also mehr oder weniger zufällig eine Stichprobe aus, prüft die sehr eingehend, zählt die potenziellen Fehler, und rechnet dann die Fehleranzahl für das Dokument oder den Codebaustein hoch. Ist die Hochrechnung über einem festzulegenden Wert, so entscheidet man sich gegen die Freigabe. Ist sie darunter, so vergibt man den (neuen) „QA passed“ Stempel.

Entscheidender Unterschied: Wir zählen Fehler, wir kommentieren sie nicht. Das dient dazu, mehr Zeit für eine noch genauere Prüfung zu haben. Der Autor oder Entwickler bekommt also nur eine Liste der Stellen auf der Seite, die die Prüfer für fehlerhaft halten. Wenn er nicht versteht, was der Prüfer da ankreidet, kann er nachfragen. Die Änderungen an den markierten Stellen vorzunehmen bleibt in seiner Verantwortung.

Einen möglichen Fehler aufzuspüren ist sehr einfach, man nimmt sehr einfache Regeln an. Für Anforderungen bin ich immer gut gefahren mit nur drei simplen Regeln: klar genug für den Leser, kein unnötig vorweggenommenes Design, und testbar. Halte ich als Prüfer eine der Regeln für verletzt, so markiere und zähle ich einen Fehler.

SOPHIST: Wie würden Sie im Nachgang die Durchführung von Extreme Inspections bewerten?

Rolf Götz: Game changer, ganz klar. Wir kommen damit sehr schnell weg vom Fehler beseitigen, hin zum Fehler vermeiden. Die Autoren lernen einfach, wie sie es anstellen müssen, nahezu beliebige Regeln einzuhalten. Sie hören schlicht auf, bestimmte Typen von Fehler zu machen. Wer dann noch die Regeln mit Augenmaß und gemeinsam mit den Autoren sowie den Konsumenten der Anforderungen festlegt, hat gewonnen. Die Autoren reißen sich plötzlich darum, ihre Dokumente geprüft zu bekommen, weil sie dabei irre schnell was echt Nützliches lernen. Die cleversten Autoren nutzen die Inspections sofort zu ihrem Vorteil und schreiben nur ganz wenig, vor der ersten Prüfung. Erst wenn sie schon einen Großteil aller Fehler vermeiden können, machen sie sich an größere Mengen Beschreibung. Lernerfolg und Kostenersparnis der Methode sind enorm.

SOPHIST: Haben Sie hierzu auch dediziert Zahlen erhoben, d.h. eine ROI-Betrachtung durchgeführt?

Rolf Götz: Ja, das hat mich dann doch mal interessiert. Ich habe Extreme Inspections mit Reviews anhand praktischer Beispiele verglichen. Genauer handelte es sich um eine fast 3-stellige Anzahl von Use Case-Beschreibungen. Inspections bedeuten unterm Strich 2/3 weniger Aufwand. Nach jeder einzelnen Inspection bleiben etwas weniger als die Hälfte der Fehler im Dokument, verglichen mit Reviews. Der Überarbeitungsaufwand steigt auf fast das 8-fache. Der Folgeschaden in Anforderungsdokumenten sinkt auf etwa die Hälfte. Mit ungefähr drei Inspektionen kommt man auf ein für Anfänger akzeptables Fehlerniveau von 8 oder weniger Fehlern pro Seite, und es lässt sich ein ROI von rund 4:1 für diese Methode ermitteln. Mit ein paar Monaten Übung kommt man auf Fehlerdichten von weniger als 1 Fehler pro Seite. Wer mal so einen Use Case gelesen hat weiß plötzlich, wie sich echte Qualität anfühlt.

Bei anderen Anwendern gibt es leicht unterschiedliche Zahlen, aber allesamt sind sie beeindruckend. Bei meinen Versuchen hat sich auch der Praxistipp ergeben, zuerst leichte Lesbarkeit sicherzustellen, bevor man versucht den Inhalt von Beschreibungen zu verbessern. Eigentlich logisch: wenn ich schon nicht verstehe, was da steht, fällt es mir schwer zu sagen, ob es richtig ist.

SOPHIST: Das sind ja beeindruckende Ergebnisse. Vielen Dank für das Interview, Herr Götz.

Extreme Inspections sind also eine sehr effektive Reviewtechnik, um möglichst viele Fehler aufzudecken und Autoren bereits im Vorfeld für bestimmte Fehlertypen zu sensibilisieren. Einen gewissen Aufwand müssen Sie trotzdem dafür spendieren. Ebenso, wenn ihr Review auf ein gemeinsames Verständnis der Anforderungen bei allen beteiligten Stakeholdern abzielt. Auch die Erstellung von Begriffsmodellen und Testfällen während der Analyse führt zwar zu einer späteren Fertigstellung der Anforderungsspezifikation, doch werden durch diese Prüfmethoden deutlich mehr Fehler in Anforderungen oder komplett fehlende Anforderungen aufgedeckt als beim „normalen“ Vorgehen. Die früh investierte Zeit wird später aber hohen Fehlerbehebungsaufwand einsparen und somit insgesamt die Kosten reduzieren. Deshalb muss aus unserer Sicht hier ein Umdenken stattfinden und mehr Zeit für die Analysephase eingeplant werden. Sie werden sehen, es wird sich lohnen!