Prozessblog

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.

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?