Seite 620ff.

Nachdem Code Junkie Basti, unser Projektleiter Andreas und Q-Mann Wolfgang nun ihre kleinen Meinungsdifferenzen über das richtige Maß an Formalität von Peer Reviews beseite legen konnten (siehe Artikel Wieviel Review hätten’s denn gern?), fragen sich die drei aber heute, was denn eigentlich CMMI zu den Peer Reviews sagt.

“Pah, nichts wird drin stehen”, meckert Wolfgang; er ist noch nicht wirklich überzeugt, dass dieses neumodische Modell wirklich mehr bringen soll als sein verehrter ISO-Standard. Währenddessen blättert Andreas in der deutschsprachigen Ausgabe des Buches: “Doch, hier hinten im Glossar ist es schon mal erwähnt. Peer-Review: Prüfung von Arbeitsergebnissen durch Gleichrangige während der Entwicklung der Arbeitsergebnisse, um zu beseitigende Mängel zu entdecken.“, zitiert er. Basti guckt grinsend hinter seinem Laptop hoch. Er hat sich inzwischen das PDF gezogen und nach dem Begriff durchsucht. “Mehr zur Durchführung von Peer-Reviews steht im Prozessgebiet Verifizierung“, findet er heraus.

Und tatsächlich! Auch wenn CMMI kein eigenes Prozessgebiet für Peer Reviews vorsieht, widmet es den Prüfungen durch Gleichgestellte doch ein eigenes Spezifisches Ziel, nämlich Specific Goal (SG) 2 im Prozessgebiet Verifizierung: “Peer-Reviews werden für ausgewählte Arbeitsergebnisse durchgeführt”. Als Ziel ist es ein erforderliches Element in einem Appraisal – an Peer Reviews kommt also keiner herum, sollte auch keiner, wie wir schon gelernt haben (siehe Artikel Was bringen Peer Reviews?).

Die drei Practices, die das Ziel dann aufweist, sind recht simpel zu verstehen, nämlich

1. Peer-Reviews vorbereiten
2. Peer-Reviews durchführen
3. Daten aus Peer-Reviews analysieren

VER SP 2.1 Peer-Reviews durchführen

Die genannten Schritte zur Vorbereitung könnten sich auch in der Beschreibung einer Peer Review Methode wiederfinden. Hier geht es darum, für jedes einzelne Peer Review zu entscheiden, wie formal es durchgeführt werden soll, wer die Prüfer sind, welche Metriken erfasst werden sollen und wie die Ein- und Ausgangskriterien lauten. Hier geht es um Review-Checklisten zu bestimmten Arbeitsergebnistypen, um die Festlegung der Zeitpunkte von Peer Reviews (Peer-Review-Zeitplan) und darum, dass der Autor oder Reviewleiter das Reviewobjekt rechtzeitig verteilt.

Die meisten dieser Punkte sollten grundsätzlich festgeschrieben sein, bspw. in der Peer Review Guideline und einer entsprechenden Vorlage für das Reviewprotokoll.

VER SP 2.2 Peer-Reviews durchführen

Hier geht es nun um das Auffinden von Fehlern und Unzulänglichkeiten im untersuchten Arbeitsergebnis. Fehler und offene Punkte werden dokumentiert, damit der Autor sie lösen kann. Ein weiteres Peer Review des selben Arbeitsergebnisses kann erforderlich sein.

VER SP 2.3 Daten aus Peer-Reviews analysieren

Measurement and Analysis lässt grüßen in dieser Practice. Definierte Metriken werden erhoben und für künftige Analysen gespeichert. Dabei ist insb. in Deutschland auf datenschutzrechtliche Sicherung zu achten. Die erhobenen Daten sollten nicht zur Leistungsbewertung von Mitarbeitern verwendet werden können.

Sinnvolle Daten könnten die folgenden sein:

• Produktname und Produktgröße zur Klassifizierung der Daten
• Zusammensetzung des Review-Teams (Rollen)
• Art (Formalität) des Peer Reviews
• Vorbereitungszeit aller Prüfer und Dauer der Review-Besprechung
• Größe des Arbeitsergebnisses bspw. in Anzahl Zeilen
• Anzahl, Schwere, Typ, Ursprung der Fehler
• Phase, in der die Fehler gemacht wurden

