Beoordeling Individuele bijdrage

• Datum: 11 okt 2021
• Auteur: Bart van der Wal

1. Inleiding: Verantwoording eigen bijdragen

Naast je beoordeling als team voor het samen gemaakte product krijg je ook een individueel cijfer op basis van jou bijdrage aan dit product. Dit gebeurt zowel tijdens beroepsproduct en voor je product uit blok 2.

Je hoeft tijdens het project geen uitgebreid verslag te schrijven, en sowieso geen Word documenten, zoals in sommige andere projecten. Maar wel moet elk groepslid wel een eigen markdown bestand toevoegen en bijhouden (direct) in de docs folder van het team repository/project. Hieronder het template. Dit template bevat de volgende 9 kopjes. Bij elk kopje kort vermeld de competenties uit de OWE of 'devops maturity' aspecten die hier in ieder geval bij horen:

1. Code/platform bijdrage

   • DevOps-1 Continuous Delivery
   • CDMM: Design & Architecture
   • CDMM: Test & Verification

2. Bijdrage app configuratie/containers/Kubernetes

   • DevOps-2 Orchestration
   • DevOps-4 Containerization
   • CDMM: Design & Architecture

3. Bijdrage versiebeheer, CI/CD pipeline en/of monitoring

   • DevOps-3 GitOps
   • DevOps-5 SlackOps
   • CDMM: Information & Reporting
   • CDMM: Test & Verification
   • CDMM: Build & Deploy

4. Onderzoek

   • DevOps-6 Onderzoek

5. Bijdrage code review/kwaliteit anderen en security

   • DevOps-4 DevSecOps
   • CDMM: Culture&Organization
   • CDMM: Test & Verification

6. Bijdrage documentatie

   • CDMM: Design & Architecture
   • DevOps-6 Onderzoek

7. Bijdrage Agile werken, groepsproces, communicatie opdrachtgever en soft skills

   • DevOps-7 Attitude*
   • CDDM: Culture & Organization

8. Leerervaringen

   • DevOps-7 Attitude
   • CDDM: Culture & Organization

9. Conclusie & feedback

   • DevOps-7 Attitude

Dit document dient als bewijslast richting beoordelaars op meer afstand, maar ook voor je eigen overzicht en ter referentie tijdens de groepssessie voor beoordeling van de individuele bijdrages.

Om een basisvulling te vereisen maar ook al te grote omvang van het document te beperken ivm beoordeelbaarheid, vermeldt het template wat minimum- en maximumaantallen. Dit bestand houdt je bij tijdens het hele project.

Hieronder in sectie 2 wat eisen en richtlijnen over het 'invullen' van het template. In sectie 3 volgt het template zelf, om te copy-pasten naar je eigen repo. In sectie 4, 5 en 6 daarna nog wat achtergrondinformatie bij de individuele beoordeling, de individuele delta die dit geeft op het groepscijfer respectievelijk de algemene beoordelingscriteria die hierbij relevant zijn.

2. Eisen en richtlijnen Individuele verantwoording

Hieronder de richtlijnen in 4 subsecties, maar deze lijst is al de TL; DR:

1. Zorg dat template teksten zo snel mogelijk weg zijn uit de templates, uiterlijk bij (en enige ;) tussentijdse beoordeling.
2. Zorg dat verantwoording ook tussentijds al leesbaar en compleet is (tussentijds eventueel TODO's voor jezelf)
3. Gebruik vrije tekst en bullets
4. Gebruik (semantische) linkteksten GEEN kale URL's.

2.1 Beoordelaar kijkt niet als er nog template teksten aanwezig zijn

Verwijder voor het inleveren alle template teksten! Zodat alleen de kopjes (en opgesomde competenties) overblijven!

De template teksten staat in de markdown als hulp. Maar aanwezigheid van deze (standaard) template teksten op het moment van beoordelen ziet de beoordelaar als een teken dat je nog niet klaar bent ermee bent. Dit heeft als gevolg dat hij/zij dus niet kan beoordelen. Niet (kunnen) beoordelen betekent een onvoldoende!

Vervang bijvoorbeeld <mijn-naam> bv. door Eliezer Yudkowsky. NB: Dus NIET <Eliezer Yudkowsky >; de angle brackets (< en >) zijn om templateteksten aan te geven, dus bij invullen moet je ze WEGhalen.

2.2 Ook leesbaar en compleet bij tussentijdse beoordeling

Bij tussentijdse toetsing heb je al een volledige en leesbare versie, met minstens de minimale aantallen. Richting de eindbeoordeling werk je deze verder bij, en schrapt evt. punten als je anders over het maximum aantal gaat en je inmiddels grotere/belangrijker zaken hebt. Of als je punten kunt samenvoegen onder 1 noemer (N.B. Punten zijn evt. terug te vinden via versie historie).

Dus je vult ook al een voorlopige eindoordeel in. En bijvoorbeeld hebt ook al de helft van de tips en tops.

Mocht je er tussentijds achterkomen dat onder een kopje nog te weinig of zelfs GEEN werk en/of links kunt geven, neem voor je zelf dan wat TODO's op, met een richting, zodat je in de 2e helft kunt zorgen dat je wel voldoende varieteit en breedte in je werk hebt.

2.3 Gebruik vrije tekst én bullets

TL; DR Dus: gebruik een combinatie van beschrijvende teksten en korte bullet lijsten met links naar werk in het met team gebruikte 'code management systeem' waarmee beoordelaar je werk kan verifieren.

De bedoeling van deze verantwoording is dat het korte tekstuele beschrijving is. Voor structuur gebruik je hierbij ook bullets. Maar je gebruikt NIET alleen maar bullets, of alleen maar paragrafen. Je gebruikt een combinatie. Typisch is een paragraaf dan een inleiding bij een bullet lijst, zoals Qua Kubernetes configuratie deed ik het volgende. Of een toelichting bij iets interessantes. Schrijf ook een korte inleiding.

2.4 Gebruik linkteksten

• Maak van links shortlinks, dus met goede linktekst en niet de hele originele URL’s (die nemen anders groot deel van je documentatie in beslag, dat is ongewenst)
• Maak deze links ook naar bv. code diffs of pull requests i.p.v. direct naar volledige bestanden/folders in versiebeheer met integrale stukken code die van iedereen in het team kunnen (en horen!) te zijn.
• Plaats ook opmerkingen in pull requests (review opmerkingen) en github issues ().

Het agile principe van face-to-face contact is ook belangrijk, maar stem niet alles alleen maar mondeling af zorg voor de traceerbaarheid en beoordeelbaarheid door externen. Zo heeft groepsgenoot ook iets om op terug te vallen na mondeling afstemmen (of deze notuleert zelf mondling overleg in issue).

Als je dit onverhoopt tijdens het project te weinig gedaan hebt, kun je alsnog dit documenteren. In je markdown zelf maakt deze wellicht te groot, maar dan kan het in een taak/issue waar je in markdown naar linkt, of in de wiki o.i.d. (hier hebben jullie hopelijk ook team standaard voor, en anders kun je die wellicht met terugwerkende kracht opstellen, in kader van overdracht naar anderen, nu jullie dit project gaan verlaten).

Dus vervuil je markdown niet met hele lange URL links, maar kort deze in, of - beter nog - maak een linktekst die echt semantisch is, en ook thuishoort in een lopende tekst. In de tabel hieronder drie voorbeelden.

Mwegh...	Okee.	Top!

3. Markdown template individuele bijdrage

# Eigen bijdrage <mijn-naam>
 
Als deliverable voor de individuele bijdrage in het beroepsproduct maak een eigen markdown bestand `<mijn-voornaam>.md` in je repo aan met tekst inclusief linkjes naar code en documentaties bestanden, pull requests, commit diffs. Maak hierin de volgende kopjes met een invulling.
 
Je schrapt verder deze tekst en vervangt alle andere template zaken, zodat alleen de kopjes over blijven. **NB: Aanwezigheid van template teksten na inleveren ziet de beoordelaar als een teken dat je documentatie nog niet af is, en hij/zij deze dus niet kan of hoeft te beoordelen**.
 
Je begin hier onder het hoofdkopje met een samenvatting van je bijdrage zoals je die hieronder uitwerkt. Best aan het einde schrijven. Zorg voor een soft landing van de beoordelaar, maar dat deze ook direct een beeld krijgt. Je hoeft geen heel verslag te schrijven. De kopjes kunnen dan wat korter met wat bullet lijst met links voor 2 tot 4 zaken en 1 of 2 inleidende zinnen erboven. Een iets uitgebreidere eind conclusie schrijf je onder het laatste kopje.


## 1. Code/platform bijdrage

Competenties: *DevOps-1 Continuous Delivery*

Beschrijf hier kort je bijdrage vanuit je rol, developer (Dev) of infrastructure specialist (Ops). Als Developer beschrijf en geef je links van minimaal 2 en maximaal 4 grootste bijdrages qua code functionaliteiten of non-functionele requirements. Idealiter werk je TDD (dus ook commit van tests en bijbehorende code tegelijk), maar je kunt ook linken naar geschreven automatische tests (unit tests, acceptance tests (BDD), integratie tests, end to end tests, performance/load tests, etc.). Als Opser geef je je minimaal 2 maximaal 4 belangrijkste bijdragen aan het opzetten van het Kubernetes platform, achterliggende netwerk infrastructuur of configuration management (MT) buiten Kubernetes (en punt 2).
 
## 2. Bijdrage app configuratie/containers/kubernetes

Competenties: *DevOps-2 Orchestration, Containerization*
 
Beschrijf en geef hier links naar je minimaal 2 en maximaal 4 grootste bijdragen qua configuratie, of bijdrage qua 12factor app of container Dockerfiles en/of .yml bestanden of vergelijkbare config (rondom containerization en orchestration).

## 3. Bijdrage versiebeheer, CI/CD pipeline en/of monitoring

Competenties: *DevOps-1 - Continuous Delivery*, *DevOps-3 GitOps*, *DevOps-5 - SlackOps*

Beschrijf hier en geef links naar je bijdragen aan het opzetten en verder automatiseren van delivery pipeline, GitOps toepassing en/of het opzetten van monitoring, toevoegen van metrics en custom metrics en rapportages.

NB Het gebruik van *versiebeheer* ((e.g. git)) hoort bij je standaardtaken en deze hoef je onder dit punt NIET te beschrijven, het gaat hier vooral om documenteren van processtandaarden, zoals toepassen van een pull model.

## 4. Onderzoek

Competenties: *Nieuwsgierige houding*

Beschrijf hier voor het Course BP kort je onderzochte technologie met een link naar je blog post, of het toepassen ervan gelukt is en hoe, of waarom niet. Beschrijf evt. kort extra leerervaringen met andere technologieen of verdieping sinds het blog. 

Tijdens het grote project beschrijf je hier onderzoek naar het domein en nieuwe onderzochte/gebruikte DevOps technologieën. Wellicht heb je nogmaals de voor blog onderzochte technologie kunnen toepassen in een andere context. Verder heb je nu een complex domein waar je in moet verdiepen en uitvragen bij de opdrachtgever. Link bijvoorbeeld naar repo's met POC's of, domein modellen of beschrijf andere onderwerpen en link naar gebruikte bronnen.

Als de tijdens course onderzochte technologie wel toepasbaar is kun je dit uiteraard onder dit punt noemen. Of wellicht was door een teamgenoot onderzochte technologie relevant, waar jij je nu verder in verdiept hebt en mee gewerkt hebt, dus hier kunt beschrijven. Tot slot kun je hier ook juist een korte uitleg geef over WAAROM  jouw eerder onderzochte technologie dan precies niet relevant of inpasbaar was. Dit is voor een naieve buitenstaander niet altijd meteen duidelijk, maar kan ook heel interessant zijn. Bijvoorbeeld dat [gebruik van Ansible in combi met Kubernetes](https://www.ansible.com/blog/how-useful-is-ansible-in-a-cloud-native-kubernetes-environment) niet handig blijkt. Ook als je geen uitgebreid onderzoek hebt gedaan of ADR hebt waar je naar kunt linken, dan kun je onder dit kopje wel alsnog kort conceptuele kennis duidelijk maken.
 
## 5. Bijdrage code review/kwaliteit anderen en security

Competenties: *DevOps-7 - Attitude*, *DevOps-4 DevSecOps*

Beschrijf hier en geef links naar de minimaal 2 en maximaal 4 grootste *review acties* die je gedaan hebt, bijvoorbeeld pull requests incl. opmerkingen. Het interessantst zijn natuurlijk gevallen waar code niet optimaal was. Zorg dat je minstens een aantal reviews hebt waar in gitlab voor een externe de kwestie ook duidelijk is, in plaats van dat je dit altijd mondeling binnen het team oplost.
 
## 6. Bijdrage documentatie

Competenties: *DevOps-6 Onderzoek*

Zet hier een links naar en geef beschrijving van je C4 diagram of diagrammen, README of andere markdown bestanden, ADR's of andere documentatie. Bij andere markdown bestanden of doumentatie kun je denken aan eigen proces documentatie, zoals code standaarden, commit- of branchingconventies. Tot slot ook user stories en acceptatiecriteria (hopelijk verwerkt in gitlab issues en vertaalt naar `.feature` files) en evt. noemen en verwijzen naar handmatige test scripts/documenten.
 
## 7. Bijdrage Agile werken, groepsproces, communicatie opdrachtgever en soft skills

Competenties: *DevOps-1 - Continuous Delivery*, *Agile*

Beschrijf hier minimaal 2 en maximaal 4 situaties van je inbreng en rol tijdens Scrum ceremonies. Beschrijf ook feedback of interventies tijdens Scrum meetings, zoals sprint planning of retrospective die je aan groespgenoten hebt gegeven.

Beschrijf tijdens het project onder dit kopje ook evt. verdere activiteiten rondom communicatie met de opdrachtgever of domein experts, of andere meer 'professional skills' of 'soft skilss' achtige zaken.
  
## 8. Leerervaringen

Competenties: *DevOps-7 - Attitude*

Geef tot slot hier voor jezelf minimaal 2 en maximaal **4 tops** en 2 dito (2 tot 4) **tips** á la professional skills die je kunt meenemen in toekomstig project, afstuderen of wellicht zelfs verdere loopbaan (de 'Transfer' uit STARRT). Beschrijf ook de voor jezelf er het meest uitspringende hulp of feedback van groepsgenoten die je (tot dusver) hebt gehad tijdens het project.

## 9. Conclusie & feedback

Competenties: *DevOps-7 - Attitude*

Schrijf een conclusie van al bovenstaande punten. En beschrijf dan ook wat algemener hoe je terugkijkt op het project. Geef wat constructieve feedback, tips aan docenten/beoordelaars e.d. En beschrijf wat je aan devops kennis, vaardigheden of andere zaken meeneemt naar je afstudeeropdracht of verdere loopbaan. 

4. Werkwijze beoordeling individuele bijdrage

Voor je individuele bijdrage in het project krijg je ook een beoordeling.

4.1 Input voor beoordeling

Basis hiervoor is de input van je teambegeleider(s), en evt. observaties van de klant/opdrachtgever tijdens Scrum ceremonies of daarbuiten of andere door beoordelaars belangrijk gevonden punten. De inbreng tijdens Productdemo of de Review sessie kan ook doorslag geven als je ervoor nog te weinig zichtbaar was. Uiteraard weegt ook mee het correct en voor externen ook leesbaar en begrijpelijk invullen van bovenstaand template met je verantwoording van je individuele bijdrage.

4.2 Groepssessie individuele beoordeling

De uiteindelijke individuele beoordeling gebeurt n.a.v. een groepssessie. Dit klinkt wellicht tegenstrijdig, want je focust in de verantwoording op eingen werk, maar we gaan er vanuit dat je toelichting bekend is bij teamgenoten en geen verantwoording. Omdat samenwerking met groepsgenoten en bv. het reviewen van elkaars werk, of anderszins samenwerken centraal staat bij DevOps. Tijdens de sessie geef je ingevulde tekst toelicht. Deze meeting duurt een half uur tot een uur afhankelijk van je groepsgrootte. Je hebt hierbij ongeveer 5 minuten voor je eigen werk. Deze sessie plan je in met je begeleiders/beoordelaars. De begeleider vraagt tijdens deze sessie bijvoorbeeld het volgende:

• Waar ben je het meest trots op van je bijdragen aan het teamproduct?
• Waar heb je nog het minst laten zien?
• Vervolgens lopen we samen snel door je factsheet heen

Aan het eind van de sessie geeft de beoordeleer aan wat je delta op het groepscijfer is.

Als teamlid mag je opmerkingen/input geven, maar we proberen discussies te bewaren voor andere contactmomenten.

4.3 Gebruik links

Naast de tekst zelf is natuurlijk de kwaliteit van het daarin gelinkte bronmateriaal (zorg dat de links zelf ook werken, en bv. wijzen naar een diff of review van eigen werk, i.p.v. naar werk van anderen). Zorg ook dat het presentabel is door GEEN kale lange URL's te geven, maar de URL's zelf waar mogelijk in te korten maar ook netjes achter een link te stoppen met korte maar duidelijke linktekst in een duidelijke en actief geschreven zin (of herschrijf).

5. Delta op teamcijfers

Je eindcijfer is het groepscijfer en nog individuele 'delta' hierop. Deze delta is in principe 0, dus dat betekent dat je eindcijfer hetzelfde is als het groepcijfer. Maar als beoordelaars aanleiding hebben kunnen deze een delta geven die varieert van -1 tot +2 op het teamcijfer. Ook geldt dat als je als teamlid geheel niet of duidelijk te weinig hebt bijgedragen, of je bijdrage niet voldoende kunt verantwoorden, dan is je eindcijfer een onvoldoende, ongeacht het teamcijfer. Dit laatste betekent dus dat je het project een volgende editie over moet doen. Hetzelfde geldt uiteraard als na toepassen van een delta je eindcijfer onder de 5,5 zit.

• 2 Project niet afgerond
• 4.5 Project gedaan maar onvoldoende bijgedragen (geen vormbehoud courses) en/of deze bijdrage niet voldoende verantwoord
• -1 Op aantal punten tekort geschoten, maar wel significante bijdrage
• -0,5 Op één of enkele punten tekortgeschoten op verwachte input of toegezegde bijdrage
• +0 Project goed meegewerkt, gezorgd voor significante bijdrage en kwaliteit en vormbehoud van course
• +0,5 Erkenning van belangrijke bijdrage op een aspect van het teamproduct of -proces
• +1 Belangrijke extra invloed qua kwantiteit of kwaliteit van teamproduct binnen het team op één of enkele punten
• +2 Op een aantal punten een essentiële positieve extra invloed qua kwaliteit, kwantiteit van werk

Om bovenstaande wat concreter te maken hieronder enkele (fictieve) beschrijvingen van projectsituaties en de hieruit voortkomende beoordeling.

5.1 Voorbeeld 1

Een team heeft als teamcijfer een 7 gehaald met een weinig opvallend project met wel een enthousaste en duidelijk einddemo. Eigenlijk al het gevraagde zat erin, zij het minimaal. Teamlid A heeft een belangrijke invloed gehad bij de realisatie van de database, en is 'above and beyond' gegaan en krijgt een 7+1=8. Teamlid B heeft steady gecodeerd, maar heeft geen enkele verslaglegging gedaan en kan achteraf ook onvoldoende terugvinden in aangemaakte issues of commit opmerkingen om dit nog te fixen voor de inlever deadline. Een 4.

5.2 Voorbeeld 2

Een team heeft een 6 gekregen. In dit team is Teamlid X in week 2 helaas uitgevallen (een 1). Het security aspect missen zij geheel, want heeft verder niemand opgepakt ondanks dat dit teamverantwoordelijkheid is. Wel is er een nieuw microservice en wijzigingen in back-end en front-end met noSQL storage. Teamlid Y heeft een bestaand issue nooit gefixt, hoewel dit wel met hem is afgesproken omdat dit bij zijn expertise hoorde. Achterliggende reden was dat zijn technologie toch niet in bleek te passen in het beroepsproduct en hierdoor was hij gedemotiveerd.

De team beslissing bij sprint 2 om dit te laten vallen en te documenteren als ADR was hij het eigenlijk niet mee eens. Maar dat durfde hij toen niet te zeggen. Omdat hij achter de schermen bleef 'doormodderen' kwam hij een week onvoldoende aan zijn issues toe. Gelukkig kon hij hier wel op reflecteren en heeft op de front-end in de week erna nog goed bijgedragen: (6-0.5 = 5.5).

Teamlid Z heeft alle issues van X opgelost, en ook de hele front-end opgezet, en hierbij ook een BDD aanpak gerealiseerd waardoor vanuit de front-end de hele applicatie geacceptatest kan worden: 6+2 = 8.

6. Beoordelingscriteria

Bij de beoordeling is uitgangspunt dus een ingevulde individuele bijdrage en uiteraard ook alles wat erachter zit qua product/configuratue en documentatie in gitlab/versiebeheer. De beoordelaars hebben verder ook indrukken beoordelaars tijdens SCRUM sessies en dergelijke. Tijdens het project hoef je niet alles te doen wat in de course behandeld is, maar je hebt hier wel gebruik van gemaakt en toont vormbehoud op de competenties uit de course fase (zoals ook vermeld in individuele bijdrage):

• DevOps-1 Continuous Delivery
• DevOps-2 GitOps
• DevOps-3 Containerization
• DevOps-4 DevSecOps
• DevOps-5 SlackOps
• DevOps-6 Onderzoek
• DevOps-7 Attitude

Verder kunnen beoordelaars ook algemene teamcompetenties meenemen zoals:

• Focus op kwaliteit en kwantiteit van het werk
• Pragmatisch houding (KISS) en rol pakken
• Teamgenoten helpen
• Kritische houding, focus op testen, security en reliability
• Aanspreekbaar zijn en verantwoordelijkheid nemen
• Nieuwsgierige en onderzoekende houding