Abschluss und Ausblick

Abschluss und Ausblick

0:00 Wir sind am Ende angekommen, und ich möchte den Abschluss nicht mit einer Werkzeugliste bestreiten. Werkzeuge ändern sich — was Sie heute installiert haben, sieht in einem Jahr anders aus. Was bleibt, ist die Arbeitsweise: erst verstehen, dann planen, dann prüfen, dann umsetzen lassen und wieder prüfen. Genau die führen wir in diesem Modul noch einmal am Stück vor.

0:21 Und dann halten Sie fest, was Sie tatsächlich mit ins eigene Projekt nehmen — schriftlich, denn nur das überlebt die Rückfahrt.

Abschluss und Ausblick

0:29 Drei Dinge zum Schluss. Erst ein ehrlicher Ausblick auf mehrere Agenten im Zusammenspiel — was davon heute trägt und was noch Versuch ist. Dann das Abschlussprojekt, in dem Sie den ganzen Ablauf selbstständig durchgehen. Und schließlich die Frage, was davon in Ihr Projekt wandert und an welcher Stelle es dort landet. Der letzte Punkt ist der, an dem Seminare üblicherweise zu schnell werden. Wir nehmen uns dafür Zeit.

0:55 Vier Ziele für den Rest des Tages. Wir ordnen ein, was mit mehreren Agenten heute funktioniert und was noch Experiment ist — nüchtern, ohne Begeisterung in eine Richtung. Wir führen alles Gelernte an einer größeren Anforderung zusammen. Wir halten Ihre Arbeitsweise so fest, dass sie im Projekt ankommt und nicht in einem Notizbuch verschwindet.

1:14 Und wir bereiten den Übergang vom Seminar in den Alltag vor, denn genau dort entscheidet sich, ob diese drei Tage etwas gebracht haben.

Mehrere Agenten im Zusammenspiel

1:23 Beginnen wir mit einem Ausblick, und zwar mit einem bewusst nüchternen. Über mehrere Agenten, die gemeinsam an einem Projekt arbeiten, wird zurzeit sehr viel geschrieben — mit stark schwankendem Realitätsgehalt. Ich möchte deshalb mit Ihnen sortieren, was davon Sie heute in einem Java-Projekt tatsächlich einsetzen können und was noch Versuchsstadium ist.

1:43 Diese Unterscheidung erspart Ihnen im Zweifel ein teures Experiment. Zwei Ansätze werden meist verwechselt. Der erste ist Parallelität: mehrere Agenten arbeiten gleichzeitig an getrennten Aufgaben in getrennten Arbeitsverzeichnissen. Das ist im Grunde nur Nebenläufigkeit und funktioniert, wenn die Aufgaben wirklich unabhängig sind. Der zweite ist Rollenteilung: einer plant, einer setzt um, einer prüft.

2:07 Das klingt nach einem Team und hat einen Haken — Koordination kostet, auch zwischen Agenten. Und je mehr Berührungspunkte, desto schneller steigt dieser Aufwand. Die Trennlinie dieser Tabelle ist die Frage, wer koordiniert. Solange ein Mensch die Aufgaben zuschneidet und zusammenführt, funktioniert das — links stehen genau diese Fälle.

2:28 Sobald die Koordination zwischen Agenten stattfinden soll, wird es unzuverlässig; das ist die rechte Spalte. Besonders hinweisen möchte ich auf die zweite Zeile links: ein prüfender Agent auf einem fertigen Diff. Das ist billig, sofort einsetzbar und erstaunlich wirksam — ein zweiter Blick von jemandem, der die Entstehung nicht miterlebt hat.

2:49 Der dritte Punkt ist der, den ich bei Begeisterung für Multi-Agent-Aufbauten immer anbringe: Der Koordinationsaufwand wächst schneller als der Nutzen. Das ist keine neue Erkenntnis — das gilt in menschlichen Teams genauso, und dort haben wir Jahrzehnte gebraucht, um es zu akzeptieren. Der letzte Punkt ist mein eigentliches Anliegen bei diesem Kapitel: Eine ehrliche Einordnung schützt vor teuren Fehlversuchen.

