Wie CCIDE arbeitet: von der ersten Idee zur fertigen Story

Die sechs Artikel der Serie oben erklären, warum Requirements Dialogue als Methodik überhaupt existiert. Dieser Artikel erklärt etwas anderes: wie CCIDE, das Werkzeug, das diese Methodik umsetzt, tatsächlich arbeitet. Kein Für und Wider mehr, sondern ein Ablauf — Schritt für Schritt, so wie er heute läuft, mit den Lücken, die heute noch offen sind, ausdrücklich benannt statt überspielt.

Drei Stationen stehen im Zentrum: wie ein Projekt überhaupt anfängt, wie eine einzelne Anforderung zu etwas Verlässlichem wird, und wie daraus am Ende eine Story entsteht, an der tatsächlich gebaut werden kann. Alles danach — Architektur, Code-Generierung, Tests, Dokumentation — wird am Schluss nur skizziert, weil es das ehrlich verdient: nicht mehr als eine Skizze zu sein.

Wie ein Projekt anfängt

Ein Projekt in CCIDE beginnt nicht mit Code, und es beginnt auch nicht mit einer fertigen Spezifikation. Es beginnt mit Text — und zwar auf eine von zwei Arten.

Entweder tippt ein Mensch eine Anforderung nach der anderen ein, im direkten Dialog. Oder er speist ein bestehendes Konzeptdokument ein, das noch niemand strukturiert hat. Beide Wege laufen danach durch dieselbe Pipeline, nicht durch zwei getrennte. Bei der zweiten Variante übernehmen zwei Instanzen die erste Zerlegungsarbeit: Sie lesen das Dokument und brechen es in einzelne, atomare Anforderungskandidaten herunter — jeder Satz, jede Absicht, jede implizite Erwartung wird zu einem eigenen, für sich prüfbaren Kandidaten.

Das ist der Punkt, den man leicht unterschätzt: Ein Projekt ist von der ersten Sekunde an kein einzelner Gedanke, sondern ein Bündel einzeln zu verifizierender Behauptungen darüber, was gebraucht wird. Genau das ist auch die Antwort auf eine Frage, die auf den ersten Blick trivial wirkt, es aber nicht ist — was ist eigentlich die "Ziel-App"? Die ehrliche Antwort lautet: Sie ist am Anfang nichts Fixiertes. Sie ist die Summe aller Anforderungen, die den bevorstehenden Requirements-Dialog durchlaufen und dort reif werden. Was am Ende gebaut wird, ist nicht das, was am ersten Tag im Kopf war, sondern das, was diesen Dialog übersteht.

An dieser Stelle muss auch eine Lücke offen benannt werden, statt sie zu kaschieren: Wie genau die allererste grobe Zielbeschreibung eines Projekts aussehen soll — ein freier Absatz, ein strukturiertes Formular, ein Interview vorab — ist heute noch nicht abschließend festgelegt. Was feststeht, ist der Moment danach: Sobald Text da ist, egal in welcher Form, läuft er durch dieselbe geprüfte Pipeline wie jede einzelne spätere Anforderung. Genau diese Pipeline ist Thema des nächsten Abschnitts.

Der Requirements-Dialog: wie aus einem Satz eine geprüfte Anforderung wird

Jeder einzelne Anforderungskandidat durchläuft denselben Kernmechanismus, unabhängig davon, ob er aus dem Freitext-Dialog oder aus einem importierten Dokument stammt. Zwei Rollen tragen diesen Mechanismus, und sie tun bewusst nicht dasselbe.

Der Refiner führt das eigentliche Gespräch. Er stellt Pflichtfragen — wer genau leidet heute unter dem, was fehlt; was passiert, wenn diese Anforderung nicht umgesetzt wird; was der kleinste Ausschnitt ist, der bereits echten Wert liefert; woran man Erfolg erkennt. Entscheidend ist dabei nicht, dass ein Feld ausgefüllt wird, sondern dass die Antwort inhaltlich trägt. Eine Antwort, die nur die Frage in anderen Worten wiederholt, zählt als unbeantwortet — Formvollständigkeit kauft keine Substanz. Wirkt eine Antwort plausibel, aber unbelegt, fragt der Refiner gezielt nach der Quelle der Behauptung, statt sie einfach zu übernehmen.

Jede Antwort, die auf diesem Weg entsteht, bekommt einen von vier möglichen epistemischen Zuständen zugewiesen:

• STATED — explizit vom Menschen bestätigt, in exakt der Formulierung, die zur Bestätigung vorlag.
• DERIVED — logisch aus bereits bestätigten Aussagen abgeleitet, nicht selbst noch einmal einzeln gefragt.
• ASSUMED — eine Arbeitsannahme, die weiterverwendet wird, aber offen als unbestätigt markiert bleibt.
• PROPOSED — ein Vorschlag des Refiners selbst, der noch auf eine Reaktion wartet.

Der Übergang von ASSUMED oder PROPOSED zu STATED ist an eine feste Regel gebunden, intern UX-24 genannt: Eine Bestätigung — ein "passt", ein "ja" — zählt nur dann, wenn genau die Formulierung, die bestätigt wird, unmittelbar vorher sichtbar angezeigt wurde. Man kann also nicht im Verlauf eines langen Gesprächs pauschal "ja, alles gut" sagen und damit fünf verschiedene, über den Dialog verteilte Annahmen gleichzeitig zu Fakten erklären. Diese Regel gilt nicht nur für das Produkt gegenüber seinen künftigen Nutzern — sie gilt auch für den Refiner selbst, im Umgang mit CCIDEs eigenem Anforderungskorpus.

Der Challenger übernimmt danach eine andere Aufgabe. Er bekommt das fertige Ergebnis des Refiner-Gesprächs, aber nicht dessen Entstehungskontext — er ist eine strukturell frische Instanz, ohne Erinnerung an den Dialog, der gerade stattgefunden hat. Diese Frische ist kein Nebeneffekt, sondern der eigentliche Punkt: Wer selbst formuliert hat, neigt dazu, die eigene Formulierung für plausibler zu halten, als sie ist — ein Ankereffekt, dem menschliche Review-Prozesse notorisch unterliegen, weil derselbe Kopf, der etwas geschrieben hat, es hinterher auch prüfen soll. Eine strukturell getrennte, kontextlose Instanz hat dieses Problem nicht, weil sie gar keinen eigenen Ankerpunkt mitbringt. Der Challenger stuft die neue Anforderung gegen den bestehenden Korpus ein: neu, verfeinert Bestehendes, widerspricht Bestehendem, oder ist ein Duplikat. Bei einem echten Widerspruch stoppt der Prozess sofort, auch mitten in einem größeren Stapel — Widersprüche werden nicht gesammelt und am Ende auf einmal aufgelöst.

Erst wenn eine Anforderung diese Prüfung besteht, gilt sie als reif. Und nur eine reife Anforderung darf überhaupt zum Ausgangspunkt für den nächsten Schritt werden: die Zerlegung in Epics, Features und Stories.

An dieser Stelle noch eine Ehrlichkeit, die zum Prinzip selbst gehört: Der genaue Wortlaut, mit dem Provenienz-Regeln zwischen einzelnen Behauptungen — etwa welche Kette von STATED- und DERIVED-Aussagen eine bestimmte Schlussfolgerung überhaupt trägt — im Detail formalisiert sind, befindet sich selbst gerade in Überarbeitung. Das Grundprinzip steht seit Monaten fest und ist praktisch erprobt; die letzte Verfeinerung der Formulierung ist es nicht.

Von der reifen Anforderung zur Story

Eine reife Anforderung ist noch keine Story. Sie ist der Ursprung, aus dem eine Hierarchie von genau drei Ebenen entsteht: Epic, Feature, Story — nicht mehr, auch dann nicht, wenn eine vierte Ebene verlockend wirkt. Wird eine Story zu groß, wird sie großzügiger geschnitten, nicht weiter unterteilt.

Diese Zerlegung entsteht nicht, indem eine einzelne Instanz einen Vorschlag macht und ihn abnickt. Sie entsteht im sogenannten Top-down-Ping-Pong: zwei simulierte Architektenrollen, die sich denselben Gegenstand aus unterschiedlichen Blickwinkeln vorlegen — mit einer harten Regel, die sich in der Praxis als das Kernstück des ganzen Mechanismus erwiesen hat. Jede Seite muss mindestens einen echten Einwand einbringen. Keine Bestätigungsschleife, kein gegenseitiges Zunicken. Verworfene Alternativen werden dokumentiert, Abweichungen von übergeordneten Vorgaben werden ausdrücklich markiert statt stillschweigend übernommen, und Querbeziehungen zwischen Epics oder Features werden benannt, sobald sie auftauchen.

Jede Zerlegung wird als eigene, durchnummerierte Version festgehalten (decomposition.v1.md, v2.md, und so weiter) — nichts wird überschrieben, nur ergänzt, dasselbe additive Prinzip, das auch für den Anforderungskorpus selbst gilt. Zu jedem Epic- oder Feature-Durchlauf gehört zusätzlich eine kurze REVIEW-SUMMARY.md: Ergebnis auf einen Blick, strittige Punkte, Abweichungen, offene Entscheidungen — getrennt von den Punkten, die ohnehin regulär auf später verschoben werden.

