Vom Ticket zur ausführbaren Spezifikation

Vom Ticket zur ausführbaren Spezifikation

0:00 Ein Agent füllt jede Lücke in der Anforderung — nur nicht unbedingt so, wie es gemeint war. Das ist keine Schwäche, das ist seine Funktionsweise: Er muss weiterarbeiten, also entscheidet er. Ein Mensch würde an derselben Stelle zurückfragen oder die Sache liegen lassen, bis jemand antwortet. Deshalb verschiebt der Einsatz von Agenten den Schwerpunkt der Arbeit nach vorn — in die Formulierung des Auftrags. Wer dort schlampt, bekommt es im Diff zurück.

Vom Ticket zur ausführbaren Spezifikation

0:27 Dieses Modul behandelt Handwerk, das älter ist als jeder Coding Agent — und das durch ihn plötzlich wieder wichtig wird. Ziele und Nicht-Ziele, prüfbare Kriterien, der offene Umgang mit Unsicherheit. Vieles davon kennen Sie. Der Unterschied liegt in der Verbindlichkeit: Was bei einem erfahrenen Kollegen stillschweigend funktioniert, muss hier explizit dastehen.

Ziele, Nicht-Ziele und Randbedingungen

0:49 Beginnen wir mit dem Teil der Spezifikation, der am wertvollsten ist und am häufigsten fehlt: der Begrenzung. Eine ausführbare Spezifikation beschreibt das Problem, nicht den Lösungsweg. Sie nennt das Ziel, die ausdrücklichen Nicht-Ziele, die technischen und fachlichen Randbedingungen und die betroffenen Schnittstellen und Datenbestände.

1:09 Der Unterschied zwischen Problem und Lösungsweg ist dabei der, an dem die meisten Tickets scheitern: „Bitte im Formular prüfen" ist ein Lösungsweg. Er schließt die bessere Lösung aus, bevor jemand darüber nachgedacht hat. Die Tabelle zeigt links, was im Ticket steht, und rechts, was daraus wird. Achten Sie auf die beiden unteren Zeilen — sie haben links kein Gegenstück, weil niemand Nicht-Ziele ins Ticket schreibt. Der Altbestand bleibt unberührt.

1:35 Am Kontenwerk wird nichts geändert. Zwei Sätze, die verhindern, dass aus einer Validierungsregel ein Datenmigrationsprojekt wird. Die Fußzeile sagt es zugespitzt: Diese beiden Zeilen verhindern mehr Arbeit, als die oberen beiden erzeugen. Der erste Grund ist der Mechanismus dahinter: Ein Agent erweitert den Auftrag, wenn die Grenze fehlt. Er sieht Nachbarcode, der verbesserungswürdig aussieht, und verbessert ihn.

2:01 Das ist gut gemeint und macht den Diff größer — und damit schlechter prüfbar, was der dritte Grund ist. Der vierte ist der, an den man zuletzt denkt: Ohne Grenze ist auch nicht entscheidbar, wann etwas fertig ist. Ein Auftrag ohne Rand hat kein Ende. Der erste Punkt ist der aus der Definition: Die Spezifikation beschreibt die Lösung und blockiert damit die bessere.

2:23 Der zweite ist der, der Termine reißt — betroffene Schnittstellen werden erst bei der Umsetzung entdeckt. Genau dagegen hilft die Impact-Analyse aus dem nächsten Modul. Und der dritte ist der Klassiker: Nicht-Ziele fehlen, weil sie selbstverständlich schienen. Selbstverständlich ist für einen Agenten eine leere Menge.

Prüfbare Akzeptanzkriterien

2:43 Kommen wir zum Kern. Ein Akzeptanzkriterium ist nur dann eines, wenn man es in einen Test übersetzen kann. Ein Kriterium beschreibt beobachtbares Verhalten: Ausgangslage, Eingabe, erwartetes Ergebnis. Es unterscheidet sich damit vom Abnahmegespräch, in dem jemand beurteilt, ob etwas gut genug ist. Beides hat seine Berechtigung — aber nur das erste kann ein Agent verwenden, und nur das erste kann eine Pipeline prüfen.

