5 Reviews, die ein Systems Engineer kennen muss

Es hat sich längst herumgesprochen, wie effektiv Reviews sind, um Fehler zu finden. Dennoch sehe ich häufig, dass Reviews auf die lange Bank geschoben werden. Doch es gibt viele verschieden Typen von Reviews. Diese zu kennen hilft uns, den richtigen zu nutzen, den Mehrwert der Reviews zu maximieren und den Aufwand, so gering wie möglich zu halten.

Agilität braucht Reviews

Um es gleich vorwegzunehmen: Agile Projekte profitieren enorm von Reviews. Daher sind diese auch feste Bestandteile von vielen agilen Methoden. Scrum zum Beispiel fordert regelmäßige Sprint Reviews. Auch Code Reviews und Pair Programming sind beliebte Techniken in der agilen Entwicklung.

Gerade in agilen Projekten ist es wichtig, dass die Reviews leichtgewichtig sind und einen klaren nutzen haben. Auch die richtigen Werkzeuge können Reviews enorm beschleunigen und „weniger schmerzhaft“ machen.

Werkzeuge machen Reviews wesentlich effizienter

Reviews sind aus mehreren Gründen unbeliebt. Viele der Gründe können allerdings mit Werkzeugen gelöst werden. Zu den wichtigsten Gründen gehört:

• Ergebnisse zusammenführen – Wer kennt es nicht: Eine Spezifikation wird als Word-Datei verschickt. Der Sender bekommt dann fünf angepasste Dokumente zurück und muss diese dann zusammenführen. Viel Spaß…
• Ergebnisse dokumentieren – Was nützt ein Review, wenn die Ergebnisse nicht ordentlich dokumentiert werden? Und zwar in einer Weise, wo sie auf bei Bedarf gefunden werden? Am Besten auch noch in einer Form, die einem Audit standhält.
• Asynchron arbeiten – Oder es treffen sich fünf Personen im Besprechungsraum und gehen durch gemeinsam durch die Anforderungen. Bei der dritten Anforderung auf der zweiten Seite gibt es eine lange Diskussion, an der sich nur zwei Experten beteiligen. Schließlich wird das Review-Meeting vertagt, da die restlichen zehn Seiten noch nicht gereviewed wurden.

Für solche Probleme gibt es keine Entschuldigung mehr:

• In der Softwareentwicklung werden längst Werkzeuge wie Gerrit oder ALM-Systeme wie gitHub eingesetzt, mit denen Teams ihre Code-Reviews zeitlich unabhängig und sauber dokumentiert durchführen können.
• Cloud-Basierte Textverarbeitungssysteme wie Google Docs haben Kommentarfunktionen für verteilte Reviews eingebaut. Selbst Microsoft Word kann das inzwischen.
• Moderne RE-Werkzeuge wie Jama Connect oder Intland Codebeamer haben integrierte Review-Systeme, die formelle Reviews ermöglichen.

Reviews in der Literatur

Gerade im Systems Engineering geht es kaum ohne Reviews, da viele Projekte sicherheitskritisch sind und entsprechende Compliance-Anforderungen umsetzen müssen. Viele Standards, einschließlich ISO 15288 oder IEEE 1028. Insbesondere die IEEE 1028 kennt fünf Reviews, die jeder Systems Engineer kennen sollte.

Wichtig ist hier jedoch, dass die Literatur diese Reviews recht formal angeht. In der Praxis sollten wir den Sinn des Reviews hinterfragen und prüfen, ob wir diesen auch weniger formal mit dem Selben Ziel umsetzen können. Gerade mit Werkzeugen können wir die Reviews gefühlt wesentlich weniger formal gestalten, da die Werkzeuge sich automatisch um den Audit-Trail kümmern.

Hier nun die fünf Review-Typen:;

Auch wenn die Bezeichnung eher an den Abteilungsleiter erinnert, geht es hier eigentlich nur ums Projektmanagement. Ein Management-Review kann informell sein und hat das Ziel, Probleme und Engpässe frühzeitig zu erkennen.

Das Daily Scrum, welches nicht länger als 15 Minuten dauern sollte, ist ein sehr informeller Management-Review.

Wie der Name schon sagt, geht es hier um einen Review für die technische Korrektheit. Ein informeller Code-Review ist ein gutes Beispiel für diese Klasse von Reviews.

