Ein echtes IT-Entwicklungsprojekt – mit KI gebaut und betrieben

Bei Resultment läuft der übliche Entwicklungsprozess eines IT-Projekts – von der Anforderung bis zum Betrieb, mit Jira, Confluence, Git und automatischen Tests. Ausgeführt wird er von einem KI-Agenten; entschieden wird an zwei Toren vom Menschen. Diese Seite zeigt beides: den Prozess, in dem gearbeitet wird, und die Ergebnisse, die dabei entstanden sind.

Wie das hier läuft

Ein Prozess, zwei Säulen

Alles auf dieser Seite folgt derselben Ordnung: Ein Prozess gibt vor, wie gearbeitet wird. Darunter stehen zwei Säulen – wer die Arbeit tut und was dabei entsteht.

Prozess wie gearbeitet wird
Wer Rollen und Besetzung Was Projekte und Bausteine

Und das ist nicht am Reißbrett entstanden. Jede Regel in diesem Prozess geht auf einen konkreten Vorfall zurück – einen Test, der falsch grün war; eine Zusicherung, die ihren Nachweis verlor; zwei Sitzungen, die sich gegenseitig überschrieben. Was hier steht, ist die Antwort auf etwas, das schiefgegangen ist.

Es handelt sich um ein internes IT-Entwicklungsprojekt der Resultment GmbH, durchgeführt von Michael Brokmann. Alles hier Gezeigte ist im laufenden Betrieb entstanden – kein Konzept, keine Studie.

1
WIE

Der Prozess

Anforderungen als eigene Vorgänge. Ein Vorgangsfluss mit fünf Stufen und zwei Toren, an denen ein Mensch entscheidet – Freigabe und Abnahme. Vorgangsverwaltung in Jira, Wissen in Confluence. Zwei Testebenen: ein Durchstich über die echte Naht und eine Regression für den Bestand. Verifikation vor jeder Abnahme, ein Auslieferungs-Tor, das bei Rot blockiert, und tägliche Prüfläufe im Betrieb.

  • Anforderungen als eigener Vorgangstyp – dauerhafte Zusicherung statt Erledigungsvermerk
  • Fünf Statusstufen, zwei menschliche Tore: Freigabe und Abnahme
  • Refinement vor der Umsetzung, Entscheidungen zur Abstimmung statt still getroffen
  • Durchstich über echte Einstiegspunkte · Regression für den Bestand · Fall-Register
  • Verifikation als Bedingung, nicht als Absicht – belegt am Vorgang
  • Auslieferung blockiert bei rotem Test; Betrieb prüft täglich still nach
  • Vereinbarungen schriftlich: ein versioniertes Regelwerk für die Zusammenarbeit

Der Ablauf – und wie weit er trägt

Anforderung umgesetzt
Fachliches Refinement umgesetzt
Beauftragung umgesetzt
Architektur / Technisches Refinement in Planung
Umsetzung umgesetzt
Verifikation eingerichtet mit bekannter Lücke
Abnahme umgesetzt
Auslieferung eingerichtet mit bekannter Lücke
Betrieb umgesetzt

Zum Prozess →

2
WER

Die Rollen

Gearbeitet wird rollenbasiert – nicht „die KI macht das schon“. Jede Rolle eines echten IT-Projekts ist benannt und einer Besetzung zugeordnet: Mensch, KI-Agent oder deterministischer Code. Was noch niemand ausfüllt, steht als offen da. Dazu Personas, gegen die Inhalte kalibriert werden.

  • 29 Projektrollen, benannt und zugeordnet – von Product Owner bis Revision
  • Drei Besetzungsarten: Mensch, KI-Agent und deterministischer Code
  • 6 Rollen noch unbesetzt – als „in Planung“ ausgewiesen statt verschwiegen
  • Personas als Zielgruppen-Stellvertreter, gegen die Inhalte geprüft werden

Zu den Projektrollen →

3
WAS

Die Ergebnisse

Was in diesem Prozess und mit diesen Rollen entstanden ist: Werkzeuge, wiederverwendbare Bauteile und daraus zusammengesetzte Lieferergebnisse – in zwei aufeinander aufbauenden Ebenen.

  • Bausteine – wiederverwendbare Bauteile für mehrere Projekte
  • Projekte – abgeschlossene und laufende Lieferergebnisse
  • Eine Matrix zeigt, welcher Baustein in welchem Projekt steckt
B
Ebene 1 · Bausteine

Methoden, Integrationen, Werkzeuge

Wiederverwendbare Bauteile – Arbeitsweisen, Pipelines, Anbindungen, fertige Skills.

Zu den Bausteinen →
P
Ebene 2 · Projekte

Konkret umgesetzte Arbeiten

In Projekten verbinden sich die Bausteine zum konkreten Ergebnis – Webseiten, automatisierte Prozesse, Hosting, Kundenaufträge.

Zu den Projekten →