Lesezeit 4 min
Review! Das Wort alleine vertreibt schon Entwickler und Projektleiter. Jeder findet zwar, dass Reviews schon gut sind für die Qualität und dass man dabei etwas lernen kann, aber...
Wir sehen, wie man Reviews mehr oder weniger effizient und effektiv durchführen kann. Und weil es keinen keinen Sinn macht, wenn man die Zeit vertut und nichts sinnvolles dabei herausschaut, finden wir, dass wir folgende Fallstricke vermeiden sollten:
- Wie sehe in den Wald wieder, nicht nur Bäume?
- Was soll ich denn nun genau prüfen?
- So ist das doch gut genug?
- Wie finde ich, was fehlt?
- Wo ist der unabhängige Reviewer?
- Wie kriege ich Konsistenz hin?
- Da fehlt noch ein Komma... Was ist mit dem Inhalt?
- Den Review-Prozess haben wir eingehalten... Das reicht wohl?
Wie sehe in den Wald wieder, nicht nur Bäume?
Problem
Der Gutachter verliert sich in der Review, er sieht den Wald vor lauter Bäumen nicht mehr. Das Hauptziel des Review wäre, Korrektheit und Vollständigkeit des Artefakts zu prüfen. Folgende Aspekte können von diesem Hauptziel ablenken:
- ein grosser Umfang der zu prüfenden Inhalte: dies führt zu vielen Details in denen man sich verlieren kann
- eine umfangreiche Liste von Prüfpunkten (z.B. in Checklisten) mit detaillierten Checks sowohl zu Inhalten und als auch zu formellen Aspekten
Lösung
Das Hauptziel der Review den Gutachter vermitteln, d.h. Korrektheit und Vollständigkeit. Dies kann in einer Schulung und in den Arbeitsanweisungen der Review geschehen.
Zusätzlich kann man die zu prüfende Aspekte einzelnen Gutachtern zuordnen. Z.B. lassen sich formelle Aspekte (Kodierregeln, Namensregeln, Anforderungsregeln...) durch einen einzelnen Gutachter effizient prüfen, der dann nicht die Übersicht haben muss. Auch verschiedene inhaltliche Themenbereiche des Artefakts können gut auf verschiedene Gutachter verteilt werden.
Was soll ich denn nun genau prüfen?
Problem
Es wird zu viel oder zu wenig geprüft, da unklar ist, was zu prüfen wäre. Nur Änderungen seit letztem Review oder alles?
Lösung
Der Umfang, das Scope des Reviews in der Review-Dokumentation klar definieren, formelle Review-Einladung erstellen mit klarer Definition des Scopes.
So ist das doch gut genug?
Problem
Gutachter haben sehr unterschiedliche qualitative Ansprüche an Artefakt.
Lösung
Definieren Sie qualitative Anforderungen und Guidelines für Artefakte (Dokument, Code, ...). Rotieren Sie die Review Partner, damit sich mit der Zeit eine gemeinsames Verständnis über die geforderte Qualität etabliert.
Wie finde ich, was fehlt?
Problem
Es fehlt eine Prüfung auf Vollständigkeit, eine Prüfung darüber, was vergessen ging. Meist ist es einfacher, die Konsistenz des vorhanden Materials zu prüfen als herauszufinden was fehlt bzw. vergessen ging.
Lösung
Bewusst in einer ersten Lesung das Artefakt nach Vollständigkeit prüfen.
Eine Checkliste erstellen mit Themen, welche im Artefakt enthalten sein müssen.
Prüfen ob übergeordnete Dokumente (z.B. Systemanforderungen beim Review von Software-Anforderungen) vollständig abgebildet wurden. Hier hilft Anforderungs-Verfolgbarkeit (Requirements-Traceability).
Wo ist der unabhängige Reviewer?
Problem
Ein Review sollte von einem Gutachter durchgeführt werden, der mit der Erstellung des Artefaktes nichts zu tun hatte. Wenn nun das "gesamte Projekt-Team" an der Erstellung des Dokumentes mitarbeitete (z.B. Anforderungen oder Architektur/ Design), wo finden wir einen unabhängigen Gutachter?
Lösung
Man kann pro Artefakt jemanden bestimmen, der daran nicht mitarbeitet. Oder noch besser, man bezieht einen unabhängigen Gutachter von ausserhalb des Projekt-Teams ein. Der Nachteil der "externen" Lösung kann sein, dass der Gutachter zuwenig Domänenwissen zum konkreten Projekt hat und daher nicht seh effizient ist. Dafür kann er neue Ideen und Impulse ins Projekt einbringen.
Oder man kann mindestens zwei Gutachter einsetzen, so ist sichergestellt, dass überall mindestens dass 4-Augen Prinzip erfüllt ist.
Wie kriege ich Konsistenz hin?
Problem
Die inhaltlichen Anforderungen sind den einzelnen Gutachtern nicht klar. Sie existieren nur in den Köpfen einiger Gutachter und manchmal auch der Autoren. Infolgedessen sind sie in der Regel nicht konsistent.
Lösung
Zuerst die übergeordnete Anforderungen dokumentieren, z.B. vor der Software Design Review das Pflichtenheft für diese Software klären.
Da fehlt noch ein Komma... Was ist mit dem Inhalt?
Problem
Eines der häufigsten Probleme ist Fokussierung auf formellen Aspekten statt auf den Inhalt. Formelle Aspekte (z.B. richtige Formatierung, richtige Revisionshistorie) sind zwar wichtig, aber wichtiger sind Inhalte. Die Prüfung der formellen Aspekte ist jedoch meist einfacher (und benötigt weniger Zeit) als sich mit dem Inhalt auseinanderzusetzen.
Lösung
Den Gutachter vermitteln, dass der Inhalt wichtiger ist als die Form. Dies kann in einer Schulung und in den Arbeitsanweisungen der Review geschehen.
Zusätzlich kann man die zu prüfende Aspekte einzelnen Gutachtern zuordnen. Z.B. lassen sich formelle Aspekte (Kodierregeln, Namensregeln, Anforderungsregeln...) durch einen einzelnen Gutachter effizient prüfen. Jemand anderer kann sich dann um den Inhalt kümmern.
Den Review-Prozess haben wir eingehalten... Das reicht wohl?
Problem
Dem korrekter formellen Ablauf wird mehr Aufmerksamkeit und Zeit geschenkt als der inhaltlichen Prüfung
Lösung
Den Gutachter vermitteln, dass der Inhalt wichtiger ist als der formelle Ablauf. Dies kann in einer Schulung und in den Arbeitsanweisungen der Review geschehen.
Matthias Eggenberger
Haben Sie zusätzliche Fragen? Haben Sie eine andere Meinung? Wenn ja, mailen Sie mir oder kommentieren Sie Ihre Gedanken unten!
Autor
Keine Kommentare