ALM met Scrum: een praktische gids voor .NET-teams

ALM is niet alleen tooling — het is een discipline

Application Lifecycle Management (ALM) is de end-to-end discipline van het beheren van software van concept tot buitengebruikstelling. Voor .NET-teams omvat ALM het verzamelen van requirements, architectuur, ontwikkeling, testen, deployment, onderhoud en governance — allemaal gecoördineerd via een gedefinieerd proces.

Scrum levert het iteratieve raamwerk. ALM levert de discipline. Samen geven ze .NET-teams een herhaalbaar pad van idee naar productie — met inzicht bij elke stap.

Deze gids is gebaseerd op meer dan 15 jaar ervaring met het opleveren van .NET-projecten met Scrum. Hij behandelt de volledige levenscyclus, keuzes in tooling (Azure DevOps, GitHub, Visual Studio) en de metrics die daadwerkelijk succesvolle oplevering voorspellen — geen ijdelheidsmetrics.

Het ALM-raamwerk: vijf fasen, één ritme

ALM verdeelt softwareoplevering in vijf onderling verbonden fasen die direct aansluiten op de Scrum-cadans:

Het belangrijkste inzicht: ALM-fasen zijn geen opeenvolgende watervallen. Ze verlopen gelijktijdig binnen elke sprint. Aan het einde van een sprint heb je werkende, geteste, potentieel te leveren software — niet alleen "code-compleet".

Fase 1: requirements & planning die echt werkt

De Product Backlog: meer dan een lijst

Een gezonde product backlog is de basis van effectieve ALM. Voor .NET-teams zou elk backlog-item het volgende moeten bevatten:

• User story: "Als [rol] wil ik [functie] zodat [resultaat]."
• Acceptatiecriteria: specifieke, testbare voorwaarden die "done" definiëren. Gebruik het Given/When/Then-format voor duidelijkheid.
• Technische notities: architectuurbeslissingen, wijzigingen aan het databaseschema, API-contracten, gevolgen voor NuGet-packages.
• Schatting: story points of ideale uren. Wij raden story points aan op basis van complexiteit, inspanning en onzekerheid — niet op tijd.
• Afhankelijkheden: andere backlog-items, externe services, third-party API's of infrastructuurwijzigingen waarvan dit item afhankelijk is.

Sprint Planning: de commitmentmeeting

Sprint planning bestaat uit twee delen:

Deel 1 — Wat: de Product Owner presenteert de backlog-items met de hoogste prioriteit. Het team stelt verhelderende vragen en onderhandelt over de scope. Uitkomst: een sprintdoel — een samenvatting in één zin van wat de sprint oplevert.

Deel 2 — Hoe: het team splitst elk backlog-item op in taken (doorgaans elk 2-8 uur). Voor .NET-projecten omvatten taken vaak: databasemigratie, implementatie van een API-endpoint, servicelaag, unittests, integratietests, frontendcomponent, code review en documentatie-update.

Anti-patronen bij planning om te vermijden:

• Taken als "Code schrijven voor functie X" — te vaag. Splits het op in specifieke deliverables.
• Planning op 100% capaciteit — laat 20-30% buffer voor ongepland werk, bugs en samenwerking.
• Technische schuld negeren — reserveer per sprint minstens één backlog-item voor refactoring of het verminderen van schuld.

Fase 2: ontwikkeling — waar code en proces samenkomen

Branchstrategie voor .NET-teams

Wij raden een trunk-based ontwikkelmodel aan met kortlevende feature branches:

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

Regels:

• Branch vanaf de laatste master en merge binnen maximaal 3 dagen terug.
• Eén PR per functie of bug. Kleine PR's worden sneller gereviewd en eerder gemerged.
• Elke PR moet slagen voor CI (build + tests) vóór de review.
• Vereis minstens één goedkeuring. Alle reviewopmerkingen moeten vóór de merge worden verwerkt.
• Gebruik squash-merge om de historie van master schoon te houden.

Code-reviewstandaarden voor .NET

Code reviews moeten controleren op:

• Correctheid: implementeert de code de acceptatiecriteria? Worden randgevallen afgehandeld?
• Beveiliging: geen hardcoded secrets. Invoervalidatie. Preventie van SQL-injectie. Correcte auth-controles op endpoints.
• Performance: geen N+1-queries. Overal async. Passende caching. Connection pooling.
• Testbaarheid: logica zit in injecteerbare services, niet in statische methoden of controllers. Afhankelijkheden zijn geabstraheerd achter interfaces.
• Conventie: volgt de naamgevingsconventies, mapstructuur en codeerstandaarden van het project.

Daily Scrum: geen statusrapport

