Reviews

Ziel

Ein Review sagt, ob ein Arbeitsergebnis trägt, bevor andere darauf aufbauen. Es richtet einen oder mehrere Blicke auf den Inhalt, die nicht die des Autors sind, und der Abstand zwischen dem, was der Autor schreiben wollte, und dem, was tatsächlich geschrieben steht, ist ein Fehler. Das BABOK setzt die Grenze von Anfang an: Ein Review bewertet den Inhalt des Arbeitsergebnisses und nicht die Fähigkeiten oder Handlungen der Teilnehmenden (§10.37.2). Diese Grenze ist die Bedingung dafür, dass ein Team seine Arbeit zur Prüfung gibt: Ein Review, das zur Bewertung von Personen abgleitet, lässt seinen eigenen Stoff versiegen.

Das geprüfte Ergebnis kann ein vollständiges Paket, ein Liefergegenstand, ein Teil davon oder noch laufende Arbeit sein, und sein Zustand lenkt bereits die Absicht. Bei einem fertigen Ergebnis ist die Absicht meist, Fehler zu entfernen oder die Reviewer zu informieren; bei laufender Arbeit ist sie, eine Frage zu klären oder einen Punkt zu entscheiden. Der Business Analyst ist immer an einem Review beteiligt, als Autor eines eingereichten Liefergegenstands oder als Reviewer des Liefergegenstands einer anderen Person.

Was die Familie zurücklässt, ist ein geprüftes Ergebnis und eine Aufzeichnung der Befunde, mehr oder weniger formell je nach gewähltem Typ. Der Wert eines Reviews liegt in dem, was die Aufzeichnung danach erlaubt: einen Punkt wieder aufnehmen, belegen, dass eine Lektüre stattgefunden hat, eine Korrektur bis zu ihrer Verifikation verfolgen.

Eine Projektmanagementmethode kann diese Aufzeichnung verbindlich machen. HERMES, die Methode des Bundes, unterscheidet das Prüfen, das die inhaltliche und formale Überprüfung von Dokumenten und die Einhaltung vereinbarter Prozesse umfasst, vom Testen, das am laufenden System ansetzt; die Aufgabe 5.4.3.38 Qualitätssicherung führen umfasst nur das Prüfen. Sie nennt "Vernehmlassungen, Reviews, Audits" als mögliche Verfahren, ohne eines vorzuschreiben. Der Prüfplan, ein Kapitel des Projektmanagementplans, hält im Voraus die zu prüfenden Ergebnisse, ihre Prüfverfahren und die ausführende Rolle fest, je nachdem, ob das Projekt klassisch oder agil vorgeht. Die Befunde und der Entscheid zum Status des Ergebnisses werden im Ergebnis 4.4.1.40 Prüfprotokoll festgehalten.

Verwendung

Wann einzusetzen

• Ein Arbeitsergebnis, von dem andere abhängen werden: Anforderungen, Spezifikation, Architektur, ein Modell, das dem Rest als Grundlage dient.
• Fehler früh zu entfernen: Ein bei der Lektüre gefundener Fehler kostet weit weniger als derselbe Fehler in der Produktion.
• Konsens oder gemeinsames Verständnis herzustellen: Mehrere Parteien müssen sich über einen Liefergegenstand einigen, bevor er weitergeht.
• Konformität mit einer Norm oder Spezifikation nachzuweisen: Ein Qualitätstor verlangt eine dokumentierte Lektüre.
• Eine offene Frage oder einen technischen Punkt zu klären: Laufende Arbeit hängt an einer Wahl, die eine gezielte Lektüre lösen kann.
• Ein Team einzuarbeiten: Ein Ergebnis von Kollegen lesen zu lassen, macht sie mit dem Inhalt vertraut, den sie pflegen werden.

Wann nicht einzusetzen

• Eine Entscheidung zwischen bereits bekannten Optionen: Ein Review bewertet Inhalt, es wählt nicht; zur Entscheidungsanalyse wechseln.
• Ausführbares Verhalten zu prüfen: Ein Review liest ein statisches Ergebnis und führt nichts aus; zu den Testtechniken und zum Testfallentwurf greifen.
• Ein bereits bekannter und lokalisierter Fehler: Es gibt nichts mehr zu finden, nur zu korrigieren und zu verifizieren; die Nacharbeit direkt eröffnen und den Punkt ins Item Tracking überführen.

Die drei Dimensionen eines Reviews

Das BABOK beschreibt die sieben Typen als das Produkt dreier Wahlen (§10.37.2). Jede Dimension wird unabhängig von den beiden anderen eingestellt, und es ist ihre Kombination, die den Typ benennt.

Das Ziel

