BMad, Spec Kit und OpenSpec im Vergleich

BMad, Spec Kit und OpenSpec im Vergleich

0:00 Wir haben zwei Tage lang mit einem Ansatz gearbeitet. Jetzt treten wir einen Schritt zurück und schauen, was es sonst noch gibt — nicht aus Vollständigkeit, sondern weil die Wahl bei Ihnen liegt und begründet sein sollte. Drei Ansätze stehen exemplarisch für drei Prozessdichten. Sie beantworten alle dieselbe Frage: Wo steht die Absicht, wenn der Chat geschlossen ist?

0:21 Sie unterscheiden sich darin, wie viel Prozess sie mitbringen. Und um es vorwegzunehmen: Keiner davon ist grundsätzlich besser.

BMad, Spec Kit und OpenSpec im Vergleich

0:29 Vier Kapitel. Zuerst ein Überblick über die Schwerpunkte, dann Spec Kit mit seiner festen Befehlskette, danach OpenSpec mit seiner Trennung zwischen Änderungsvorschlag und lebender Spezifikation. Und zum Schluss die eigentliche Frage: Welcher Ansatz passt zu welcher Situation? Damit der Vergleich nicht abstrakt bleibt, sehen wir dieselbe Anforderung — unsere Warteliste — in den Artefakten der verschiedenen Ansätze.

Drei Ansätze im Überblick

0:53 Beginnen wir mit der Vogelperspektive. Die Unterschiede zwischen den Ansätzen sind kleiner, als die jeweiligen Dokumentationen vermuten lassen — und die Gemeinsamkeit ist größer. Sehen wir uns beides an, damit Sie nicht auf Marketingunterschiede hereinfallen. Denn wer den gemeinsamen Kern kennt, kann später wechseln, ohne von vorn anzufangen.

1:14 Alle drei halten Absicht als versioniertes Artefakt fest, bevor Code entsteht. Das ist der gemeinsame Kern, und er ist wichtiger als jeder Unterschied. Sie variieren in drei Dimensionen: wie viel Prozess sie mitbringen, wie stark sie mit Rollen arbeiten und wie sie mit bestehendem Code umgehen. Man kann sich das wie Bauvorschriften vorstellen: Ob Sie einen vollständigen Bauantrag brauchen oder eine Anzeige genügt, hängt nicht vom Haus ab, sondern davon, wer alles zustimmen muss.

1:41 Genauso hier. Lesen Sie diese Tabelle nicht als Bewertung, sondern als Standortbestimmung. Der Ansatz links bringt ausgeprägte Rollen mit und deckt den ganzen Weg ab — das hilft, wenn man den Prozess erst aufbaut, und kann erdrückend wirken, wenn man ihn schon hat. Der mittlere ist gründlich und artefaktorientiert, mit einer festen Kette. Der rechte ist bewusst knapp und denkt in Änderungen statt in Prozessen.

2:05 Die Fußzeile ist mir wichtig: Kein Ansatz ist grundsätzlich besser. Sie treffen verschiedene Teams — und dasselbe Team in verschiedenen Phasen. Diese vier Gemeinsamkeiten sind der eigentliche Ertrag des Vergleichs. Absicht wird geschrieben, bevor Code entsteht. Jede Phase erzeugt ein Markdown-Artefakt für die nächste — Markdown deshalb, weil es sowohl für Menschen als auch für Agenten lesbar ist.

2:29 Der Coding Agent liest diese Artefakte als Kontext, was der ganze Sinn der Übung ist. Und der vierte Punkt ist der, den man sich merken sollte: Sie ersetzen keine Entscheidung, sie halten sie fest. Wer sich vom Werkzeug eine Entscheidung erhofft, wird von allen dreien enttäuscht. Der erste Punkt ist der teuerste: Zwei Ansätze parallel im selben Repository erzeugen zwei Wahrheiten, und niemand weiß, welche gilt.

