Spec-driven Development verstehen

Spec-driven Development verstehen

0:00 Im vorigen Modul haben wir festgestellt: Was das Projekt überlebt, muss irgendwo stehen. In diesem Modul schauen wir uns an, wo genau — und in welcher Form. Spec-driven Development ist dabei kein neues Werkzeug, sondern eine Umkehrung der Blickrichtung. Bisher war der Code das Ergebnis und die Beschreibung ein Nebenprodukt, das man nach dem Merge vergessen durfte.

0:21 Jetzt wird die Beschreibung zum führenden Artefakt und der Code zu ihrem Ausdruck in einer bestimmten Sprache. Das klingt akademisch, hat aber sehr praktische Folgen — vor allem für die Frage, wie viel man eigentlich aufschreiben muss.

Spec-driven Development verstehen

0:35 Drei Fragen strukturieren dieses Modul. Erstens: Was unterscheidet ein dauerhaftes Artefakt von einem guten Prompt? Zweitens: Welche Arten von Spezifikationen gibt es überhaupt, und wann braucht man welche? Und drittens die Frage, die im Alltag am meisten Zeit spart: Wie viel Planung braucht eine konkrete Änderung? Am Ende ordnen Sie fünf Änderungswünsche selbst ein.

Von Prompts zu dauerhaften Artefakten

0:59 Fangen wir mit dem Unterschied an, der alles andere trägt: dem zwischen einer Unterhaltung und einem Dokument. Beide können denselben Inhalt haben — und doch sind sie nicht dasselbe wert. Der Unterschied liegt nicht in der Qualität des Gedankens, sondern in seiner Haltbarkeit und seiner Zugänglichkeit für andere. Beides entscheidet darüber, ob ein Agent morgen noch damit arbeiten kann.

1:21 Denken Sie an den Unterschied zwischen einem Telefonat mit dem Handwerker und einem Angebot auf Papier. Im Telefonat wird oft mehr gesagt, es ist schneller und persönlicher. Nur: Vier Wochen später erinnert sich jeder anders daran. Das Angebot ist knapper, aber es liegt vor, es lässt sich prüfen, und wenn sich etwas ändert, ändert man es dort.

1:41 Genau diese Rolle spielt eine Spezifikation. Sie ist nicht ausführlicher als ein guter Chatverlauf — sie ist nur die Fassung, auf die sich alle beziehen können. Und sie wird versioniert, reviewt und weiterentwickelt wie Quellcode. Die interessanteste Zeile dieser Gegenüberstellung ist die letzte. Über Lebensdauer und Sichtbarkeit denken die meisten schon nach.

2:02 Dass eine Spezifikation aber wiederverwendbar ist, wird oft übersehen — und genau das ist im agentischen Arbeiten der eigentliche Gewinn. Der Agent liest sie in jeder neuen Sitzung als Kontext. Sie schreiben also nicht für ein Archiv, sondern für die nächste Sitzung. Deshalb lohnt sich auch der scheinbar überflüssige Aufwand: Ein guter Prompt hilft einmal, ein gutes Artefakt hilft bei jedem weiteren Lauf, ohne dass jemand daran denken muss.

2:28 Von diesen vier Bestandteilen wird der dritte am häufigsten weggelassen — und er ist der wertvollste. Randbedingungen, Ausschlüsse und offen benannte Annahmen klingen nach Kleingedrucktem, sind aber genau die Stellen, an denen ein Agent sonst selbst entscheidet. Was nicht ausgeschlossen ist, gilt als erlaubt; was nicht als Annahme markiert ist, gilt als Tatsache.

2:49 Der vierte Punkt, die Akzeptanzkriterien, ist die Verbindung nach vorn: Er verknüpft Anforderung, Code und Test miteinander. Ohne ihn hat der Test keinen Maßstab außer sich selbst. Was Sie hier sehen, ist keine Vorlage zum Ausfüllen, sondern ein Zuschnitt. Fünf Felder, mehr braucht es nicht: warum überhaupt, was das System danach kann, was sich nicht ändern darf, was ausdrücklich draußen bleibt, und woran der Erfolg messbar wird.