Das Ziel wird vor dem Review angekündigt und allen Teilnehmern mitgeteilt (§10.37.3.1). Das BABOK nennt sieben mögliche: Fehler entfernen, die Konformität mit einer Spezifikation oder Norm prüfen, feststellen, dass das Ergebnis vollständig und korrekt ist, Konsens über einen Ansatz oder eine Lösung herstellen, eine Frage beantworten oder Varianten erkunden, die Reviewer mit dem Ergebnis vertraut machen, seine Qualität messen. Das dominierende Ziel wiegt bei der Wahl des Typs am schwersten: Die Qualität einer kritischen Komponente zu messen, verlangt nicht dasselbe Review wie eine rasche Rückmeldung zu einem Entwurf.

Die Teilnehmer

Vier Rollen stehen zur Verfügung (Tabelle 10.37.1). Der Autor beantwortet Fragen, hört zu und arbeitet die Änderungen nach dem Review ein. Der Reviewer, ein Kollege oder eine Stakeholderin, prüft das Ergebnis gegen die angekündigten Ziele; bei einem Review zur Fehlererkennung prüft er es vor der Sitzung und führt die Liste seiner Befunde. Der Moderator, ein neutraler Teilnehmer, leitet die Sitzung, hält sie auf ihrem Ziel und stellt sicher, dass die Reviewer sich vorbereitet haben; das BABOK hält fest, dass er nicht der Autor sein sollte, sonst wird das Review beeinträchtigt. Der Protokollant, ebenfalls ein neutraler Teilnehmer, hält Fehler, Kommentare, Punkte und offene Fragen fest. Die Zahl der Reviewer ist die entscheidende Einstellung dieser Dimension: einer allein, und man ist auf der Seite von Desk Check und Ad-hoc-Review; ein Team, und man ist auf der Seite von Inspektion, formalem Walkthrough und Umlaufverfahren. Moderator und Protokollant treten nicht in jedem Typ auf. Der Moderator leitet die formellsten Reviews, die Inspektion und den formalen Walkthrough, und kann beim technischen Review mithelfen. Der Protokollant hält in der Inspektion, im formalen Walkthrough und im informellen Walkthrough fest.

Die Technik und die Formalität

Das BABOK ordnet die sieben Typen vom formellsten zum informellsten und bezeichnet die ersten drei als formelle Techniken, die folgenden vier als informelle (§10.37.3.2). Zwei binäre Fragen stellen diese Dimension ein. Ist die Sitzung geplant, mit zugewiesenen Rollen? Prüfen die Reviewer das Ergebnis jeder für sich, bevor sie darüber sprechen? Zwei Ja stellen das Review unter die formellen Typen, aufwendig und streng; zwei Nein stellen es unter die informellen Typen, leicht und schnell. Entlang dieser Dimension steigen auch Sicherheit und Kosten gemeinsam.

Von den drei Einstellungen zum Typ

Sind die drei Dimensionen eingestellt, ist der Review-Typ nahezu bestimmt. Die Qualität einer fertigen Spezifikation messen, mit einem verfügbaren Team und einer geplanten Sitzung: Das ist eine Inspektion. Konsens herstellen und einarbeiten, mit Kollegen und Stakeholdern in der Sitzung: ein formaler Walkthrough. Einen einzelnen Punkt oder die Konformität mit einer Norm entscheiden, mit einigen Fachleuten des Themas: ein technisches Review. Rasche Rückmeldungen zu einem Entwurf einholen, mit Kollegen, die sich wenig vorbereitet haben: ein informeller Walkthrough. Ein einzelner externer Reviewer, wann es ihm passt: ein Desk Check. Mehrere Reviewer, jeder für sich, ohne Sitzung: ein Umlaufverfahren. Die punktuelle Hilfe eines Kollegen bei laufender Arbeit: ein Ad-hoc-Review.

Die drei Dimensionen sind nicht ganz frei voneinander, und das macht die Entscheidung praktikabel. Die Qualität eines Ergebnisses zu messen, heisst zu zählen, also eine formelle Technik und ein Team: Dieses Ziel zieht die beiden anderen Dimensionen zum formellen Ende der Familie. Umgekehrt kann ein einzelner Reviewer keinen Konsens herstellen, sodass Desk Check und Ad-hoc-Review den Zielen der Rückmeldung und der Hilfe dienen. Ein Befund, der das Review überdauern muss, welcher Typ auch immer, verlässt die Technik und tritt ins Item Tracking ein, wo er einen Verantwortlichen, eine Frist und einen Status erhält.

Stärken und Grenzen der Familie

