Wie wir Softwareprojekte umsetzen

Kurzfassung: der Bauplan auf einen Blick

Zusammenfassung: Talent-Teams liefern in Wochenzyklen und trennen dabei sauber die tägliche Feature-Arbeit (dev), die wöchentlichen Partner-Demos (lokal oder als Preview) und die Produktionsreleases (main). Jede Codeänderung durchläuft automatisierte CI-Prüfungen und ein Peer-Review innerhalb von 48 Stunden. Wesentliche Entscheidungen werden in einem zentralen Log festgehalten, damit aus informellen Gesprächen keine vergessenen Zusagen werden.

1. Die sieben schlanken Arbeitsprinzipien

Dieser Bauplan gibt kleinen Talent-Teams (2–4 Entwicklerinnen und Entwickler) in unseren Industrieprojekten einen leichtgewichtigen, ergebnisorientierten Rahmen. Er verbindet Tempo und eigenverantwortliches Arbeiten mit produktionstauglichen Schutzmechanismen.

Die Punkte ohne Verhandlungsspielraum

• Geschützte Produktion: Direkte Pushes auf main sind deaktiviert. Nur der Delivery Lead (oder die feste Vertretung) gibt Releases frei.
• Ein Peer-Review plus CI: Kein Code gelangt ohne grüne Prüfungen und die Freigabe eines Teammitglieds in die gemeinsame Codebasis.
• Keine Secrets in Git: Eine gepflegte .env.example mit Platzhalterwerten ist die einzige Referenz im Repository.
• Feste Vertretung: Jedes Team benennt eine zweite Person mit administrativen Rechten, damit die Lieferung nicht an einer Person hängt.
• Klare Eskalation: Jede externe Abhängigkeit, die länger als 72 Stunden blockiert, wird unmittelbar beim Partner angesprochen.

2. Aufbau der Umsetzung: Entwicklung, Demo und Produktion getrennt

Damit es keine künstlichen Wartezeiten gibt, trennt dieser Bauplan Feature-Fertigstellung, wöchentliche Partner-Demos und Produktionsreleases ausdrücklich voneinander:

Drei klar getrennte Meilensteine

1. Feature fertig (Wochenzyklus): Der Pull Request erfüllt alle Akzeptanzkriterien, besteht die CI, wird von einer zweiten Person freigegeben und nach dev gemergt. Das Issue wird geschlossen.
2. Demo-bereit (Partner-Showcase): Inkremente in dev werden im wöchentlichen Partner-Sync gezeigt — per Screenshare oder über einen Preview-Build auf Abruf. Nicht jedes Wochen-Inkrement braucht ein automatisiertes Deployment.
3. Produktionsrelease (Liefermeilenstein): Bewusste Überführung eines geprüften Feature-Pakets von dev nach main für den Pilotbetrieb oder das Onboarding beim Partner.
   • Wer den PR öffnet: Eine Entwicklerin, ein Entwickler oder die feste Vertretung öffnet den Release-PR (dev → main) mit Release Notes und Versions-Tag.
   • Wer prüft und merged: Der Delivery Lead (oder die feste Vertretung) prüft die Pre-Flight-Sicherheit (Datenbank-Snapshot, Umgebungsvariablen), führt das formale Review durch und merged nach main.

2.1 Branching-Modell und Release-Fluss

3. Schlankes Kanban-Board mit fünf Spalten

Die Teams verfolgen ihre Arbeit in fünf einfachen Spalten:

3.1 Lebenszyklus einer Story

4. Pragmatisches Pairing und das 2-Tage-Review

Pairing wird im Standup vereinbart

Pairing-Zusagen entstehen im Standup, nicht nebenbei. In jedem Standup gehen Team und Delivery Lead die laufenden Stories durch und vergeben Pairing-Partner für alle Arbeiten, die definierte Risikokriterien erfüllen:

1. Risikoreiche Arbeit im Standup erkennen: Im Wochenauftakt und im Standup zur Wochenmitte werden die anstehenden Karten gesichtet und markiert:
   • Architektonische Grundlagen: Projektgerüst, gemeinsame Datenbankschemata, zentrale Schnittstellen.
   • Sicherheit und Secrets: Anmeldeprozesse, Berechtigungsprüfungen, Partner-Schnittstellen.
   • Unbekannte Technologie: Erstmalige Einrichtung einer Vektordatenbank, lokale Modellausführung, Container-Netzwerke.
   • Feststeckende Arbeit: Jede Aufgabe, die länger als 24 Stunden blockiert ist, bekommt im Standup automatisch ein Paar zugewiesen.