Zwischen den Ebenen gilt eine Kopplungsregel, die im ersten Moment unlogisch wirkt, es aber nicht ist: Die Epic-Ebene darf im Stapel abgearbeitet werden, weil sie lose gekoppelt ist. Der Übergang von Feature zu Story dagegen nicht — er läuft eins nach dem anderen, mit einer Freigabe zwischen jedem einzelnen Schritt, weil hier die einzelnen Teile tatsächlich aufeinander aufbauen. Und egal wie weit ein Durchlauf trägt: Nach jedem zugeteilten Umfang steht ein harter Stopp. Kein automatischer Sprung in die nächste Ebene, keine Fortsetzung ohne ausdrückliche Freigabe.

Welches Epic oder Feature zuerst an der Reihe ist, wenn mehrere gleichrangig zur Wahl stehen, folgt ebenfalls einer Regel und nicht dem Zufall — allerdings einer, die selbst schon einmal korrigiert werden musste. Ursprünglich zählte schlicht, wie oft ein Kandidat in anderen Zerlegungen referenziert wurde. Das erwies sich als zu grob: Ein Kandidat, der sich selbst in eigenen Folgeentscheidungen wiederholt zitierte, konnte sich damit künstlich nach vorne schieben. Heute zählen nur noch gerichtete, bestätigte Verweise von aktuell offenen Nachbarkandidaten auf derselben Ebene, ergänzt um eine zweite, gleichrangige Größe: wie teuer ein Fehler an dieser Stelle wäre, verglichen mit einem Fehler an anderer Stelle. Ein Detail, das zeigt, dass auch die Regeln, die die Zerlegung selbst steuern, demselben Prinzip unterliegen wie die Anforderungen, die sie zerlegen — sie werden geprüft, korrigiert, und die Korrektur wird sichtbar dokumentiert statt verschwiegen.

Auch dieser Teil hat einen aktuellen, sehr konkreten Beleg dafür, dass die Methodik ernst gemeint ist, statt nur behauptet zu werden: Der bisherige Epic/Feature/Story-Baum von CCIDE selbst — sechs Epics, 86 Stories — wurde vor kurzem als überholt markiert. Nicht gelöscht, aber nicht mehr Zielstruktur. Der Grund ist genau der Punkt, um den es in diesem Artikel geht: Diese 86 Stories entstanden, bevor der hier beschriebene Requirements-Dialog auf CCIDE selbst angewendet wurde. Sie ruhen also auf keiner geprüften Anforderungsgrundlage, sondern auf einer, die diesen Prozess nie durchlaufen hat. Statt das rückwirkend zu heilen, wird der fehlende Anforderungskorpus gerade neu und vollständig aufgebaut, bevor die Zerlegung ein zweites Mal beginnt — dieselbe Konsequenz, die auch von jedem anderen Projekt verlangt würde, das CCIDE einmal verwaltet.

Was danach kommt — bewusst nur skizziert

Aus einer fertigen Story wird irgendwann Code. Dazwischen liegen mehrere Stationen, die im Moment aktiv Form annehmen, aber noch nicht so stabil sind, dass eine detaillierte öffentliche Beschreibung ehrlich wäre: ein Architektur-Dialog, der aus dem Story-Baum ein technisches Fundament ableitet; eine Übersetzung dieses Fundaments in eine konkrete, ausführbare Bauanleitung; die eigentliche Code-Generierung; automatisiertes Schreiben und Ausführen von Tests; und eine Dokumentation, die sich bei Bedarf selbst aktuell hält.

Manches davon ist bereits entschieden — etwa, dass es sich um eine Browser-Anwendung handelt statt um eine separate Desktop-Installation, oder welche Datenbank-Anbindung den Anfang macht. Aber das sind Randbedingungen, keine fertige Architektur. Der eigentliche Zusammenhang zwischen Story, Datenmodell, Testabdeckung und generiertem Code — also genau der Teil, der aus einer Spezifikation ein laufendes Programm macht — wird gerade erst konzeptionell erarbeitet, mit derselben Sorgfalt, mit der auch der Requirements-Dialog und die EFS-Zerlegung entstanden sind. Hier entsteht gerade etwas — mehr lässt sich heute ehrlich nicht sagen, und alles andere wäre eine Spezifikation vorzutäuschen, die es noch nicht gibt.