ALM mit Scrum: Ein praktischer Leitfaden für .NET-Teams

ALM ist nicht nur Werkzeuge — es ist eine Disziplin

Application Lifecycle Management (ALM) ist die durchgängige Disziplin, Software von der Konzeption bis zur Ausserbetriebnahme zu verwalten. Für .NET-Teams umfasst ALM die Anforderungserhebung, Architektur, Entwicklung, Tests, Deployment, Wartung und Governance — alles koordiniert durch einen definierten Prozess.

Scrum liefert das iterative Framework. ALM liefert die Disziplin. Zusammen geben sie .NET-Teams einen wiederholbaren Weg von der Idee bis zur Produktion — mit Transparenz bei jedem Schritt.

Dieser Leitfaden basiert auf über 15 Jahren Erfahrung in der Umsetzung von .NET-Projekten mit Scrum. Er behandelt den gesamten Lebenszyklus, die Werkzeugauswahl (Azure DevOps, GitHub, Visual Studio) und die Metriken, die den Liefererfolg tatsächlich vorhersagen — keine Vanity-Metriken.

Das ALM-Framework: Fünf Phasen, ein Rhythmus

ALM unterteilt die Softwarelieferung in fünf miteinander verbundene Phasen, die sich direkt auf die Scrum-Kadenz abbilden lassen:

Die zentrale Erkenntnis: ALM-Phasen sind keine sequenziellen Wasserfälle. Sie laufen innerhalb jedes Sprints parallel. Am Ende eines Sprints haben Sie funktionierende, getestete, potenziell auslieferbare Software — nicht nur „Code fertig".

Phase 1: Anforderungen & Planung, die wirklich funktioniert

Das Product Backlog: Mehr als eine Liste

Ein gesundes Product Backlog ist die Grundlage für effektives ALM. Für .NET-Teams sollte jedes Backlog-Item Folgendes enthalten:

• User Story: „Als [Rolle] möchte ich [Feature], damit [Ergebnis]."
• Akzeptanzkriterien: Spezifische, testbare Bedingungen, die „fertig" definieren. Verwenden Sie das Given/When/Then-Format zur Klarheit.
• Technische Notizen: Architekturentscheidungen, Änderungen am Datenbankschema, API-Verträge, Auswirkungen auf NuGet-Pakete.
• Schätzung: Story Points oder ideale Stunden. Wir empfehlen Story Points auf Basis von Komplexität, Aufwand und Unsicherheit — nicht von Zeit.
• Abhängigkeiten: Andere Backlog-Items, externe Services, Drittanbieter-APIs oder Infrastrukturänderungen, von denen dieses Item abhängt.

Sprint-Planung: Das Commitment-Meeting

Die Sprint-Planung besteht aus zwei Teilen:

Teil 1 — Was: Der Product Owner stellt die Backlog-Items mit der höchsten Priorität vor. Das Team stellt klärende Fragen und verhandelt den Umfang. Ergebnis: ein Sprint-Ziel — eine Ein-Satz-Zusammenfassung dessen, was der Sprint liefert.

Teil 2 — Wie: Das Team zerlegt jedes Backlog-Item in Aufgaben (typischerweise je 2-8 Stunden). Bei .NET-Projekten umfassen Aufgaben häufig: Datenbankmigration, Implementierung von API-Endpunkten, Service-Schicht, Unit-Tests, Integrationstests, Frontend-Komponente, Code-Review und Dokumentationsaktualisierung.

Zu vermeidende Planungs-Antipatterns:

• Aufgaben wie „Code für Feature X schreiben" — zu vage. Zerlegen Sie sie in konkrete Ergebnisse.
• Planung mit 100 % Kapazität — lassen Sie 20-30 % Puffer für ungeplante Arbeit, Fehler und Zusammenarbeit.
• Technische Schulden ignorieren — reservieren Sie pro Sprint mindestens ein Backlog-Item für Refactoring oder Schuldenabbau.

Phase 2: Entwicklung — wo Code auf Prozess trifft

Branch-Strategie für .NET-Teams

Wir empfehlen ein Trunk-based-Development-Modell mit kurzlebigen Feature-Branches:

master (always deployable)
  └── feature/dotnet9-migration (1-3 days)
  └── feature/payment-plugin-pix (1-3 days)
  └── fix/checkout-null-reference (hours)

Regeln:

