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

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
• 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

Toelichting

Merk op dat dat bovenstaande punten grofweg knock-outs zijn van het minimale verwachte werk, de te gebruiken werkwijze en de op te leveren zaken (deliverables). Voor het komen tot een concreet cijfer kijken begeleiders naar de hoeveelheid 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 wan zonder nieuwe features en requirements heb je geen DevOps nodig.

Hoe ga ik naar ruim voldoende, goed, zeer goed of uitmuntend?

Voor het aantonen van hogere 'Devops volwassenheid' (en dus eindcijfer boven een 6) kun je — net als in de coursefase — het CDMM er weer bij pakken en jezelf hiermee assessen. Hou het niet bij alleen afvinken, maar argumenteer 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 een goede linktekst op te nemen vergelijkbaar met je dit in individuele fact sheet doet.

En 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 dit aantonen. 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'. Lees ook de toelichting bij verschillende checkpoints in de 'lijst van devops concepten'.

Een goede redenering en argumentatie is dus ook 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)

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 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 bijvoorbeeld ook een recenter maturity model, CD3M genaamd, maar de term 'continuous intelligence' hierin is nogal 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).

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