Beoordelingsmodel (groepsproduct + -proces)

Als beoordelingsmodel voor de weekopdrachten en het beroepsproduct (BP) dat je maakt — gebruiken we het Continuous Delivery Maturity Model (CDMM) zoals gedefinieerd in een blogpost op de website InfoQ. Deze onderscheid vijf categorieen (rijen) met elk 5 niveaus (kolommen) met een aantal 'checkpunten'.

Hieronder een korte opsomming van de 5 categorieën uit het CDMM, met per categorie een beschrijving van belangrijke aspecten. Maar voor de verplichte self assessment moet je ook zelf de details achterhalen van de 'checkpoints', zoals onderaan de pagina verder beschreven, toegelicht onder 'DevOps concepten' op deze website, maar ook in het originele 'InfoQ' artikel (Böstrom et al., 2013).

• 🧑‍🤝‍🧑 Culture & Organization: Multidisciplinair samenwerken, conform Agile manifesto, verminderen silo's en gedeelde verantwoordelijkheid conform 'DevOps is not a role', etc. (Agile).
• ⛪ Design & Architecture: Just in time design, continuous documentation, microservice architectuur, High Availability, autonomy over authority, etc. (C4, IaC, clustering)
• 🏗️ Build & Deploy: Gescripte pipelines, continuous integration, continuous deployment, koppeling aan versiebeheer, 'automate all the things' etc. (GitOps)
• 🧪 Test & Verification: Leesbare en liefst uitvoerbare specificaties, geautomatiseerd testen, testpiramide, opstellen en meten bedrijfsmetrics, etc. (TDD, BDD, test pyramid)
• 📈 Information & Reporting Inzicht in issues/backlog, metrics vanuit productie, beeld hard- en softwaregebruik, log aggregatie, visualisatie, 'strengthen feedback loops', etc. (SlackOps)

Bovenstaand de categorieën nog even in het Engels en als toelichting een indicatie van hogere maturity per punt met wat kernpunten. Het Maturity model geeft meer stapsgewijze opbouw in niveaus met bij elk niveau checkpunten om af te vinken. Deze vind je hieronder opgesplitst over twee tabellen zodat het goed op deze pagina past:

• de beginniveaus (🐣 2, 🐥 4 en 🦆 6-)
• respectievelijk hogere niveaus (🤨 6+, 8 😍, 🤯 10)

Om niet direct te verdwalen in het detail kun je eerst overzicht te krijgen via de toelichtingin in subsecties hier eronder. Sectie A geeft een toelichting van het gebruik CDMM als beoordelingsmodel voor cijferindicatie. Sectie B licht de vijf beoordelingscriteria toe die dit model bevat. Sectie C beschrijft de samenhang met (en mapping naar) de thema's, opdrachten en lessen van de course fase. Sectie D licht de indeling van de teampresentatie momenten toe. Tot slot in sectie E iets over de impliciete aanname dat je geautomatiseerd testen en aan TDD doet. Tot slot de gebruikte Bronnen.

Voor het eind beroepsproduct van de coursefase krijg je ook een individueel cijfer. Deze is veelal gelijk aan het teamcijfer, maar zoals elders is toegelicht hoe elk teamlid hiervoor de verplichte 'verantwoording van de individuele bijdrage' geeft, via een persoonlijk markdown bestand (waarvoor een template format is), en een mondelinge toelichting hierbij tijdens de Review.

CDMM Basis tot gemiddeld

CDMM Gemiddeld tot Expert

A. Toelichting gebruik CDMM als beoordelingsmodel

Dit model is opgesteld voor ICT organisaties, om de fase van adoptie van DevOps patterns en het toepassen van Continuous Delivery aan te geven. In deze course gebruiken we dit ook voor bepalen van niveau van jullie als DevOps team. Je DevOps team zien we daarbij dus zien als een kleine DevOps organisatie.