3:09 Alles, was eine Einschätzung verlangt, bleibt Menschenarbeit und gehört ausdrücklich so benannt. Fünf Schritte, und der fünfte ist der Test für die anderen vier: Lässt sich aus dem Kriterium ein Testname ableiten? Wenn Ihnen dabei nichts einfällt, ist das Kriterium noch keins. Das ist eine erstaunlich verlässliche Probe, und sie dauert zehn Sekunden.

3:30 Probieren Sie es einmal an einem echten Ticket aus Ihrem Backlog — die Ausbeute ist ernüchternd und ausgesprochen lehrreich. Fünf Fälle für eine einzige Regel — das überrascht viele. Die ersten drei sind erwartbar: gültig, fehlend, unbekannt. Die letzten beiden sind die interessanten, und die Fußzeile sagt warum: Sie stehen im Ticket nie und fallen im Betrieb immer auf.

3:53 Was passiert mit Bestandsanfragen ohne Kostenstelle? Und was passiert, wenn das Kontenwerk nicht antwortet — wird dann angenommen oder abgelehnt? Das ist eine fachliche Entscheidung, keine technische, und sie muss jemand treffen. Der erste Punkt ist das Musterbeispiel eines Nicht-Kriteriums: funktioniert korrekt. Das steht tatsächlich in Tickets.

4:15 Der zweite ist die häufigste Lücke — nur der Erfolgsfall ist beschrieben. Und der dritte ist der gefährlichste, weil er bequem ist: Das Testorakel wird dem Agenten überlassen. Dann schreibt er den Test, der zu seiner Implementierung passt, und beides ist konsistent falsch. Was richtig ist, muss von außen kommen.

Unsicherheiten sichtbar machen

4:35 Jetzt zu dem Teil, der Mut verlangt: dem offenen Eingeständnis, dass etwas nicht geklärt ist. Fehlende Informationen verschwinden nicht dadurch, dass niemand sie nennt — sie werden zu stillen Annahmen im Code. Das ist der Kernsatz. Und zwar zu Annahmen, die man später nicht mehr findet, weil sie nirgends als solche markiert sind.

4:55 Eine Spezifikation listet die offenen Fragen deshalb getrennt auf und markiert, welche vor Implementierungsbeginn beantwortet sein müssen. Das kostet nichts außer der Bereitschaft, Unwissen aufzuschreiben. Zwei Achsen: Ist die Frage klärbar, und blockiert sie? Klärbar und blockierend heißt: vorher beantworten lassen, ohne Wenn und Aber.

5:16 Klärbar und unkritisch: Annahme notieren, später prüfen. Nicht klärbar und blockierend — das ist der unangenehme Fall: Der Auftrag geht zurück. Und nicht klärbar, aber unkritisch: bewusst offenlassen und dokumentieren. Der Wert dieser vier Felder liegt darin, dass sie den Reflex durchbrechen, jede Unsicherheit gleich zu behandeln.

5:39 Der zweite Punkt ist der, den ich für den nützlichsten halte: Gebündelte Fragen zeigen den Umfang der Unschärfe auf einmal. Fünf Einzelfragen über zwei Tage verteilt wirken wie fünf Kleinigkeiten. Fünf Fragen auf einer Seite wirken wie das, was sie sind — ein Auftrag, der noch nicht startklar ist. Und der dritte Punkt ist die Zeitfrage: Wer erst beim Implementieren fragt, hat die Annahme schon verbaut. Danach ist die Antwort nicht mehr kostenlos.

6:05 Der erste Punkt ist das, was Agenten typischerweise tun: Die Annahme wird getroffen und nur im Zwischentext erwähnt — in einem Absatz, den niemand liest. Der zweite ist ein Prozessfehler mit Folgen: Die offene Frage wird beantwortet, aber nirgends festgehalten. Beim nächsten ähnlichen Auftrag beginnt dieselbe Diskussion.

