Ausgangslage

Die Werkzeuge sind ausgerollt. Entwicklerinnen und Entwickler nutzen sie im Editor, in der Kommandozeile und als Agenten, die ganze Änderungen vorbereiten. Der Review-Prozess ist derselbe wie vorher: Pull Request, eine Person liest, kommentiert, gibt frei. Er war für Änderungen ausgelegt, die eine Person selbst geschrieben und dabei verstanden hat. Für Änderungen, die eine Person angenommen hat, ohne jede Zeile geschrieben zu haben, fehlt ihm ein Kriterium. Die Folge zeigt sich als längere Review-Warteschlange, als größere Pull Requests und als Fehler, die im Review durchgehen, weil ein generierter Test etwas anderes prüft, als sein Name sagt.

Ein Review-Gate ist eine Stelle im Ablauf, an der ein generiertes Ergebnis nach einem festgelegten Kriterium geprüft wird, bevor es weitergeht. Nach ISO 9241-110 ist Steuerbarkeit ein Grundsatz der Dialoggestaltung: Die Person behält die Kontrolle über den Ablauf. Im Engineering heißt das, dass die Entscheidung über die Übernahme einer Änderung bei einer Person liegt, die sie beurteilen kann, und dass diese Entscheidung im Ablauf einen festen Ort hat.

Die drei Gates im Ablauf

Wir setzen drei Gates. Sie liegen vor der Delegation, vor der Übernahme in den Branch und im Review des Pull Requests.

Gate 1, vor der Delegation. Bevor eine Aufgabe an ein Werkzeug geht, ist festgelegt, ob sie delegiert werden darf und mit welchem Kontext. Aufgaben mit Sicherheitsbezug, mit Zugriff auf Produktionsdaten oder mit Auswirkungen auf Schnittstellen, die andere Teams nutzen, stehen auf einer Liste, für die das Gate eine zweite Person verlangt oder die Delegation ausschließt. Das Gate besteht aus einer kurzen Prüfliste, die die Person vor dem Auftrag durchgeht, und einer Notiz im Ticket, was delegiert wurde.

Gate 2, vor der Übernahme in den Branch. Die Person, die den Vorschlag angenommen hat, prüft ihn nach einem Kriterium, das für generierte Anteile geschrieben ist: Tut die Änderung, was der Auftrag verlangt, und nichts darüber hinaus? Prüfen die Tests das Verhalten der Funktion, oder wiederholen sie den Code, den sie begleiten? Sind Abhängigkeiten hinzugekommen, die niemand angefordert hat? Die Person kennzeichnet im Commit, welche Anteile generiert sind.

Gate 3, im Review des Pull Requests. Die reviewende Person sieht die Kennzeichnung aus Gate 2 und prüft die generierten Anteile mit einer eigenen Liste. Sie ist kürzer als die Liste aus Gate 2 und zielt auf das, was die erste Person nicht sehen konnte: Passt die Änderung zu den Konventionen des Repositorys, verändert sie Verhalten an Stellen, die der Auftrag nicht nennt, und ist die Kennzeichnung vollständig? Das Gate hält fest, wer freigegeben hat.

Die Freigabe zur Auslieferung bleibt, wie sie ist. Sie braucht kein eigenes Gate für generierte Anteile, weil die Prüfung davor stattgefunden hat.

Die Kriterien für die Freigabe

Ein Kriterium ist eine Frage, die mit Ja oder Nein beantwortet wird und deren Antwort im Ablauf festgehalten wird. Wir schreiben die Kriterien mit dem Team, aus den Fehlern der zurückliegenden Monate: Welche generierten Änderungen sind durchgegangen und hätten es nicht dürfen? Jeder dieser Fälle liefert eine Frage für Gate 2 oder Gate 3. Die Liste bleibt kurz. Ein Gate mit einer langen Liste wird übersprungen, und dann prüft niemand.

Zwei Fragen gehören in unseren eigenen Abläufen zu jedem Gate: die Frage nach dem Umfang der Änderung („nichts darüber hinaus") und die Frage nach dem, was die Tests prüfen. Beide zielen auf die Fehlerarten, die wir bei generierten Änderungen am häufigsten gefunden haben: Änderungen, die mehr tun als beauftragt, und Tests, die grün sind, weil sie nichts verlangen.

Ein Kriterium, dessen Antwort nie Nein lautet, wird gestrichen oder geschärft. Ein Kriterium, dessen Antwort oft Nein lautet, zeigt eine Stelle, an der Gate 1 nachgezogen werden muss: Die Aufgabe hätte mit mehr Kontext oder gar nicht delegiert werden sollen.

Der Baseline-Vergleich

Bevor die Gates eingeführt werden, messen wir je Ablauf, wie es ohne sie läuft. Vier Größen reichen dafür aus, und sie lassen sich aus dem Repository und dem Ticketsystem gewinnen: der Anteil der Änderungen, die im Review korrigiert oder zurückgewiesen werden; die Zeit vom Öffnen des Pull Requests bis zur Freigabe; die Fehler, die nach der Freigabe gefunden werden und auf die Änderung zurückgehen; und die Größe der Änderung. Wir erheben sie über einen festgelegten Zeitraum vor der Umstellung und halten den Werkzeugstand fest.

Nach der Einführung der Gates messen wir mit demselben Raster erneut, zu einem Zeitpunkt, der vor der Umstellung festgelegt wurde. Der Vergleich zeigt, ob die Gates die Nachbesserung nach der Freigabe senken und was sie an Review-Zeit kosten. Beides gehört nebeneinander in den Bericht. Ein Team, das nur die Review-Zeit berichtet, sieht die Gates als Verlangsamung; ein Team, das nur die Nachbesserung berichtet, sieht den Aufwand nicht. Vergleichswerte aus Kundenprojekten liegen uns nicht vor; die Größen und das Vorgehen stammen aus unserer eigenen Umstellung.

Grenzen

Gates kosten Zeit, und zwar an der Stelle, an der der Rollout Zeit sparen sollte. Wer das nicht in der Baseline abbildet, bekommt eine Diskussion über Geschwindigkeit statt über Qualität. Gates ersetzen keine Architekturentscheidung und keine Codekonvention; sie prüfen, ob eine Änderung dazu passt. Die Liste in Gate 1 muss gepflegt werden, sonst veraltet sie mit dem ersten neuen Werkzeug. Und die Gates sagen nichts über die Fähigkeiten einzelner Werkzeuge; sie gelten für jede generierte Änderung, unabhängig davon, womit sie entstanden ist.

Was danach vorliegt

Drei Gates mit je einer kurzen Kriterienliste, eine Kennzeichnung generierter Anteile in Commit und Pull Request, ein Messraster mit Baseline und Wiederholungsmessung und ein Ablauf, der für jede Änderung dokumentiert, wo sie geprüft wurde und von wem. Diese Dokumentation ist zugleich die Antwort auf die Frage, wo im Engineering Ergebnisse geprüft worden sind, die Compliance nach einem Rollout stellt. Das Team kann die Gates selbst weiterentwickeln, weil die Kriterien aus seinen eigenen Fehlern stammen.