KI-nativer Delivery-Prozess für Salesforce in 14 Schritten

Ein KI-nativer Delivery-Prozess für Salesforce macht das Jira-Ticket zur ausführbaren Spezifikation. Ein Agent erledigt die Fleißarbeit von der Workshop-Vorbereitung bis zum Pull Request, die Pipeline prüft deterministisch, und Personen entscheiden an fünf festen Toren: Protokoll, Spec, Code-Review, Bugs und Change Requests, Release. Der Prozess hat 14 Schritte von der ersten Anforderung bis zur Produktion. Er hält eine Kette zusammen, die klassische Projekte selten schaffen: Jede Zeile Code führt auf einen Satz zurück, den jemand beim Kunden gesagt hat. Für Hersteller ändert sich vor allem eines: Der Fachbereich sieht viel früher etwas Lauffähiges und muss dafür schneller bestätigen.

Was heißt KI-nativ in einem Salesforce-Projekt?

KI-native Delivery bedeutet, den Lieferprozess um den Agenten herum zu bauen, statt dem alten Prozess einen Coding-Assistenten hinzuzufügen. Wie sich dadurch die Teamaufstellung ändert, habe ich in KI-native Delivery: kleinere Salesforce-Teams beschrieben. Hier geht es um den Ablauf selbst. Er ist mein Zielbild: Einzelne Schritte nutze ich schon, durchgängig vom Workshop bis zur Produktion setze ich ihn im nächsten Projekt auf, und ein paar Lücken sind noch zu schließen. Er ruht auf vier Ideen:

Der Unterschied zu KI-gestützt: Dort bekommt der alte Prozess einen Coding-Assistenten, der Business Analyst tippt weiter Stories ab, und der Kunde sieht erst im Abnahmetest etwas Lauffähiges. Hier liefert der Agent Protokoll, Stories und einen Prototyp, und jede Rückmeldung wird gegen das bestätigte Protokoll eingeordnet.

Wie läuft der Prozess vom Workshop bis zur Produktion?

Der Prozess hat drei Phasen mit zusammen 14 Schritten. Jede Grafik zeigt eine Phase in drei Spuren: was Personen im Gespräch tun, was der Agent erledigt und was die Pipeline prüft. Die dunklen Balken sind die Tore, an denen eine Person verbindlich entscheidet. Die blaue Spalte rechts zeigt den Status des Jira-Tickets und wer ihn setzt: Der Agent legt Stories direkt in Jira an, die Pipeline schaltet den Status nach Validierung und Deployment selbst weiter.

Discovery: der Agent bereitet vor, Personen führen das Gespräch

Phase 1 von 3 · Discovery

1. Personen
2. Agent
3. Pipeline
4. Jira

1. 01 · AgentWorkshop vorbereitenOrg-Analyse, Agenda, Hypothesen
2. 02 · PersonenDiscovery-WorkshopKunde, BA, Architekt; Transkript läuft
3. 03 · AgentAuswertungProtokoll, Story-Entwürfe mit ZeitstempelJira: Stories angelegt · Agent
4. Stories angelegtAgent
5. Tor 1Kunde bestätigt das Protokoll
6. 04 · AgentPrototypIn einer Scratch Org, in Stunden
7. 05 · PersonenRefinement am PrototypKunde klickt durch, Transkript läuft
8. 06 · AgentStory-Diff und ImpactÄnderungen, Testfälle, MetadatenJira: Stories aktualisiert · Agent
9. Stories aktualisiertAgent
10. Tor 2BA und Architekt geben die Story freiJira: Ready for Agent · BA
11. Ready for AgentBA

Vor dem Workshop analysiert der Agent die bestehende Org: Objekte, Flows, Validierungsregeln, Berechtigungen. Daraus entwirft er Agenda, Hypothesen und gezielte Fragen, etwa: „Auf Opportunity laufen drei Flows, die sich überschneiden. Wer ist dafür fachlich zuständig?“ Der Business Analyst schärft die Agenda und streicht Hypothesen, die politisch heikel sind. Wie eine solche Org-Analyse aussieht, steht in KI-Org-Analyse: technische Schulden finden.

