Eisen aan eindproject van DevOps minor

De opdrachtomschrijving voor het project in blok 2 volgt tijdens dat blok zelf. De requirements moet je 'agile' afstemmen met de klant/opdrachtgever.

De totale beoordeling bestaat uit een oordeel over jullie DevOps teamproduct en een oordeel over je individuele bijdrage op basis van je eigen verantwoording. De beoordeling over het teamproduct staat hieronder beschreven. De individuele beoordeling is volgens hetzelde model als die voor de Course BP.

Beoordeling groepscijfer

Hieronder de eisen en beoordelingscriteria voor het teamproduct. Onderstaand de 6 eisen met korte samenvatting, maar verdere secties geven de details hiervan:

• een ingevuld self assessment
  • CDMM checkpoints met toelichtingen + cijfer indicatie 5 hoofdcategorieën
• a. Omgang Technologie
  • techstack, devops tools, monitoring/metrics
• b. Jullie 'Way of Working'
  • Scrum, Storymap, etc.
• c. Build en Deployment
  • ontwikkelstraat, Azure DevOps, etc.
• d. Documentatie
  • C4, continuous documentation, ADR's, etc.
• e. Soft Skills
  • effectief Agile werken, communiceren en presenteren aan technische+niet technische stakeholders

Na de gedetailleerde beschrijving van criteria A t/m E volgt een sectie over Tech Reviews en Sprint Reviews, die de high-level werkwijze beschrijft en aangeeft hoe je tijdens het project bewijs levert voor de verschillende beoordelingscriteria.

De checkpoints gelden hierbij als vereisten en dus knock-outs voor het teamcijfer. De beoordelingsniveaus zijn beperkt tot onderstaande 5; dit ter beoordeling aan de begeleiders en opdrachtgever. Als één punt onvoldoende is, is het gehele eindcijfer een onvoldoende (e.g. het zijn knock-outs). Als er Twijfel is kun je het compenseren met Goed of Uitmuntend op andere beoordelingscriteria, om totaal boven de minimale 5.5 te komen om het project succesvol af te sluiten.

• O=knOck-out, 2.0, niet gedaan of niet aangetoond
• T=Tsja (Twijfelachtig), 4.0, twijfel of serieuze tekortkomingen
• V=Pass (Voldoende), 6.0, punt voldaan
• G=Goed , 8.0, met veel kwaliteit of kwantiteit en afgestemd met begeleiders/opdrachtgever
• U=Uitmuntend 10.0, je ging 'above and beyond' de vereisten

Self assessment

Bij je oplevering (tussentijds en eind) hoort ook een zelf als team samen opgesteld self assessment met het CDMM model (net als bij het beroepsproduct aan het einde van de course). Houdt vanaf het begin hiermee ook al in de gaten of je voldoende variatie in werkzaamheden hebt en op je 'DevOps volwassenheid'. Het CDMM is hierbij niet alleen het beoordelingsmodel, er zijn ook concretere eisen opgesteld onder de volgende vijf beoordelingscriteria A tot en met E hieronder.

A. Technologie

• ⛪ Design & Architecture
• 📈 Information & Reporting

1. Je werkt met de technologiestack zoals de klant die gebruikt (of hebt een goede onderbouwing waarom je daar van afgeweken bent)
2. De applicatie is opgedeeld in (Docker) containers en draait in een Kubernetes (cluster)
3. Je hebt monitoring ingericht die de beschikbaarheid van de (onderdelen van de) applicatie inzichtelijk maakt

B. Way of Working

• 🧑‍🤝‍🧑 Culture & Organization

1. Je hebt nauw contact met opdrachtgever/Product Owner (meer malen per week)
2. Je werkt volgens Scrum met een- of tweeweekse sprints, Scrum ceremonies en wekelijks contactmomenten
   • Elke week een Review met demo
     • met werkende software, uiterlijk week 2 à 3
     • met monitoring, uiterlijk week 3 of 4
   • Opleveren: Een overzicht van verbeterpunten uit de retrospectives (minimaal 1, liever meer, zinvolle procesverbetering per week en het resultaat van de verbetering)