3:14 Achten Sie besonders auf die zweite Zeile. Jede einzelne Fähigkeit trägt ihre eigene Erfolgsbedingung — nicht die Spezifikation als Ganzes. Sobald Sie das ernst nehmen, fallen unpräzise Fähigkeiten von selbst auf: Wo Sie keine Bedingung formulieren können, haben Sie noch keine Fähigkeit beschrieben, sondern eine Absicht.

3:34 Diese vier Muster stammen aus realen Spezifikationen, und alle vier fühlen sich beim Schreiben gut an. Wer den Code beschreibt statt der Absicht, hat das Gefühl, gründlich zu sein — produziert aber eine zweite, schlechtere Fassung des Quelltexts. Wer „benutzerfreundlich" schreibt, hat etwas Wahres gesagt, das niemand prüfen kann. Annahmen im Kopf sind gar nicht als Problem erkennbar, solange alle dieselbe haben.

3:57 Und der letzte Punkt ist der leiseste: Nach dem Merge fasst niemand die Datei mehr an, und ab da führt sie in die Irre — was schlimmer ist, als sie nie gehabt zu haben.

Unterschiedliche Formen von Spezifikationen

4:08 Spezifikation ist ein Sammelbegriff, und das ist die Quelle vieler Missverständnisse. Sehen wir uns an, welche Formen es gibt — und vor allem, welche man weglassen kann. Denn die Kunst besteht nicht darin, alle zu kennen, sondern darin, für ein konkretes Vorhaben die richtigen zwei oder drei auszuwählen. Wer alle schreibt, verliert die Zeit, die der Ansatz eigentlich sparen sollte.

4:31 Es hilft, an Bauunterlagen zu denken. Eine Machbarkeitsstudie, ein Bauantrag, ein Grundriss und ein Handwerkerauftrag beschreiben dasselbe Haus — aber für verschiedene Leser und mit verschiedenem Verbindlichkeitsgrad. Genauso hier: Ein Product Brief ordnet die Idee ein, ein PRD einigt mehrere Beteiligte, eine Feature Spec ist ein knapper Umsetzungsvertrag, eine Story schneidet ihn in prüfbare Einheiten.

4:54 Der Fehler ist selten, das falsche Dokument zu schreiben. Der Fehler ist, alle zu schreiben, weil eine Methode sie anbietet. Nehmen Sie diese Tabelle bitte nicht als Checkliste. Sie ist ein Katalog, aus dem Sie auswählen. In unserem Beispielprojekt bleiben von den sieben Zeilen vier leer: kein Product Brief, kein PRD, keine eigene Testspezifikation. Das ist kein Versäumnis, sondern das Ergebnis.

5:19 Ein Team, ein Feature — da muss sich niemand schriftlich einigen. Interessant ist die letzte Zeile: Das Entscheidungstagebuch kostet fast nichts und beantwortet die Frage, die nach drei Monaten garantiert kommt. Nämlich, warum eine offensichtlich naheliegende Lösung damals verworfen wurde. Die Schwelle für ein PRD ist einfacher, als sie oft dargestellt wird: Es geht um Einigung.

5:43 Sobald mehrere Menschen sich darauf festlegen müssen, was das Produkt ist, oder mehrere Epics zueinander passen sollen, brauchen Sie ein Dokument, das diese Einigung trägt. Dasselbe gilt, wenn eine Entscheidung außerhalb des Entwicklungsteams fällt. Alles darunter — und das ist der Großteil der täglichen Arbeit — geht direkt zur Feature Spec.

6:03 Diese Abkürzung ist ausdrücklich vorgesehen und kein Qualitätsverzicht. Der erste Punkt ist der teuerste: Ein PRD für ein Zwei-Tage-Feature bindet mehr Zeit, als es je einspart, und diskreditiert nebenbei den ganzen Ansatz im Team. Der zweite ist der heimtückischste. Wenn dieselbe Aussage in drei Dokumenten steht, wird sie irgendwann in zweien geändert — und ab da haben Sie zwei Wahrheiten, ohne es zu merken.