Im Workshop moderiert der Business Analyst und muss nicht mitschreiben. Aus dem Transkript erzeugt der Agent ein Protokoll mit Entscheidungen, offenen Fragen und Verantwortlichen sowie Entwürfe für Epics und Stories in Jira, jeweils mit Zeitstempel. Er trennt hart zwischen „Kunde hat gesagt“ und „Agent interpretiert“. Der Business Analyst kuratiert: streichen, schärfen, Fit-Gap ergänzen (Standard, Konfiguration oder Code), falsch erkannte Fachbegriffe und verwechselte Sprecher korrigieren.

Bestätigt der Kunde das Protokoll, steht die Scope-Baseline. Danach baut der Agent in Stunden einen Prototyp in einer Scratch Org, einer kurzlebigen Test-Org, mit Objekten, Feldern, Layouts und einem einfachen Flow. Im Refinement reagiert der Kunde auf etwas Echtes statt auf Papier. Der Agent schreibt danach keinen neuen Story-Satz, sondern einen Diff gegen die bestehenden Stories: „Akzeptanzkriterium 2 geändert, weil der Kunde bei 00:41:07 sagte …“, ergänzt um betroffene Metadaten, Testfälle und Impact gegen den Stand im Repository.

Bauen: der Agent programmiert, der Entwickler reviewt

Phase 2 von 3 · Bauen

1. Personen
2. Agent
3. Pipeline
4. Jira

1. 07 · AgentImplementierungPlan, Freigabe, Code und TestsJira: In Arbeit · Agent
2. In ArbeitAgent
3. 08 · AgentPull RequestBeschreibung, Jira-Link, KI-ReviewJira: In Review · Agent
4. In ReviewAgent
5. Tor 3Entwickler reviewt und merged
6. 09 · PipelineCI-ValidierungDelta als Check-Deploy, Tests, AnalyzerJira: Validiert · PipelineFehler: Agent liest das Log und fixt, höchstens 2 Versuche
7. ValidiertPipeline

Erst wenn Business Analyst und Architekt eine Story auf „Ready for Agent“ setzen, beginnt die Umsetzung. Der Agent liest das Ticket, legt einen Feature-Branch an, schreibt einen Umsetzungsplan und setzt ihn erst nach Freigabe durch den Entwickler um: Apex, Lightning Web Components oder Flow, jeweils mit Tests. Bei unklaren Anforderungen liest er die verlinkte Stelle im Transkript, statt zu raten. Er schreibt die Beschreibung des Pull Requests mit Ticket-Link und Komponentenliste, ein KI-Reviewer kommentiert vorab.

Gemergt wird nur nach dem Review durch einen Entwickler. Der Entwickler reviewt in diesem Prozess mehr, als er schreibt. Warum ich auf dieses Tor nie verzichte, steht in Warum Pull-Request-Reviews Pflicht sind.

Danach läuft die Pipeline: ein Delta-Paket mit sfdx-git-delta, ein Check-only-Deploy gegen die Integrations-Sandbox, definierte Tests und ein Code-Analyzer-Gate. Schlägt sie fehl, bekommt der Agent das Log und darf einen Fix-Commit liefern, höchstens zwei Versuche. Danach übernimmt der Entwickler. Welche Prüfungen ich für KI-Code in die Pipeline setze, beschreibe ich in Quality Gates für KI-Code.

Release: der Kunde testet, der Agent ordnet ein

Phase 3 von 3 · Release

1. Personen
2. Agent
3. Pipeline
4. Jira

1. 10 · PipelineDeploy nach UATAgent schreibt Testskripte ins TicketJira: In UAT · Pipeline
2. In UATPipeline
3. 11 · PersonenAbnahmetestKunde testet, BA begleitet
4. 12 · AgentFeedback-TriageBug, Change Request oder KlärungJira: Bug oder CR angelegt · Agent
5. Bug oder CR angelegtAgent
6. Tor 4BA und Kunde entscheiden über Bugs und CRsBugs zurück an 07, Change Requests als neue Story an 06
7. Tor 5Kunde gibt das Release freiJira: Freigegeben · Kunde
8. FreigegebenKunde
9. 13 · PipelineRelease nach ProduktionQuick Deploy der validierten IDJira: Erledigt · Pipeline
10. ErledigtPipeline
11. 14 · AgentRelease Notes und HandbuchBA liest gegen