3. In week 1 oriënteer je je op het project en legt je werkwijze als team vast (binnen gegeven kaders project)
   • Een Definition of Ready
   • Opleveren: Definition of Ready
4. Je week 1 maak je ook een User Story Map
   • User story map en overige zaken
   • Verdeeld in zinvolle slices die je gebruikt in de communicatie met de opdrachtgever en bijhoudt gedurende het project.
   • High level user stories met prioritering en waar mogelijk onderliggende acceptatiecriteria, persona's e.d.
   • Initiele backlog
   • Opleveren: Gevulde backlog, User story map, elke week een foto of afbeelding van de bijgewerkte map
5. Je past code reviews toe
   • Je hebt een systeem van pull requests ingericht met reviewopmerkingen in Azure DevOps (of ander gekozen Code management systeem)
   • Bij persoonlijke beoordelingen (na 4 en 8 weken) tenminste 1 review laten zien van jouw over andermans code.

C. Build en Deployment

• 🏗️ Build & Deploy

1. Je hebt na sprint 1 een 'productie omgeving' en werkt deze daarna bij
2. Je hebt na sprint 2 à 3 werkende software in productie staan en bouwt daar vervolgens op voort
3. Je denkt na over meerdere omgevingen, dus naast productie bv. een develop, QA of staging omgeving
4. Je levert vanaf sprint 5 à 6 aantoonbaar vaker op dan enkel einde sprint, middels automatische uitrol
5. Je hebt automatische tests in een build pipeline

D. Documentatie

• ⛪ Design & Architecture

1. Je hebt je product gedocumenteerd met:
   • Een goede README voor developers (volgens Microsoft richtlijnen)
   • C4-diagram: minstens een Context en Container diagram, inlcusief toelichting op elk, als documentatie van je Software Architectuur
   • Architectuurbeslissingen in de vorm van ADR’s
   • Specificaties in de vorm van given-when-then’s (Gherkin)
