Abschlussprojekt und Transfer

Abschlussprojekt und Transfer

0:00 Fertig heißt geprüft, nicht compiliert. Mit diesem Unterschied endet dieses Seminar, und er ist mehr als eine Formulierung. Sechs Tage lang haben wir Entscheidungen getroffen und geprüft — zum Zustand, zum Ladeweg, zum Formularmodell, zum Rendering, zur Sicherheit. Jetzt führen wir das zusammen: ein eigenes Feature bis zur Abnahme, die Befunde aus vier Richtungen an einer Stelle, und ein Plan für das, was Montag in Ihrem eigenen Projekt ansteht.

Modernisierung, KI-Einsatz und Abschluss

0:27 Das letzte Modul. Kein neuer Stoff mehr — stattdessen die Frage, wie aus sechs Tagen Seminar etwas wird, das in Ihrem Projekt ankommt. Und das ist erfahrungsgemäß die schwierigste Übung der ganzen Woche.

Ein Feature vollständig fertigstellen

0:40 Beginnen wir mit der Frage, wann etwas eigentlich fertig ist. Sie wird selten gestellt und noch seltener beantwortet. Ein Feature gilt als fertig, wenn sein Nutzerbedarf beschrieben ist, seine Akzeptanzkriterien vorher festgelegt und nachher erfüllt sind, seine Fehlerfälle behandelt und seine Bedienung ohne Maus möglich ist.

0:59 Vier Bedingungen, und keine davon lautet „der Code ist geschrieben". Und ein Satz, der in Zeiten generierter Änderungen wichtiger wird: Die Menge des geschriebenen oder erzeugten Codes sagt darüber nichts aus. Sie war noch nie ein Maß, aber sie wird gerade wieder als eines missverstanden. Fünf Schritte, und Schritt zwei ist der, den ich für den aussagekräftigsten halte: Erfolgs- und Fehlerfall im laufenden Programm vorführen. Nicht beschreiben — vorführen.

1:26 Der Fehlerfall ist dabei der interessante, weil er in Demos praktisch nie gezeigt wird. Schritt fünf ist der, der Haltung verlangt: offene Punkte benennen, statt sie zu glätten. Die Fußzeile sagt, warum das mehr ist als Ehrlichkeit — wer offene Punkte verschweigt, verschiebt sie auf jemanden, der ihren Zusammenhang nicht kennt.

1:46 Der erste Punkt ist der, der die ganze Akzeptanzkriterien-Idee aushebelt: Sie entstehen erst nach der Umsetzung. Dann beschreiben sie, was gebaut wurde, statt zu prüfen, ob das Richtige gebaut wurde. Der zweite ist die halbe Vorführung: Der Fehlerfall wird beschrieben, aber nicht gezeigt — und beschreiben kann man vieles.

2:05 Und der dritte ist die Verwechslung, mit der dieses Modul anfängt: Fertig meint lauffähig, nicht geprüft.

Entscheidungen im Team erläutern

2:11 Kommen wir zum zweiten Teil der Abnahme. Und zu einem Unterschied, der beim Erklären sofort auffällt. Eine Entscheidung erklärt sich über ihre Alternativen. Wer nur die gewählte Lösung zeigt, liefert eine Beschreibung, keine Begründung — das hatten wir bei den Architekturentscheiden in Modul acht, und es gilt hier genauso.

2:31 Zu erläutern sind der Architekturschnitt, die Art des Zustands, der Ladeweg, das Formularmodell und der Rendering-Modus. Also im Grunde die fünf großen Weichenstellungen dieser Woche. Für jede gilt: Warum diese und nicht die andere? Vier Schichten, und die unterste ist die, die fast immer fehlt: der Auslöser, der die Entscheidung wieder öffnet.

2:52 Kontext, Optionen und Wahl schreiben die meisten auf — das ist der Standardaufbau. Aber die Frage, was die Entscheidung wieder aufmachen würde, verwandelt ein Dokument von einer Chronik in ein Werkzeug. Wenn dort steht „sobald ein zweites Feature denselben Zustand liest", dann weiß der Nachfolger, worauf er achten muss. Ohne diese Zeile weiß er nur, was damals galt.

3:15 Der erste Punkt ist der, den wir schon kennen: Nur die gewählte Option wird gezeigt. Der zweite ist die Begründung, die keine ist: „So werde es üblicherweise gemacht." Das mag stimmen und sagt nichts darüber, ob es hier passt. Und der dritte ist ein Organisationsproblem mit Spätfolgen: Die Entscheidung wird erklärt, aber nirgends festgehalten.

3:35 Dann war die Erläuterung eine Stunde Gespräch, von der in drei Monaten nichts übrig ist.

Befunde zusammenführen

3:41 Jetzt der Teil, der im Projektalltag am häufigsten ausfällt: die vier Prüfrichtungen an einer Stelle zusammenbringen. Am Ende liegen Befunde aus vier Richtungen vor: Tests, Zugänglichkeit, Sicherheit und Performance. Jede für sich ist überschaubar. Zusammengeführt ergeben sie ein Bild vom Zustand der Anwendung — einschließlich dessen, was vor einem produktiven Einsatz noch zu klären ist.

4:05 Und genau dieser letzte Teil ist der Grund für die Zusammenführung. Einzeln wirkt jeder offene Punkt klein genug zum Verschieben. Zusammen sieht man, ob man startbereit ist. Vier Zeilen, und sie sind zugleich eine Zusammenfassung der Woche. Die Teststrategie und die Suite aus den Modulen dreizehn und vierzehn. Der Accessibility-Review aus Modul fünfzehn. Die Entscheidung zur Vertrauensausnahme aus Modul achtzehn. Und die Vorher-nachher-Messung aus Modul siebzehn.

