Indem Sie das Backlog als Warteschlange kleiner, gut beschriebener Aufgaben behandeln. KI-Agenten können Tickets aus einem Jira-Backlog nacheinander übernehmen, jede Änderung auf einem eigenen Branch umsetzen und einen Pull Request öffnen, während Menschen die wichtigen Entscheidungen behalten. Entscheidend ist weniger der Agent als die Reife Ihrer Tickets.
Zuerst das Backlog sortieren
Agenten brauchen kein perfektes Backlog, aber Tickets, die sie abschließen können. Wer das Backlog vorab in vier Gruppen sortiert, erspart sich die meisten verschwendeten Läufe.
| Art des Tickets | An einen Agenten geben? | Was zuerst zu tun ist |
|---|---|---|
| Klares Ergebnis, kleiner Umfang, prüfbar | Ja | So übergeben. |
| Gute Idee, vage Beschreibung | Noch nicht | Ergänzen, was „fertig“ heißt, und den Code-Bereich nennen. |
| Zwei Aufgaben in einem Ticket | Nein | In zwei Tickets aufteilen. |
| Braucht eine Design- oder Produktentscheidung | Nein | Erst eine Person entscheiden lassen, dann die Entscheidung am Ticket festhalten. |
Jira hilft bei den ersten Kandidaten. Mit der Abfragesprache JQL speichern Sie einen Filter, der Tickets nach Status, Label oder Alter auflistet, wie im JQL-Leitfaden von Atlassian beschrieben. Beginnen Sie mit einem Filter für kleine Tickets, die bereits eine klare Beschreibung haben.
So sieht ein Ticket aus, das ein Agent fertigstellen kann
Hier ein Beispiel, so geschrieben, wie ein Product Owner es in Jira schreiben würde. Es ist klein, es sagt, was „fertig“ heißt, und es nennt, wo die Arbeit stattfindet.
PAY-214: CSV-Export auf der Rechnungsseite ergänzen
Ergebnis: Ein Mitarbeiter aus der Finanzabteilung kann die gefilterte Rechnungsliste als CSV-Datei herunterladen.
Fertig, wenn: Die Datei hat dieselben Spalten wie die Tabelle, beachtet den Filter auf dem Bildschirm, und ein Test deckt eine leere Liste ab.
Bereich: die Rechnungsseite und ihre API. Nicht im Umfang: PDF-Export.
Das zu schreiben dauert etwa eine Minute. Ohne die letzten drei Zeilen muss ein Agent bei diesem Ticket raten, und aus Raten entsteht Nacharbeit.
Ein Ticket, Schritt für Schritt
So durchläuft PAY-214 die neun Stufen der Dutopilot-Pipeline: Architect, Planner, Implementer, Gate, drei Reviewer, Autofixer und QA. Vor der ersten Stufe legen Menschen einmal pro Projekt die Freigabepunkte fest und das Ticket wird übernommen. Nach der letzten gibt eine Person das Release in Produktion frei.
| Schritt | Was der Agent tut | Was Sie sehen |
|---|---|---|
| Vor den Stufen: Aufnahme | Liest PAY-214 und die verlinkte Design-Seite und bestätigt, dass das Ticket bereit ist. | Ein Kommentar, dass das Ticket aufgenommen wurde und bereit ist. |
| 1. Architect | Schlägt vor, welche Dateien sich ändern (die Rechnungsseite und der Export-Endpoint), wie die Daten fließen und welche Tests dazukommen. | Der Plan als Kommentar. Eine benannte Person gibt ihn frei, bevor Code geschrieben wird. |
| 2. Planner | Macht aus dem freigegebenen Plan eine geordnete Aufgabenliste für den Implementer. | Die Aufgabenliste am Ticket. |
| 3. Implementer | Schreibt die Änderung auf einem eigenen Branch in einer abgeschotteten Sandbox und öffnet einen Pull Request. | Ein nach dem Ticket benannter Branch und ein Pull Request, der auf PAY-214 verweist. |
| 4. Gate | Führt Lint, Build und Tests aus und liefert ein gemeinsames Urteil. | Ein einziges Prüfergebnis am Pull Request statt vieler verstreuter Signale. |
| 5 bis 7. Drei Reviewer | Drei getrennte virtuelle Dutopilot-Teammitglieder lesen die Änderung jeweils für sich. Einer bemerkt, dass der Export den Filter auf dem Bildschirm ignoriert. | Review-Kommentare am Pull Request, geschrieben wie von einer Person aus Ihrem Team. |
| 8. Autofixer | Ein Fixer-Agent bekommt den Kommentar oder das fehlgeschlagene Log, repariert den Code, und das Gate läuft erneut. | Ein neuer Commit und ein frisches Prüfergebnis. |
| 9. QA | Wenn alle Prüfungen grün sind, wird der Pull Request unter Ihrem Branch-Schutz gemergt und erreicht Ihre Testumgebung, wo die QA das Ergebnis testet. | Das Ticket wechselt in Ihren Teststatus. |
| Nach den Stufen: Release | Wartet auf eine Person und deployt dann über dieselbe Pipeline. | Eine Anfrage zur Freigabe des Releases. |
Zwei Punkte warten standardmäßig auf eine Person: der Plan und das Produktions-Release. Alles dazwischen läuft ohne Aufsicht, und jede Stufe schreibt ins Ticket, sodass Sie die Geschichte hinterher lesen, statt dabei zu sein.
Viele Tickets gleichzeitig, ohne Kollisionen
Schwierig ist bei einem großen Backlog nicht ein einzelnes Ticket, sondern die Menge gleichzeitig. Geben Sie jedem Ticket einen eigenen Branch, lassen Sie voneinander abhängige Tickets auf das warten, was sie brauchen, und begrenzen Sie die parallelen Läufe auf das, was Ihr Team prüfen kann. Berühren zwei Tickets dieselben Dateien, laufen sie nacheinander.
Angenommen, PAY-215 ist ein Export-Button auf dem Dashboard, der den Endpoint aus PAY-214 braucht. Markieren Sie ihn in Jira als von PAY-214 blockiert: Er wartet und startet dann mit Code, der den Endpoint schon enthält. Zwei unabhängige Tickets, etwa eine Textänderung und ein neuer Bericht, laufen nebeneinander, ohne voneinander zu wissen. Vor dem Start holt sich jedes Ticket selbst den neuesten Code Ihres Hauptzweigs, daher wartet kein Ticket darauf, dass jemand einen Branch von Hand aktualisiert.
Was Sie einrichten
- Verbinden Sie Ihr Jira-Projekt und Ihren Code-Host (GitHub, GitLab, Bitbucket oder Azure DevOps).
- Wählen Sie den Ausschnitt des Backlogs für den Start, zum Beispiel ein Label oder einen gespeicherten Filter.
- Legen Sie fest, wer den Plan und das Produktions-Release freigibt und welche Codebereiche einen namentlich benannten Reviewer brauchen.
- Verbinden Sie Ihr eigenes Claude- oder Codex-Abo oder einen API-Key.
Die meisten Teams lassen ihr erstes Ticket innerhalb einer Woche laufen.
Was Ihr Forward Deployed Engineer tut
Jeder Dutopilot-Kunde bekommt einen Forward Deployed Engineer: einen Ingenieur von Dutopilot, der mit Ihrem Team arbeitet, keine Support-Warteschlange. Er schreibt nicht Ihren Produktcode. Er passt die Pipeline an Ihre bestehende Arbeitsweise an.
- Onboarding: Er verbindet Ihre Werkzeuge mit Ihnen und wählt den ersten Ausschnitt des Backlogs.
- Ticket-Reife: Er geht die ersten Tickets mit Ihrem Product Owner durch und Sie einigen sich auf eine kurze Vorlage wie die oben.
- Freigaben und Gates: Er legt fest, welche Pläne und welche Codebereiche eine Person brauchen und welche nicht, passend dazu, wie Ihr Team tatsächlich prüft.
- Erste Läufe: Er begleitet die ersten Tickets mit Ihnen und behebt, was einen Lauf aufhält.
- Laufender Betrieb: Er prüft mit Ihnen hängende Tickets und Review-Befunde und lockert oder verschärft die Gates, wie es die Daten zeigen.
So geht Dutopilot vor
Dutopilot verbindet sich mit Ihrem Jira-Backlog und arbeitet es mit seiner Pipeline aus neun Stufen ab: Es plant die Änderung, baut sie in einer abgeschotteten Sandbox, führt Tests und Qualitätsprüfungen aus, lässt sie von drei getrennten Reviewern prüfen, behebt Fehlschläge und mergt, sobald die von Ihnen gewählten Freigaben vorliegen. Jede Stufe wird ins Ticket zurückgeschrieben, sodass das Backlog stets zeigt, wo jedes Ticket steht.
Ihr Branch-Schutz und Ihre Pflicht-Reviews gelten weiter, und wir speichern nie eine Kopie Ihres Repositorys. Neben Jira arbeitet Dutopilot für das Backlog mit Linear, Notion, GitHub Issues und Azure DevOps sowie mit Slack. Der Ratgeber vom Jira-Ticket zum gemergten Pull Request zeigt ein Ticket von Anfang bis Ende.
Häufige Gründe, warum ein Lauf stockt
- Die Beschreibung enthält keine Abnahmekriterien, also muss der Agent raten, was „fertig“ heißt.
- Das Ticket vermischt zwei Aufgaben, sodass der Pull Request zu groß für ein Review wird.
- Die Tests sind langsam oder instabil, sodass niemand sagen kann, ob die Änderung funktioniert.
- Es ist keine freigebende Person benannt, also wartet ein fertiger Pull Request.
Beheben Sie das im Backlog, und die Erfolgsquote steigt, ohne dass Sie am Agenten etwas ändern.
Wo Menschen das Sagen behalten
- Vor dem Code: Eine Person entscheidet über die Architektur von allem Neuen oder Riskanten.
- Beim Merge: Eine benannte Person gibt Änderungen in den wichtigsten Bereichen frei.
- Beim Release: Das Produktions-Release folgt Ihrem eigenen Prozess.
Ergänzen Sie Freigaben, wo immer Sie eine möchten, und nehmen Sie sie zurück, wenn das Vertrauen wächst. Der Ratgeber Welche Schritte brauchen eine Freigabe erklärt, wie Sie das entscheiden.
Häufig gestellte Fragen
Brauchen KI-Agenten ein aufgeräumtes Backlog?
Nein, aber jedes Ticket, das ein Agent übernimmt, braucht ein klares Ergebnis, einen kleinen Umfang und eine Möglichkeit zur Prüfung. Lassen Sie die unfertigen Tickets im Backlog und sortieren Sie sie zuerst.
Was passiert, wenn ein Agent nicht weiterkommt?
Ein gutes Setup sorgt dafür, dass der Agent das am Ticket sagt und anhält, statt zu raten. In Dutopilot zeigt das Ticket, was blockiert und was eine Person tun kann, und eine Antwort von ihr lässt die Arbeit weiterlaufen.
Können wir unser eigenes KI-Abo nutzen?
Ja. Dutopilot läuft mit Ihrem eigenen Claude- oder ChatGPT-Konto (Codex) oder einem API-Key, mit Claude Code, Codex, OpenCode oder Oh My Pi als Coding-Agent, virtuelle Dutopilot-Teammitglieder arbeiten also unter den Bedingungen und Limits, die Sie bereits haben.
Wie lange dauert es, bis das erste Ticket läuft?
Die meisten Teams lassen ihr erstes Ticket innerhalb einer Woche laufen: Sie verbinden Backlog und Projekt, richten Dutopilot auf einen Ausschnitt des Backlogs und weiten dann schrittweise aus.