Nach dem Merge deployt die Pipeline in die UAT-Sandbox, und der Agent schreibt Testskripte direkt aus den Akzeptanzkriterien ins Ticket. Der Kunde testet, der Business Analyst begleitet die Sessions. Jede Rückmeldung ordnet der Agent ein: Bug, wenn sie einem bestätigten Kriterium widerspricht, Change Request, wenn sie neu ist, Klärungsbedarf, wenn der Beleg fehlt. Business Analyst und Kunde bestätigen die Einordnung. Bugs gehen zurück in die Implementierung, Change Requests werden als neue Story bewertet, auch kommerziell. Scope Creep wird damit sichtbar, mit Beleg statt Bauchgefühl. Wie ein Abnahmetest mit dem Fachbereich aufgebaut ist, steht in Salesforce-UAT mit dem Fachbereich.

Nach der Freigabe rollt die Pipeline die bereits validierte Deployment-ID per Quick Deploy aus. Der Agent schreibt Release Notes und eine Anwenderhilfe in der Sprache des Fachbereichs, der Business Analyst liest gegen.

Verbindlich entscheiden nur Personen mit Namen

Agent und Pipeline entscheiden nichts Verbindliches. Jede Entscheidung, die Scope, Qualität oder Produktion betrifft, trifft eine Person mit Namen.

Wer in welcher Phase entscheidet

DiscoveryBauenRelease

KundeTorErzählt und bestätigt das ProtokollBeantwortet RückfragenTorTestet und gibt das Release frei

Business AnalystTorModeriert, kuratiert und gibt die Spec freiKlärt FachfragenTorBegleitet den Test, entscheidet über CRs

ArchitektTorSetzt Leitplanken und gibt die Spec freiPflegt die RegeldateiAchtet auf Datenmodell und Sharing

EntwicklerPrüft den PrototypTorGibt Pläne frei, reviewt und mergedÜbernimmt bei Eskalation

AgentAnalysiert, protokolliert, entwirftBaut Code und TestsTestskripte, Triage, Release Notes

PipelineNoch nicht beteiligtValidiert, setzt den Jira-StatusDeployt, setzt den Jira-Status

Für die Rollen ändert sich mehr als die Werkzeuge. Der Business Analyst schreibt weniger und entscheidet mehr; seine Kernkompetenz wird, Widersprüche zwischen Gesagtem und Gemeintem zu erkennen. Der Architekt wird zum Hüter der Regeldatei, der Markdown-Datei im Repository mit Trigger-Framework, Namenskonventionen, Sharing-Regeln und Verboten, die der Agent zu Beginn jeder Sitzung liest. Sie ist der größte Hebel für die Qualität aller Agenten-Ergebnisse, siehe KI-Regeldatei im Salesforce-Repository. Der Kunde braucht mehr Disziplin bei Bestätigungen, sonst kippt die Geschwindigkeit in Chaos.

Ein Beispiel: vom Satz im Workshop zur Release Note

Ein angenommenes Beispiel, um die Kette zu zeigen. Im Discovery-Workshop eines Maschinenbauers sagt der Vertriebsleiter bei Minute 14: „Eine Opportunity unter 10.000 Euro schließen wir nicht ab.“

• Der Agent macht daraus im Protokoll die Anforderung „Opportunity erst ab 10.000 Euro schließen“, mit Verweis auf 00:14:52, und eine Story mit diesem Akzeptanzkriterium.
• Im Refinement am Prototyp fällt dem Vertriebsleiter auf, dass verlorene Opportunities auch unter 10.000 Euro geschlossen werden müssen. Der Agent zeigt das als Diff zur Story: Die Regel gilt nur für „Closed Won“. Business Analyst und Architekt geben frei.
• Der Agent baut eine Validierungsregel auf der Opportunity, schreibt den Test für 9.999 und 10.000 Euro und verlinkt das Ticket im Commit. Der Entwickler reviewt, die Pipeline validiert und setzt das Ticket auf „In UAT“.
• Im Abnahmetest meldet eine Vertriebsmitarbeiterin, dass kleine Ersatzteilaufträge trotzdem als gewonnen gelten sollen. Der Agent ordnet das als Change Request ein, weil kein bestätigtes Kriterium eine Ausnahme vorsieht.
• Die Release Note nennt die neue Mindestsumme für gewonnene Opportunities.

Fragt ein Jahr später jemand, warum die Regel bei 10.000 Euro greift, führt die Kette in zwei Klicks zur Aussage im Workshop.

Rückverfolgung: vom Satz im Workshop zur Release Note