2. Verbindliche Zusage im Standup: Das Team legt Paar und Zeitfenster direkt fest (zum Beispiel: „Anna und Max pairen am Mittwochnachmittag zwei Stunden am Rechnungsschema.“).
3. Modulare Arbeit einzeln: Routinearbeit (CRUD-Endpunkte, UI-Komponenten nach Designvorlage, Test-Fixtures) wird einzeln erledigt. Wer mitten im Zyklus feststeckt, meldet das sofort im Teamchat oder im nächsten Standup.

Das 2-Tage-Review

• Zeitfenster: Die zugewiesene Person prüft, testet und beantwortet einen offenen Pull Request innerhalb von zwei Arbeitstagen (48 Stunden).
• Neuvergabe: Bleibt ein Review nach zwei Arbeitstagen offen, vergibt der Delivery Lead es neu oder übernimmt es selbst.
• Feste Vertretung: Jedes Projekt benennt eine zweite Person mit administrativen Rechten, die dringende Pull Requests freigeben, Secrets verwalten und Deployments koordinieren kann.

5. Kommunikation und schlankes Entscheidungslog

Kanäle

Ein einziges Entscheidungslog

Aus informellen Gesprächen dürfen keine vergessenen Zusagen werden. Das Team pflegt ein einziges Log für wesentliche Entscheidungen:

• Änderungen am Umfang oder an der Priorisierung von Meilensteinen.
• Fragen zu geistigem Eigentum oder Open-Source-Lizenzen.
• Budget, Serverkosten oder Infrastrukturabhängigkeiten beim Partner.
• Sicherheitsvorgaben und der Umgang mit sensiblen Partnerdaten.

<!-- Beispieleintrag -->### 2026-09-12: Selbst gehostete Vektordatenbank statt verwaltetem Dienst- **Kontext:** Die Sicherheitsrichtlinie des Partners verbietet die Übertragung von Lieferantennamen an externe Clouds.- **Entscheidung:** Vektordatenbank containerisiert auf dem eigenen Server mit persistentem Volume betreiben.- **Beteiligte:** Delivery Lead, Entwicklungsteam, Mentor des Partners.

6. Git-Workflow und automatisierte Qualitätsprüfungen

Branch-Standard

Standard für Pull Requests

• Feature-PRs (Ziel: dev):
  • Eröffnet von: Autor:in der Story oder dem Paar.
  • Freigegeben von: einer zugewiesenen Person (SLA: < 2 Arbeitstage).
  • Voraussetzungen: Verknüpftes Issue (Closes #14), grüne CI, Testnachweis (0 Fehler) sowie ein visueller oder technischer Funktionsnachweis. Der Merge nach dev schließt das Issue.
• Release-PRs (Ziel: main):
  • Eröffnet von: Entwicklungsteam oder fester Vertretung (mit Versions-Tag und Release Notes).
  • Geprüft und gemergt von: ausschließlich dem Delivery Lead (oder der festen Vertretung).
  • Voraussetzungen: Grüne CI, ausgeführter Datenbank-Snapshot und geprüfte Umgebungsvariablen.

7. Deployment, Sicherheit und Störungen

Damit dieser Bauplan lesbar bleibt, stehen die konkreten Serverbefehle in einem eigenen Betriebshandbuch. Die Grundsätze lauten:

1. Deployment-Rhythmus

• Wöchentliche Partner-Demos: Gezeigt werden geprüfte Inkremente aus dev, per Screenshare aus der lokalen Umgebung oder über einen Preview-Build auf Abruf. Automatische Deployments bei jedem Merge nach dev vermeiden wir bewusst — sie machen Demos instabil und verursachen unnötigen Betriebsaufwand.
• Produktion nur über main: Das automatisierte Deployment auf den Server ist formalen Releases auf main vorbehalten, abgesichert durch die Freigabe des Delivery Lead, einen Datenbank-Snapshot und eine /health-Prüfung.

2. Datenbanksicherheit

• Nur additive Migrationen: Aktive Spalten werden im selben Zyklus weder umbenannt noch gelöscht. Wir arbeiten nach dem Expand-Contract-Muster.
• Snapshot vor dem Release: Vor jeder Schema-Migration in der Produktion wird ein Backup erstellt.
• Keine reinen Code-Rollbacks: Ist eine inkompatible Migration gelaufen, genügt ein Zurücksetzen des Codes nicht — es folgt die Wiederherstellungsprozedur aus dem Betriebshandbuch.

3. Umgang mit Secrets und Notfallmaßnahmen

• Getrennte Umgebungen: Produktionsgeheimnisse liegen ausschließlich in den Umgebungsvariablen der Betriebsplattform. Lokal wird mit Sandbox-Zugängen gearbeitet.
• Keine Secrets in Git: Wurde ein Zugang versehentlich eingecheckt, wird der Schlüssel sofort beim Anbieter widerrufen — das Löschen des Commits genügt nicht. Danach folgt das Vier-Schritte-Verfahren aus dem Betriebshandbuch.

8. Besprechungsrhythmus