Es ließen sich daraus gewisse Metriken errechnen, die man im Laufe der Zeit optimieren könnte:

• Erkennungsrate: Anzahl Fehler / Anzahl Zeilen
• Erkennungseffizienz: Anzahl Fehler / Benötigte Zeit

Sie sehen, CMMI verlängt Peer Reviews und zwar nicht nur die Durchführung, sondern auch die Analyse und damit die ständige Verbesserung des Prozesses. Die Process Area Verification ist auf Maturity Level 3.

Wer hat denn nun Recht? Wie läuft ein “richtiges” Peer Review ab? Wieviel Aufwand muss man treiben? Die Standardantwort (“It depends.”) passt natürlich auch hier: Es kommt drauf an. Es kommt drauf an, wie wichtig mein Arbeitsergebnis ist. So würde ich mich einer Anforderungsspezifikation bestimmt intensiver widmen als der Überarbeitung der Testspezifikation einer Komponente, die schon seit Jahren in Betrieb ist. Vielleicht aber auch nicht, denn die Testfälle, die hinzugefügt wurden, sollen nun endlich die immer wieder auftauchenden Probleme der Komponente lösen.

Es kommt auch drauf an, in welchem Zustand sich ein Arbeitsergebnis befindet. Bei den Artikeln zu den (informaleren) Walkthroughs haben wir schon festgestellt, dass diese eher angewendet werden, wenn das Arbeitsergebnis vielleicht ein Drittel fertig ist, um sich die Richtung bestätigen zu lassen. Vor der endgültigen Freigabe eines Projekthandbuches müsste ich aber doch sehr wohl etwas mehr Formalität an den Tag legen, bestimmt doch dieses Wesentliches im weiteren Projektverlauf.

Was aber unterscheidet nun die unterschiedlichen Peer Review Methoden? Basti, Andreas und Wolfgang haben schon einige afugedeckt.

• Der Einsatz eines Reviewleiters kann sinnvoll sein, da er den Peer Review Prozess kennt und als geschulter Moderator im Führen von Meetings erfahren ist.
• Ein gewisses Maß an Konfigurationsmanagement erleichtert das Peer Review. Dazu zählt zum einen, das Dokument “aufzuräumen”, mit Zeilennummern zu versehen, auf Rechtschreibfehler zu prüfen und Kommenatre zu entfernen. Zum anderen sollte für das Review die Unveränderbarkeit des Reviewobjekts sichergestellt werden, damit alle Reviewer die selbe Version des Arbeitsergebnisses prüfen.
• Für größere Peer Reviews macht es oft Sinn, ein Review Kickoff durchzuführen, in dem der Reviewleiter oder der Autor kurz das Vorgehen erläutert, einen Überblick über das zu prüfende Arbeitsergebnis liefert und evtl. verschiedene Schwerpunkt-Sichten an die Reviewer verteilt.
• Entscheindend ist dann bei allen Peer Reviews aus meiner Sicht, dass sich die Reviewer das Arbeitsergebnis “offline” ansehen und ihre Anmerkungen notieren. Diese Vorbereitung ist wichtiger als ein anschließendes Reviewmeeting. In diesem sollten die gefundenen Findings nur noch besprochen werden, so dass der Autor weiß, was gemeint war.
• In einem sehr reifen Reviewprozess kann man nach einem Peer Review die gefundenen Unzulänglichkeiten analysieren, um Kernursachen für Fehler zu identifizieren. Diese können dann in Checklisten eingearbeitet werden, um die selben Fehler zukünftig zu vermeiden.

Grundsätzlich macht es also Sinn, sich mehrere Peer Review Methoden zu definieren, die dann jeweils die oben genannten Elemente einbinden oder eben nicht. Neben dem Walkthrough schlage ich den informalen Buddy Check (“Schau mal rüber”) vor, darüber hinaus aber auch ein formaleres Technisches Review mit Offline Review und Reviewprotokoll, sowie die sehr formale Inspektion, die nicht vom Autor selbst, sondern von einem Reviewleiter geführt wird.