• Branchen Sie vom neuesten master, mergen Sie spätestens innerhalb von 3 Tagen zurück.
• Ein PR pro Feature oder Fehler. Kleine PRs werden schneller reviewt und früher gemergt.
• Jeder PR muss die CI (Build + Tests) bestehen, bevor er reviewt wird.
• Verlangen Sie mindestens eine Freigabe. Alle Review-Kommentare müssen vor dem Merge bearbeitet werden.
• Squash-Merge, um die master-Historie sauber zu halten.

Code-Review-Standards für .NET

Code-Reviews sollten auf Folgendes prüfen:

• Korrektheit: Setzt der Code die Akzeptanzkriterien um? Werden Randfälle behandelt?
• Sicherheit: Keine fest codierten Geheimnisse. Eingabevalidierung. Verhinderung von SQL-Injection. Korrekte Auth-Prüfungen an Endpunkten.
• Performance: Keine N+1-Abfragen. Durchgängig asynchron. Angemessenes Caching. Connection-Pooling.
• Testbarkeit: Logik liegt in injizierbaren Services, nicht in statischen Methoden oder Controllern. Abhängigkeiten werden hinter Interfaces abstrahiert.
• Konvention: Folgt den Namenskonventionen des Projekts, der Ordnerstruktur und den Coding-Standards.

Daily Scrum: Kein Statusbericht

Das Daily Scrum ist ein Koordinationsmeeting, kein Mikromanagement-Werkzeug. Jedes Teammitglied beantwortet: Was habe ich gestern fertiggestellt, was werde ich heute fertigstellen, und was blockiert mich? Wenn ein Blocker auftaucht, löst ihn der Scrum Master — ausserhalb des Daily Scrum. Das Meeting sollte 15 Minuten dauern, nicht 45.

Phase 3: Continuous Integration — automatisieren Sie alles

Die CI-Pipeline für .NET-Projekte

Jeder Commit in einen Feature-Branch sollte Folgendes auslösen:

1. Restore: dotnet restore — löst NuGet-Abhängigkeiten auf. Cachen Sie Pakete für mehr Geschwindigkeit.
2. Build: dotnet build --configuration Release --no-restore — kompiliert mit Optimierungen. Behandeln Sie Warnungen als Fehler.
3. Test: dotnet test --no-build --configuration Release — führt alle Unit- und Integrationstests aus. Lassen Sie den Build bei einem Testfehler fehlschlagen.
4. Analyze: Führen Sie StyleCop, SonarQube oder die .NET-Analyzer aus. Blockieren Sie den Merge, wenn neue Warnungen eingeführt werden.
5. Package: Für Bibliotheken: dotnet pack. Für Anwendungen: dotnet publish. Für Docker: docker build.

Beispiel: Azure DevOps YAML-Pipeline

trigger:
  branches:
    include:
      - master
      - feature/*
      - fix/*

pool:
  vmImage: 'ubuntu-latest'

variables:
  buildConfiguration: 'Release'

steps:
- task: UseDotNet@2
  inputs:
    version: '9.x'

- script: dotnet restore
  displayName: 'Restore packages'

- script: dotnet build --configuration $(buildConfiguration) --no-restore
  displayName: 'Build solution'

- script: dotnet test --no-build --configuration $(buildConfiguration) --collect:"XPlat Code Coverage"
  displayName: 'Run tests'

- task: PublishCodeCoverageResults@1
  inputs:
    codeCoverageTool: 'Cobertura'
    summaryFileLocation: '$(Agent.TempDirectory)/**/coverage.cobertura.xml'

Build Verification Tests (BVT)

Über Unit-Tests hinaus sollten Sie eine kleine Menge von Smoke-Tests einbeziehen, die als Teil der CI laufen — prüfen Sie, ob die Anwendung startet, die Datenbank verbindet, die wichtigsten API-Endpunkte 200 zurückgeben und kritische User Journeys funktionieren. Diese fangen Umgebungs- und Konfigurationsprobleme ab, die Unit-Tests nicht sehen können.

Phase 4: Tests & Qualität — jenseits von „Es funktioniert auf meinem Rechner"

Die .NET-Testpyramide

Testprinzip: Schreiben Sie Tests auf der niedrigsten Ebene, die Ihnen Vertrauen gibt. Nicht jedes Feature braucht einen E2E-Test — eine gut getestete Service-Schicht mit Integrationstests für die Datenbankschicht fängt die meisten Fehler schneller und zuverlässiger ab als Browser-Automatisierung.

Sprint Review: Funktionierende Software demonstrieren

