Der IEEE Std™ 1028-2008 IEEE Standard for Software Reviews and Audits [IEEE1028] ist der zentrale Standard für das Thema Reviews. Er beschreibt ausführlich die Kriterien, die ein Review erfüllen muss, um als formales Review zu gelten und alle Charakteristika der folgenden Reviewtypen:

• Walkthroughs,
• Inspektionen und
• Technische Reviews.

Zusätzlich werden auch

• Management Reviews und
• Audits

definiert.

Walk-throughs sind Reviews in denen der Moderator, der häufig auch der Autor selbst ist, gezielt durch das Dokument hindurch führt (walk through the document). Da die [IEEE1028] für das Walk-through nur wenige Anforderungen an Dokumente, an Ein- und Ausgangskriterien sowie an die Vorgehensweise stellt, ist dies der am wenigsten formale Reviewtyp.

Walkthroughs sind in der Praxis häufig schlecht oder gar nicht vorbereitet, die Diskussionen in der Reviewsitzung sind manchmal zu wenig zielgerichtet und daher führen Walkthroughs oft zu Open-End-Sitzungen.

Die formale Inspektion nach Fagan, nach Graham/Gilb oder anderen Autoren (Wiegers, Radice, Bryzcynski, Laitenberger, …) basiert darauf, dass alle Gutachter das Dokument detailliert gelesen haben, Befunde in einer entsprechenden Liste dokumentiert haben und sich typischerweise innerhalb von ein bis zwei Wochen nach Erhalt des zu reviewenden Dokumentes in einer moderierten Reviewsitzung zusammen mit dem Autor treffen. Zusätzlich gibt es noch die Rollen des Protokollanten und evtl. auch des Vorlesers, die aber auch von Gutachtern eingenommen werden können. Alle Autoren betonen, dass es für den Erfolg der Inspektion wichtig ist, dass

• nur Kollegen und keine Vorgesetzten beteiligt sind (Peer Review),
• der Moderator geschult ist,
• Kennzahlen erhoben und dem Management anonymisiert zur Verfügung gestellt wird,
• die Reviewsitzung zügig abläuft,
• der Autor möglichst keine weiteren Rollen und auf keinen Fall die Moderation übernimmt.

Auch wenn Technische Reviews in der IEEE Std 1028™-2008 als der formalste Typ von Dokumentenreviews (noch vor Inspektionen) definiert wird, so sieht es in der Praxis oft etwas anders aus. Die Durchführung Technischer Reviews schwankt oft stark zwischen informell und sehr formal.

Zwei Besonderheiten unterscheiden das Technische Review von den anderen Reviewtypen:

1. Die [IEEE1028] gibt nicht vor, dass der Autor des Dokuments am Technischen Review teilnimmt. Ich empfehle das jedoch, damit der Autor die Anmerkungen besser versteht, er besser lernt und auch Fragen an den Autor sofort beantwortet werden können.
2. Die [IEEE1028] erlaubt die Teilnahme von Entscheidern, falls dies zur Erreichung des Reviewzieles wichtig ist. Damit handelt es sich nicht mehr um ein Peer Review, was bei einer gefestigten Reviewkultur im Unternehmen meiner Erfahrung nach kein Problem darstellt, wohl aber sehr kritisch ist, wenn Reviews erst eingeführt werden sollen oder noch nicht mehrere Jahre als Kultur etabliert sind. Dann ist es besser, das Review zweistufig durchzuführen. D.h. das Management erhält nach Abschluss aller Reviewtätigkeiten also auch der Korrekturen durch den Autor das Dokument zu einem weiteren Review, dessen ausschließliches Ziel nur noch die Entscheidung ist. Optimalerweise hat das erste Reviewteam eine zusätzliche Entscheidungsempfehlung an das Management erstellt, so dass entsprechende Begründungen für den Entscheider gut nachvollziehbar sind.

Sobald einzelne Kriterien für formale Reviews nicht erfüllt sind, spricht man von informellen Reviews.  Vor allem gibt es für Ad-hoc Reviews, Schreibtischtest, Passaround-Reviews, etc. teilweise keine

• schriftlich festgelegten Ziele
• Moderation
• Reviewsitzung
• Protokolle
• Ein- und Ausgangskriterien
• festgelegten Prozesse
• definierten Hilfsdokumente für die jeweilige angewendete Lesetechnik (z.B. Checklisten).

In vielen Unternehmen wird zwar von Inspektionen gesprochen, de facto aber fehlen oft mehrere der oben angegebenen Formalitäten. Diese Formalitäten sind nicht einfach lästiges Beiwerk, das von einem Standard gefordert wird. Sie sind hilfreiche Mittel, um den Erfolg von Reviews zu ermöglichen. Ohne Protokolle sind Reviews nicht nachvollziehbar, es fehlen Kennzahlen, um die Reviews selbst aber auch um den gesamten Softwareentwicklungsprozess verbessern zu können. Ohne Dokumente zur Lesetechnik, hängt es von der Tagesverfassung und dem Knowhow des Gutachters ab, welche und wie viele Befunde er findet. Es sind also vergebene Chancen, Reviews im Unternehmen tatsächlich kosteneffektiv einzusetzen.

Wenn Sie mehr über Reviews und seinen erfolgreichen Einsatz wissen wollen, können Sie in diesem Blog in der nächsten Zeit weitere Artikel darüber lesen oder Sie besuchen einen meiner Workshops als Präsenztraining oder als Online-Workshop .