Also, Basti, Andreas und Wolfgang, ich denke, Ihr alle hattet irgendwie Recht.

Der Autor erklärt zu Beginn des Walkthroughs, wie das Walkthrough Meeting abläuft. Es besteht in der Regel aus den folgenden zwei Abschnitten:

• der Autor präsentiert das Reviewobjekt
• der Autor moderiert eine Kommentarrunde

Präsentation des Reviewobjekts

Der Autor stellt sein Arbeitsergebnis den Teilnehmern vor, so dass diese den Inhalt des Reviewobjekts verstehen. Sind die Prüfer mit dem Reviewobjekt noch nicht vertraut, sollte der Autor das Arbeitsergebnis schrittweise vorstellen, ohne irgendwelchen Inhalt auszulassen. In der Regel wird der Autor sein Arbeitsergebnis sogar Wort für Wort vorlesen. Das hört sich zunächst übertrieben an, ist aber notwendig, wenn der Inhalt des Arbeitsergebnisses für die Teilnehmer gänzlich neu ist.

Wurde vorher schon mal ein Review zu dem Arbeitsergebnis durchgeführt, an dem alle anwesenden Prüfer beteiligt waren, ist es ausreichend, nur auf die geänderten Stellen einzugehen.

Die Prüfer machen sich parallel Notizen, die sie in der anschließenden Kommentarrunde anmerken.

Kommentarrunde

In der Kommentarrunde bringt jeder Prüfer seine notierten Reviewanmerkungen hervor. Der Autor notiert diese idealerweise in einem Reviewprotokoll oder macht entsprechende Anmerkungen direkt im Reviewobjekt. Die folgenden Spielregeln sind denkbar:

• Die Gruppe einigt sich vorher auf ein Zeitlimit für die Kommentarrunde.
• Jeder Prüfer bringt reihum jeweils eine Reviewanmerkung hervor, die unter Angabe des Prüfers im Reviewprotokoll notiert wird.
• Prüfer können in einer Runde aussetzen (“Ich passe.”) und wieder eine Reviewanmerkung in der folgenden Runde bringen.
• Jede Reviewanmerkung muss irgendein Defizit im Arbeitsergebnis identifizieren.
• Es liegt im Ermessen des Autors, inwiefern er auch die Diskussion von Lösungsansätzen zulässt.
• Jede Reviewanmerkung muss allen Teilnehmern klar sein, bevor sie im Reviewprotokoll erfasst wird.
• Persönliche Kritik ist verboten. Reviewanmerkungen beziehen sich auf das Arbeitsergebnis, nicht auf den Autor.

Die Kommentarrunde endet, wenn alle Teilnehmer aussetzen oder das Zeitlimit erreicht ist.

Variationen

Statt der Aufteilung in Präsentation und Kommentarrunde kann sich der Autor auch dazu entschließen, sein Arbeitsergebnis abschnittsweise zu präsentieren und nach jedem Abschnitt Kommentare zuzulassen, die er als Reviewanmerkungen notiert.

Reviewanmerkungen beheben

Nach dem eigentlichen Walkthrough Meeting behebt der Autor die protokollierten Reviewanmerkungen in seinem Arbeitsergebnis. Der Autor ist Eigner des Dokuments und entscheidet selbst, welche Reviewanmerkungen er behebt und welche nicht. Eine erneute Prüfung durch die Prüfer ist nicht Bestandteil desselben Walkthroughs.

Soweit der Vorschlag der Durchführung eines Reviews. Was meinen Sie? Ist die Aufteilung in Präsentation und Kommentarrunde zu künstlich?

Der Autor wählt typischerweise Prüfer aus, die über ein zum Reviewobjekt entsprechendes Fachwissen verfügen und an der Verbesserung des Arbeitsergebnisses interessiert sind. Das Walkthrough erfordert in der Regel keine Vorbereitung der Prüfer, so dass der Autor ohne größere Vorlaufzeit zum Walkthrough Meeting einladen kann.