Der Sprint Review ist eine Demonstration funktionierender, getesteter Software — kein Foliensatz. Zeigen Sie die Features so, wie sie den Nutzern erscheinen werden. Sammeln Sie Feedback direkt. Aktualisieren Sie das Backlog auf Basis dessen, was Sie lernen. Wenn ein Feature nicht demonstrierbar ist, war es nicht fertig.

Phase 5: Release & Betrieb — von fertig zu ausgeliefert

Release-Management für .NET

Releases sollten langweilig sein — automatisiert, vorhersehbar und umkehrbar. Hier ist der Ablauf, den wir bei SplatDev verwenden:

1. Versionserhöhung: Semantische Versionierung (MAJOR.MINOR.PATCH). Erhöhen Sie die Version während des Sprints, wenn Features landen, nicht erst zum Release-Zeitpunkt.
2. Release-Branch: Aus master mit dem Versions-Tag abgezweigt. Nur Hotfixes werden in Release-Branches gemergt.
3. Staging-Deployment: Automatisiertes Deployment in eine Staging-Umgebung, die die Produktion spiegelt. Führen Sie die Regressions-Suite aus.
4. Smoke-Test: Manuelle Überprüfung kritischer Pfade im Staging. Erfassen Sie Screenshot-Belege.
5. Produktions-Deployment: Blue-Green- oder Canary-Deployment. Überwachen Sie Fehlerraten, Antwortzeiten und Business-Metriken 30 Minuten nach dem Deploy.
6. Verifizierung nach dem Deploy: Bestätigen Sie das Deployment anhand der Release-Checkliste. Aktualisieren Sie die Release Notes.

Monitoring: Wissen, bevor Ihre Nutzer es Ihnen sagen

Produktions-Monitoring ist Teil von ALM — Sie sind nicht fertig, wenn Sie deployen, sondern erst, wenn Sie bestätigt haben, dass das System gesund ist. Wichtige Metriken für .NET-Anwendungen:

• Anwendungsfehler: Unbehandelte Ausnahmen, 500er-Antworten. Sofort alarmieren.
• Antwortzeiten: P50-, P95-, P99-Latenz pro Endpunkt. Bei Verschlechterung alarmieren.
• Durchsatz: Anfragen pro Sekunde. Bei Anomalien alarmieren.
• Ressourcennutzung: CPU, Arbeitsspeicher, GC-Pausen, Thread-Pool-Erschöpfung. Achten Sie auf Lecks.
• Business-Metriken: Aufgegebene Bestellungen, verarbeitete Zahlungen, abgeschlossene Registrierungen. Das sind Ihre echten Gesundheitsindikatoren.

Verwenden Sie Application Insights (Azure), Datadog oder Prometheus + Grafana für .NET-Monitoring. Loggen Sie in ein strukturiertes Logging-System (Serilog + Seq/Elasticsearch) — debuggen Sie niemals anhand der Produktions-Konsolenausgabe.

Scrum-Metriken, die den Erfolg tatsächlich vorhersagen

Die meisten Scrum-Metriken sind Vanity. Hier sind diejenigen, die mit den Lieferergebnissen korrelieren:

Lead Time und Cycle Time

Lead Time: Zeit von der Erstellung eines Backlog-Items bis zum Deployment. Cycle Time: Zeit vom Arbeitsbeginn bis zum Deployment. Kürzer ist immer besser — es bedeutet kleinere Batches, schnelleres Feedback und weniger Work-in-Progress. Ziel: Cycle Time unter 5 Tagen für die meisten Items.

Sprint-Burndown (mit Vorsicht)

Burndown-Charts zeigen die verbleibende Arbeit gegenüber der Zeit. Ein flacher Burndown in der ersten Sprint-Hälfte, gefolgt von einem Absturz am Ende, bedeutet, dass Ihr Team die Arbeit spät fertigstellt und nicht inkrementell liefert. Der ideale Burndown ist gleichmässig — Arbeit wird über den gesamten Sprint hinweg fertiggestellt, nicht erst am Ende.

Entwichene Defekte

Fehler, die in der Produktion gefunden werden und die früher hätten abgefangen werden sollen. Dies ist die mit Abstand wichtigste Qualitätsmetrik. Wenn die Anzahl Ihrer entwichenen Defekte nicht gegen null tendiert, ist Ihre Definition of Done oder Ihre Teststrategie unzureichend.

Deployment-Frequenz

Wie oft Sie in die Produktion deployen. Elite-Performer deployen mehrmals pro Tag. Für die meisten .NET-Teams ist ein Deployment mindestens einmal pro Sprint ein gutes Ziel. Wenn Sie seltener deployen, bündeln Sie zu viel Risiko.

