Seite 2: Wie lange?

Inhaltsverzeichnis

Aufwand oder Dauer eines Reviews hängen primär von den Zielen, dem Scope und der Größe des betrachteten Systems ab. Der Autor hat Reviews zwischen zwei und 60 Personentagen (kurz: PT) durchgeführt. In zwei bis vier PT können Teams einen Überblick gewinnen und eine Art "Bericht zur Lage der Nation" abgeben, ohne dabei viel Code zu sehen. Für große Systeme inklusive Betrachtung von Quellcode sowie organisatorischen Aspekten steigt der Aufwand für Reviews entsprechend an. Im Rahmen von 10 bis15 PT lassen sich schon recht viele Aspekte beleuchten und eine Menge Interviews führen. Falls sich das nach viel Aufwand anhört: Für Systeme mit 10 Personenjahren Entwicklungsaufwand (also ca. 2300 PT) bedeuten 10 PT ja gerade mal 0,4 Prozent des Gesamtaufwandes. Im Vergleich: Inspektionskosten beim PKW liegen bei knapp einem Prozent des Kaufpreises pro Jahr.

Teams sollten von ihrem Zeitbudget mindestens 20 Prozent für die Vorbereitung und Kommunikation ihrer Ergebnisse kalkulieren. Oftmals kommen nach einer Abschlusspräsentation noch eine Menge Fragen und Änderungswünsche auf das Review-Team zu.

Kick-off

Es empfiehlt sich, alle Beteiligten zu einem kurzen Kick-off-Workshop einzuladen, auf dem die Ziele und der Scope des Reviews sowie die Vorgehensweise kommuniziert werden, zusammen mit Meilensteinen und dem Zieltermin. Das spart bei den eigentlichen Interviews viel Zeit und beugt einer unproduktiven Gerüchteküche vor. Das schließt die Fach-/Produktseite, das Entwicklungsteam, Test/QS, Betrieb sowie gegebenenfalls Nutzer ein. Jedes Kick-off verdient eine individuelle Agenda, aber ein paar Themen gehören in jedem Fall dazu:

• Fachlich/organisatorisch verantwortliche Personen sollten den wirtschaftlichen oder fachlichen Zweck des Systems in Kurzform darstellen.
• Technisch versierte Personen (etwa: Architekten, Entwicklungsleitung) sollten die Architektur des Systems beziehungsweise wesentliche Subsysteme und fundamentale technische Entscheidungen aufzeigen.
• Jemand sollte das Entwicklungsvorgehen skizzieren, von Anforderungen über Implementierung/Test, Build, Deployment und Release.

In dieser Runde lässt sich eine erste qualitative Analyse des Systems durchführen, also Probleme bezüglich konkreter Qualitätsanforderungen suchen.

Kern der Sache

Zentrale Aufgabe üblicher Reviews ist die Suche nach Problemen, und die finden sich an ganz unterschiedlichen Stellen – auch jenseits vom reinen Quellcode. Tabelle 1 zeigt einige typische Bereiche, in denen man bei der Suche fündig wird.

Bereich	Was zu untersuchen ist
Architektur	interne Struktur & Modularisierung (Komponenten, Subsysteme), interne Schnittstellen & Abhängigkeiten, Kopplung, Kohäsion, Konsistenz („Homogenität“)
Code	Strukturierung, Komplexität, Änderungshäufigkeit, Verständlichkeit, Kopplung, Einheitlichkeit
Technologie	Eingesetzte Basistechnologie, 3rd-Party-Produkte/-Frameworks
Qualität	Erreichung von Qualitätsanforderungen, etwa bezüglich Performance, Änderbarkeit, Robustheit, Benutzbarkeit, Betreibbarkeit
Kontext	Externe Schnittstellen, externe Datenquellen und -senken, Benutzerrollen
Infrastruktur	Verwendete Hardware/Infrastruktur, Prozessoren, Netzwerke, Speichermedien, Topologie
Daten	Datenstrukturen, Datenbanken, Datenbanksysteme, Korrektheit und Volatilität von Daten, Verteilung/Replikation, Backup
Laufzeitverhalten	Laufzeit- und Speicherverhalten, allgemeine Ressourcennutzung, Bottlenecks
Entwicklungsprozess	Der Weg von Anforderungen zur laufenden Umsetzung, Requirements- und Change-Management, Entwicklung, Test, Build, Deployment, Versionsmanagement
Dokumentation	Das ungeliebte Thema vieler Entwicklungsteams. Zu viel oder zu wenig Dokumentation, Aktualität/Korrektheit und Akzeptanz, Auffindbarkeit, Konsistenz
Management	Umgang mit Zeit und Budget, Ressourcenplanung, Organisation der gesamten Entwicklung

