Herausgegeben von Anvil Coder · Halvic Labs GmbH
Aktualisiert
Was ist Spec-Driven Development?
Spec-Driven Development nutzt eine versionierte Spezifikation als Arbeitsgrundlage. So verbindest du Anforderungen, Akzeptanzkriterien, Planung und Review.
Was bedeutet Spec-Driven Development?
Spec-Driven Development stellt eine ausdrückliche Spezifikation vor die Umsetzung: Was soll entstehen, welche Grenzen gelten und woran wird das Ergebnis geprüft? Die Spezifikation bleibt versioniert und wird bei neuen Erkenntnissen aktualisiert. Sie ist eine Arbeitsgrundlage, kein einmalig eingefrorenes Dokument.
Ein Chat kann bei der Klärung helfen. Entscheidend ist nicht, ob ein Team chattet, sondern ob die gültigen Entscheidungen ausserhalb des Gesprächs nachvollziehbar festgehalten werden.
Was gehört in eine brauchbare Spezifikation?
- Problem und Zielgruppe: Wer braucht welche Veränderung?
- Umfang und Nicht-Ziele: Was gehört bewusst nicht zum Auftrag?
- Akzeptanzkriterien: Welches beobachtbare Verhalten gilt als erfolgreich?
- Schnittstellen, Abhängigkeiten und offene Annahmen.
- Prüfstrategie: Welche Tests und welches menschliche Review werden benötigt?
Beispiel: „Registrierung verbessern“ ist zu offen. „Leere E-Mail-Adresse abweisen, keinen Datensatz anlegen und eine verständliche Meldung anzeigen“ lässt sich gezielter umsetzen und prüfen.
Wie nutzt Anvil Coder diese Grundlage?
Im Spec-Studio werden Anforderungen und Projektgrundlagen vorbereitet. Daraus entstehen kuratierte Epics und Tickets. Das Erzeugen dieser Tickets startet noch keinen Code-Lauf. Die Umsetzung einer Story folgt der Planung in kleinen Arbeitsschritten.
Von der Spezifikation zum Pull-Request-Entwurf beschreibt den praktischen Übergang. Ein Stack-Profil benennt dabei Werkzeuge und Prüfkommandos; deren Verfügbarkeit muss gesondert sichergestellt werden.
Welche Grenzen hat die Methode?
Eine falsche Spezifikation kann zu einer präzise umgesetzten falschen Lösung führen. Widersprüche, fehlende Nutzerbedürfnisse und neue Erkenntnisse müssen zurück in die Spezifikation fliessen. Weder das Dokument noch seine Verwendung beweisen die Korrektheit des Codes.
Als externe Methodenreferenz beschreibt GitHub Spec Kit ebenfalls einen spezifikationsgetriebenen Entwicklungsprozess. Das ist eine konzeptionelle Referenz, keine Behauptung einer Integration oder einer unabhängigen Bewertung von Anvil Coder.