De daily scrum is een coördinatiemeeting, geen micromanagementinstrument. Elk teamlid beantwoordt: wat heb ik gisteren afgerond, wat rond ik vandaag af en wat blokkeert mij? Als er een blocker opduikt, lost de Scrum Master die op — buiten de daily scrum. De meeting hoort 15 minuten te duren, geen 45.

Fase 3: Continuous Integration — automatiseer alles

De CI-pipeline voor .NET-projecten

Elke commit naar een feature branch zou het volgende moeten triggeren:

1. Restore: dotnet restore — lost NuGet-afhankelijkheden op. Cache packages voor snelheid.
2. Build: dotnet build --configuration Release --no-restore — compileer met optimalisaties. Behandel waarschuwingen als fouten.
3. Test: dotnet test --no-build --configuration Release — voer alle unit- en integratietests uit. Laat de build falen bij een testfout.
4. Analyseer: voer StyleCop, SonarQube of de .NET-analyzers uit. Blokkeer de merge als er nieuwe waarschuwingen worden geïntroduceerd.
5. Package: voor libraries: dotnet pack. Voor applicaties: dotnet publish. Voor Docker: docker build.

Voorbeeld: 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)

Neem naast unittests een kleine set smoke-tests op die als onderdeel van CI draaien — verifieer dat de applicatie start, dat de database verbinding maakt, dat de belangrijkste API-endpoints 200 retourneren en dat kritieke gebruikersreizen werken. Deze vangen omgevings- en configuratieproblemen op die unittests niet kunnen zien.

Fase 4: testen & kwaliteit — verder dan "het werkt op mijn machine"

De .NET-testpiramide

Testprincipe: schrijf tests op het laagste niveau dat je vertrouwen geeft. Niet elke functie heeft een E2E-test nodig — een goed geteste servicelaag met integratietests voor de databaselaag vangt de meeste bugs sneller en betrouwbaarder op dan browserautomatisering.

Sprint Review: demonstreer werkende software

De sprint review is een demonstratie van werkende, geteste software — geen slidedeck. Toon de functies zoals ze aan gebruikers zullen verschijnen. Verzamel direct feedback. Werk de backlog bij op basis van wat je leert. Als een functie niet te demonstreren is, was hij niet done.

Fase 5: release & operations — van done naar deployed

Releasemanagement voor .NET

Releases horen saai te zijn — geautomatiseerd, voorspelbaar en omkeerbaar. Dit is de flow die we bij SplatDev gebruiken:

1. Versieverhoging: Semantic Versioning (MAJOR.MINOR.PATCH). Verhoog tijdens de sprint naarmate functies landen, niet op het moment van release.
2. Release branch: afgetakt van master met de versietag. Alleen hotfixes mergen naar release branches.
3. Staging-deployment: geautomatiseerde deployment naar een staging-omgeving die de productie weerspiegelt. Voer de regressiesuite uit.
4. Smoke-test: handmatige verificatie van kritieke paden in staging. Leg screenshotbewijs vast.
5. Productie-deployment: blue-green- of canary-deployment. Monitor foutpercentages, reactietijden en businessmetrics gedurende 30 minuten na de deploy.
6. Verificatie na deployment: bevestig de deployment aan de hand van de release-checklist. Werk de release notes bij.

Monitoring: weet het voordat je gebruikers het vertellen

Productiemonitoring is onderdeel van ALM — je bent niet klaar wanneer je deployt, je bent klaar wanneer je hebt bevestigd dat het systeem gezond is. Belangrijke metrics voor .NET-applicaties:

• Applicatiefouten: niet-afgehandelde excepties, 500-responses. Waarschuw onmiddellijk.
• Reactietijden: P50-, P95-, P99-latentie per endpoint. Waarschuw bij verslechtering.
• Doorvoer: requests per seconde. Waarschuw bij afwijkingen.
• Resourcegebruik: CPU, geheugen, GC-pauzes, uitputting van de thread pool. Let op lekken.
• Businessmetrics: geplaatste orders, verwerkte betalingen, voltooide aanmeldingen. Dit zijn je echte gezondheidsindicatoren.

Gebruik Application Insights (Azure), Datadog of Prometheus + Grafana voor .NET-monitoring. Log naar een gestructureerd loggingsysteem (Serilog + Seq/Elasticsearch) — debug nooit vanuit de productieconsole-uitvoer.

Scrum-metrics die succes daadwerkelijk voorspellen

De meeste Scrum-metrics zijn ijdelheid. Dit zijn de metrics die correleren met opleverresultaten:

Lead time en cycle time

Lead time: de tijd van het aanmaken van een backlog-item tot de deployment. Cycle time: de tijd van de start van het werk tot de deployment. Korter is altijd beter — het betekent kleinere batches, snellere feedback en minder onderhanden werk. Doel: cycle time onder 5 dagen voor de meeste items.

