Coroid nutzt spezifikationsgesteuerte Entwicklung: Die Spezifikation begleitet ein Arbeitspaket von der Planung über das Testen bis zur Rezension, sodass jede Phase nach derselben Definition von Erfolg arbeitet.
Statt von einem Satz auszugehen und die Details beim Programmieren zu entscheiden, wandelt Coroid die Anfrage in expliziten Umfang, Ausnahmen und Akzeptanzkriterien um. Dieses Dokument wird zur einzigen Quelle der Wahrheit für den Plan, die Implementierung, die Tests und die finale Rezension.
Was ist spezifikationsgesteuerte Entwicklung?
Spezifikationsgesteuerte Entwicklung ist eine Methode zum Softwareaufbau auf Basis einer vereinbarten, prüfbaren Beschreibung des Ergebnisses. Die Spezifikation definiert, was sich ändern wird, was unverändert bleibt, welche Einschränkungen gelten und wie ein Rezensent den Erfolg der Arbeit feststellen kann.
Sie trennt zwei Entscheidungen, die leicht miteinander verwechselt werden können:
- Die Spezifikation definiert, was Erfolg bedeutet.
- Der Implementierungsplan definiert, wie dies erreicht wird.
Diese Trennung ermöglicht es Ihnen, den Umfang vor dem Entstehen des Codes zu korrigieren, ohne die Implementierung zu früh vorzuschreiben. In Coroid können Sie außerdem den optionalen SDLC-Workflow aktivieren, wenn Sie die Intention und die Spezifikation vor Beginn der Planung genehmigen möchten.
Wie der Workflow in Coroid funktioniert
- Beschreiben Sie das gewünschte Ergebnis. Geben Sie Coroid das benötigte Ergebnis, den relevanten Kontext sowie alle Einschränkungen oder Nicht-Ziele an.
- Überprüfen Sie die Spezifikation. Prüfen Sie den Umfang, die Ausnahmen und die Akzeptanzkriterien auf der Spezifikation -Reiter des Tasks.
- Genehmigen Sie den Plan. Der Architekt wandelt das vereinbarte Ergebnis in geordnete Implementierungsschritte um.
- Erstellen und überprüfen Sie. Entwickler- und QA-Agenten nutzen dieselben Kriterien, um die Änderung zu implementieren und jedes versprochene Verhalten zu beweisen.
- Überprüfen Sie den pull request. Die gelieferte Änderung überträgt den Plan, die Testergebnisse, die Erkenntnisse und die Nachweise zurück zur ursprünglichen Spezifikation.
Das Ergebnis ist die Nachvollziehbarkeit von der Produktintention bis zum Code und zu den Nachweisen, die ein menschlicher Rezensent sieht. Sehen Sie sich Wie eine Aufgabe zu einem pull request wird für den vollständigen Ausführungspfad an.
Warum dieser zusätzliche Schritt?
Eine Anweisung wie „Caching für die Benutzersuche hinzufügen“ lässt sich auf mindestens vier sinnvolle Weisen implementieren – ohne klare Definition des Erreichten. Ein Agent wählt eine davon aus. Ob er Ihre Wahl trifft, ist reiner Zufall.
Die Spezifikation macht diese Entscheidung bereits vor Beginn der Implementierung explizit – genau zu dem Zeitpunkt, an dem eine Änderung der Meinung am kostengünstigsten ist.
Sie liefert auch etwas zum Prüfen vor. Ohne Akzeptanzkriterien reduziert sich die Frage „Hat das funktioniert?“ auf „Bestehen die Tests noch?“, was eine deutlich schwächere Fragestellung ist.
Was eine Spezifikation enthält
| Teil | Was er beantwortet |
|---|---|
| Umfang | Was sich ändern wird |
| Außerhalb des Umfangs | Was bewusst nicht enthalten sein soll, damit die Änderung nicht ausuferrt |
| Akzeptanzkriterien | Woran man erkennen kann, dass es funktioniert hat |
| Kontext | Einschränkungen, Konventionen und vorherige Entscheidungen, die gelten |
Sie können ihn auf der Spezifikation -Reiter des Tasks vor Beginn der Ausführung lesen und bearbeiten. Für die Arbeitsbeschreibung und den unterstützenden Kontext, die diesen Prozess beeinflussen, sehen Sie sich Beschreiben, was Sie benötigen.
Praxisbeispiel: Von der Anweisung zur prüfbaren Spezifikation
Angenommen, die ursprüngliche Anweisung lautet:
Add caching to the user lookup so repeated requests are faster.Sie beschreibt das gewünschte Ergebnis, lässt aber wichtige Entscheidungen offen. Eine nützliche Spezifikation wandelt diese Entscheidungen in Grenzen und Prüfpunkte um:
Scope
- Cache successful user lookups by user id for 60 seconds.
- Invalidate the cached entry when the user record is updated.
Out of scope
- Do not cache failed lookups.
- Do not change the public signature of getUser.
Acceptance criteria
- Two lookups for the same user id within 60 seconds call the data source once.
- Updating that user invalidates the existing cache entry.
- A cache miss preserves the current result and error behavior.Der Plan kann nun eine Implementierung wählen, das QA-Team kann die Kriterien in Tests umwandeln und der Rezensent kann den pull request mit dem versprochenen Verhalten vergleichen.
Was gute Akzeptanzkriterien ausmacht
Sie müssen von jemandem prüfbar sein, der nicht an der ursprünglichen Absprache teilgenommen hat.
Schwach:
Caching works correctly and performance is improved.Stark:
- Repeated lookups for the same user id within 60s hit the cache, verified
by a test asserting the data source is called once across two lookups.
- Cache entries are invalidated when the user record is updated.
- A cache miss behaves identically to today, including error handling.
- No change to the public signature of `getUser`.Die zweite Version sagt dem Entwickler-Agenten, was zu bauen ist, dem QA-Agenten, was zu testen ist, und Ihnen, was Sie auf dem pull request prüfen sollen. Die erste Variante lässt all diese Entscheidungen offen.
Umfangsangaben sind genauso wichtig wie Kriterien
pull request wird am häufigsten überdimensioniert – nicht weil ein Agent seine Vorgabe überschreitet, sondern weil die Spezifikation nie angibt, wo die Vorgabe endet.
Wenn Sie nicht wollen, dass das umgebende Modul während der Bearbeitung refaktoriert wird, geben Sie das explizit an. Die Anweisung „Die Aufrufstellen dürfen nicht geändert werden“ ist eine legitime und nützliche Vorgabe.
Häufige Fehler bei Spezifikationen
| Fehler | Besserer Ansatz |
|---|---|
| Die Implementierung statt des gewünschten Ergebnisses beschreiben | Legen Sie das gewünschte Verhalten und die Einschränkungen fest – anschließend wählt der Plan die passende Implementierung aus. |
| Verwendung von Begriffen wie „schnell“, „sicher“ oder „funktioniert korrekt“ | Ersetzen Sie diese durch beobachtbare Schwellenwerte, konkrete Verhaltensweisen oder Tests. |
| Nicht-Ziele nicht erwähnen | Benennen Sie benachbarte Code-Teile, Schnittstellen oder Verhaltensweisen, die unverändert bleiben müssen. |
| Unzusammenhängende Ergebnisse kombinieren | Teilen Sie die Arbeit auf, sodass eine Aufgabe in einem überprüfbaren pull request mündet. |
| Ein Ticket kopieren, ohne Annahmen zu prüfen | Fügen Sie den Kontext sowie die Entscheidungen hinzu, die im Repository nicht ersichtlich sind. |
Falls Sie damit nicht einverstanden sind
Bearbeiten Sie die Spezifikation. Sie ist bis zum Beginn der Ausführung ein lebendiges Dokument – eine Korrektur ist weitaus kostengünstiger als die Nachbesserung des daraus resultierenden Codes.
Falls die Spezifikation zeigt, dass die Arbeit aus zwei Teilen besteht, teilen Sie sie in zwei Aufgaben auf. Eine Aufgabe sollte in einem pull request enden, das eine Person in einem Arbeitsgang überprüfen kann.
Weiterführender Weg
Bei Änderungen, die über kleine Anpassungen hinausgehen, wird die Spezifikation zur Planung. Weitere Informationen finden Sie unter Aufgaben, Pläne, Sprints und Arbeitsbereiche, wo erläutert wird, wie die Arbeit vor dem Codieren aufgeteilt und freigegeben wird.
Häufig gestellte Fragen
Ist eine Spezifikation dasselbe wie ein technisches Design?
Nein. Eine Spezifikation definiert das gewünschte Ergebnis und die Grenzen. Ein technisches Design oder Implementierungsplan beschreibt die Architektur sowie die Schritte zur Erreichung dieses Ergebnisses.
Braucht jede Änderung eine ausführliche Spezifikation?
Nein. Eine kleine, eindeutige Änderung benötigt oft nur wenige Zeilen zum Umfang und zu den Akzeptanzkriterien. Die Spezifikation soll relevante Unsicherheiten beseitigen – nicht unnötige Formalitäten hinzufügen.
Wer sollte die Spezifikation freigeben?
Die Person, die für das Ergebnis verantwortlich ist, muss bestätigen, dass Umfang und Kriterien den Teamanforderungen entsprechen. Technische, Sicherheits- oder Compliance-Verantwortliche können beteiligt werden, wenn ihre Vorgaben das Ergebnis beeinflussen.
Kann eine Spezifikation nach Beginn der Arbeit geändert werden?
Das ist möglich, doch die Änderung sollte eine neue Version erzeugen und eine Überprüfung des abhängigen Plans sowie der Arbeit auslösen. Stille Änderungen am Umfang unterbrechen die Beweiskette zwischen der Anfrage und dem fertiggestellten pull request.