Architektur und Zerlegung

Architektur und Zerlegung

0:00 Guten Morgen. Der zweite Tag beginnt mit einem Thema, bei dem viele Teams entweder zu viel oder zu wenig tun: Architektur. Zu viel heißt, ein Dokument zu pflegen, das nach drei Monaten niemand mehr aufmacht. Zu wenig heißt, dass zwei Leute unabhängig voneinander entscheiden und die Ergebnisse nicht zusammenpassen. Beim agentischen Arbeiten wird das schärfer, weil einer der beiden kein Mensch ist und nicht nachfragt, wenn ihm etwas komisch vorkommt.

0:26 Wir suchen deshalb das Minimum an Festlegung, das den Zusammenprall verhindert — und zerlegen die Arbeit danach in Einheiten, die eine Sitzung schafft.

Architektur und Zerlegung

0:35 Der Tag beginnt mit dem Architecture Spine — dem Rückgrat statt der vollständigen Dokumentation. Danach schauen wir uns an, was eine Arbeitseinheit agentengerecht macht und warum senkrechte Schnitte fast immer besser funktionieren als waagerechte. Es folgen fünf Bereitschaftsfragen, die man vor jeder Sitzung stellt. Und am Ende zerlegen Sie unser Beispiel-Feature selbst — inklusive der Frage, was eigentlich parallel laufen darf.

Architektur als Leitplanke

1:00 Beginnen wir mit der Frage, wie viel Architekturdokumentation ein Vorhaben eigentlich braucht. Die Antwort ist erfreulich knapp, und sie hat eine sehr brauchbare Faustregel — eine, die man in einer Sitzung anwenden kann, ohne vorher eine Methodendiskussion zu führen. Genau darin liegt ihr Wert: Sie macht aus einer Grundsatzfrage eine Entscheidung von zwei Minuten.

1:21 Der Architecture Spine hält nur eine bestimmte Sorte Entscheidung fest: die, die zu einem Konflikt führen würde, wenn zwei Beteiligte sie unabhängig träfen. Das ist eine erstaunlich trennscharfe Regel. Denken Sie an eine Wohngemeinschaft: Ob jemand seinen Schreibtisch links oder rechts stellt, muss nirgends stehen. Wer die Küche putzt und wo der Müll hingeht, sehr wohl — weil zwei vernünftige Antworten sich hier gegenseitig ausschließen.

1:46 Genauso hier: Ansatz, Grenzen, Zustandsübergänge und Datenhoheit gehören in den Spine. Stack, Ordnerstruktur und Feldnamen stehen im Code und brauchen kein zweites Zuhause. Was die rechte Spalte eint: Sie ist im Code sichtbar und ändert sich, ohne dass jemand Schaden nimmt. Die linke Spalte ist unsichtbar — Zustandsübergänge einer Buchung sehen Sie keinem Modul an, und wem die Daten gehören, steht nirgends geschrieben.

2:12 Achten Sie auf die letzte Zeile links: Eine Entscheidung wird immer zusammen mit ihrer Alternative notiert. Ohne die Alternative ist es keine Entscheidung, sondern eine Feststellung — und sie lässt sich später nicht bewerten. Die Fußzeile gibt die Faustregel: Nur was an einer Epic-Grenze wehtut, wenn es fehlt. Warum den Grund mitschreiben, wenn die Entscheidung doch feststeht? Weil eine Entscheidung ohne Grund später nicht überprüfbar ist.

2:37 Wenn sich Rahmenbedingungen ändern, wollen Sie wissen, ob die Annahme von damals noch trägt — nicht nur, was damals herauskam. Dazu kommt die Konsequenz: Sie benennt den Preis, den man bewusst zahlt, und verhindert die spätere Empörung darüber. Und ein sehr praktischer Punkt zum Schluss: Ein Agent hält sich eher an eine Regel, deren Grund im Text steht. Das gilt übrigens für menschliche Kollegen genauso.

3:01 Fünf Zeilen — mehr ist eine Architekturentscheidung nicht. Entscheidung, Alternative, Grund, Folge, Grenze. Das Beispiel zeigt gut, wie die Teile zusammenhängen: Weil die Spezifikation das Buchungsmodell schützt, wird die Warteliste eine eigene Tabelle; der Preis dafür ist, dass das Nachrücken eine Transaktion braucht. Diese Folge ist keine Nebenbemerkung, sondern eine Zusage an den, der später baut. Und die Grenze am Schluss legt fest, wer die Daten besitzt.