Die Stärken gelten für die ganze Familie (§10.37.4.1). Reviews fangen Fehler früh im Lebenszyklus des Ergebnisses ab, dort, wo sie am wenigsten zu entfernen kosten. Sie machen die Reviewer am Ergebnis beteiligt: Wer ein Ergebnis gelesen hat, fühlt sich für dessen Qualität mitverantwortlich. Und die informellen Typen mit einem oder mehreren asynchronen Reviewern fügen sich dem Zeitplan des Reviewers, ohne einberufene Sitzung.

Die Grenzen folgen denselben Dimensionen. Ein formaler Walkthrough oder eine Inspektion, auf allen drei Achsen hoch eingestellt, kostet Zeit und Aufwand, sodass nur die kritischsten Ergebnisse das rechtfertigen. Ein niedrig eingestelltes Review, mit einem oder zwei Reviewern, ist günstig, gibt aber weniger Sicherheit, dass alle wesentlichen Fehler entfernt wurden. Bei einem Desk Check oder einem Umlaufverfahren ist es für den Autor schwer zu verifizieren, dass eine unabhängige Lektüre tatsächlich stattgefunden hat. Und per E-Mail ausgetauschte Rückmeldungen erzeugen viele Nachrichten, die schwer abzugleichen sind. Die drei Dimensionen einzustellen, heisst auch, zu wählen, welche dieser Grenzen man in Kauf nimmt.

KI-Überlegungen

Die Hilfe betrifft den Stoff des geprüften Ergebnisses. Ein Modell liest ein Ergebnis gegen eine Prüfliste und meldet die mechanischen Lücken, eine Anforderung ohne Akzeptanzkriterium, ein Begriff, der verwendet wird, bevor er definiert ist, eine Referenz, die nicht auflöst: ein erster Durchgang, der die Technik-Dimension der formellen Typen entlastet. Es gruppiert und formt die verstreuten Rückmeldungen eines Umlaufverfahrens, was die Grenze der E-Mail-Stränge unmittelbar angeht. Es verfasst ein Protokoll aus den Notizen des Protokollanten.

Die Grenze fällt auf das Einstellen der drei Dimensionen, das ein Urteil ist. Das Ziel festzulegen, setzt voraus zu wissen, wozu das Ergebnis verpflichtet und welchen Nachweis die Organisation wird zeigen müssen; die Teilnehmer festzulegen, setzt voraus, ihre Verfügbarkeit und ihre Expertise zu kennen; die Formalität festzulegen, setzt voraus, zwischen der angestrebten Sicherheit und der verfügbaren Zeit abzuwägen. Ein Modell kennt keines dieser drei Elemente. Die Ziele von Konsens und Einarbeitung laufen zudem über ein Gespräch zwischen Personen, das keine automatische Zusammenfassung ersetzt, und ein von einem Modell erzeugter Befund ist von seiner Bauart her plausibel, sodass er als Hypothese ins Review eingeht, die ein Reviewer bestätigt oder verwirft. Da die geprüften Ergebnisse oft sensibel sind, interne Anforderungen, Kundendaten, setzt ihre Weitergabe an ein externes Werkzeug die Rechtsgrundlage und die Berechtigung voraus, die der Datenschutz verlangt.

Quellen

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.37 Reviews: die Definition des Reviews, die Grenze, die das Review auf den Inhalt beschränkt, die drei Dimensionen (Ziele, Techniken, Teilnehmer), die vier Rollen, die Ordnung der sieben Typen nach Formalität und die Stärken und Grenzen der Familie.
• IEEE Std 1028-2008, IEEE Standard for Software Reviews and Audits: standards.ieee.org/ieee/1028. Die normierte Taxonomie der Reviews und Audits und die Unterscheidung formell/informell.
• Karl E. Wiegers, Peer Reviews in Software: A Practical Guide, Addison-Wesley: processimpact.com, Kapitel 3. Das Formalitätskontinuum der Peer-Reviews und der Kompromiss zwischen Strenge, Kosten und Sicherheit.
• Schweizerische Eidgenossenschaft, Bundeskanzlei, HERMES 2022, Referenzhandbuch Projektmanagement, Aufgabe 5.4.3.38 Qualitätssicherung führen, Ergebnis 4.4.1.40 Prüfprotokoll, Prüfplan (Kapitel des Ergebnisses 4.4.1.34 Projektmanagementplan): die Unterscheidung zwischen Prüfen und Testen, das Review als eines der möglichen Prüfverfahren, ohne dass seine Form vorgeschrieben wird, der Prüfplan, der Ergebnis, Prüfverfahren und Rolle im Voraus festlegt, sowie das Prüfprotokoll, das die Befunde und den Entscheid zum Status des Ergebnisses festhält.