Het model kent vijf beoordelingscategorieën met elk vijf beschreven niveaus: base, beginner, intermediate (=gemiddeld), advanced en expert. Voor de becijfering koppelen we grofweg een cijfer aan elk niveau:

• 😴 base niveau cijfer **2**
• 🥱 beginner niveau, een **4**
• 😐 gemiddeld niveau een **6**
• 🙂 gevanceerd niveau een **8**
• 😎 expert niveau een **10**

Het voldoende niveau (dus een 6) is dus intermediate oftewel gemiddeld. Hier ben je voldoende volwassen. Bij lager zit je op onvoldoende, maar dat betekent in dit geval niet dat je aanpak niet adequaat is, vandaar de gebruikte emoticons van het nog slapen en ontwaken: 😴 2 en 🥱 4. Wellicht waren deze iconen ook passend geweest: 🐣 2, 🐥 4 en 🦆 6 (😉).

Deze 'Beginner' punten moet je dus wel inrichten, dit zijn traptreden die je moet nemen naar hoger niveau. Op tenminste een aantal punten moet je ook naar gemiddeld of hoger zitten voor een voldoende. Je hebt immers een DevOps minor gevolgd, dus een bedrijf verwacht dan dat je meer DevOps kennis hebt dan de gemiddelde instappende ICT'er. Het staat de beoordelaar vrij om een tussenliggend cijfer te geven op de deelaspecten, dus bijvoorbeeld een 5, 7 of 9 is ook mogelijk (een 1 betekent dat je niks hebt gedaan of ingeleverd).

Bij de beoordeling levert de docenten/beoordelaars wel maatwerk, dus rekening houdend met omstandigheden. Bij beoordeling is het niet allen een kwestie van simpelweg afvinken, maar belangrijkste is dat je ook zelf kunt beoordelen waar je staat, de gebruikte termen goed kunt interpreteren, koppelen aan je eigen en je teams werk. Kortom dat je aantoont dat je een 'bewust bekwame' DevOps professional bent.

Verdere opmerkingen:

