--- titel: "Für Produktteams" adresse: https://anvil-coder.tech/fuer-produktteams beschreibung: "Anvil Coder ist für ein internes Produktteam ein Weg, den Backlog abzuarbeiten, ohne einzustellen: Anforderungen gehen als Aufträge hinein, fertige Repositories kommen heraus, und die Guardrails gelten dabei als Bedingung jedes einzelnen Arbeitsschritts." sprache: de --- Für Produktteams # Der Backlog löst sich, die Kontrolle bleibt Anvil Coder ist ein Weg für ein internes Produktteam, Arbeit abzugeben, ohne die Kontrolle abzugeben: Anforderungen gehen als Aufträge hinein, fertige Repositories kommen heraus, und die Guardrails gelten dabei nicht als Empfehlung, sondern als Bedingung jedes Arbeitsschritts. ## Warum Einstellen selten die Antwort ist Ein Backlog, der schneller wächst als er abgebaut wird, lässt sich durch Neueinstellungen nur verzögert lösen — und jede zusätzliche Person erhöht zunächst den Abstimmungsaufwand, bevor sie Durchsatz bringt. Die Alternative ist, die *Durchführung* zu verlagern und die Entscheidung zu behalten. Genau dafür gibt es die Freigabe-Stufen: wie viel Aufsicht ihr behaltet, ist eine Einstellung je Projekt — von *jede Aktion braucht eine Freigabe* bis *nur die folgenreichen*, und ohne gesetzte Stufe läuft der Auftrag durch. Der Übergabepunkt bleibt davon unberührt: im betriebenen Dienst kommt das Ergebnis als Entwurf eines Pull-Requests an, und auf den Hauptzweig führt ihn ein Mensch zusammen. ## Governance, die nicht im Wiki steht Jedes Team hat Architekturvorgaben. Die meisten stehen in einem Dokument, das beim Onboarding gelesen und danach vergessen wird — und die Abweichung fällt im Review auf, wenn sie schon gebaut ist. Bei Anvil Coder kann die Vorgabe Teil des Auftrags sein. Ein Stack-Profil hält Sprache, Framework, Architektur und Versionsstände fest; ist es eingerichtet, wird es in die Prompts gerendert und — noch einmal gesondert zuschaltbar — am Ende als Gate geprüft. Was von der Vorgabe abweicht, fällt dort auf, wo es entsteht. ## Wie ein Auftrag ins System kommt **Der Auslöser ist eine Story** Die Anbindung an YouTrack ist zuschaltbar; ist sie eingerichtet, genügt es, eine Story auf den Trigger-Zustand zu ziehen. Das System übernimmt sie, plant, führt aus und setzt den Zustand am Ende auf „To Verify" oder „Failed". **Barrieren statt Vertrauen** Zwischen den Phasen liegen Barrieren: eine Phase beginnt erst, wenn alle Arbeitsschritte der vorigen fertig sind. Am Ende prüft ein Konsistenz-Durchgang das Ganze gegeneinander; ein zusätzlicher Build- und Test-Durchgang ist zuschaltbar und im betriebenen Dienst an. **Aufsicht ist eine Einstellung** Wie viel Aufsicht ihr behaltet, stellt ihr je Projekt ein: von jede Aktion braucht eine Freigabe bis nur die folgenreichen, und ohne gesetzte Stufe läuft der Auftrag durch. Was auch dann gilt: im betriebenen Dienst kommt das Ergebnis als Entwurf eines Pull-Requests an, und auf den Hauptzweig führt ihn ein Mensch zusammen. **Der Stack ist ein Vertrag** Sprache, Framework, Architektur und Versionsstände lassen sich als Profil hinterlegen — ein zuschaltbares Merkmal. Ist es eingerichtet, wird das Profil vorn in die Prompts gerendert; die Gegenprüfung am Ende ist noch einmal gesondert zuschaltbar. ## Passt das zu eurem Prozess? Wenn ihr bereits mit Tickets arbeitet und Architekturvorgaben habt, ist die Frage weniger, ob es passt, als wo ihr die Gates setzen wollt. Genau das lässt sich in einem Gespräch schneller klären als hier. [Kostenlos starten](https://app.anvil-coder.tech/register)[Demo vereinbaren](https://anvil-coder.tech/demo)