Stufe 2 – Team-Standard
Ziel: Nachhaltige, wartbare Lieferung für echte Produkte.
Stufe 2 ist der professionelle Normalmodus für Software, die länger lebt als ein Experiment oder MVP.
Sie ermöglicht:
- planbare Weiterentwicklung
- parallele Teamarbeit
- beherrschbare Wartungskosten
Ohne Stufe 2 ist Skalierung organisatorisch nicht stabil möglich.
Abgrenzung
| Stufe 1 | Stufe 2 | Stufe 3 | |
|---|---|---|---|
| Lebensdauer | Wochen/Monate | ≥ 6 Monate | Mehrjährig |
| Produktivbetrieb | begrenzt | stabil | stabil + SLA |
| CI | optional/minimal | verpflichtend | vollautomatisiert |
| Architektur | pragmatisch | modular | strategisch dokumentiert |
| Monitoring | kaum | Basis | SLO-basiert |
Stufe 2 ist der erste Level, der systematisch wartbar ist.
Typische Einsatzfälle
- Produkt mit 6+ Monaten Laufzeit
- Interne Plattform oder Kundenportal
- Mehrere Entwickler arbeiten parallel
- Regelmäßige Releases
Kontextbedingungen
| Faktor | Erwartung |
|---|---|
| Lebensdauer | ≥ 6 Monate |
| Risiko | Moderat |
| Teams | Mehrere Entwickler |
| Releases | Wiederkehrend |
| Betrieb | Monitoring vorhanden |
Anforderungen
- Verbindliche CI-Pipeline (Build + Lint + Tests)
- Code Reviews verpflichtend
- Automatisierte Tests für kritische Logik
- Basis-Observability
- Dokumentierte Architekturentscheidungen (ADRs)
Teststrategie (Richtwerte)
- Unit: 60–75 % auf kritischen Modulen
oder Diff-Coverage > 70 % - Integration: Smoke-Tests für Hauptschnittstellen
- E2E: 2–5 kritische E2E-Flows, reproduzierbar dokumentiert
Coverage ist Indikator – nicht Ziel.
Kritische Pfade sind maßgeblich.
Minimale Gates
- CI läuft bei jedem Merge
- Code Review mit mindestens 1 Approver
- Tests für kritische Module vorhanden
- Linting & Formatting enforced
- Security-Scan ohne Critical Issues
- Basis-Monitoring aktiv (Logs + Error Tracking)
- Backup & Restore getestet
Diese Gates sind nicht optional, wenn Stufe 2 beansprucht wird.
Praktiken
- Modulare Architektur mit klarer Ownership
- Reproduzierbare Deployments (mindestens Staging)
- Strukturierte Logs und Error Tracking
- ADRs für relevante Architekturentscheidungen
- Klare Definition of Done
Rollen
- Tech Lead (verbindliche Standards)
- Developer
- Test Engineer
- Optional: DevOps Engineer
Akzeptierte Risiken
- Nicht alle Fehler werden vor Release gefunden
- Performance ist „gut genug“, nicht optimiert
- Keine vollständige Compliance-/Audit-Absicherung
- SLOs sind implizit, nicht formal definiert
Wirtschaftlicher Kontext
Stufe 2 reduziert:
- Wartungskosten
- Koordinationsaufwand
- Rework
- Onboarding-Zeit neuer Entwickler
Der Mehraufwand gegenüber Stufe 1 amortisiert sich bei längerer Laufzeit fast immer.