Inhalt

Lernziel Modul 6

1. Die Leitidee benennen — QRSPI ordnet nach Phasen, BMAD nach Rollen, OpenSpec nach Artefakten.
2. Nach Philosophie einordnen — nicht die Kommandos vergleichen, sondern die Stelle, an der ein Framework Alignment erzeugt.
3. Begründet wählen — zu einem gegebenen Projekttyp sagen können, welches passt und was es an Aufwand kostet.

Arbeitsteilung ist nicht neu — der Zuschnitt schon

Schnitte, die man nicht vermischt

1. Fundament ist ein eigenes Projekt, kein Vorspann zum Feature: eigener Auftrag, eigene Spec, eigene Abnahme — sonst wandert Fachlichkeit ins Gerüst und ist dort nicht mehr zu finden.
2. Die Firmengröße bestimmt nur die Träger, nicht die Trennung: große Häuser haben ein Framework- und ein Test-Team; kleine haben dieselben drei Schnitte — als getrennte Sessions und getrennte Commits.

Jede Ebene hat ihre eigene Abnahme

nach unten: seltener geändert, breiterer Schaden  ·  Test ist keine Ebene, sondern eine Spalte — jede Ebene prüft anders (Modul 9)

Alle lösen dasselbe Problem

Die gemeinsame DNA

1. Alignment vor Arbeit — bevor Code entsteht, wird Einigkeit über Problem und Lösung hergestellt, und zwar schriftlich. Der teure Denkfehler soll passieren, solange er noch nichts kostet.
2. Artefakte statt Gedächtnis — das Einvernehmen liegt in einer Datei im Repo, nicht in einer Chat-Historie. Eine frische Session muss daraus weiterarbeiten können.
3. Isolierter Context statt Riesensession — jeder Schritt bekommt genau den Kontext, den er braucht, nicht die gesamte Projektgeschichte.

Die Einordnungsachse dieses Moduls

Phasen — die Pipeline als Leitidee

Prinzipien, die es wert sind

Rollen — das Team als Leitidee

BMAD im Ablauf

BMAD Stärken und Kosten

Artefakte — die Spezifikation als Leitidee

OpenSpec im Ablauf — eine Änderung von Anfang bis Archiv

Spec als Vertrag, nicht als Plan

GitHub Spec Kit

Vergleichsmatrix statt Glaubensfragen

Wie diese Matrix zu lesen ist

Das Artefakt ist der Schnitt

1. „Self-contained" ist keine Stilfrage, sondern eine Kontext-Aussage: Das Story-File ist genau deshalb vollständig, damit die Umsetzung bei null anfangen kann.
2. Dasselbe beim Delta: es ist klein, damit niemand das Vollbild mitschleppen muss.

Ein echter Workflow, kein Lehrbeispiel

Legende für die nächsten drei Folien:  Gate Freigabe-Punkt — solange er offen ist, wird nicht weitergearbeitet.  · Mensch ein Mensch muss ausdrücklich bestätigen; kein Agent entscheidet das.

Planen und designen (1–3a)

Bauen und prüfen (4–7b)

Ausliefern und schließen (8–15a)

Wo darin welche Philosophie steckt

Gewachsene Synthese, kein Produkt

Die Zeremonie-Falle

Was jeder Gate wirklich kostet

Regeln aus Schmerz, nicht aus Prinzip

Wie man daraus etwas einführt

1. Nicht das Framework kopieren, die Leitidee wählen — braucht euer Problem Reihenfolge, Arbeitsteilung oder eine gepflegte Wahrheit?
2. Mit einem Gate anfangen — in der Praxis fast immer das gleiche: Alignment vor Code. Alles andere kann folgen.
3. Auslöser definieren, nicht Pflicht für alles — wann greift der volle Ablauf, wann reicht ein Ticket?
4. Mechanisieren, was mechanisierbar ist — eine Regel, die ein Hook prüft, driftet nicht: „control flow, not prompts".
5. Jede neue Regel bekommt ihren Auslöser ins Dokument — Datum und Vorfall dazu, sonst fehlt in einem Jahr die Begründung.

Modul 6 in vier Sätzen

1. Alle Workflow-Frameworks antworten auf dieselben zwei Eigenschaften aus Modul 1 — stateless und nicht-deterministisch — mit denselben drei Bausteinen: Alignment, Artefakte, isolierter Context.
2. Sie unterscheiden sich in der Leitidee: Phasen (QRSPI/RPI), Rollen (BMAD), Artefakte (OpenSpec).
3. Ein realer Workflow ist meist eine Synthese aus allen dreien — und darf das auch ehrlich so nennen.
4. Jeder Gate kostet. Wer die Zeremonie-Falle vermeiden will, skaliert Zeremonie an Auslösern und begründet jede Regel mit einem echten Vorfall.

Übung 6 — Begründet entscheiden

Dauer ca. 20 Minuten · Zweiergruppen, danach Auflösung im Plenum

Auflösung Übung 6