4:33 Jedes dieser Artefakte ist im Modul entstanden, in dem es hingehört — und keines davon wäre entstanden, wenn wir es uns für den Schluss aufgehoben hätten. Vier Gründe, und der zweite ist der, den ich am wertvollsten finde: Zwei Befunde deuten manchmal auf dieselbe Ursache. In Spurweite war das so — der offene Performance-Punkt beim Tippen und ein Nebenbefund aus dem Review zeigten beide auf dasselbe Suchfeld.

4:59 Einzeln wären es zwei Tickets gewesen, zusammen ist es eine Korrektur. Der erste Grund: Einzeln wirken die Befunde kleiner, als sie gemeinsam sind. Der dritte: Die Reihenfolge der Behebung will entschieden werden. Und der vierte: Was offen bleibt, muss jemand übernehmen. Der erste Punkt ist der organisatorische Normalzustand: Die Befunde bleiben in vier Dokumenten, und niemand liest alle.

5:22 Der zweite ist der, der beim Aufschreiben passiert: Offene Risiken werden weggelassen, weil das Bild sonst unfertig wirkt — dabei ist es ja unfertig, und das ist die Information. Und der dritte ist der, der offene Punkte versanden lässt: Es fehlt die Angabe, wer ihn übernimmt. Ein offener Punkt ohne Namen ist eine Notiz, keine Aufgabe.

Transfer in die eigene Codebasis

5:43 Und damit zum eigentlichen Zweck der ganzen Woche. Denn das hier ist ein Seminar über Ihre Anwendung, nicht über Spurweite. Der Übertrag beginnt mit der Standortbestimmung: eingesetzte Angular-Version, Abstand zum unterstützten Bereich, Zustand der Tests. Daraus entstehen drei konkrete nächste Schritte — nicht zwanzig. Und dann eine Trennung, die den Plan realistisch macht: Was entscheidet das Team selbst, und wofür braucht es Unterstützung? Diese zweite Frage ist ungewohnt und wichtig.

6:13 Ein Plan, der stillschweigend voraussetzt, dass Sie alles allein hinbekommen, scheitert an der Stelle, an der es nicht stimmt. Fünf Schritte, und der erste ist der, den man nachsehen und nicht schätzen sollte: die eigene Version und den Supportzeitraum. Das dauert zwei Minuten und ist überraschend oft anders als vermutet. Schritt zwei benennt einen Schmerzpunkt — einen, nicht drei.

6:37 Schritt drei legt drei Schritte fest, mit Aufwand und Reihenfolge. Schritt vier trennt selbst und mit Unterstützung. Und Schritt fünf ist der, den die Fußzeile begründet: ein Überprüfungstermin. Ohne ihn ist der Plan eine Absichtserklärung. Der erste Punkt ist der, an dem die meisten Vorsätze sterben: Der Plan umfasst zwanzig Punkte und beginnt deshalb nie.

6:59 Zwanzig Punkte sind keine Planung, das ist eine Bestandsaufnahme. Der zweite ist der, der sich leicht vermeiden lässt: Die eigene Version wird geschätzt statt nachgesehen. Und der dritte ist ein Reihenfolgefehler mit Blockadewirkung: Der erste Schritt ist der größte — dann kommt man nie zum zweiten, und nach drei Wochen ist der ganze Plan tot.

Übung

7:19 Die letzte Übung. Ein eigenes Feature, vollständig, vorgeführt — und danach Ihr Plan. Jedes Team bekommt eine zusätzliche Anforderung für Spurweite — etwa eine Übergabe zwischen zwei Standorten oder eine Wiedervorlage für wartende Aufträge. Sie wird vollständig umgesetzt, geprüft und vorgeführt. Beide Anforderungen sind echte Wünsche aus dem Betrieb, und beide berühren mehrere der Themen dieser Woche: Zustand, Navigation, Formular, Fehlerfall und Berechtigung.

7:49 Sie können also nichts davon umgehen. Das Lernziel ist die Zusammenführung selbst: die Mittel der Woche in einem eigenständigen Feature verbinden und die Entscheidungen begründen. Das Erfolgskriterium nennt drei Teile — vorgeführt einschließlich Fehler- und Berechtigungsfall, Tests auf der günstigsten Ebene, Befunde aus vier Richtungen zusammengeführt.

8:09 Der Berechtigungsfall ist bewusst dabei: Er ist der, der in Vorführungen am häufigsten fehlt, weil man sich dafür extra abmelden müsste. Neunzig Minuten, fünf Schritte — und der zweite ist der, der über die Qualität entscheidet: Entscheidungen zu Zustand, Ladeweg und Formular treffen, bevor Sie anfangen. Das fühlt sich nach verlorener Zeit an und ist keine. Schritt drei ist die Umsetzung, Schritt vier die Vorführung mit allen drei Fällen.

8:34 Und Schritt fünf ist der, der über das Seminar hinausweist: die Befunde zusammenführen und den eigenen Transferplan schreiben. Nehmen Sie sich die letzten zwanzig Minuten dafür wirklich. Der erste Punkt ist der, den ich in Vorführungen ständig sehe: Es wird nur der Erfolgsfall gezeigt. Der zweite ist der, der aus einer Abnahme eine Demo macht: Die Entscheidungen werden gezeigt, aber nicht begründet.

8:58 Und der dritte ist der, der das Seminar folgenlos bleiben lässt: Der Transferplan bleibt allgemein und nennt keine drei Schritte. Damit sind wir am Ende. Sie haben in sechs Tagen eine Anwendung gebaut, geprüft, gemessen, abgesichert und modernisiert — und wissen jetzt, welche drei Dinge in Ihrem eigenen Projekt als Nächstes dran sind.

9:18 Viel Erfolg damit.