Spezifikationsgesteuerte Entwicklung in Jira
Bei der spezifikationsgesteuerten Entwicklung verfasst du vor dem Erstellen durch einen Agenten eine strukturierte Spezifikation, damit der Agent das Richtige erstellt statt einer plausiblen Vermutung. In Jira lebt diese Spezifikation direkt in dem Vorgang, an dem du bereits arbeitest, sobald er eine echte Absicht enthält: Ergebnisse, Umfang, Einschränkungen und Akzeptanzkriterien. Ein Vorgang kann die vollständige Spezifikation für eine Aufgabe enthalten oder einen Teil einer größeren Funktionsspezifikation, die auf mehrere Vorgänge aufgeteilt ist.
In diesem Leitfaden erfährst du, was eine Spezifikation agententauglich macht, warum der Vorgang der richtige Ort dafür ist und wie du deine erste Spezifikation verfasst. Kurz gesagt bietet dir die spezifikationsbasierte Entwicklung in Jira drei Dinge:
Eine zentrale Informationsquelle, auf deren Grundlage der Agent arbeitet und anhand derer der Reviewer den Vorgang prüft
Akzeptanzkriterien, die des Status "erledigt" für Agenten und Personen definieren
Weniger Nacharbeit, weil die Absicht geklärt ist, bevor der Agent eine einzige Zeile Code schreibt
Was ist spezifikationsbasierte Entwicklung?
Bei der spezifikationsgesteuerten Entwicklung verfasst du eine strukturierte Spezifikation, die definiert, was entwickelt werden soll und wie Erfolg gemessen wird. Der Agent setzt sie dann um, statt anhand eines einzeiligen Prompts zu raten.
Die Spezifikation wird zur Informationsquelle. Sie treibt den Plan, die Umsetzung und die Prüfung an, und in Jira findet alles direkt im selben Vorgang statt. Die Idee entstand schon vor der KI und geht auf API-Design sowie formale Methoden zurück, bei denen du das Verhalten festlegst, bevor du mit dem Bauen beginnst.
Die Definition ändert sich ständig, während sich die Tools weiterentwickeln. Betrachte sie daher als eine Orientierungshilfe und nicht als festes Spezifikationsformat. Was konstant bleibt, ist der zentrale Schritt: Definiere den Vorgang, bevor der Agent ihn erstellt.
Der Unterschied liegt darin, wann du Mehrdeutigkeiten auflöst. Beim Vibe-Coding wird das Problem erst nach dem Schreiben des Codes gelöst; bei der spezifikationsgesteuerten Entwicklung bereits vorher.
Vibe-Coding: Du steuerst den Agenten mit Prompts und akzeptierst, was er zurückgibt, sodass der Umfang, die Einschränkungen und die Grenzfälle, von denen er ausgeht, erst sichtbar werden, wenn der Code bereits existiert.
Spezifikationsgesteuert: Du legst zuerst Absicht, Einschränkungen und Abnahmekriterien fest, damit der Agent sich an einer Definition orientiert statt an einer Vermutung. Die Überprüfung erfolgt anhand derselben Definition direkt in dem Vorgang, in dem alles stattfindet.
Bei Code, der sich in einer echten Codebasis bewähren muss, kann ein Agent ohne festgelegten Kontext das Problem aus dem Ticket zu wörtlich lösen und dabei die entscheidende Einschränkung übersehen. An diesem Punkt beginnt die Nacharbeit.
Prompts neigen dazu, zwei Dinge zu verschmelzen: Die Spezifikation ist das, was du erstellst, der Plan ist, wie es erstellt wird. Die spezifikationsgesteuerte Entwicklung legt zuerst das "Was" fest und entwickelt daraus dann das "Wie". Das ist der Schritt, den der Planmodus in den Tools der KI-Programmierung oft überspringt: Er entwirft die Vorgehensweise direkt anhand eines Prompts, meist ohne dass eine festgelegte Spezifikation dahintersteht.
Der Planmodus kann als vereinfachte Spezifikation dienen, aber das "Wie" wird dabei spontan anhand eines Prompts im jeweiligen Moment entworfen – nicht anhand einer vereinbarten Spezifikation, die für den gesamten Vorgang gilt.
Warum Spezifikationen für die KI-Programmierung wichtig sind
Wenn die Codegenerierung günstiger wird, ist das Schreiben von Code nicht mehr der schwierige Teil. Es ist vielmehr, zu definieren, was genau entwickelt werden soll. Damit ist die Spezifikation und nicht der Prompt das wirkungsvollste Artefakt, das du erstellst.
Ein einmaliger Prompt überlässt es dem Agenten, die Lücken zu füllen – dieser füllt sie dann mit Annahmen und erzeugt Code, der zwar richtig aussieht, aber das falsche Problem löst. Eine Spezifikation schließt diese Lücken zuerst, sodass der Agent auf eine Definition hinarbeitet statt auf eine Vermutung. In Jira ist diese Spezifikation der Vorgang, den dein Team bereits plant, zuweist und überprüft.
Was gehört in eine Spezifikation, auf deren Grundlage ein Agent einen Build erstellen kann?
Eine agententaugliche Spezifikation beantwortet die Fragen, die ein guter Entwickler vor dem Projektstart stellen würde. In Jira sind diese Antworten in der Zusammenfassung, der Beschreibung, den verknüpften Anforderungen und den Abnahmekriterien des Vorgangs zu finden. Sechs Elemente sind wichtig:
Ergebnisse: Beschreibe, was die Änderung bewirken soll – mit klar definierten Zielen, die ein Reviewer überprüfen kann.
Umfang: Erläutere, was dazugehört, und was nicht (dies ist genauso wichtig).
Einschränkungen: Halte die zu beachtenden Grenzen in Bezug auf Architektur, Sicherheit und Leistung fest.
Frühere Entscheidungen: Beschreibe den bereits geklärten Kontext, sodass der Agent ihn nicht erneut aufrollt.
Aufschlüsselung der einzelnen Aufgaben: Halte die einzelnen Schritte des Vorgangs fest. Diese müssen so überschaubar sein, dass sie leicht überprüfbar sind.
Abnahmekriterien: Lege die testbare Definition von "erledigt" fest, auf die der Agent hinarbeitet und anhand derer er überprüft wird. In Jira sind sie im Vorgang hinterlegt, und bei einer KI-Code-Überprüfung kann die Änderung anhand dieser Kriterien geprüft werden, bevor sie an einen Mitarbeiter weitergeleitet wird.
Wie der Vorgang zur Spezifikation in Jira wird
Ein gut formulierter Vorgang kann als Spezifikation dienen, auf deren Grundlage der Agent arbeitet und anhand derer er Sachverhalte überprüft. Die Spezifikation kann auch in einem verknüpften Dokument vorliegen – so funktionieren viele SDD-Tools. Jira ermöglicht allerdings, dass sie dort hinterlegt ist, wo der Vorgang bereits abläuft. Die Kriterien einer sinnvollen Spezifikation sind erfüllt, wenn sie die sechs oben genannten Elemente enthält. Ein einzeiliger Vorgang mit der Anweisung "Den Login-Fehler beheben" reicht nicht aus.
Die Spezifikation im Vorgang zu hinterlegen, hat einen strukturellen Vorteil: Sie befindet sich genau dort, wo die Arbeit bereits stattfindet, sodass sie im Vergleich zu einer Markdown-Datei in einem Repository, das niemand mehr öffnet, nicht so leicht zu vernachlässigen ist. Das bedeutet jedoch nicht, dass sie ein Selbstläufer ist. Es bedeutet lediglich, dass die Spezifikation und der Vorgang nie voneinander abweichen.
Alles wird gemeinsam übertragen: Zusammenfassung, Beschreibung, verknüpfte Confluence-Anforderungen und Abnahmekriterien – alles an einem Ort, den sowohl der Agent als auch der Reviewer einsehen können.
Eine Repository-Datei hingegen befindet sich abseits des Ortes, an dem der Vorgang nachverfolgt, überprüft und abgeschlossen wird. Sie ist also in dem Moment veraltet, in dem sich der Plan ändert.
Derselbe Vorgang wird zur Review-Oberfläche, sobald der Agent fertig ist – dort stimmt sich dein Team zu Anforderungen und offenen Fragen ab.
Jira erstellt Pläne mit klaren Leistungsbeschreibungen, Aufgaben und integrierten Schätzungen.
Wie Jira Planner eine strukturierte Spezifikation erstellt
Im vorherigen Abschnitt ging es um die Baseline: wie du einen Vorgang selbst in eine Spezifikation umwandelst. Jira Planner ist für komplexe Initiativen gedacht, an denen mehrere Teams beteiligt sind und bei denen es nicht praktikabel ist, jede Spezifikation von Hand zu erstellen. Das Tool beginnt mit der Initiative und unterteilt sie in strukturierte Vorgänge, jeweils mit eigener Spezifikation.
Jira Planner ist der Beschleuniger, nicht die Baseline. Die grundlegende SDD-Methode besteht aus einem klar definierten Vorgang sowie Akzeptanzkriterien, und das kann heutzutage jedes Team umsetzen. Jira Planner beschleunigt den schwierigsten Teil dieses Vorgangs: eine komplexe, mehrdeutige Anfrage in eine strukturierte Spezifikation umzuwandeln.
Bei komplexen Projekten greift Jira Planner auf den Teamwork Graph zurück – einschließlich deiner Codebasis, des Jira- und Confluence-Verlaufs sowie des Teamkontexts –, um Anforderungen zu definieren und eine strukturierte technische Spezifikation in Confluence zu erstellen, auf der Entwickler oder Programmierungsagenten aufbauen können. Ein Plan, viele Zielgruppen: für einen Menschen lesbar, für einen Agenten nützlich.
Leistungsspektrum des Tools:
Es bietet dir und deinem Team eine gemeinsame Oberfläche für die Zusammenarbeit, damit ihr euch vorab abstimmen könnt, bevor ein Agent ausgeführt wird.
Es greift auf Informationen aus deinem gesamten Arbeitskontext zurück, sodass die Spezifikation auf dem aufbaut, was dein Team bereits weiß, statt mit einem leeren Prompt zu beginnen.
Es erstellt eine Spezifikation, die für Menschen klar lesbar ist und von einem Agenten problemlos verarbeitet werden kann, sodass dasselbe Artefakt sowohl für die Überprüfung als auch für die Ausführung genutzt werden kann.
Es speichert die Spezifikation in Confluence und verknüpft sie mit dem Vorgang, sodass Absichten und Entscheidungen nachvollziehbar bleiben.
Jira Planner verwandelt vage Ideen in strukturierte, agententaugliche Spezifikationen
Jira Planner ist für den frühzeitigen Zugang verfügbar – trag dich in die Warteliste ein.
So schreibst du deine erste agententaugliche Spezifikation in Jira
Nimm dir einen Vorgang vor und wandle ihn manuell in eine agententaugliche Spezifikation um – nutze dabei die sechs Elemente als Checkliste.
Beginne mit einem Vorgang. Halte in der Beschreibung das Ergebnis, den Umfang und die Einschränkungen fest – gib nicht nur einen Titel an.
Übertrage deine Absicht in eine strukturierte Spezifikation. Das ist der eigentliche SDD-Vorgang. Wandle den vorherigen Kontext in Ergebnisse, Umfang und Einschränkungen für den Vorgang um, damit der Agent eine Definition erhält.
Schreibe überprüfbare Abnahmekriterien. Dies sind die Verträge, auf die der Agent hinarbeitet und anhand derer der Reviewer den Vorgang prüft. Die meisten Kriterien müssen oft etliche Male überarbeitet werden, bevor sie getestet werden können.
Weise alles einem Programmierungsagenten zu. Ein als sinnvolle Spezifikation formulierter Vorgang liefert dem Agenten genug Informationen, um die Implementierung umzusetzen und eine Pull-Anfrage zu erstellen, die mit dem Vorgang verknüpft ist.
Überprüfe die Pull-Anfrage anhand der Kriterien und optimiere sie dann. Präzisiere die Spezifikation dort, wo der Agent Mutmaßungen angestellt hat, und verwende das Muster beim nächsten Vorgang erneut.
Häufig gestellte Fragen zur spezifikationsgesteuerten Entwicklung
Brauche ich den Jira Planner für eine spezifikationsgesteuerte Entwicklung?
Nein. Die Baseline ist ein gut formulierter Vorgang mit Abnahmekriterien, den jedes Team heutzutage schreiben kann. Bei komplexen Vorgängen beschleunigt der Jira Planner den Prozess, indem das Tool von einem übergeordneten Plan – einer Initiative – ausgeht und diesen in strukturierte Jira-Vorgänge aufteilt, bei denen die Spezifikationen jeweils bereits ausgefüllt sind, sodass du nicht jede einzelne von Hand erstellen musst.
Was ist der Unterschied zwischen einer Spezifikation und Akzeptanzkriterien?
Die Spezifikation definiert die gesamte Änderung: Ergebnisse, Umfang, Einschränkungen und Kontext. Akzeptanzkriterien sind ein Teil davon – die testbare Definition von "erledigt", auf die der Agent hinarbeitet und anhand derer der Reviewer den Vorgang überprüft.
Reicht ein sehr guter Prompt aus?
Bei kleinen, reversiblen Vorgängen reicht dies häufig aus. Bei allem, was komplex oder schwer rückgängig zu machen ist, birgt ein Prompt die Gefahr, dass der Agent spekuliert, was du ausgelassen hast. Eine Spezifikation macht das Rätselraten überflüssig.
Sollte die Spezifikation in einer Repository-Datei oder in einem Jira-Vorgang gespeichert werden?
Die Spezifikation sollte im Vorgang hinterlegt werden, da die Arbeit dort verfolgt, überprüft und abgeschlossen wird. Dadurch ist es weniger wahrscheinlich, dass etwas aus dem Ruder läuft, als bei einer Markdown-Datei in einem Repository, das niemand mehr öffnet.
Werden die Teams durch eine spezifikationsgesteuerte Entwicklung ausgebremst?
Sie sorgt zwar zunächst für etwas mehr Aufwand, erspart aber später Nacharbeit. Bei komplexen Vorgängen zahlt sich dies unter dem Strich auf jeden Fall aus. Bei kleinen Korrekturen kannst du die Spezifikation überspringen und direkt zum Prompt übergehen.
Wann sollte ich eine Spezifikation schreiben – und wann sollte ich darauf verzichten?
Schreibe eine Spezifikation für komplexe, weitreichende oder schwer rückgängig zu machende Vorgänge – oder für alles, was echte architektonische oder sicherheitstechnische Einschränkungen mit sich bringt. Verzichte darauf, wenn es um kleine, reversible Korrekturen geht, bei denen ein kurzer Prompt schneller ist.