• De Engelse termen uit het CDMM-artikel, zoals 'base', worden afgewisseld met Nederlandse equivalenten ('basis') voor verduidelijking.
• Termen in monocase font (dus met backticks ` in markdown) verwijzen naar specifieke concepten of labels zoals beschreven in het CDMM-model.
• De termen 'beoordelingscriteria' en 'categorieën' gebruiken we in de tekst als synoniemen en verwijzen naar dezelfde onderdelen.

B. De 5 beoordelingscriteria

Onderstaand de vijf beoordelingscriteria waar je in je team laten op 'intermediate' niveau moet scoren. Als indicatie een korte beschrijving en wat voorbeelden. Maar voor beoordeling moet je de hele rubric bekijken en bekijk voor uitleg van alle 'etc.' in onderstaande het originele InfoQ artikel als verdere achtergrond. Merk op dat achter elk criterium uit CDDM tussen haakjes ook een ruw equivalent van de criteria uit de OWE.

1. 🧑‍🤝‍🧑 Cultuur & Organisatie - CO: DevOps is een cultuur (en geen rol). Van basis versiebeheer en ad hoc proces tot projectgebaseerde teams met volledig gedefinieerd DevOps proces. Het team heeft gezamenlijke verantwoordelijkheid en backlog en hanteert een Agile aanpak en ceremonies (bv. Scrum), etc. (DevOps-1 - Continuous Delivery)
2. ⛪ Design & Architectuur - OA: Ontwerp van je software architectuur. Van monoliet naar microservices mapping op infrastructuur (evt. IaC), focus op NFR's voor bv. autoscaling, twelve-factor app principles, etc. (DevOps-3 - Containerization/Orchestration)
3. 🏗️ Build & Deploy - BD: Van wat handmatige stappenplan naar volautomatische build met kwaliteitschecks en een Canary of bluegreen deploy vanuit zelf ingerichte pipeline, dev/prod parity etc. (DevOps-2 GitOps)
4. 🧪 Test & Verificatie - TV: Van wat (goede) unit tests¹ naar volledige testpiramide, load tests en tests van bedrijfswaarde. De mate van TDD, acceptatietests, BDD, security, refactorings, review-proces en -inspanningen etc. (DevOps-4 - DevSecOps)
5. 📈 Informatie & Rapportering - IR: Van standaard hardware monitoring naar realtime applicatiespecifieke metrics en cross applicatie en cluster informatie, A/B tests. Hoe goed monitor je de applicatie, static code analyse, loglevels/-aggregatie, productspecifieke rapportages, etc? (DevOps-4 - SlackOps)

Hieronder de beoordelingsrubric overgenomen van het Continuous Delivery Maturity Model (CDMM) van infoq.com. De rubric is feitelijk overgenomen uit een plaatje bij dit artikel wat een samenvatting van het artikel vormt, in de vorm van afvinkbare 'checkbox punten'. Drze zijn verdeeld over vijf categorieen die elk weer vijf niveaus van 'volwassenheid' hebben.

Wijzigingen t.o.v. originele CDMM

De wijzigingen in bovenstaande tabel ten opzicht van het originele CDMM van InfoQ zijn erg beperkt en spreken deels voor zich, maar hier voor de nieuwsgierigen.

• Ten opzichte van het InfoQ artikel is elk item/checkbox vertaald naar het Nederlands.
• Elk checkpunt nu een eigen code (bv. CO-003), die kort de categorie en het niveau aangeeft.
• Om het op één pagina te laten passen is de grote tabel opgesplitst in twee tabellen; één met niveaus 0 t/m 2 voor het gewenste niveau tijdens theorie deel van de course fase (1e 5 weken).
• Het streefniveau 2 'Gemiddeld' komt dus in beide tabellen voor als indicatie/koppeling tussen de twee. Tabel 2 is met niveaus 2 t/m 4 voor verdere verdieping in onderzoek, BP en het grote project. Vanaf base niveau 0 naar 2 doe je in de course fase als het goed is.

Tot slot zijn de volgende checkpoints in het CDMM toegevoegd:

• CO-206 Trunk based development - In lijn met punt 'CO-201 *minimale branching' is het logisch dat developers in versiebeheer zoveel mogelijk op de trunk werken (bv. main). Zie verder het artikel hierover uit 2018 op InfoQ hierover, 5 jaar na het CDMM artikel :) (InfoQ, 2019)
• Punt DB wijzigingen in VCS is verplaatst vanuit categorie 'Ontwerp & Architectuur' naar 'Build & Deploy' als BD-105 in lijn met de overige hogere checkpoints rondom 'db' zoals 'Automatiseer meeste DB wijzigingen* die ook in deze categorie staan. Deze hangen meer samen met automatiseren van deploys met pipeline en versiebeheer standaarden dan met de applicatie architectuur. Wel kun je argumenteren dat het gebruik van een ORM tool met migrations wel weer deels een (software) design of architectuur keuze is. Wel een ADR waard in ieder geval. Dan zouden BD-303 en BD-402 juist naar de categorie OA moeten, maar i.v.m. consistentie doen we dit niet.
• Verder nog geen punten. Suggesties zijn welkom, mits natuurlijk niet dubbelop met bestaande punten.

Gebruik checkpunten voor self assessments

De checkpunten ga je gebruiken in de weekopdracht en beroepsproduct, maar het is wel de bedoeling naast de code OOK de naam op te nemen in je eigen product documentatie, toelichting bijdrage team en dergelijke. Dus NIET enkel de code, want dan wordt het erg cryptisch (en moet de lezer dit weer opzoeken).

Bijvoorbeeld:

Het gezamenlijk zelf komen tot een besluit tijdens de sprint retrospective — in plaats van naar de PO te kijken voor een besluit — zien wij als voorbeeld van CDMM CO-206 - Decentrale besluitvorming). Dit toont aan dat wij als team al voldoende scoren op criterium Cultuur en Organisatie.

Op een eventuele vraag van de beoordelaar waarom jullie dan nog niet 'handelen op metrics' (C0-203) moeten je dan zelf idealiter een antwoord formuleren (wellicht is "Promotheus doen we pas in week 5" een goede verdediging ;))

Een verdere toelichting op de categorieën en niveaus vind je hieronder. Of vraag ernaar tijdens de lessen!

C. Mapping van de 'CDMM checkboxes' op de weekthema's/-opdrachten

Tijdens de lesweken in de course fase richt je je in opdrachten vooral op stappen Basis en Beginner. Tijdens het onderzoek en DevOps BP ontwikkeling (laatste 3 weken) ga je je als het goed is ontwikkelen naar hoger niveau een of manier criteria (maar tenminste vormbehoud).

Hieronder een klein opzetje van de mapping. Merk op dat het merendeel van de checkboxes nog ingedeeld moet worden. Waarbij je sommige in twee of meer categorieen kunt/moet indelen (zoals BD-207 'standaard proces voor alle omgevingen' in containerization en Continuous Deployment en OA-103 in containerization en devSecOps).

• Wk1 - GitOps: CO-003, BD-001 Code in versiebeheer, BD-103 Handmatige tags en versies, BD-201 Auto triggered builds (commit hooks), TV-001 Automatische unit tests, IR-102 Statische code analyse, TV-201 Automatische component test (geisoleerd), ...
• Wk2 - Containerization: OA-103 (3rd party) library management, BD-203 Build once deploy anywhere, BD-204 Automatiseer meeste DB wijzigingen, BD-206 , BD-401
• Wk3 - Continuous Delivery/BDD: CO-001, CO-101, BD-205, BD-206, IR-101, IR-202, TV-301 ...
• Wk4 - Orchestration/DevSecOps: OA-201 Geen of minimale branching, TV-002, TV-303, TV-304, OA-103, ...,
• Wk5 - SlackOps/DDD: IR-001, IR-002, IR-101, IR-301, OA-502... / IR-201, OA-501

D. Beoordelingsmomenten/toetsen

De beoordeling van dit beroepsproduct gebeurt op basis van 3 onderdelen. Deze komen langs twee beoordelingsmomenten; een Productdemo en een Code review. Hier een overzicht met ook beoordelingscriteria per onderdeel.

1. Productdemo a. Het tonen van het product en het updaten en live monitoren ervan tijdens een korte teamdemonstratie voor beoordelaar(s)/opdrachtgever
2. Code review a. Product en code/config review: Langer overleg met alleen team en beoordelaar(s):
   • toelichting indididuele bijdrage
   • vragen van beoordelaars
   • bespreking van jullie self assessment b. Kwaliteit van proces, README en de verdere achterliggende documentatie
   • verloop sprints en Scrum ceremonies
   • doornemen scrumborden, issues, user stories, traceerbaarheid wijzigingen via issues, commit messages, pull requests en review opmerkingen
   • doornemen/toetsen README en begrijpelijkheid documentatie (C4 + UML en overige diagrammen en (verpliche) tekstuele toelichting)

Hieronder geven subsectie E1, E2 en E3 verdere toelichting van respectievelijk Productdemo en Code Review en tot slot de wegingsfactoren o beter gezegd dat er juist geen harde/kwantitatieve wegingsfactoren zijn.

D1. Toelichting Productdemo

De productdemo duurt circa een kwartier en daarna max een kwartier vragen. De presentatie gebeurt voor de beoordelaars en in principe met aanwezigheid van de andere teams NIET met aanwezigheid andere teams. Omdat jullie in principe op basis van een redelijk bekende product hoef je aan introductie hiervan niet veel tijd te bestenden en licht je vooral je eigen uitbreiding hiervan toe, en demo't deploy van product increment en monitoring hiervan.

Voordat de demo is doe je met het hele team een self assessment van het gemaakte DevOps product en gevolgde proces en vult in een self-assessment.md voor alle 5 BC's een cijfer in op basis van niveaubeschrijvingen in de rubric in. Je schrijft hierbij ook een argumentatie voor de invulling, met enkele steekwoorden per BC en ook een of meer paragrafen voor de eindcijfer.

Bij beoordeling geldt dat alle te beoordelen zaken aanwezig zijn in ingeleverde beroepsproduct en ook in je documentatie te vinden zijn. Je werkt dus NIET in Word documenten, maar in tekst en markdownbestanden geintegreerd samen bij de broncode en configuratiebestanden.

Merk op dat de beschrijvingen van de 'lagere niveaus', basis, en beginner niet per se tekortkomingen beschrijven, maar ladders zijn op een trap die je moet nemen richting een voldoende en hopelijk zelfs goed cijfer. Op een aantal criteria zit je gelukkig wel al direct op een 6 door bijvoorbeeld gezamenlijke backlog voor Dev&Ops te gebruiken en een Test en/of Behaviour Driven aanpak te gebruiken.

Als gezegd moet je alle belangrijke zaken, zoals behaalde non functional requirements, of je proces als DevOps team ook zelf kort beschrijven in je documentatie. Je moet ook weten waar je zelf staat. De niveaubeschrijvingen zijn geen kant en klare recepten, dus je moet zelf ook een interpretatie hiervan doen en imvulling. Bij twijfel stem zaken - als het goed is vooraf - af met de beoordelende docent(en). Het expert (=extreem) niveau dat bij een 10 en hierbij ga je above en beyond, dus moet je ook zelf aangeven waarom je op het niveau zit.

D2. Toelichting Code Review

Bij een tweede langer assessment met alleen de docenten en je team gaan we ook in op kwaliteit code, match configuratie met infrastructuur model en gewenste NFR's? Als intro hiervoor bespreken jullie de grove rol- en werkverdeling en elk teamlid geeft toelichting van eigen bijdrage in het product (minstens 1 bijdrage waar je trots op bent, en kwaliteit kunt beargumenteren en een stuk werk waar je concrete verbeterpunten kunt noemen).

De kwaliteit van de README beoordelen docenten bijvoorbeeld door terplekke zelf de code te pullen uit versiebeheer en containers of clusters te runnen o.b.v. jullie README. En daarnaast te bekijken of documentatie voldoende aangrijpingspunten biedt voor nieuwe developer in team om het product snel te begrijpen en aan verder te bouwen.

Voor individuele beoordeling geef je verantwoording van je eigen bijdrage in het groepsproduct en bv. aan de hand van je markdown document ook meer details van het toepassen van de onderzochte technologieen uit de onderzoeksweek. Als gezegd hebben deze tools/technologieen hopelijk een positieve uitwerking op je eindproduct gehad. Denk aan verbeterde/makkelijkere monitoring, hogere productiviteit, betere security, betere code kwaliteit, geautomatiseerde pipeline etc.

D3. Eindcijferbepaling en wegingsfactoren

Tot slot nog evenover de weging; om dit EXPLICIET te maken: er is GEEN hard voorgeschreven weging tussen de 5 beoordelingscriteria om tot een eindcijfer te komen. Normaliter zullen alle vijf de criteria even zwaar wegen, en is er vaak een lijn qua product. En geeft een onvoldoende op een aspect reden tot twijfel. Maar het gaat meer om je eigen beoordeling en - vooral - beargumentering hiervan. Daarom moet je ook een self assessment doen; zie onder.

Het kan zijn dat sommige aspecten minder van belang waren in jullie opdracht en op zichzelf onvoldoende waren. Maar het overall toch voldoende was doordat een ander aspect buitengewoon goed is gedaan, of zaken door externe en niet te voorspellen zaken juist erg tegenvielen.

Merk ook op dat het eindproduct zelf geen eigen cijfer krijgt. Dit is bewust (dit is overigens tijdens projectblok anders, waar de opdrachtgever ook een deelcijfer geeft). Geen cijfer voor eindproduct betekent natuurijk NIET dat je geen product increment moet hebben. Dit is verplicht. Maar we willen niet dat je inzet op heel complexe functionaliteit en daarbij de DevOps basics uit het ogen verliest. Of bv. logging of monitoring aan de kant schuift. Maa zonder product (increment) is er geen proces. En beter product en logische 'bedrijfswaarde' geeft meer gelegenheid DevOps skills te tonen en een betere demo en leidt indirect toch tot een hoger cijfer.

Bijvoorbeeld een groter product increment of uitgebreide refactoring in bestaande code of opsplitsen van microservice in 1 container in 2 aparte, geeft ook een langer commit spoor, meer unit tests, een aanleiding voor extra Q&A omgeving, een demo canary deploy voor subfunctionaliteit I, een A/B test van een andere functionaliteit, data migratie van feature X, en (zelf onderzochte) InfraStructure As Code configuratie voor microservice Z. Een groter product increment geeft natuurlijk ook meer aanleiding voor een complexere architectuur. Ga je voor een simpele CRUD microservice, of kies je juist complexe logica die ook een 'domain driven' ontwerp vraagt, met wellicht caching in miroservice en synchronisatie tussen microservives, een event-driven en/of CQRS aanpak met eventual consistentie, inzet van een message broker etc.

E. Speciale noot over (geautomatiseerd) testen

¹ Merk tot slot op dat het instapniveau (dus 2) niveau qua Test en Verificatie direct 'code is onder test', dus geautomatiseerde tests. Terwijl dit in het beroepsveld lang nog niet bij alle bedrijven gebeurt. In de course gaan we in op BDD (ook wel ATDD = Acceptance Test Driven Design of 'Specification by Example' genoemd), waar ISM studenten ook nog een rol bij kunnen spelen in het opstellen. Maar er is in de minor binnen contacturen niet de tijd om TDD 'vanaf de grond' aan te leren. Maar TDD en gerelateerde patterns en principe als Arrange, Act, Assert (AAA) en Red, Green Refactor veronderstellen we wel als bekend bij developers. Zorg dat je hier ook mee geoefend hebt, of alsnog oefent!

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

De grondlegger van de term Continuous Integration Martin Fowler hamert in vele van zijn blogs op TDD aanpak en legt in blog met titel 'Is high quality software worth the cost?' aan dat deze vraag op een verkeerde veronderstelling berust, omdat kwaliteitssoftware juist goedkoper is om te onderhouden in plaats van duurder (zie figuur 1).

Figuur 1: High (internal) quality software is goedkoper i.p.v. duurder! Aldus Martin Fowler (2019).

In deze lijn trekken in de DevOps wereld over het algemeen door, bv. Continuous Delivery voorman David Farley (van het gelijknamige 'seminal' boek). Met 'goed' bedoelen we hier:

• behoorlijke test coverage, in ieder geval van complexe code (hoge cyclomatische complexiteit)
• leesbare testcode met cyclomatische complexiteit van 1)
• gericht op gedrag en testen van interface i.p.v. implementatie details
• en zonder 'unit testing anti patterns' (zoals 'Liar', 'Excessive setup', 'The giant' en 'The mockery' zie deze video van David Farley).

Bronnen

• Boström, P & Palmbor., T 6 februari 2013. The Continuous Delivery Maturity Model, geraadpleegd 13-1-2021 op https://www.infoq.com/articles/Continuous-Delivery-Maturity-Model
• Fowler, M. 19 mei 2019, Is high quality software worth the cost. Geraadpleegd 20-10-2021 op https://martinfowler.com/articles/is-quality-worth-cost.html
• InfoQ (2018). Trunk Based Development as a Cornerstone for Continuous Delivery. InfoQ.com. Geraadpleegd 5-9-2024 op https://www.infoq.com/news/2018/04/trunk-based-development/