Prozessblog

Die Art und Weise, ein Peer Review durchzuführen, kann ja so unterschiedlich sein. Da haben wir Basti, Software-Entwickler, frisch von der Uni, aber fit im programmieren. Basti genügt es, wenn sein Kollege ‘mal eben rüberschaut’ über die Designspezifikation seiner Software-Komponente. Andreas, sein Projektleiter, kann das nicht gut heißen. Er hat schon einige Jahre Projekterfahrung hinter sich und ist überzeugter Protokollschreiber. “Was nicht protokolliert wird, ist nicht passiert”, ist seine Divise. Und so besteht Andreas auf ein Reviewprotokoll, in dem die identifizierten Findings aufgelistet sind. Wolfgang ist Qualitätssicherer aus Überzeugung und legt schon von Berufs wegen Wert auf Unabhängkeit. “Ein richtiges Peer Review muss von einem unabhängigen Moderator geleitet werden”, postuliert er. Andreas ist dagegen: “Das bindet zu viele Ressourcen in meinem Projekt!” Basti stöhnt: “Ich wollte doch eigentlich nur eben meine Komponente coden…”

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.

Nachdem wir in den letzten Wochen gesehen haben, was Walkthroughs sind und wie man sie plant, wollen wir heute mal diskutieren, wie so ein Walkthrough durchgeführt werden könnte. Hier also ein Vorschlag, der natürlich gerne kommentiert werden darf.

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?

Nachdem wir letzte Woche Sinn und Zweck eines Walkthroughs angesprochen haben, wollen wir nun sehen, wie so ein Walkthrough durchgeführt werden könnte.

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?