3:30 Beachten Sie die Fußzeile: Was länger wird als das hier, gehört meistens in die Spezifikation.

Agentengerechte Arbeitseinheiten

3:36 Im zweiten Kapitel schneiden wir die Arbeit. Der Begriff Story ist Ihnen aus agilen Verfahren vertraut — was sich beim agentischen Arbeiten ändert, ist der Maßstab für einen guten Schnitt. Er hängt jetzt daran, ob eine Einheit ohne erfundene Entscheidungen umsetzbar ist. Das Kriterium ist beinahe elegant: Eine gute Arbeitseinheit lässt sich umsetzen, ohne dass jemand Entscheidungen erfinden muss, die nirgends festgehalten sind.

4:02 Prüfen Sie eine Story einmal daran — Sie werden überrascht sein, wie viele scheinbar fertige Stories daran scheitern. Dazu kommen zwei bekannte Anforderungen: unabhängig prüfbar und senkrecht durch die Schichten geschnitten. Senkrecht heißt: eine Fähigkeit von der Oberfläche bis zur Datenbank, statt erst alle Tabellen und dann alle Endpunkte.

4:21 Was dabei an Doppelarbeit entsteht, spart man beim Zusammenfügen mehrfach ein. Die letzte Zeile enthält den ganzen Unterschied: Beim waagerechten Schnitt ist erst am Ende etwas prüfbar, beim senkrechten nach jedem Schritt. Für menschliche Teams ist das ein Komfortgewinn. Für agentische Arbeit ist es fast Voraussetzung — denn wenn Sie nach jeder Sitzung prüfen wollen, muss es nach jeder Sitzung etwas zu prüfen geben.

4:45 Die Fußzeile nennt den Preis ehrlich: Der senkrechte Schnitt kostet etwas Doppelarbeit, weil man dieselbe Schicht mehrfach anfasst. Diese Doppelarbeit ist billiger als die Integrationsschmerzen am Ende. Diese vier Punkte sind die Autopsie gescheiterter Sitzungen. Zwei Einheiten ändern dieselbe Datei — das merkt man beim Zusammenführen, nicht vorher.

5:06 Die Reihenfolge ist unklar, also fehlt beim Bauen eine Grundlage, und der Agent erfindet sie. Es gibt kein Akzeptanzkriterium, also endet die Sitzung nach Gefühl, meist mit einem freundlichen „fertig". Und der letzte Punkt ist der unterschätzte: Wenn Aufgabe und Kontext nicht in eine Sitzung passen, sinkt die Verlässlichkeit gegen Ende spürbar.

5:27 Größe ist hier kein Ehrgeiz, sondern eine technische Grenze. Der erste Punkt ist der häufigste Anfängerfehler: nach Dateien schneiden statt nach Wirkung. Das fühlt sich ordentlich an und erzeugt Einheiten, die einzeln nichts können. Der zweite betrifft die Abhängigkeiten — sie erst beim Bauen zu entdecken, ist teuer, weil dann schon Code entstanden ist.

5:48 Der dritte ist die Parallelisierungsfalle: Nicht alles, was unabhängig aussieht, ist unabhängig, sobald zwei Einheiten in dieselben Bereiche schreiben. Und der vierte ist banal und passiert trotzdem: Akzeptanzkriterien stehen in der Spezifikation, aber nicht in der Story, mit der jemand arbeitet.

Implementation Readiness

6:05 Jetzt eine kurze Prüfung, die sich in der Praxis sehr bewährt hat: fünf Fragen vor der ersten Build-Sitzung. Sie dauert zwei Minuten und beantwortet die Frage, ob eine Einheit überhaupt bereit ist, gebaut zu werden — oder ob wir gerade dabei sind, Unklarheit an eine Maschine weiterzureichen. Die fünf Fragen prüfen unterschiedliche Dinge, und das ist der Trick. Ist der Intent stabil oder wird noch verhandelt? Sind die nötigen Entscheidungen festgehalten?

6:33 Lässt sich das Ergebnis objektiv prüfen? Sind irreversible Aktionen bekannt? Und passt der Umfang in eine Sitzung? Wichtig ist die Haltung dahinter: Ein Nein ist kein Abbruch. Es benennt nur, was vorher noch zu klären ist. Wer die Prüfung als Hürde erlebt, wird sie weglassen; wer sie als Werkzeug zum Sortieren nimmt, spart sich mittendrin die Rückfrage.