2. Je hebt zelf een beeld van je DevOps volwassenheid via een self assessment van het CDDM
   • met een realistisch deelcijfer/niveau op elk van de 5 categorieën
   • en per cijfer/categorie ook eigen toelichting* over hoe je 'checkpunten' hebt gehaald en waar dit zichtbaar is in eigen werk (of (net) niet hebt behaald (wellicht met goede reden),
3. Opleveren: Een overzicht van de (runtime) omgevingen, hoe ze zijn ingericht, en beheerd worden (incl. de koppeling met versiebeheer).

E. Soft skills

• 🧑‍🤝‍🧑 Culture & Organization

1. Je werkt prettig samen met de opdrachtgever en geeft een professionele indruk
2. Je werkt goed samen als team en creëert een goede werksfeer
3. Je valt de opdrachtgever niet lastig met technische details, maar kunt issues en werkzaamheden vertalen naar bedrijfstermen
4. Je schermt als team de opdrachtgever af van kleine afwijkingen van de planning
5. Maar bij grote(re) tegenslagen communiceer je tijdig, zodat opdrachtgever kan meedenken over alternatieve richtingen
6. Bij extra tijd en evt. opraken van werk denk je pro actief mee met business over mogelijk waardevolle features

Extra details 2025 Sprints

Deze sectie beschrijft de high-level Way of Working tijdens het project: hoe je door middel van gestructureerde reviews bewijs levert voor de beoordelingscriteria A t/m E hierboven.

Tijdens het project vinden er 4 Tech Reviews en 4 Sprint Reviews plaats. Deze reviews zijn gekoppeld aan de beoordelingscriteria A t/m E en helpen je om je DevOps-volwassenheid te tonen en te ontwikkelen.

I. Tech Reviews

Tech reviews vinden plaats om de week (eind week 1, 3, 5, 7) en richten zich op technische DevOps-vaardigheden. Iedere Tech Review heeft een kernopdracht en een groeidoel. Lever bewijs aan in documentatie, pipeline, K8S config of dashboards (alles in repo).

Video: Tech Review 3 – loadtesten (NotebookLM)

Korte toelichting (punten om te behandelen in TR3):

• Welk type loadtest heb je? Welke gebruikersscenario’s test je?
• Aantal gelijktijdige gebruikers dat je applicatie minimaal/maximaal aankan.
• Bottlenecks: waar zit de beperking? Hoe meet je dat? Wat is de follow-up?
• Testbeperkingen en aanvullende nuttige tests.
• Vooruitblik TR4: welke tech/onderzoek per teamlid?

Belangrijk: Dit is voorlopige planning die een goed handvat geeft, maar tech moet zoveel mogelijk in dienst staan van de opdracht (demand pull over technology push). Buiten het vaste kader van 'MSA in K8S op Azure' kan deze planning tijdens het project op basis van input van opdrachtgever/InfoSupport nog bijgewerkt worden.

Koppeling met beoordelingscriteria:

• A. Technologie: Bewijs per tech review van GitOps-werkwijze, CI/CD-pipelines, container registry, deployment tooling, monitoring/performance tooling, chaos engineering, en/of specifieke CNCF/project-relevante technologieën (tooling naar keuze)
• C. Build en Deployment: CI/CD met build, test, artefact push, geautomatiseerde deploys, GitOps-triggers, performance-teststage en tijdelijke omgevingen
• D. Documentatie: Dashboards, testresultaten en review-logboek per sprint (opdracht + evt. groeidoelen)

Opmerking: De tooling is naar keuze; de focus ligt op het aantonen van de DevOps-principes en werkwijzen, niet op specifieke tools. Overleg met je begeleiders als je alternatieve tooling wilt gebruiken.

II. Sprint Reviews

Sprint reviews vinden plaats aan het einde van iedere sprint (onderwijsweek 2, 4, 6, en 8) bij de opdrachtgever/Product Owner. In tegenstelling tot Tech reviews hebben Sprint reviews geen vaste indeling van onderwerpen, maar richten zich op de functionele voortgang en afstemming met de opdrachtgever.

In de andere week (niet de sprint review week) is er een Teams video call met de opdrachtgever voor het stellen van vragen en korte afstemming.

Koppeling met beoordelingscriteria:

• B. Way of Working: Scrum-ritme over 4 sprints met planning, review, retro en statusupdates aantoonbaar (artefacts, acties, groeiopdrachten). User story map bijhouden en refinement van user stories.
• E. Soft skills: Samenwerking met PO, InfoSupport en HAN; actieve voorbereiding reviews, reflectie op groeidoelen en professionele communicatie. Vertalen van technische zaken naar bedrijfstermen.

III. Aandachtspunten per sprint

Per sprint ben je met onder andere onderstaande zaken bezig. Deze aandachtspunten zijn een hulpmiddel, kijk zelf naar de acceptatiecriteria/werkwijze A t/m E hierboven. Qua tonen van gemaakt werk/bespreken aandachtspunten tijdens de Tech review vs. Sprint review moet je hier zelf goed over nadenken. Wie is de doelgroep. Het indelen van de punten uit het volgende lijstje hieronder hoort bij beoordelingscriterium E3.

• Sprint 1:

  • User Story Map en Domein Model opstellen
  • C4 Context model
  • Opzet applicatie met front-end en back-end en message bus
  • Evt. wireframes + API design
  • CI/CD pipeline opzetten
  • Individuele verantwoording (tenminste template hebben staan)
  • Template van CDMM staat er en vindbaar vanuit root README
  • Opzet ADR's

• Sprint 2:

  • C4 Container en meerdere Component diagrammen
  • Pipeline verbeteren (beter CD-stuk)
  • Evt. linting toevoegen + styleguides
  • Overzicht van omgevingen opstellen (zie D3)
  • Evt. code diagrammen: class diagrams, data model/database schema (waar relevant voor je domein)
  • Refinement van user stories in acceptatiecriteria
  • Afstemming van user stories op basis van feedback van opdrachtgever/PO en projectbegeleiders
  • Individuele verantwoording (template teksten weg, 1e helft van bullets per kopje, max 2 van 9 kopjes nog leeg)
  • CDMM voor ca. helft ingevuld en idee van hoe in volgende sprints naar Voldoende of hoger
  • Retrospective notulen/uitkomsten

• Sprint 3:

  • Alles verder uitbreiden
  • Documentatie van pipeline maken
  • Meer ADR's toevoegen
  • Acceptatiecriteria verder uitwerken
  • README's inrichten
  • C4-documentatie bijwerken
  • Evt. code diagrammen bijwerken/uitbreiden (class diagrams, data model, sequence diagrams waar relevant)
  • Performance/load tests implementeren (K6 of vergelijkbaar) met realistische end-to-end scenario's
  • Evt. UML sequence diagrams van kritieke flows en/of load test scenario's
  • Overzicht van omgevingen bijwerken
  • Bij begeleiders voorstel doen of uitvragen nieuw te gebruiken technologieën in Sprint 4 (per teamlid één technologie)
  • Refinement van user stories
  • Individuele verantwoording bijgewerkt
  • Retrospective notulen/uitkomsten

• Sprint 4:

  • Alles verder uitbreiden en afronden
  • Documentatie compleet maken (pipeline, ADR's, README's)
  • Meer ADR's toevoegen voor gemaakte keuzes
  • Onderzoek en implementatie van gekozen technologieën (per teamlid één: monitoring, chaos engineering, of andere relevante tech die bijdraagt aan het project)
  • Evt. BDD/Gherkin tests: .feature bestanden met acceptatietests (Cucumber, SpecFlow, Req'n'Roll o.i.d.)
  • Acceptatiecriteria finaliseren
  • C4-documentatie compleet maken
  • Evt. code diagrammen compleet maken (class diagrams, data model, sequence diagrams waar relevant)
  • Performance/load test resultaten en analyse documenteren
  • Overzicht van omgevingen compleet maken
  • Individuele verantwoording afgerond
  • Retrospective notulen/uitkomsten

Toelichting

Merk op dat de punten onder de beoordelingscriteria A. Technologie, B. Way of Working, C. Build en Deployment, D. Documentatie en E. Soft skills grofweg knock-outs zijn van het minimale verwachte werk, de te gebruiken werkwijze en de op te leveren zaken (deliverables).

De Tech Reviews en Sprint Reviews hierboven geven aan hoe je tijdens het project gestructureerd bewijs levert voor deze criteria. Voor het komen tot een concreet cijfer kijken begeleiders naar de hoeveelheid (kwantieit) en de kwaliteit van met team gemaakte product, en ook omgang en goed hanteren van Agile proces en samenwerken als team. Bedenk hierbij dat het gemaakte product een DevOps product is, dus focus niet alleen op code en functionaliteit, maar toon DevOps volwassenheid. Andersom, focus je niet alleen op pipelines, build bakeries etc. maar maak ook een product, want zonder features en requirements heb je geen DevOps nodig.

Retrospective notulen/uitkomsten: Bij elke sprint hoort een retrospective waarbij je notulen/uitkomsten vastlegt. Wissel hierbij bijvoorbeeld af tussen sterke en zwakke punten van het team (bijv. met SWOT of Sails methode) en individuele tips en tops op voor de volgende retro. Of het liefst altijd beiden natuurlijk, maar bepaal zelf wat het meest nuttig is en niet alleen overhead geeft.

Hoe naar ruim voldoende, goed, of hoger?

Voor het aantonen van hogere 'Devops volwassenheid' (en dus eindcijfer boven een 6) moet je — net als in de coursefase — het CDMM er weer bij pakken en naast de Basis, Beginner en Gemiddeld ook naar de hogere checkpunten kijken, Gevorderd en Expert. De XX-30X en XX-40X checkpoints en jezelf hiermee assessen. Hou het niet bij alleen afvinken, maar beargumenteer per checkpunt onder de verschillende niveaus van de beoordelingscriteria waarom je het wel of niet of deels hebt. Om je beschrijving enigszins kort te houden helpt het wel om ook te linken naar concreet werk in je code management systeem. Dus neem een link op maar denk ook aan een goede linktekst vergelijkbaar met hoe je dit in individuele fact sheet doet.

Zeker bij de hogere punten XX-30X en XX-40X moet je — behalve zeggen DAT je het doet — ook uitleggen/beargumenteren HOE je hier dan aan voldoet. Voor het afvinken van deze criteria moet je ook 'bewust bekwaam' zijn en concreet aangeven welk werk jij en je team hebben gedaan. Anders kan een beoordelaar aanvoeren dat het een 'toevalstreffer is'. Ook is het zelden voldoende om te zeggen 'Dit checkpunt hebben we omdat we Tool X gebruiken'. Bijvoorbeeld 'Cross Silo analysis voldoen we aan omdat we Prometheus en Grafana gebruiken'. Geef of beschrijf in plaats daarvan een concreet scenario van een 'cross silo analysis' met deze tool. Lees ook de toelichting bij verschillende checkpoints in de 'lijst van devops concepten'.

Een goede redenering en argumentatie is dus nodig voor een goed cijfer. Je kunt ook een checkpunt afvinken, maar aangeven dat je er deels nog niet aan voldoet, maar wel een oplossingsrichting geven. Dus maai liever het gras voor de voeten weg van mogelijke kritiek of vragen door de beoordelaar, dan er over te zwijgen.

Figuur 1: Het Continuous Delivery Maturity Model van infoq.com

Merk overigens op dat het CDMM van InfoQ is, iets anders is dan InfoSupport. Als je zelf overigens een ander moderner, simpeler, passender of anderszins beter maturity model weten of vinden dan het CDMM uit de coursefase, dan kun je deze in overleg met de begeleiders ook gebruiken voor dit self assessment! Plumlogix' model is wat simpel en enkel 'cretologie' zonder onderscheid tussen niveaus, dus dit moet je allemaal zelf definiëren en beargumenteren. Het Nederlandse NISI heeft nog een recenter maturity model, CD3M genaamd, maar de term 'Continuous Intelligence' hierin is wellicht nog wat vaag. Het CDMM van InfoQ (feb 2013) is nog van (net) voor de tijd dat veel huidige DevOps tools ontstonden (bijvoorbeeld Docker (1.0 in maart 2013 uit dotCloud) of Kubernetes (2014, open-source versie onder de naam 'Borg') bestonden of gemeengoed waren). Zelfs microservices werden net iets later pas hot. Maar het CDMM bevatte conceptueel al wel heel veel zaken zoals een 'Build bakery' (dit idee zit in de base images uit Docker) en 'microservices' zijn de 'componenten' uit OA205: 'Modules omzetten naar componenten' (e.g. van modulaire monolith naar microservices, waar OA-101 'Systeem opsplitsen in modules' nog te zien is als de stap is van een niet-modulaire monoliet naar een wel-modulaire) monoliet.

Figuur 2: Een alternatief DevOps Maturity Model van plumlogix.com

Bronnen

• Porras, A. (2025, 23 oktober). How to Perform Load Testing on a Distributed System with k6. Geraadpleegd op 11-12-2025 via https://blog.4geeks.io/how-to-perform-load-testing-on-a-distributed-system-with-k6/