1. 01Satz im Transkript00:14:52: „Eine Opportunity unter 10.000 Euro schließen wir nicht ab.“
2. 02AnforderungOpportunity erst ab 10.000 Euro schließen
3. 03StoryGilt nur für Closed Won, ergänzt im Refinement am Prototyp
4. 04CommitValidierungsregel: Closed Won mit Amount < 10000 wird abgelehnt
5. 05Test9.999 Euro wird abgelehnt, 10.000 Euro geht durch
6. 06Release NoteGewonnene Opportunities brauchen mindestens 10.000 Euro

Welche Werkzeuge brauchen Sie dafür?

Der Prozess hängt an keinem bestimmten Coding-Agenten. Er braucht vier Verbindungen, Stand Oktober 2026:

• Jira als gemeinsames Ticketsystem. Agent und Pipeline laufen nicht in Jira, sie lesen und schreiben nur dieselben Tickets. Der Agent läuft beim Entwickler und greift über den Atlassian Rovo MCP Server auf Jira zu; laut Atlassian1 liest er dort auch das Development-Panel mit verknüpften Branches, Pull Requests und Commits. Die Pipeline läuft auf der Git-Plattform und setzt den Ticketstatus nach jedem Lauf selbst, damit niemand ihn von Hand pflegt.
• Zugriff auf die Sandboxes. Über die Salesforce CLI mit den Skills aus sf-skills2, das Claude-Code-Plugin von Salesforce3 oder Hosted MCP Server. Der lokale Salesforce DX MCP Server erreicht laut README am 2. November 2026 sein End of Life; was das für Ihre Partner heißt, steht in Salesforce DX MCP Server: Ende am 2. November 2026. Der Agent erreicht jede Org, an der die Salesforce CLI auf seinem Rechner angemeldet ist. Dort sind deshalb nur feste Sandbox-Aliase angemeldet, nie die Produktion.
• Eine Git-Pipeline, die ohne KI validiert und deployt, mit Produktionszugang nur für die Pipeline. Wie ich sie aufsetze, beschreibe ich unter DevOps und Release Management.
• Transkription im Tenant des Kunden, etwa über die Aufzeichnung in Teams. Einwilligung und Betriebsrat behandle ich in KI-Coding, Betriebsrat und DSGVO.

Wo stolpert der Prozess?

Im Discovery-Teil:

• Ein Transkript ist keine Wahrheit. Ein Satz im Meeting ist keine Entscheidung. Der Agent erzeugt daraus nie verbindliche Stories ohne Prüfung durch den Business Analyst.
• Kunden ohne Aufzeichnung. Dann diktiert der Business Analyst direkt nach dem Termin eine Zusammenfassung, die denselben Weg geht.
• Aufbewahrung. Transkripte nach der Abnahme löschen oder auf die bestätigten Protokolle reduzieren.

In der Salesforce-Strecke:

• Klickentwicklung. Admins bauen Flows und Layouts weiter in Sandboxes. Der Prozess braucht einen Schritt, in dem der Agent solche Änderungen abruft und committet, sonst driftet Git von der Org weg.
• Profile, Permission Sets, Destructive Changes. Die klassischen Deploy-Fallen gehören als ausdrückliche Regeln in die Regeldatei.
• Konfigurationsdaten. CPQ- und Field-Service-Setups oder Custom Settings sind kein Metadaten-Deploy und brauchen eine eigene Strecke.

Erster Schritt: die Spec-Freigabe

Fangen Sie mit dem Tor an, das am meisten spart: der Spec-Freigabe. Erst wenn diese Strecke stabil läuft, lohnt sich der Rest.

1. 01

   Spec-Freigabe

   ein Stream · BA und Architekt

   Stories so schreiben, dass ein Agent sie ohne Rückfrage umsetzen kann.

2. 02

   Messen

   im Code-Review · Entwickler

   Zählen, wie oft der Entwickler trotzdem nachfragen muss.

3. 03

   Absichern

   parallel

   Aufzeichnung und Tenant klären, jeden Produktionszugang außer dem der Pipeline sperren.

4. 04

   Ausbauen

   wenn es stabil läuft

   Prototyp und Feedback-Triage dazunehmen.

Quellen3

1. 1Atlassian (öffnet in einem neuen Tab)atlassian.com
2. 2sf-skills (öffnet in einem neuen Tab)github.com
3. 3Claude-Code-Plugin von Salesforce (öffnet in einem neuen Tab)developer.salesforce.com