Sprint-Retrospektive: Feedback-Schleifen, die tatsächlich etwas verändern

Die Retrospektive ist die wichtigste Scrum-Zeremonie — und die am häufigsten übersprungene. Führen Sie sie in jedem Sprint durch. Stellen Sie drei Fragen: Was lief gut, was lief schlecht, was werden wir im nächsten Sprint ändern? Dann — und das ist entscheidend — wählen Sie EINE Massnahme aus und setzen Sie sie um. Nichts zerstört den Wert einer Retrospektive schneller, als Sprint für Sprint dieselben Probleme zu besprechen, ohne etwas zu ändern.

Tooling: Der .NET-ALM-Stack

Azure DevOps (empfohlen für Enterprise-.NET-Teams)

Azure DevOps bietet eine integrierte ALM-Suite: Azure Boards (Backlog-Management, Sprint-Planung, Boards), Azure Repos (Git-Hosting mit Branch-Richtlinien), Azure Pipelines (CI/CD mit erstklassiger .NET-Unterstützung), Azure Test Plans (manuelles und exploratives Testen) und Azure Artifacts (NuGet-Paket-Hosting). Für Teams, die bereits auf Azure sind, ist die Integration nahtlos.

GitHub + GitHub Actions (empfohlen für Open-Source- und moderne Teams)

GitHub bietet Projects für das Backlog-Management, Issues für das Work-Tracking, Actions für CI/CD und Packages für NuGet-Hosting. GitHub Advanced Security ergänzt Code-Scanning, Secret-Scanning und Dependency-Review. Für Teams, die die Tiefe von Azure Boards nicht benötigen, bietet GitHub ein einfacheres, stärker auf Entwickler ausgerichtetes Erlebnis.

Visual Studio + VS Code

Visual Studio Enterprise enthält ALM-Funktionen: Architekturdiagramme, IntelliTest (automatisierte Testgenerierung), Live-Abhängigkeitsvalidierung und Code-Clone-Erkennung. Für Teams, die diese Werkzeuge schätzen, amortisiert sich die Enterprise-Lizenz durch reduzierte Debugging-Zeit.

Erste Schritte: Ein 30-Tage-ALM-Implementierungsplan

1. Woche 1: Richten Sie Ihre Toolchain ein — Azure DevOps oder GitHub, CI-Pipeline, Test-Framework. Definieren Sie Ihre Definition of Done.
2. Woche 2: Befüllen Sie das Product Backlog. Führen Sie Ihre erste Sprint-Planung durch. Etablieren Sie den Daily-Scrum-Rhythmus.
3. Woche 3: Schliessen Sie den ersten Sprint ab. Demonstrieren Sie funktionierende Software. Führen Sie die Retrospektive durch. Messen Sie Ihre Baseline für Cycle Time und entwichene Defekte.
4. Woche 4: Deployen Sie in die Produktion (oder ins Staging, falls Richtlinien es verlangen). Prüfen Sie die Metriken. Passen Sie den Prozess auf Basis der Retrospektive an. Wiederholen.

Das Ziel ist nicht perfektes Scrum — es ist ein Prozess, der vorhersehbar und sichtbar funktionierende Software hervorbringt. Fangen Sie einfach an, messen Sie alles und verbessern Sie inkrementell.

Wie SplatDev mit ALM + Scrum liefert

Wir liefern seit 2009 .NET-Projekte — bevor Scrum Mainstream war und bevor es Azure DevOps gab. Unsere ALM-Beratungspraxis hilft Teams, die in diesem Leitfaden beschriebenen Praktiken zu übernehmen: Backlog-Management, Sprint-Disziplin, Einrichtung von CI/CD-Pipelines, Testautomatisierung und Release-Management.

Wir bieten ALM-Beratung für .NET-Teams jeder Grösse — vom 3-Personen-Startup bis zum 50-Personen-Enterprise-Team. Unsere Engagements umfassen typischerweise: Prozessbewertung, Tooling-Einrichtung, Sprint-Coaching (wir führen 2-3 Sprints gemeinsam mit Ihrem Team durch) und einen Übergang zur Eigenständigkeit.

Möchten Sie .NET-Software schneller ausliefern, mit weniger Fehlern und weniger Stress? Lassen Sie uns über Ihren aktuellen Prozess sprechen und darüber, wo ALM + Scrum die grösste Wirkung erzielen kann.

ALM-Beratung anfragen

Oder kontaktieren Sie uns: [email protected]