chap 7: Projektabschluss — Soll-Ist, Zielerreichung, Reflexion, Ausblick

chapters/closure/reflection.tex

@@ -1,5 +1,50 @@
 \section{Reflexion}
 \label{sec:reflection}
 
-% TODO: Lessons Learned — S3-Lookup-Entscheidung, Race Conditions als offenes Thema,
-% Infrastruktur-Vorlauf unterschätzt (AU-Kommunikation 2026-07-22 bis 2026-08-07)
+\subsection{Externe Abhängigkeiten früher klären}
+
+Die deutlichste Lehre betrifft den Umgang mit Abhängigkeiten außerhalb des eigenen Einflussbereichs. Zwischen dem Antrag auf den Speicher und der abschließenden Auskunft über die verfügbaren Funktionen lagen vier Wochen — bei einem Projektzeitraum von wenigen Wochen ein erheblicher Anteil.
+
+Der Fehler lag nicht in der Bearbeitungsdauer, die für einen Vorgang über einen externen Betreiber nicht ungewöhnlich ist, sondern im Zeitpunkt der Anfrage. Die fachliche Klärung war seit dem 18.~Juni abgeschlossen; dass ein Speicher benötigt wird, stand damit fest. Der Antrag folgte erst über vier Wochen später. Hätte er unmittelbar nach der Feature-Analyse vorgelegen, wäre auch die Frage nach den verfügbaren Funktionen früher beantwortet gewesen — und die Recherche zum Lookup hätte nicht auf eine Antwort warten müssen, die schließlich negativ ausfiel.
+
+Die Lehre daraus ist allgemeiner Natur: Vorgänge, deren Dauer man nicht selbst bestimmt, gehören an den Anfang der Planung, unabhängig davon, wann ihr Ergebnis benötigt wird. Sie kosten in der Regel keine eigene Arbeitszeit, aber Wartezeit — und Wartezeit lässt sich nur durch frühes Beginnen verkürzen.
+
+\subsection{Eine Architekturentscheidung ist die Summe ihrer Randbedingungen}
+
+Das Lookup-Problem war die technisch anspruchsvollste Aufgabe des Projekts. Aufschlussreich ist weniger die Lösung als der Weg dorthin.
+
+Die zunächst betrachteten Ansätze — Zwischenspeicher, Anmeldetoken, Feld im ITSM-System — waren alle technisch tragfähig und hätten das Problem messbar entschärft. Verworfen wurden sie, weil sie jeweils eine zweite Stelle einführen, an der dieselbe Information gepflegt wird. Die schließlich gewählte Lösung ist nicht die naheliegendste; sie ergab sich erst aus der genauen Betrachtung der eigentlichen Randbedingung.
+
+Ausschlaggebend war die Unterscheidung zwischen der Anforderung und ihrer vermuteten Umsetzung: Die interne Pflege verlangte eine \emph{Sortierung nach Kundennamen}, nicht zwingend Ordnernamen, die \emph{ausschließlich} aus dem Kundennamen bestehen. Erst diese Präzisierung machte die Lösung sichtbar. Ohne die Rückfrage bei der internen Fachseite wäre die Anforderung als „Ordnername = Kundenname" verstanden und der Lösungsraum entsprechend enger geblieben.
+
+Die Erkenntnis: Wenn alle betrachteten Lösungen unbefriedigend sind, lohnt sich die Prüfung, ob eine der Randbedingungen genauer formuliert werden kann, als sie zunächst verstanden wurde.
+
+\subsection{Eigene Arbeit gegenlesen}
+
+Die Nebenläufigkeitsproblematik wurde nicht durch einen Test, ein Review oder einen Fehlerbericht gefunden, sondern durch das erneute Durchgehen des eigenen, bereits fertiggestellten Codes.
+
+Das ist insofern bemerkenswert, als der betreffende Pull Request zu diesem Zeitpunkt geschrieben und eingereicht war. Die Fehlerbehandlung des Umbenennens war ausdrücklich geschrieben worden, um Datenverlust zu verhindern — und genau sie verursacht ihn unter Nebenläufigkeit. Ein Sicherheitsnetz, das man selbst eingebaut hat, prüft man nicht ohne Weiteres erneut; die Annahme, dass es wirkt, ist die eigene.
+
+Ausschlaggebend war ein Perspektivwechsel: nicht zu fragen „funktioniert das?", sondern „was passiert, wenn das hier zweimal gleichzeitig läuft?". Diese Frage ist an einer Anwendung, die in mehreren Instanzen betrieben wird, für jeden verändernden Codepfad zu stellen — und sie war beim Schreiben des Codes nicht gestellt worden, weil der Pfad als seltener Sonderfall galt. Genau diese Einordnung als Sonderfall ist es, die die Prüfung unterbleiben lässt.
+
+\subsection{Pull Requests kleiner und sequenziell schneiden}
+
+Die in Abschnitt~\ref{sec:code-reviews} beschriebene Ballung der Zusammenführungen war die Folge einer bewussten, im Rückblick aber falschen Entscheidung. Vier gleichzeitig eröffnete Pull Requests sollten verhindern, dass Arbeitszeit mit Warten auf Reviews vergeht.
+
+Der erwartete Vorteil trat nicht ein, weil die Arbeiten inhaltlich aufeinander aufbauten. Ein Reviewer konnte den zweiten Pull Request nicht sinnvoll abschließen, solange der erste offen war. Statt Parallelität entstand eine Warteschlange, deren Auflösung sich in die Woche vor Abnahme und Produktivsetzung verschob.
+
+Die Verkettung der Zielbranches, die das Reviewproblem löste, brachte zudem eigene Kosten mit sich: Jede Umstellung auf den Hauptbranch setzte abgegebene Freigaben zurück. Für künftige Arbeiten wäre der Schluss, bei inhaltlich abhängigen Aufgaben sequenziell vorzugehen und Parallelität nur dort zu suchen, wo tatsächliche Unabhängigkeit besteht.
+
+\subsection{Konsistenz braucht einen Vergleich, keine Beschreibung}
+
+Der einzige aus der Abnahme hervorgegangene Fehler betrifft eine Anforderung, die in mehreren Backlog Items sinngemäß enthalten war: Die Bedienung soll sich an den übrigen Seiten der Anwendung orientieren.
+
+Diese Anforderung wurde nicht verletzt, weil sie übersehen worden wäre, sondern weil sie sich nicht vollständig aus einer Beschreibung ableiten lässt. Eine Schaltfläche zum Leeren des Suchfelds ist eine sinnvolle Ergänzung — sie widerspricht keiner Vorgabe. Erst der unmittelbare Vergleich mit den bestehenden Seiten macht die Abweichung sichtbar.
+
+Für Anforderungen dieser Art ist ein Abnahmetest durch eine Person, die die übrige Anwendung kennt, nicht durch vorgelagerte Prüfstufen ersetzbar. Das ist zugleich ein Argument dafür, solche Tests früher anzusetzen als hier geschehen.
+
+\subsection{Persönliche Einordnung}
+
+Gegenüber den vorangegangenen Praktika lag der Schwerpunkt dieses Projekts deutlicher auf Entwurfsentscheidungen als auf der Implementierung. Der Anteil der Zeit, der auf Recherche, Abwägung und Begründung entfiel, war erheblich — die Bewertung von sechs Lösungsansätzen für den Lookup und die Analyse der Nebenläufigkeit erzeugten für sich genommen keine einzige Zeile ausgelieferten Codes.
+
+Zugleich waren es genau diese Anteile, die den Verlauf des Projekts bestimmten. Die Erfahrung, dass eine sauber begründete und dokumentierte Abgrenzung — etwa die eines erkannten Problems in ein eigenes Backlog Item — fachlich mehr wert ist als eine schnelle, unvollständige Behebung, ist die wesentliche persönliche Erkenntnis aus diesem Projekt.