Zeitverschreibung

Falls Zeitverschreibung auf Projekte und Vorgänge in Ihrer Firma eine Rolle spielt, sollte der Autor schon in der Einladung angeben, worauf die geladenen Prüfer den Aufwand verbuchen können.

Da die Durchführung eines Walkthroughs in der Regel keine Vorbereitung der Prüfer bedarf, werden Walkthroughs meist nicht explizit vom Projektleiter im Projektplan eingeplant; alle Teilnehmer verbuchen auf einen allgemeinen Vorgang, den der Projektleiter für informale Reviews vorgesehen hat.

Teilnehmer

Die Anzahl der Prüfer hängt vom beabsichtigten Zweck des Walkthroughs ab. Möchte sich der Autor eher seine Herangehensweise absichern lassen, sind neben ihm in der Regel drei weitere Prüfer genug. Möchte der Autor jedoch vor allem das Verständnis seines Arbeitsergebnisses bei seinen Kollegen erhöhen, ist die Teilnehmerzahl im Grunde nur davon begrenzt, inwiefern die Informationen noch effektiv kommuniziert werden können. Es sollten jedoch nur Kollegen teilnehmen, die einen Benefit aus dem Walkthrough für Ihre Arbeit ziehen.

Die Prüfer brauchen kein spezielles Training, um an Walkthroughs teilzunehmen, müssen aber über entsprechendes Fachwissen zum Reviewobjekt verfügen. Idealerweise nehmen Prüfer teil, die das zu betrachtende Arbeitsergebnis aus unterschiedlichen Perspektiven betrachten.

Wie viele Teilnehmer haben Sie in der Regel in einem Walkthrough sitzen?

Das Walkthrough ist eine informale Reviewmethode, bei dem der Autor den Inhalt seines Arbeitsergebnisses in einem Meeting den anwesenden Prüfern erläutert, indem er es sukzessive vorliest. Die Prüfer haben die Chance, auf Probleme oder Unklarheiten hinzuweisen oder Verständnisfragen zu klären.

Ein Walkthrough kann somit als “Peer Group Diskussion” verstanden werden. Wie bei allen Peer Reviews hat auch das Walkthrough zum Ziel, Fehler und Verbesserungspotential im Arbeitsergebnis zu identifizieren. Im Gegensatz zu anderen Reviewmethoden hat das Walkthrough aber einen relativ großen Kommunikations- und Schulungscharakter. Es eignet sich daher besonders gut als zum Vorstellen eines Dokumentes in der Entstehung und zur Klärung eines gewählten Ansatzes. Bei weitergehender Fertigstellung können dann andere Reviewmethoden einen stärkeren Schwerpunkt auf das Finden von Fehlern legen. Ein Walkthrough allein ist keinesfalls ausreichend für die abschließende Prüfung eines Arbeitsergebnisses.

Ein Walkthrough wird also durchgeführt, um

• einen ersten Entwurf oder Ansatz vorzustellen und Feedback einzuholen
• gemeinsam Unstimmigkeiten aufzudecken
• mit Kollegen Alternativen zu hinterfragen
• das Reviewobjekt zu verbessern
• Kollegen den Inhalt eines Reviewobjekts nahe zu bringen

Nächstes Mal schauen wir uns an, wie man so ein Walkthrough plant und durchführt. Wie ist das in Ihrer Firma? Führen Sie Walkthroughs durch?

Qualität steigern

Eines der offensichtlichsten Ziele ist es, die Qualität der Arbeitsergebnisse zu steigern. Dokumente, die in einem oder mehreren Peer Reviews geprüft wurden, sind von höherer Qualität, denn identifizierte Fehler, Unstimmigkeiten und Widersprüche konnten beseitigt werden. Der Autor kann dadurch ein besseres Arbeitsergebnis abliefern, das er ohne die Mithilfe seiner Kollegen (Peers) nicht in derselben Qualität hätte erzeugen können.

Nacharbeit reduzieren