6:27 Der dritte betrifft die Grenze zwischen UX und Architektur: Wer Oberflächenentscheidungen als Architekturvorgabe notiert, blockiert Alternativen, die niemand blockieren wollte. Und ohne Entscheidungstagebuch führen Sie jede Diskussion nach ein paar Monaten erneut.

Wie viel Planung braucht eine Änderung?

6:43 Kommen wir zu der Frage, die im Alltag am meisten Zeit spart oder kostet — je nachdem, wie Sie sie beantworten. Wie viel Planung braucht eine konkrete Änderung? Diese Frage stellt sich mehrmals täglich, und meistens wird sie unbewusst beantwortet. Wir machen sie explizit — mit drei Pfaden und einer Regel, die man sich merken kann.

7:03 Verbreitete Methoden staffeln die Planung nach Größe, und das ist ein bemerkenswert unideologischer Zug. Kleine Änderungen werden direkt gebaut, ohne jedes Artefakt. Was mehrere Sitzungen braucht, bekommt eine Spezifikation und geordnete Stories. Und Vorhaben über viele Sitzungen brauchen zusätzlich Koordination zwischen den Teilen.

7:23 Der Punkt dabei ist: Die Methode fordert nicht ihr eigenes volles Programm. Sie fordert eine bewusste Entscheidung darüber, wie viel Prozess dieser eine Fall verdient — und die trifft ein Mensch, nicht das Werkzeug. Achten Sie auf die Fußzeile dieser Tabelle, denn sie enthält die eigentliche Regel. Der Umfang bestimmt den Pfad — aber Risiko hebt ihn an.

7:44 Eine Änderung, die nur eine Datei berührt, aber Zugriffsrechte betrifft, gehört nicht in den direkten Pfad, egal wie klein sie aussieht. Umgekehrt gilt das nicht: Ein umfangreiches, aber risikoarmes Vorhaben bleibt ein Epic und wird nicht zum Projekt. Wer diese Asymmetrie einmal verinnerlicht hat, entscheidet solche Fragen in einer Minute statt in einer Diskussion.

8:06 Diese fünf Schritte dauern zusammen selten länger als zwei Minuten, und der fünfte ist der, den man weglassen möchte. Reichweite, Risiko und Umkehrbarkeit sind schnell geschätzt. Der Pfad ergibt sich dann fast von selbst. Aber die Begründung dazuzuschreiben, fühlt sich nach Bürokratie an. Sie ist trotzdem der wertvollste Teil: Nur die Begründung lässt sich später prüfen.

8:28 Wenn ein Vorhaben aus dem Ruder läuft, wollen Sie nicht wissen, welcher Pfad gewählt wurde, sondern warum — und ob die Annahme von damals noch stimmt. Jetzt zu Ihnen. Sie bekommen fünf Änderungswünsche, von der trivialen Korrektur bis zum Wechsel des Anmeldeverfahrens. Ordnen Sie jeden einem Pfad zu, notieren Sie die Begründung und legen Sie fest, welche menschlichen Prüfstellen nötig sind.

8:52 Der spannende Fall ist erfahrungsgemäß nicht der größte, sondern der mittlere: eine kleine Regel mit fachlicher Wirkung. Sie bleibt im direkten Pfad — bekommt aber eine Prüfstelle. Wenn Sie in der Gruppe an einem Fall uneins sind, haben Sie meistens unterschiedliche Annahmen über das Risiko. Genau das ist die Diskussion, die sich lohnt.

9:12 Vier Dinge nehmen wir mit. Die Spezifikation führt, der Code folgt — deshalb wird sie versioniert und nicht abgelegt. Akzeptanzkriterien sind das Bindeglied zwischen Anforderung, Implementierung und Test; ohne sie misst der Test sich selbst. Welches Artefakt entsteht, richtet sich nach Risiko und Reichweite, nicht nach Vollständigkeit.

9:32 Und der wichtigste Satz zum Schluss: Wer immer alles erzeugt, hat den Ansatz genauso verfehlt wie der, der nie etwas erzeugt. Im nächsten Modul sehen wir uns an, wie eine Methode diese Artefakte als aufrufbare Abläufe ins Projekt bringt.