2:54 Entscheiden Sie sich — auch wenn beide gut sind. Der zweite ist die Übernahme ohne Bedarfsprüfung; das endet meistens in einem Prozess, den nur eine Person versteht und pflegt. Der dritte ist eine bekannte Verwechslung: Werkzeugwechsel gelten als Fortschritt, obwohl die Artefakte dieselben blieben. Und der vierte ist die Wahl nach Beliebtheit statt nach Teamgröße und Risiko.

Spec Kit im Ablauf

3:16 Sehen wir uns den ersten Alternativansatz genauer an. Sein Kennzeichen ist eine feste Kette benannter Phasen, jede mit einem eigenen Befehl. Das wirkt zunächst formal — und hat für bestimmte Umgebungen genau deshalb einen echten Wert. Überall dort nämlich, wo jemand später nachweisen muss, warum etwas so und nicht anders gebaut wurde.

3:37 Der Ablauf beginnt mit etwas, das die anderen so nicht kennen: Projektgrundsätze, einmalig festgelegt. Danach führt eine Kette durch spezifizieren, planen, in Aufgaben zerlegen und umsetzen. Ergänzend gibt es einen Abgleich des tatsächlichen Bestands gegen Spezifikation und Plan — das ist die Antwort auf eine Frage, die jeden Prozess irgendwann einholt: Stimmt das, was wir aufgeschrieben haben, eigentlich noch mit dem überein, was im Repository steht?

4:03 Diese Rückkopplung ist der interessanteste Teil des Ansatzes. Achten Sie auf die Reihenfolge, nicht auf die Schreibweise. Grundsätze zuerst, dann Anforderungen, dann der technische Plan, dann die Aufgabenliste, dann die Umsetzung — und am Ende der Abgleich. Der Plan hat dabei eine besondere Rolle: Er bildet Anforderungen auf technische Entscheidungen ab, jede mit Begründung.

4:26 Das ist genau das, was in regulierten Umgebungen verlangt wird, wenn jemand fragt, warum eine Technologie gewählt wurde. Und beachten Sie die Fußzeile: Die zusätzlichen Befehle zum Klären und Analysieren sind optional. Die Hauptkette bleibt schlank. Der Ansatz passt zu Teams, die eine verbindliche, wiederholbare Kette wollen — und zu Umgebungen, in denen Grundsätze schriftlich gelten müssen.

4:49 Der dritte Punkt ist der praktisch wichtigste: Wenn der Plan die Technikwahl begründen soll, bekommen Sie hier eine Struktur, die genau das leistet. Und dann der ehrliche vierte Punkt: Wenn schon der Aufwand der Kette abschreckt, ist es der falsche Ansatz. Ein Prozess, den man umgeht, ist schlechter als ein knapper, den man einhält.

OpenSpec im Ablauf

5:08 Der zweite Alternativansatz geht in die andere Richtung. Er ist bewusst kompakt und macht eine Unterscheidung, die ich für sehr klug halte: die zwischen der Arbeit, die gerade ansteht, und dem Zustand, der dauerhaft gilt. Diese Trennung löst ein Problem, das viele Teams kennen, ohne es benennen zu können — Spezifikationen, die mit der Zeit zu Aufgabenlisten verkommen.

5:30 Zwei Dinge werden getrennt. Ein Änderungsvorschlag beschreibt geplante Arbeit — er entsteht vor der Umsetzung und wird danach archiviert. Die lebende Spezifikation daneben beschreibt, was dauerhaft gilt. Der Vergleich aus dem Alltag: Der Bauantrag beschreibt den Umbau, der Grundriss beschreibt das Haus danach. Beides braucht man, aber es sind verschiedene Dokumente mit verschiedener Lebensdauer.

5:53 Wer diese Trennung nicht macht, hat entweder eine Spezifikation voller erledigter Aufgaben oder eine Aufgabenliste, die den Zustand beschreiben soll. Interessant an diesem Block ist die Ablage. Der Vorschlag liegt in einem eigenen Verzeichnis, zusammen mit den Anforderungen als Szenarien, dem technischen Ansatz und einer Aufgabenliste — vier Dateien, überschaubar.