3:11 Ein gescheiterter aufwendiger Versuch kostet nicht nur Zeit, er kostet auch die Bereitschaft, es noch einmal zu probieren. Der erste Punkt ist der praktische Fehler, den man einmal macht: Aufgaben parallelisieren, die dieselben Dateien berühren. Sie bekommen zwei Ergebnisse, die einzeln funktionieren und zusammen nicht — und das Zusammenführen kostet mehr, als die serielle Bearbeitung gekostet hätte.

3:35 Der zweite Punkt ist der konzeptionelle: Rollen benennen, ohne die Zuständigkeit tatsächlich zu trennen. Wenn der planende und der umsetzende Agent denselben Kontext und dieselbe Anweisung haben, haben Sie keine zwei Perspektiven — Sie haben denselben Blick zweimal.

Abschlussprojekt: eine Anforderung vollständig umsetzen

3:50 Jetzt kommt der Teil, für den wir die letzten drei Tage gearbeitet haben. Sie gehen den vollständigen Ablauf einmal allein durch — von der Anforderung bis zur Abnahme, ohne dass ich zwischendurch die nächsten Schritte ansage. Nehmen Sie sich Zeit und, noch wichtiger, nehmen Sie sich nicht zu viel vor. Der Wert liegt im vollständigen Durchlauf, nicht im Umfang der Anforderung.

4:11 Eine größere Anforderung an Lagerwerk, vollständig umgesetzt: analysieren, planen, prüfen, umsetzen lassen, testen, abnehmen. Und der entscheidende Satz steht am Ende — bewertet wird nicht der Code allein, sondern der Weg dorthin. Denn den Code hätten Sie auch mit drei ungeprüften Aufträgen bekommen. Was Sie hier üben, ist die Fähigkeit, den Weg nachvollziehbar zu machen.

4:34 Genau das brauchen Sie, wenn Sie im eigenen Haus erklären sollen, warum diese Arbeitsweise vertrauenswürdig ist. Fünf Schritte, und Sie erkennen jeden einzelnen aus den letzten beiden Tagen wieder. Umfang ermitteln aus Modul 6, Plan korrigieren ebenfalls, nach jedem Schritt testen mit dem Kommando aus Modul 5, abnehmen nach der Routine aus Modul 4.

4:55 Neu ist nur, dass Sie es am Stück tun. Und dann Schritt fünf, auf den ich besonders hinweisen möchte — die Fußzeile sagt es: Abweichungen in die Anweisungsdatei zurückspielen. Das ist der Unterschied zwischen einem einmaligen Erfolg und einer Arbeitsweise, die von allein besser wird. Der erste Punkt ist der, weshalb wir das am Stück machen: Der ganze Ablauf zeigt, wo es im Alltag klemmt.

5:17 Einzelne Schritte funktionieren im Seminar immer — die Übergänge sind das Interessante. Der dritte Punkt ist der didaktische: Eigene Entscheidungen sind wertvoller als vorgeführte. Sie werden vermutlich an einer Stelle etwas anders machen als ich es gezeigt habe, und wenn Sie begründen können warum, ist das ein besseres Ergebnis, als meiner Vorlage zu folgen.

5:38 Der erste Punkt ist der häufigste: eine zu große Anforderung wählen und im Plan stecken bleiben. Der Ehrgeiz ist verständlich, aber Sie üben hier den Ablauf, nicht die Fachlichkeit. Lieber klein und vollständig. Der zweite Punkt folgt daraus: den Ablauf abkürzen, weil die Zeit knapp wird. Wenn Sie merken, dass es eng wird, verkleinern Sie die Anforderung — nicht den Ablauf.

6:01 Und der dritte ist der, der den Lerneffekt kostet: die Anweisungsdatei unverändert lassen, obwohl es Abweichungen gab. Sie haben die Wahl: eine neue Anforderung an Lagerwerk oder das nächste Modul aus der Migrationskarte. Beides trainiert denselben Ablauf, und beides ist richtig — nehmen Sie das, was Ihrer Situation im Haus näher kommt.