6:55 Gehen wir die Fragen einmal an unserem Beispiel durch. Der Intent zur Warteliste ist stabil — er wurde am Vortag freigegeben. Die Entscheidungen liegen im Spine. Prüfbar ist das Ergebnis, weil jede Fähigkeit ihre Erfolgsbedingung hat. Irreversibel ist genau eine Sache, nämlich die Migration, und die wird nur ergänzt. Und beim Umfang wird es interessant: Eine der vier Stories liegt an der Grenze dessen, was eine Sitzung schafft. Genau deshalb bekommt sie später einen zusätzlichen Checkpoint.

7:25 Die Prüfung hat also nicht blockiert, sondern etwas verändert. Der Zeitgewinn entsteht an einer Stelle, die man vorher nicht sieht. Eine unklare Einheit produziert nämlich keine Fehlermeldung, sondern eine Rückfrage — mittendrin, wenn schon halb gebaut ist. Dann müssen Sie sich einlesen, entscheiden und der Agent muss neu ansetzen.

7:45 Schlimmer noch ist der Fall ohne Rückfrage: Dann wurde die fehlende Entscheidung erfunden, und Sie finden sie erst im Review, wenn überhaupt. Zwei Minuten vorher sind dagegen ein guter Preis. Und irreversible Schritte wollen Sie ohnehin vorher wissen, nicht hinterher.

Zerlegen und ordnen

8:01 Im letzten Kapitel wird es konkret. Wir nehmen die Spezifikation vom Vortag und schneiden sie in Stories — mit Reihenfolge, mit Abhängigkeiten und mit der Frage, wo ein Mensch draufschauen soll. Danach machen Sie dasselbe mit Ihrem eigenen Beispiel. Und Sie werden sehen: Die Diskussion über Parallelität lässt sich mit einer einzigen Zusatzangabe je Story beenden.

8:23 Aus der Spezifikation entsteht eine geordnete Liste von Stories, und zu jeder gehört mehr als ein Titel: die Frage nach dem Vorgänger und die Frage nach dem Checkpoint. Letztere wird oft übersehen, ist aber die wirksamste Stelle für menschliche Kontrolle. Ein Checkpoint davor heißt: Ich will den Plan sehen, bevor etwas passiert.

8:42 Ein Checkpoint danach heißt: Ich schaue mir das Ergebnis an, bevor es weitergeht. Beides zusammen setzt man sparsam ein — für die eine Story, bei der es wirklich darauf ankommt. Sehen Sie sich die dritte Zeile an. Nachrücken bekommt als einzige Story einen Checkpoint davor und danach — und die Fußzeile sagt auch warum: Sie berührt Transaktionen und Rechte.

9:04 Das ist die Sorte Entscheidung, bei der ein Blick vorher billiger ist als eine Korrektur nachher. Die übrigen drei Stories laufen mit einem Blick am Ende. Beachten Sie auch die Reihenfolge: Eintragen kommt zuerst, weil ohne Einträge nichts nachrücken kann. Solche Abhängigkeiten wirken offensichtlich, wenn sie dastehen — und werden regelmäßig übersehen, wenn sie fehlen.

9:26 Ihre Aufgabe: Zerlegen Sie ein Feature in unabhängig prüfbare Einheiten mit klarer Reihenfolge. Jede Einheit braucht ein Akzeptanzkriterium, einen Vorgänger und die Angabe, was parallel laufen darf. Der Hinweis auf der Folie ist der praktische Trick dabei: Prüfen Sie je Paar, ob beide dieselben Dateien schreiben. Das entscheidet über Parallelität zuverlässiger als jedes Bauchgefühl.

9:48 Wenn Sie in der Gruppe streiten, ob zwei Stories unabhängig sind, schreiben Sie einfach auf, welche Dateien sie berühren. Die Diskussion ist danach meistens vorbei. Vier Punkte zum Mitnehmen. Der Spine hält nur Entscheidungen fest, die unabhängig getroffen kollidieren würden — alles andere steht im Code. Eine gute Einheit erfordert keine erfundenen Entscheidungen; das ist der schärfste Test für einen Schnitt.

10:13 Senkrechte Schnitte sind nach jedem Schritt prüfbar, waagerechte erst am Ende. Und fünf Bereitschaftsfragen ersparen die Rückfrage mitten in der Umsetzung. Damit ist alles vorbereitet. Im nächsten Modul lassen wir zum ersten Mal wirklich bauen.