.projectstore / Methode / 2
Die Branche hat das längst erfunden.
Agenten haben es günstig gemacht.
ADRs, Reviews, ein Backlog, Abnahmekriterien, Verknüpfungen vom Ziel bis zum Code. Reife Engineering-Teams arbeiten seit zwanzig Jahren so. ProjectStore erfindet nichts davon.
Woher jedes Stück kommt
- 1969RFCs: Entscheidungen, aufgeschrieben und nummeriert, dann offen diskutiert.
- 1992DO-178B: In der Avionik muss jede Anforderung auf Code und auf einen Test zurückführbar sein.
- 1995Scrum: die Arbeit als Backlog, geordnet und sichtbar.
- 1999XP: User Stories und Abnahmekriterien, die sagen, wann eine fertig ist.
- 2007Kanban für Software: ein Board, das zeigt, was in Arbeit ist.
- 2011ADRs, Michael Nygard: eine kurze Datei pro Architekturentscheidung.
- jetztCoding-Agenten: Jeder Schritt dauert Minuten. Ohne die Artefakte beginnt jede Sitzung leer.
Ein Projekt, viele Hände. Dieselbe Grundlage für alle.
Ein ADR hält fest, was entschieden und was verworfen wurde. Eine Spec sagt, wie es funktionieren muss. Ein Epic und seine Stories sagen, was gebaut wird und wann jeder Teil fertig ist. Das Board zeigt, was gerade läuft.
Mit ihnen starten ein Entwickler, der morgen dazukommt, ein Reviewer aus einem anderen Team und ein Agent in einer frischen Sitzung alle mit dem Wissen der ersten Person. Darum pflegen Teams, die große Systeme bauen, diese Dokumente seit Jahrzehnten.
Der Prozess war immer wertvoll. Teuer war, dass Menschen jeden Schritt selbst ausführten.
Der Prozess funktioniert. Seine Dokumente sind das Wertvollste, was einem Unternehmen nach einem Projekt bleibt: warum das System so gebaut ist, was als fertig galt, wo jedes Feature im Code liegt. Aber wenn Menschen ihn von Hand betreiben, ist er langsam. Ein ADR zu schreiben kostet einen Nachmittag, bis zum Review vergeht eine Woche. Dokumente hinken dem Code hinterher. Das Board passt nicht mehr zur Realität. Also kürzen Teams ab, und „agil“ wird zur Ausrede, nichts aufzuschreiben.
Fehlen die Artefakte, sieht es bei Menschen und Agenten gleich aus: Geklärtes kommt wieder hoch, niemand kann sagen, warum der Code so ist, wie er ist, und jeder Neue fängt mit Raten an.
Bei Agenten ist es umgekehrt. Ein ADR schreiben, ein Epic in Stories zerlegen oder einen Diff gegen Kriterien prüfen: Das dauert bei einem Agenten Minuten, nicht Tage. Was einem Agenten fehlt, bekommen Menschen gratis: ein Gedächtnis über Sitzungen hinweg, Kontext, den sie mit Kollegen teilen, die Verbindung vom Ziel zum Code. Jede neue Sitzung beginnt leer und entscheidet neu, was längst geklärt war.
Prozess der Menschen+Tempo der Agenten=ProjectStore
ProjectStore bringt beides zusammen. Die Geschwindigkeit von Agenten macht den alten Prozess zum ersten Mal günstig. Die Dokumente dieses Prozesses liegen als Dateien neben dem Code und geben Agenten, was sie nie hatten: den Kontext des Projekts, verknüpft nach oben mit den Zielen und nach unten mit dem Code. Jeden Schritt reviewt laut Arbeitsregel ein zweiter Agent, der den Entwurf nicht geschrieben hat. Geschwindigkeit bekommt ein Gedächtnis, und das Gedächtnis eine Prüfung.
Sechs Stufen, von Hand und in ProjectStore.
| Phase | Die Praxis und ihr Alter | Von Menschen erledigt | In ProjectStore |
|---|---|---|---|
| Entscheidungwarum | ADR, Michael Nygard, 2011. Davor Architekturgremien und Design-Reviews. | Ein Nachmittag zum Schreiben, eine Woche in der Review-Warteschlange. Die verworfenen Alternativen bleiben in irgendjemandes Kopf. | Der Agent entwirft es in einer Minute. Ein separater Critic sucht nach Schwachstellen. Du gibst frei. Das Ergebnis ist eine datierte Datei, die auch festhält, was verworfen wurde. |
| Vertragwie | Spec, Design-Doc, RFC. RFCs werden seit 1969 nummeriert; Design-Docs sind in großen Unternehmen die Norm. | Braucht eine Woche zum Schreiben und ist beim Release schon veraltet. Niemand prüft, ob der Code noch dazu passt. | Eine Spec beschreibt das erwartete Verhalten als nummerierte Regeln. Ihre Abnahmepunkte gelten für jede Story, die von ihr abgedeckt wird. Eine Story kann nicht geschlossen werden, solange ihre Spec noch ein Entwurf ist. |
| Backlogwas | Product Backlog aus Scrum, 1995. User Stories aus XP, 1999. Kanban für Software, 2007. | Grooming-Meetings. Das Board entfernt sich binnen einer Woche von der Realität, weil es von Hand gepflegt wird. | Jede Story-Datei trägt ihren eigenen Status. Board, Indizes und Link-Map entstehen aus diesen Dateien. Laufen sie auseinander, baut ein Befehl sie neu auf. |
| Planwo | Technisches Design, Auswirkungsanalyse. Der Tech Lead schaut, wo das im bestehenden Code landet. | Das Wissen, wie frühere Features im Code gelandet sind, existiert nur im Kopf des Tech Leads. Der ist im Urlaub. | Der Planner schaut, wo frühere Epics im Code gelandet sind. Er sagt, wo die Änderung hingehört und was sich wiederverwenden lässt. Der Plan kommt in die Story. |
| AbnahmeNachweis | Abnahmekriterien, Definition of Done. XP und Scrum, frühe 2000er. | Ein QA-Zyklus am Sprintende. „Fertig“ per Ansage; Kriterien stichprobenartig geprüft. | Der Reviewer prüft den Diff gegen jedes Kriterium und verlangt einen Nachweis: einen Test, einen ausgeführten Befehl, eine Codezeile. Ohne Nachweis kein Abschluss. |
| NachverfolgbarkeitVerknüpfungen | Nachverfolgbarkeit von Anforderungen. Pflicht in der Avionik seit DO-178B (1992) und bei Medizinsoftware. | Eine Excel-Matrix „Anforderung → Code → Test“, die nach dem zweiten Release niemand mehr aktualisiert. | Jede Story verweist nach oben auf ihr Epic, ihre ADRs und Specs und nach unten auf ihren Code. Der Nachweis steht unter jedem Abnahmekriterium. Link-Map und Code-Map werden generiert, niemand pflegt sie von Hand. |
Die Verknüpfungen, die ein Agent gratis bekommt: vom Ziel zum Nachweis
- ZielEpicCHECKOUT · warum wir das tunepic:
- warumADRdie Entscheidung und die verworfenen Optionenadr: [ ]
- wieSpecdas erwartete Verhaltenspecs: [ ]
- wasStoryPlan und Abnahmekriteriencode_refs:
- woCodesrc/billing/cards/ · wo frühere Epics schon liegen— Nachweis:
- BelegNachweistests/cards.test.ts:58 · je Kriterium
Die Verknüpfungen stehen im Kopf jeder Datei, und der Nachweis ist eine Zeile unter jedem Abnahmekriterium. All das trägt der Agent bei der Arbeit ein. Die Link-Map zeigt, womit jedes Dokument verbunden ist. Die Code-Map zeigt, wo der Code jedes Epics liegt. Eine neue Sitzung, ein neues Modell oder ein neuer Kollege startet von dieser Kette aus, nicht bei null.
Install the projectstore plugin from https://github.com/SmartAndPoint/ProjectStore and set it up for this project.