6:15 Nach der Umsetzung wandert das Ganze ins Archiv, und was dauerhaft gilt, steht in den lebenden Spezifikationen daneben. Die Anforderungen selbst werden als schlichte Wenn-Dann-Szenarien geschrieben, ohne eigenes Format. Das ist unspektakulär und genau richtig: Ein Team lernt kein Schema, sondern schreibt auf, was passieren soll.

6:34 Dieser Ansatz passt zu Teams mit geringerem Prozessbedarf und schnellem Takt. Er passt besonders gut zu Bestandssystemen, in denen sich Anforderungen laufend verschieben — weil er Änderungen als Normalfall behandelt und nicht als Abweichung vom Plan. Er passt zu Arbeit, die sich gut als Folge einzelner Änderungen beschreiben lässt. Und er passt weniger gut, wenn viele Beteiligte sich vorab einigen müssen.

6:57 Für diesen Fall fehlt ihm bewusst das Dokument, in dem so eine Einigung festgehalten wird.

Auswahl für den eigenen Fall

7:03 Damit sind wir bei der Frage, um die es eigentlich geht: Was passt zu Ihnen? Drei Größen entscheiden das — und eines der möglichen Ergebnisse ist ausdrücklich, keinen der drei Ansätze zu nehmen. Ein selbst geschnittener Minimalprozess ist kein Ausweichen, sondern oft die ehrlichste Antwort auf die eigene Lage. Drei Größen: Wie viele Menschen müssen sich einigen? Wie hoch ist das Risiko? Und wie viel Prozess trägt das Team wirklich mit?

7:29 Die dritte ist die, die am häufigsten ignoriert wird, obwohl sie am meisten entscheidet. Ein Prozess, den das Team nicht mitträgt, wird nach vier Wochen umgangen — und dann haben Sie nicht nur keinen Prozess, sondern zusätzlich die Erfahrung, dass so etwas bei uns nicht funktioniert. Wer nur zwei Artefakte braucht, sollte deshalb nicht zwölf einführen.

7:50 Drei typische Situationen, drei verschiedene Antworten. Kleines Team mit bestehender Anwendung: der knappe, änderungsorientierte Weg. Reguliertes Unternehmensprojekt: die feste Kette mit schriftlichen Grundsätzen, weil dort der Nachweis Teil der Anforderung ist. Schneller interner Prototyp: ein eigener Minimalprozess mit zwei Artefakten.

8:10 Die Fußzeile ist der Satz, den ich Ihnen mitgeben möchte: Entscheidend ist, dass die Wahl begründet ist — nicht, dass sie vollständig ist. Eine begründete kleine Lösung schlägt eine unbegründete große. Ihre Aufgabe: Wählen Sie für diese drei Szenarien jeweils einen Ansatz und begründen Sie die Wahl. Nennen Sie außerdem, welche Artefakte tatsächlich entstehen sollen — nicht welche möglich wären.

8:34 Der Hinweis auf der Folie ist ernst gemeint: Ein selbst geschnittener Minimalprozess ist ein zulässiges Ergebnis. Wenn Sie am Ende bei zwei Dateien landen, einer für den Intent und einer für offene Fragen, und das begründen können, haben Sie die Aufgabe besser gelöst als mit einer vollständigen Werkzeugkette, die niemand benutzt.

8:53 Vier Punkte. Alle drei Ansätze halten Absicht als versioniertes Artefakt fest, bevor Code entsteht — das ist der gemeinsame Kern. Sie unterscheiden sich in Prozessdichte, Rollenmodell und im Umgang mit Bestandscode. Zwei Ansätze parallel erzeugen zwei Wahrheiten im selben Repository, also entscheiden Sie sich. Und die begründete Wahl zählt mehr als die vollständige.

9:15 Im letzten Modul bauen Sie daraus Ihren eigenen Workflow — auf einer Seite, mit Namen und Festlegungen statt Absichten.