Arbeitsweise — unser Playbook

Wie sieht ein Quality Gate bei uns aus? #

Ein Merge braucht: grüner Build, grüne Unit-Tests, grüne Integrationstests gegen real hochgefahrene Abhängigkeiten, grüne E2E-Tests der betroffenen Pfade und eine bestandene statische Analyse. Dazu ein Review durch eine zweite Person. Es gibt keine Ausnahme und keinen Schnellweg — auch nicht für Hotfixes; dort wird der Umfang kleiner, nicht das Gate.

Test-Driven Development #

Red/green/refactor ist verbindlicher Teamstandard, nicht Empfehlung. Der praktische Effekt ist weniger die Testabdeckung als der Entwurfsdruck: Code, der schwer zu testen ist, ist meist auch schwer zu ändern. Wer den Test zuerst schreibt, merkt das vor dem Refactoring statt danach.

Wie ist ein arc42-Dokument bei uns geschnitten? #

Nicht alle zwölf Kapitel, sondern die, die Entscheidungen tragen:

1. Kontextabgrenzung — wer redet mit dem System, über welche Schnittstelle.
2. Bausteinsicht — bis zur Ebene, auf der eine neue Person eine Änderung verorten kann; nicht tiefer.
3. Laufzeitsicht — nur für die kritischen Abläufe: Fehlerfälle, Wiederanlauf, die Pfade, an denen Zustand entsteht.
4. Querschnittskonzepte — Fehlerbehandlung, Logging, Security, Konfiguration.
5. Architekturentscheidungen — mit Begründung und verworfenen Alternativen. Dieser Teil ist der wertvollste und wird am häufigsten weggelassen.

Dokumentation ist bei uns Produktbestandteil. Sie entsteht mit dem Code, nicht danach.

Was darf ein Agent, was nicht? #

Agentengestützte Entwicklung läuft innerhalb definierter Leitplanken:

• Agenten arbeiten ausschließlich auf Issues mit Definition of Ready — Anforderung, Akzeptanzkriterien und Scope stehen vor dem ersten Commit.
• Nichts umgeht die Pipeline. Dieselben Gates wie bei handgeschriebenem Code.
• Ein separater Review-Agent prüft jede Änderung, bevor sie in den menschlichen Review geht.
• Werkzeugzugang über MCP statt Kontext im Prompt.
• Architektur, Security und Release bleiben beim Menschen. Immer.

Ausführlich im Artikel Welche Leitplanken wir Agenten setzen.

Zusammenarbeit #

Scrum oder Kanban, je nach Vorhaben, mit enger Abstimmung zu Product Ownern und Fachbereichen und kurzen Feedbackzyklen. Remote, hybrid oder vor Ort, deutschlandweit. Projektsprache Deutsch und Englisch.

Wissenstransfer #

Coaching im Team und beim Kunden, Schulungen bei Industriekunden, eigene Ausbildung seit 2012. Ein Projekt gilt bei uns nicht als gelungen, wenn nur wir es weiterbetreiben können.

Zusammenarbeitsmodelle #

• Projektentwicklung — abgegrenztes Vorhaben mit definiertem Ergebnis
• Expertenprofile / Teamverstärkung — einzelne Spezialisten in Ihrem Team
• Architektur- und Code-Reviews — punktuelle Analyse mit Handlungsempfehlungen
• KI-Enablement — agentengestützte Entwicklung in bestehende Teams einführen
• Schulungen & Workshops — zugeschnitten auf Ihr Team
• Wartung & Weiterentwicklung — langfristige Betreuung, auch für fremde Systeme