Sprint burndown (met voorzichtigheid)

Burndowncharts tonen resterend werk tegenover tijd. Een vlakke burndown gedurende de eerste helft van de sprint gevolgd door een instorting aan het einde betekent dat je team het werk laat afrondt en niet incrementeel oplevert. De ideale burndown is gestaag — werk wordt gedurende de hele sprint afgerond, niet alleen aan het einde.

Ontsnapte defecten

Bugs die in productie worden gevonden en die eerder hadden moeten worden opgemerkt. Dit is de allerbelangrijkste kwaliteitsmetric. Als je aantal ontsnapte defecten niet richting nul beweegt, schiet je Definition of Done of je teststrategie tekort.

Deploymentfrequentie

Hoe vaak je naar productie deployt. Elite presteerders deployen meerdere keren per dag. Voor de meeste .NET-teams is minstens één keer per sprint deployen een goed doel. Als je minder vaak deployt, verpak je te veel risico in één keer.

Sprint Retrospective: feedbackloops die echt dingen veranderen

De retrospective is de belangrijkste Scrum-ceremonie — en de meest overgeslagen. Voer hem elke sprint uit. Stel drie vragen: wat ging goed, wat ging slecht, wat gaan we de volgende sprint anders doen? Kies dan — cruciaal — ÉÉN actiepunt en voer het uit. Niets doodt de waarde van een retrospective sneller dan sprint na sprint dezelfde problemen bespreken zonder verandering.

Tooling: de .NET ALM-stack

Azure DevOps (aanbevolen voor enterprise .NET-teams)

Azure DevOps biedt een geïntegreerde ALM-suite: Azure Boards (backlogbeheer, sprint planning, boards), Azure Repos (Git-hosting met branch policies), Azure Pipelines (CI/CD met eersteklas .NET-ondersteuning), Azure Test Plans (handmatig en exploratief testen) en Azure Artifacts (hosting van NuGet-packages). Voor teams die al op Azure zitten, is de integratie naadloos.

GitHub + GitHub Actions (aanbevolen voor open-source- en moderne teams)

GitHub biedt Projects voor backlogbeheer, Issues voor werkregistratie, Actions voor CI/CD en Packages voor NuGet-hosting. GitHub Advanced Security voegt code scanning, secret scanning en dependency review toe. Voor teams die de diepgang van Azure Boards niet nodig hebben, biedt GitHub een eenvoudigere, meer op developers gerichte ervaring.

Visual Studio + VS Code

Visual Studio Enterprise bevat ALM-functies: architectuurdiagrammen, IntelliTest (geautomatiseerde testgeneratie), live dependency validation en detectie van gedupliceerde code. Voor teams die deze tools waarderen, verdient de Enterprise-licentie zichzelf terug in verminderde debugtijd.

Aan de slag: een 30-daags ALM-implementatieplan

1. Week 1: zet je toolchain op — Azure DevOps of GitHub, CI-pipeline, testframework. Definieer je Definition of Done.
2. Week 2: vul de product backlog. Voer je eerste sprint planning uit. Vestig het ritme van de Daily Scrum.
3. Week 3: rond de eerste sprint af. Demonstreer werkende software. Voer de retrospective uit. Meet je nulmeting voor cycle time en ontsnapte defecten.
4. Week 4: deploy naar productie (of staging als het beleid dat vereist). Bekijk de metrics. Pas het proces aan op basis van de retrospective. Herhaal.

Het doel is geen perfecte Scrum — het is een proces dat voorspelbaar en zichtbaar werkende software oplevert. Begin eenvoudig, meet alles en verbeter incrementeel.

Hoe SplatDev levert met ALM + Scrum

We leveren al sinds 2009 .NET-projecten — voordat Scrum mainstream was en voordat Azure DevOps bestond. Onze ALM-consultingpraktijk helpt teams de praktijken uit deze gids te adopteren: backlogbeheer, sprintdiscipline, het opzetten van CI/CD-pipelines, testautomatisering en releasemanagement.

We bieden ALM-consulting voor .NET-teams van elke omvang — van een startup van 3 personen tot een enterpriseteam van 50 personen. Onze trajecten omvatten doorgaans: procesbeoordeling, het opzetten van tooling, sprintcoaching (we draaien 2-3 sprints naast je team mee) en een overgang naar zelfredzaamheid.

Wil je .NET-software sneller opleveren, met minder bugs en minder stress? Laten we praten over je huidige proces en waar ALM + Scrum de grootste impact kunnen maken.

Vraag ALM-consulting aan

Of neem contact met ons op: [email protected]