Prozessblog

Im Rahmen des allgemeinen Qualitätsmanagements haben Sie bei sich im Projekt Reviews der Design-Spezifikationen festgelegt. Aufgrund von Termindruck möchten Sie den Projektfortschritt bei der Design-Spezifikation zeitnäher steuern und überwachen. Durch die notwendigen Abstimmungen zwischen verschiedenen Abteilungen sind Sie zudem gezwungen, den Termin für geplante Reviews vorzuziehen. Sie tun sich dabei jedoch schwer, den Autor der Spezifikation zu Reviews von Zwischenständen zu bringen. Er wiegelt dabei ab mit dem Argument, dass das Dokument noch nicht in einem prüfbaren Zustand sei, oder schlicht mit der Aussage, er sehe den Sinn in den ständigen Reviews nicht. Schaffen Sie es dennoch, ein Review durchzuführen, blockt der Autor an vielen Stellen mit dem Hinweis, dass es ja noch nicht fertig sei ab und fühlt sich bei Kritik persönlich angegriffen. Diese Verhaltensweise ist für Sie erstaunlich, da der Autor in der Regel sehr hilfsbereit und kooperativ und dafür bekannt ist, qualitativ hochwertige Ergebnisse abzuliefern.

Die Kombination aus der grundsätzlich kooperativen Art des Autors, jedoch einer deutlichen Ablehnung von Kritik und Kontrolle seiner Arbeitsweise, ist vor allem beim Typ „Champion“ zu beobachten. Der Autor will seine Arbeit unabhängig und selbstverantwortlich durchführen. Jegliche Kontrolle und Kritik an seiner Arbeitsweise durch andere Projektbeteiligte führt zu einem Abblocken seinerseits. Er neigt dazu, die Verantwortung für auftretende Probleme durch scheinbar logische Argumente auf andere Personen zu schieben. Wird der „Champion“ weiter unter Druck gesetzt, so kann dies sogar zu einem destruktiven Verhalten führen.

Folgende Verhaltensweisen Ihrerseits erlauben unter den beschriebenen Bedingungen, mit diesen Menschentyp erfolgreiche Reviews durchzuführen:

• Stellen Sie das Review als eine Plattform zur Wissensweitergabe an Andere dar!
• Sorgen Sie dafür, dass der Autor die Review-Termine rechtzeitig kennt! Lassen Sie ihn ggf. selbst einen Terminvorschlag machen. Dies gibt ihm die Möglichkeit, angefangene Themen abzuschließen!
• Teilen sie ihm mit, warum dieses Review durchgeführt werden soll! Wenn er die Hintergründe des Reviews versteht, wird er kooperativer sein.
• Informieren Sie die anderen Review-Teilnehmer vor dem eigentlichen Review in Abwesenheit des Autors, sich nur auf das Wesentliche zu beschränken!
• Fungieren Sie für den Autor als Schutzschild gegenüber unangebrachten Bemerkungen!
• Bitten Sie den Autor nach dem Review unter vier Augen, diejenigen Anmerkungen, die begründbar nicht im überprüften Dokument umgesetzt werden sollten, entsprechend zu kommentieren und die anderen Anmerkungen in das Dokument einzuarbeiten!

[1] D.Keirsey: Please Understand me II, Prometheus Nemesis, 1998
[2] www.personalitypage.com

Dieser Gastbeitrag wurde von Paul Roux-Wentzel in Zusammenarbeit mit Christian Hertneck erstellt.

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.