Das Projekthandbuch, Anforderungen, Test-Spezifikationen, Design-Dokumente, Zeichnungen und alle anderen Arbeitsergebnisse, die im Projekt entstehen, enthalten Fehler und Unstimmigkeiten, ihnen fehlen Informationen, sie bergen Missverständnisse beim Lesen oder widersprechen schlicht den gültigen Standards und Eltern-Dokumenten. Das ist normal und unumgänglich.

Entscheidend ist, wann diese Unzulänglichkeiten entdeckt werden. Die Kosten für Nacharbeit steigen exponentiell zur Projektdauer. Eine missverständliche Anforderung lässt sich zu Beginn des Projektes noch leicht neu formulieren. Wenn aber erst ein Design und Source Code entstanden ist und erst bei einer Demonstration des fertigen Produktes beim Kunden herauskommt, dass etwas Falsches entwickelt wurde, sind die Kosten immens.

Frühe Fehlererkennung kann sogar den Zeitplan eines Projektes verkürzen, wie Studien belegen. Daher ist es wichtig, rechtzeitig Peer Reviews durchzuführen, um Nacharbeit (Rework) so gering wie möglich zu halten.

Wissen weitergeben

Viele sehen Knowledge-Transfer als einen der Hauptvorteile von Peer Reviews. Oft entwickelt nur ein einzelner Mitarbeiter an einem bestimmten Arbeitsergebnis. Der Ausfall dieses Mitarbeiters kann ein hohes Risiko für das Projekt darstellen. Durch Peer Reviews können Kollegen mit in die Details eingebunden werden, da sie sich als Prüfer intensiv mit dem Arbeitsergebnis beschäftigen. Auch zur Einarbeitung neuer Mitarbeiter können Peer Reviews beitragen.

Teamarbeit fördern

Die Einbindung von Kollegen (Peers) zur Durchsicht eines Dokumentes fördert die Arbeit im Team. Ein Mitarbeiter, der an Peer Reviews als Prüfer mitwirkt, erhält ein umfassenderes Verständnis des Gesamtproduktes und kann die Kenntnisse für seine eigenen Arbeitsergebnisse verwenden. Ein Autor, der sein Arbeitsergebnis einem oder mehreren Peer Reviews unterzogen hat, kann sich mit den Prüfern über fachliche Inhalte austauschen, aktuelle Probleme diskutieren und so sein Arbeitsergebnis schneller und qualitativ hochwertiger fertig stellen.

Der Begriff Review lässt sich im Deutschen vielleicht mit Durchsicht übersetzen, aber Review ist so geläufig, dass es eine Übertragung ins Deutsche hier fehl am Platz ist. Diese Kollegen sehen sich also mein Arbeitsergebnis an und weisen mich idealerweise auf Fehler, Unstimmigkeiten, fehlende Informationen, Zweideutigkeiten oder Missverständliches hin. Dabei kann der Grad der Formalität sehr unterscheidlich sein und so definieren sich viele Firmen unterschiedliche Peer Review Methoden – doch dazu ein ander Mal mehr.

Damit ich als Prüfer (als Reviewer) entscheiden kann, was richtig oder falsch ist, brauche ich eine Referenz. Eine solche Referenz kann den Prüfern  in Form eine Review-Checkliste zu einem bestimmten Arbeitsergebnis-Typ vorliegen. Jedes Arbeitsergebnis sollte außerdem ein High-Level-Dokument haben, von dem es abgeleitet ist. So ist bspw. eine Design-Spezifikation von den Anforderungen abgeleitet und kann dagegen geprüft werden.

Zusammenfassend können wir uns also folgende Definition basteln:

Ein Peer Review ist ein Prozess zur Verifikation eines Arbeitsergebnisses in einem bestimmten Zustand, bei dem kleine Teams gleichgestellter Experten durch manuelle Durchsicht Unzulänglichkeiten im Arbeitsergebnis aufdecken zur Sicherstellung von Korrektheit und Konformität zu Standards, Spezifikationen und Anforderungen.

Ich denke, mit dieser Definition können wir erstmal leben. Kommentare und Verbesserungen sind natürlich erwünscht. Nächste Woche schauen wir uns dann an, was Peer Reviews eigentlich bringen.