6:24 Und der vierte ist die Realität unter Termindruck: Die Klärung dauert, also wird sie übersprungen. Das ist eine legitime Entscheidung — sie muss nur bewusst getroffen und notiert werden.

Spezifikation als Artefakt im Repository

6:35 Bleibt die Frage, wo das Ganze eigentlich hingehört. Und die Antwort hat praktische Konsequenzen. Die Spezifikation gehört ins Repository — verknüpft mit dem Ticket, versioniert wie Code. Der Grund ist nicht Ordnungsliebe. Erstens wird sie damit für den Agenten überhaupt erreichbar, und das ist die Einsicht aus Modul 9. Zweitens wird sie zum Prüfmaßstab im Review.

6:58 Und drittens lässt sich der fertige Diff gegen sie halten — was im Ticketsystem nicht geht, weil beides nicht nebeneinander liegt. Vier Verwendungen für ein Dokument, das man ohnehin schreiben müsste. Auftrag für den Agenten. Prüfmaßstab im Review, und zwar unabhängig vom Ergebnis — man liest erst die Spezifikation, dann den Diff, nicht umgekehrt. Historie, wenn später jemand nach dem Warum fragt.

7:23 Und Vorlage für den nächsten Auftrag derselben Art. Diese vierte Rolle wird unterschätzt: Nach fünf Spezifikationen haben Sie ein Muster, und der Aufwand je Auftrag sinkt deutlich. Fünf Schritte, und der fünfte ist der, auf den es ankommt: Erst danach den Agenten beauftragen. Nicht parallel, nicht vorher, nicht „er kann ja schon mal anfangen".

7:45 Der erste Schritt verdient auch eine Bemerkung: Problem vom Lösungsvorschlag trennen. In den meisten Tickets steht beides vermischt, und der Lösungsvorschlag stammt von jemandem, der den Code nicht kennt. Ihn zu ignorieren ist erlaubt — solange das Problem dahinter erhalten bleibt. Der erste Punkt ist genau die Situation, die wir mit dem Repository lösen: Die Spezifikation liegt im Ticketsystem und ist für den Agenten unerreichbar.

8:11 Der zweite ist der schleichende: Sie wird während der Umsetzung stillschweigend angepasst — dann prüft man am Ende gegen einen Maßstab, den das Ergebnis selbst verschoben hat. Und der dritte ist die Frage, ob sich der ganze Aufwand gelohnt hat: Der fertige Diff wird nie gegen sie gehalten. Dann war es Dokumentation statt Werkzeug.

Übung

8:30 Machen wir das an unserem Ticket — dem, das Sie schon aus Modul 1 kennen. Der Auftrag ist derselbe wie am ersten Tag, aber die Anforderung ist jetzt eine andere. Damals ging es um einen Canvas mit fünf Feldern. Jetzt geht es um eine Spezifikation, aus der sich Tests ableiten lassen — und um die saubere Trennung zwischen dem, was entschieden ist, und dem, was noch offen bleibt.

8:53 Ziel, mindestens zwei Nicht-Ziele, Randbedingungen, fünf prüfbare Akzeptanzkriterien. Die offenen Fragen stehen getrennt und sind als blockierend oder unkritisch markiert. Und die Frage, an der sich alles entscheidet, steht im Hinweis: Was passiert mit Altbeständen ohne Kostenstelle? Wenn Sie die nicht beantworten können, ist der Auftrag nicht startklar — und das festzustellen ist ein vollwertiges Ergebnis dieser Übung.

9:19 Der erste Punkt ist der, den ich bei dieser Übung am häufigsten sehe: Die Kriterien beschreiben Formularfelder statt Systemverhalten. Der zweite ist die vergessene Zeile aus der Tabelle — der Ausfall des Kontenwerks kommt in keinem Kriterium vor. Der dritte ist subtil und verbreitet: Offene Fragen werden als Annahmen getarnt, weil eine Annahme hinschreiben leichter ist als zuzugeben, dass man nachfragen muss.

9:42 Im nächsten Modul geht es darum, was der Agent mit dieser Spezifikation anfängt.