05.05, 17:00–17:30 (Europe/Berlin), Saal St. Petersburg
Sprache: Deutsch
Git ist für uns seit Jahren die verlässlichste Single Source of Truth – zuerst für Code, später auch für Dokumentation (Docs-as-Code) und Infrastruktur (GitOps). Mit Spec-Driven Development (SDD) verschiebt sich der Fokus erneut: Die Spezifikation wird zum primären Artefakt, Code und Tests werden zunehmend ableitbar.
Wir teilen, welche Praktiken dafür im Team funktionieren – und wo SDD scheitert, wenn man es nur als "Spec → Code" missversteht.
Viele Teams haben das gleiche Problem, nur unterschiedliche Tools: Entscheidungen und Kontext zerstreuen sich über Tickets, Chats, Mails und Meetings – und spätestens nach ein paar Wochen ist unklar, was eigentlich noch gilt. Spezifikation wird anfangs erstellt und diskutiert, verliert dann bei der Implementierung jedoch ihre Beachtung, Wert und Pflege.
Unsere These aus einem aktuellen Projektkontext: SDD funktioniert erst dann wirklich, wenn die Spezifikation als projektweites, versioniertes Projektgedächtnis verstanden wird ("Spec as the Project Brain") – nicht als hübsche Doku, und nicht als Marketingkürzel für KI-generierten Code.
Was ihr mitnehmt
- Ein mentales Modell: Was ist SDD (und was ist es nicht)?
- Rituale für "Spec-first" im Alltag (inkl. Journaling/Session-Doku als Teil der SSOT)
- Qualitätskriterium: Konsistenz vor Vollständigkeit (und wie man das durchhält)
- Typische Anti-Patterns und Grenzen (wann SDD eher schadet)
Grober Ablauf (30min)
- 5min: Warum Git/SSOT als Metapher heute nicht mehr reicht (der Kontext muss mit [sic!])
- 10min: SDD als Perspektivwechsel: Spec als Truth, Code als View
- 10min: Praktiken/Patterns: Entscheidungen, Begriffe, Konsistenz, Journaling
- 5min: Grenzen, Fragen, Diskussion
bla