Die Beteiligten sollten bei Reviews stets in der Breite suchen. Das heißt, sie stellen möglichst zu allen der in Tabelle 1 aufgeführten Themen Fragen. Die Erfahrung aus Dutzenden von Reviews zeigt, dass gravierende Probleme in Systemen definitiv nicht auf Code und Kopplung beschränkt sind, sondern dass manchmal die wirklich schlimmen Dinge an ganz anderen Stellen lauern. Ständig wechselnde Prioritäten bei Anforderungen sowie den Zwang zur Nutzung veralteter Datenstrukturen oder Datenbanken seien hier als Beispiele aufgeführt.

Es gibt neben dem Entwicklungsteam noch eine Reihe weiterer Personen oder Organisationen, die Auskünfte über das System und seine Eigenschaften respektive Probleme geben können. Diese kennen Stärken und Schwächen aus erster Hand, erleben Probleme und profitieren von Stärken – das sind für einen Review wertvolle Informationen.

Da das Review als Breitensuche durchgeführt wird, sollte auch die Auswahl der Interviewpartner in die Breite gehen. Hier sollte man beispielsweise mit folgenden Gruppen sprechen:

• Nutzer
• fachlich Verantwortliche (etwa: Vertreter der Fachbereiche)
• technisch Verantwortliche (etwa: Architekten)
• Auftraggeber, Management
• Beteiligte aus dem Entwicklungsteam. Bei größeren Systemen mit mehreren großen Subsystemen oder Komponenten eine Mischung aus mehreren Teams
• Test/Qualitätssicherung, falls nicht Teil des Entwicklungsteams
• Personen aus Infrastruktur und/oder Betrieb
• Projekt- und Produkt-Manager
• in agilen Organisationen: Product Owner, Scrum Master oder Agile Coach

Es empfiehlt sich, in Interviews offene Fragen zu stellen, die ganze Sätze als Antworten erfordern, und Ja- beziehungsweise Nein-Fragen zu vermeiden. Ratsam ist auch, nach Problemen, Schwierigkeiten und besonders aufwendigen oder langwierigen Aktivitäten im Zusammenhang mit dem System zu fragen, genauso wie nach Dingen oder Aspekten, die Personen unbedingt beibehalten möchten.

Schließlich empfiehlt der Autor, auch nach denkbaren Abhilfen der genannten Probleme zu fragen, um die Kreativität der Interviewpartner herauszufordern:

• Was würden diese tun, wenn sie eine Woche lang die gesamte Entwicklung beliebig steuern dürften?
• Was wären die Top-3-Änderungen am System, dem Entwicklungsprozess oder der Organisation, wenn sie das bestimmen dürften?

Zum Abschluss eines Interviews ist hilfreich, sich zu erkundigen, welche Fragen vermisst wurden. Das gibt den interviewten Personen die Gelegenheit, noch ganz andere Themen anzusprechen.

Interviews sollte man am besten zu zweit führen. Wenn ein Duo im Wechsel fragt und mitschreibt, dann kann sich die fragende Person besser auf Gestik, Mimik und Verhalten der anderen konzentrieren und ist nicht ständig durch Mitschreiben abgelenkt. Man sollte Bemerkungen markieren, die weitere Analysen oder Nachprüfungen erfordern, und sich bei Bedarf weitere Ansprechpersonen nennen lassen, die mehr Informationen zu bestimmten Themen haben. Die Interviews sollten auf 60 bis 90 Minuten begrenzt sein, und bei Bedarf sollte man lieber Folgetermine vereinbaren. Zwischen zwei solcher Interviews sollten Interviewer für sich selbst 15 Minuten Pause einplanen, damit sie kurz reflektieren, ihre Notizen kennzeichnen und sich für das nachfolgende Interview mental sammeln können.