Technische Reviews können extrem informell sein. In der Softwareentwicklung ist das Pair-Programming eine Form eines kontinuierlichen, informellen Reviews. Ebenso können wir Kollegen kurz am Schreibtisch mit einem Blatt Papier besuchen (nun ja, Corona…), um kurz Feedback einzuholen.

Es ist erstaunlich, wie unverständlich einem die selbst geschriebene Spezifikation manchmal schon nach einer Woche erscheint…

Für einen technischen Review brauchen wir noch nicht einmal Kollegen: Genauso können wir einen Review unserer eigenen Arbeitsergebnisse durchführen. Sinnvoll ist es hier, dies nicht sofort nach der Erstellung zu machen, sondern etwas Abstand zum Arbeitsergebnis zu bekommen. Außerdem ist es sinnvoll, übliche Review-Techniken einzusetzen, zum Beispiel Checklisten.

Es wird formaler

Ein Walk-Through ist genau das, was der Name sagt: Eine Person führt eine Gruppe durch ein Arbeitsprodukt und erklärt in einer sinnvollen Reihenfolge, warum das Arbeitsprodukt so ist wie es ist. Die Führung kann der Autor übernehmen, das muss aber nicht unbedingt so sein.

Die IEEE 1028 definiert einen Walk-Through recht formal mit bestimmten vorgegebenen Rollen. Doch auch die oft bei einem Sprint-Review vorgesehene Demo ist ein Walk-Through.

Walk-Throughs können auch schnell interaktiv werden, wenn Teilnehmer bestimmte Schritte nicht nachvollziehen können oder in Frage stellen. Dies ist eine gute Gelegenheit, Alternativen zu diskutieren. Darauf sollten wir bei einem Walk-Through vorbereitet sein. Denn hier steckt ein hoher Wert des Walk-Throughs: Wir können Skeptiker ins Boot holen und überzeugen. Und vielleicht haben die Skeptiker ja recht und wir erarbeiten gemeinsam eine noch bessere Lösung.

Eine Inspektion ist formaler als ein Walk-Through. Insbesondere muss bei einer Inspektion das gesamte Arbeitsprodukt geprüft und formal festgehalten werden.

Eine Inspektion arbeitet in der Regel recht formal. Zum Beispiel gibt es oft Prüfregeln, Checklisten, Vorgaben an die Teilnehmer und vieles mehr.

Auch wenn es keine gesetzlichen Vorgaben gibt, so können Inspektionen, richtig eingesetzt, die Qualität des Ergebnisses drastisch verbessern. Wer sich dafür entscheidet, sollte unbedingt so viel wie möglich automatisieren. Zum Beispiel kann ein modernes Entwicklungssystem so konfiguriert werden, dass mindestens zwei unterschiedliche Personen ein Code-Review durchführen, bevor Code in einen Branch gemerged wird. Ebenso können viele formale Prüfungen auch automatisiert werden. Das ist in der Softwareentwicklung längst Standard (bspw. mit statischer Codeanalyse). Und selbst Spezifikationen in natürlicher Sprache können inzwischen auf Vokabular, Konsistenz und anderes automatisch überprüft werden.

Der formalste aller Reviews ist der Audit. Hier ist ein externer Sachverständiger zugange. Audits werden oft vom Gesetzgeber durchgeführt, aber auch von Kunden oder unabhängigen Organisationen. Audits sind häufig wegen Compliance-Anforderungen vorgeschrieben.

Organisationen, die eine Review-Kultur haben, brauchen sich vor Audits nicht zu fürchten. Doch auch in solchen Fällen kann ein Audit einen Erheblichen Aufwand verursachen, da dieser Zeit und Ressourcen bindet. Auch hier können Werkzeuge helfen. Ein vernünftig aufgesetztes Repository mit entsprechenden Prozessen kann enorm viel Zeit sparen. Es ist dabei unerheblich ob das Repository Anforderungen, Modelle oder Code enthält. Gute Prozesse sorgen dafür, dass eine Organisation kontinuierlich „audit-ready“ ist.

Fazit

Reviews sind enorm effektiv und letzten Endes auch günstig. Damit es funktioniert, braucht eine Organisation eine Review-Kultur. Die richtige Einstellung, pragmatische Prozesse und gute Werkzeuge helfen, den Reviews den Schrecken zu nehmen.

Photo by Markus Winkler on Unsplash