6:22 Das Erfolgskriterium hat vier Teile, und der letzte ist der eigentliche: mindestens eine Erkenntnis steht am Ende in der Anweisungsdatei. Wenn Sie nichts gefunden haben, das dort hineingehört, haben Sie vermutlich nicht genau genug hingesehen.

Die eigene Arbeitsweise festhalten

6:36 Und damit zum letzten Kapitel dieses Seminars. Es ist das kürzeste und in gewisser Weise das wichtigste, denn hier entscheidet sich, was von drei Tagen tatsächlich übrig bleibt. Ich bitte Sie ausdrücklich darum, dabei schriftlich zu arbeiten. Mündliche Vorsätze sind ehrlich gemeint und überleben die Rückfahrt trotzdem nicht — das ist keine Charakterfrage, das ist schlicht Erfahrung aus vielen Seminaren.

7:00 Jetzt halten Sie fest, was in Ihr eigenes Projekt übergeht: die Anweisungsdatei, die Prüfroutine, die Freigabegrenze, die Arbeitsteilung zwischen Ihnen und dem Agenten. Vier Dinge, mehr braucht es nicht. Und bitte widerstehen Sie der Versuchung, alles auf einmal einzuführen. Eine übernommene Regel, die tatsächlich angewendet wird, ist mehr wert als ein Konzeptpapier, das alles abdeckt und in einem Ordner liegt.

7:24 Fangen Sie mit dem an, was in Ihrem Projekt heute am meisten weh tut. Die rechte Spalte dieser Tabelle ist die eigentliche Botschaft, und sie sagt dreimal dasselbe: ins Repository. Nicht in ein Wiki, nicht in eine Präsentation, nicht in Ihren Notizen. Ins Repository, neben den Code, wo das Team es findet und wo es mitversioniert wird.

7:44 Und dann die Fußzeile, die ich Ihnen als Prüfstein mitgebe: Alles, was nicht im Repository landet, ist nach vier Wochen vergessen. Das ist keine Übertreibung — vier Wochen sind ungefähr die Halbwertszeit guter Vorsätze nach einer Schulung. Der dritte Punkt ist der, der über Erfolg entscheidet: Eine kleine übernommene Regel schlägt einen großen Plan.

8:05 Ich habe viele Teams gesehen, die nach einer Schulung ein umfassendes Konzept geschrieben haben — und keines davon eingeführt. Und ich habe Teams gesehen, die eine einzige Datei ins Repository gelegt haben und sechs Monate später damit arbeiteten. Der letzte Punkt ist die ehrliche Bilanz: Der Übertrag ins eigene Projekt ist der eigentliche Seminarerfolg. Alles, was hier passiert, ist Vorbereitung darauf.

8:29 Der zweite Punkt ist wichtiger, als er klingt: Regeln übernehmen, die zum eigenen Projekt nicht passen. Unsere Freigabegrenze für Lagerwerk ist für Lagerwerk gemacht. In einem regulierten Umfeld ist sie zu locker, in einem internen Werkzeug zu streng. Übernehmen Sie die Struktur, nicht die Zeilen. Und der letzte Punkt ist der, den fast niemand macht und der am meisten bringt: nach vier Wochen nachsehen, ob es noch stimmt.

8:54 Setzen Sie sich dafür heute einen Termin, solange Sie noch daran denken.

Danke!

8:59 Damit sind wir am Ende. Sie haben in drei Tagen modernes Java im Bestandscode angewendet, die Eigenheiten von Sprachmodellen bei Java kennengelernt, einen Agenten über Analyse und Plan geführt, ein Modul migriert und die Grenzen gezogen, innerhalb derer das alles vertretbar ist. Das Beispielprojekt und die Materialien liegen in der Freigabe.

9:17 Wenn Sie an einzelnen Stellen tiefer einsteigen möchten — zu den Werkzeugen oder zur Qualitätssicherung —, finden Sie auf der Folie die passenden Seminare. Vielen Dank für Ihre Aufmerksamkeit und für die vielen Beispiele aus Ihren eigenen Projekten.