Projectverslag

Belangrijk: op confluence zijn alle figuren en afbeeldingen die ik heb ingevoegd gebroken. Ik heb meerdere keren geprobeerd deze toe te voegen, maar het gaat niet. De afbeeldingen staan in mijn pdf versie, zowel op de email als in ISAS.

Thijmen Schoonbeek

10 juni 2022

OOSE-project groep Perlman

Opdrachtgever: JDI

Projectbegeleider: Jaap Papavoine

Professional skills begeleider: Sjir Schütt

Versie 1.1

INHOUDSOPGAVE

1        INLEIDING.. 3

1.1     Inhoudelijke uitdagingen. 3

1.2     Leerdoelen. 4

2        OORDEEL KWALITEIT GELEVERDE DEELPRODUCTEN.. 5

2.1     Deelproduct 1 - Plan van Aanpak. 5

2.2     Deelproduct 2 – Onderzoeksverslag. 7

2.3     Deelproduct 3 – SRS. 8

2.4     Deelproduct 4 - SDD.. 10

2.5     Deelproduct 5 – Unittests. 11

2.6     Deelproduct 6 – Stuk code. 14

2.7     Deelproduct 7 - Testrapport 16

3        Oordeel kwaliteit geleverd eindproduct. 17

4        Evaluatie PROJECTMETHODE. 19

5        ROLLENBESCHRIJVING.. 21

6        Toelichting COMPETENTIES. 22

6.1     OOSE P-03. De student voert een kwalitatief en kwantitatief onderzoek op een systeem uit en levert hierover een onderzoeksrapport op. 22

6.2     OOSE P-04. De student ontwerpt de software van een systeem en documenteert deze onder andere met behulp van UML diagrammen en decision templates in een Software Design Specification (SDD) 23

6.3     OOSE P-05. De student implementeert een gedistribueerd systeem, evalueert het ontwerp en de realisatie daarvan en zorgt voor traceerbaarheid daartussen en naar de functionele en niet-functionele eisen. 26

6.4     OOSE P-07. De student bewaakt continu de kwaliteit van de software en het proces door o.a. reviews en gestructureerd testen en stuurt waar nodig bij. 28

7        Leerdoelen. 30

7.1    Eerste leerdoel - Plannen. 30

7.2    Tweede leerdoel - Communiceren. 30

8        CONCLUSIE. 32

9        Bronnen.. 33

10      BIJLAGEN.. 34

10.1   Fact sheet 34

10.2   Uitgebreide situatiebeschrijvingen bij leerdoelen. 41

10.2.1 Leerdoel 1 – situatiebeschrijving 1: Leiden planningspoker 41

10.2.2.......... Leerdoel 1 – situatiebeschrijving 2: Persoonlijke TODO lijstjes. 42

10.2.3. Leerdoel 2 – situatiebeschrijving 1: Daily standup/logboek. 43

10.2.4.......... Leerdoel 2 – situatiebeschrijving 2: Tweede retrospective. 43

10.3   Logboek. 45

1          INLEIDING

In dit project zal ik binnen een team van 5 studenten een HR Portaal realiseren. Het portaal is voor een extern bedrijf. In ons geval is dit bedrijf JDI Smart Web applications. Er is ons gevraagd om het huidige systeem, wat vooral aan de hand van spreadsheats gaat, te optimaliseren met een online hr portaal. Op dit portaal kunnen werknemers en werkgevers inloggen om zaken zoals de werkplek registratie en de reiskosten declaraties te beheren.

Het doel van dit document is om mijn individuele bijdrage aan het OOSE-project te verantwoorden, maar ook om aan te geven wat mijn ervaringen waren binnen dit project en wat ik de volgende keer anders zou doen.

1.1       Inhoudelijke uitdagingen

Over het algemeen denk ik dat het project voor mij goed te doen zal zijn. Vooral omdat ik hiervoor al het i-project en het ISE project heb gehad. Ook zijn er door het project heen meerdere malen nutshell talks die voor mij zaken zoals sonarcube verduidelijken. Met de backend onderdelen heb ik al ervaring opgedaan tijdens de afgelopen periode, dus daar heb ik vertrouwen in. De front-end onderdelen zullen voor mij een stuk uitdagender zijn, omdat ik nog niet eerder met een framework zoals Vue.js heb gewerkt. Zelfs nadat ik twee dagen onderzoek gedaan had naar Vue en het vergeleek met andere frameworks zoals React, heb ik het nog steeds niet helemaal onder de knie.

Na het tussentijdse inlevermoment is Vue voor mij gelukkig een stuk duidelijker geworden, door in het begin simpele taken op te pakken (zoals een lijst van de gebruikers weergeven) werd de structuur snel duidelijk. Hierna heb ik nog een aantal front-end taken opgepakt en dit ging mij goed af.

Een uitdaging die wel door het hele project heen gebleven is, is de tijdsdruk. Ik had bij dit project meer last van een constante tijdsdruk dan bij de vorige projecten. Ik denk dat dit voornamelijk komt omdat we de taken voor dit project duidelijk hebben gepland aan het begin van iedere sprint, en hier ook een tijdsinschatting aan hebben toegevoegd. Bij de planningspoker zat ik qua tijdsinschatting altijd wat hoger dan de rest, wat ervoor zorgt dat de meeste taken minder tijd hebben gekregen dan ik er persoonlijk voor zou hebben geschat. Dit heeft ook gezorgd dat ik regelmatig in tijdsnood kwam, en hierdoor werd het gevoel van tijdsdruk steeds sterker. Inhoudelijk heeft dit geen grote gevolgen gehad, omdat we nog wel wat speling hadden, en sommige taken juist sneller af waren. Dit was vooral een uitdaging in de zin dat het wat minder fijn werkte, en dat ik afgeleid werd door de tijdsdruk.

1.2       Leerdoelen

Leerdoel 1: zelf initiatief nemen met plannen, en minder afwachtend te werk gaan;

Ik wil in dit project beter plannen en minder afwachtend te werk gaan. Ik wil meer initiatief nemen om zelf iets te gaan doen, zonder op het team te wachten zodat zij mij vertellen wat ik moet gaan doen. 

Leerdoel 2: communicatie-skills verbeteren zodat het voor teamgenoten direct duidelijk is wat ze van mij kunnen verwachten, of wat ik aan hen vraag;

Ik wil in dit project mijn ideeën en mijn mening duidelijk op de rest van het team overbrengen. Ik wil mijn communicatie-skills verbeteren. 

Leerdoelen zijn verder uitgewerkt ik hoofdstuk 7.

2          OORDEEL KWALITEIT GELEVERDE DEELPRODUCTEN 

In dit hoofdstuk zal ik voor de deelproducten de kwaliteit beoordelen. Ik kijk in dit hoofdstuk dus terug op wat we als team hebben opgeleverd aan school en aan de opdrachtgever binnen JDI, en ik beoordeel of ik tevreden ben met het opgeleverde werk. Tegelijk laat ik aan de hand van deze beoordelingen zien dat ik over deze producten heb nagedacht en dat ik weet waar de sterke en zwakke punten van alle deelproducten binnen dit project liggen.

2.1       Deelproduct 1 - Plan van Aanpak

Het Plan van Aanpak is een essentieel onderdeel voor een succesvol project, omdat het Perlman ontwikkelteam hierin van tevoren vastlegt hoe we alle onderdelen binnen het project zullen aanpakken en wat we van elkaar en van de opdrachtgever verwachten.

Een groot feedbackpunt wat tijdens het assesment van het plan van aanpak naar voren kwam, was dat het nog niet genoeg op de opdrachtgever gericht is, maar meer op het ontwikkelteam. Zo kwam er duidelijk naar voren dat veel van onze tijd naar pauze, overleg en andere zaken gaat waardoor er minder tijd overblijft voor het echte programmeren. Hier moeten we zorgen dat het plan wat positiever overkomt, bijvoorbeeld door de overige activiteiten kort samen te vatten, in plaats van hier heel veel aandacht aan te besteden.

Na het tussentijdse verslag heb ik als feedback gekregen dat ik mijn beoordeling meetbaar moet maken. Om dit te realiseren zal ik het document ‘Toelichting op het PvA’ (Toelichting op het PvA, z.d.) gebruiken, en de criteria vergelijken met ons product (de tabelvorm is geïnspireerd door de aanpak van Connor, dit lijkt mij een goede methode om meetbaar inzicht in mijn beoordeling te geven).

Al met al komt er voor het PvA een 7.3 uit voor mij.

2.2       Deelproduct 2 – Onderzoeksverslag

Binnen dit project heb ik het Vue.js onderzoek geschreven. Dit zal dan ook het onderzoek zijn die ik ga beoordelen. Ik ben eerst op zoek gegaan naar een aantal meetbare criteria om mijn onderzoek op te beoordelen. Hiervoor heb ik een overzichtelijk document gevonden van de Universiteit van Utrecht (Schrijfwijzer Voor Moderne Talen: Onderzoeksverslag, 2020). Onderstaand heb ik per criteria een oordeel gegeven om tot een eindcijfer te komen.

Al met al kom ik uit op een 5.8. Dit komt wel omdat ik de discussie niet mee heb genomen in mijn front-end framework onderzoek. Als ik de discussie buiten beschouwing laat komt er een nette 6.7 uit.

2.3       Deelproduct 3 – SRS

Om te beginnen ben ik tevreden over de volledigheid van het document. Een groot voordeel van de verslaglegging in dit OOSE project voor mij was dat er in Confluence al een overzicht beschikbaar is van alle onderdelen die in onze documentatie worden verwacht. Zo bevat het SRS al alle hoofdstukken en subkopjes, en is het voor ons team eenvoudiger om hierover na te denken en de kopjes in te vullen. De algemene beschrijven en de actors zijn wat mij betreft duidelijk; werkgever en werknemer en verder hebben we ook de gebruikte technieken en operating systems onderbouwd. Zelf vond ik het nog niet heel logisch om het overzicht van de product functions al in de inleiding te hebben omdat deze pas een stuk later worden uitgewerkt, maar dit was al op deze manier voorgedaan. De inhoudt van het use case diagram is duidelijk, maar deze moet eventueel nog geüpdatet worden. Ik ben bezig geweest met de use case beschrijvingen en merk dat een deel hiervan verouderd is ten opzichte van het systeem wat we binnen het team hebben bedacht. Zo zijn er taken in de sprint die niet overeenkomen met een van de use cases, en ook zijn er use cases zoals ‘berekenen reisafstand’ die eigenlijk alleen door het systeem worden gedaan, waardoor ik niet zeker weet of ze in het schema thuishoren.

Wat betreft de non-functionele requirements, hiervoor heb ik internetbronnen geraadpleegd om inspiratie op te doen, omdat dit in mijn ogen vaak lastig is om concreet op te schrijven. Zo is het van belang dat de site makkelijk te leren en begrijpen is, maar dit is moeilijk om meetbaar te maken. Momenteel denk ik dat er voor de requirements nog wat aanpassingen nodig zullen zijn, maar ik ben wel tevreden met de volledigheid van de non functionele requirements.

Vervolgens hebben we de user stories ook uitgewerkt. Ik vind dit zelf heel handig werken omdat het makkelijk leesbaar is. Binnen de zes zinnen die we voor de user stories hebben geschreven wordt het snel duidelijk wat de scope is van het project, en wat de uiteindelijke eisen aan het hr portaal zullen zijn.

Zoals bovenaan genoemd missen er nog wat use case descriptions, maar de bestaande descriptions zijn wat mij betreft duidelijk. Ze geven een overzicht van de interactie tussen de werknemer/werkgever en het systeem aan de hand van logische stappen. Zelf heb ik hiervoor vooral de technieken gebruikt die we in de vorige periode hebben geleerd.

Voor de concrete beoordeling van het SRS zal ik gebruik maken van de criteria die aan het begin van het project in het Plan van Aanpak zijn vastgelegd.

Alles bij elkaar kom ik voor het SRS uit op een 7.3.

2.4       Deelproduct 4 - SDD

Het SDD is uiteindelijk een beetje een ‘afterthought’ gebleven, waar we eigenlijk eerder aandacht aan hadden moeten besteden. Wat mij betreft hebben we SDD in de laatste week nog redelijk goed in elkaar gezet, maar omdat we er zo laat mee bezig zijn gegaan heeft het niet veel nut gehad tijdens de uitvoering van het project. Ik zal mijn beoordeling van het SDD, net als bij het SRS, baseren op de eisen uit het Plan van Aanpak en op de template die in Confluence beschikbaar was.

Mijn beoordeling van het deployment diagram is gebasseerd op een externe bron waarin een duidelijke uitleg gegeven werd over het bouwen van deployment diagrams (Ugochi, 2021).

Al met al kom ik voor het SDD uit op een 6.6.

2.5       Deelproduct 5 – Unittests

Om het deelproduct Unittests te beoordelen ga ik uit van twee verschillende bronnen. Ik voeg namelijk criteria uit het Plan van Aanpak, en criteria uit een artikel over unit testing (Unit Testing Best Practices, 2021) samen. Net als bij de andere onderdelen zal ik ook hier op basis van de beoordeling van de criteria tot een gemiddeld eindcijfer komen.

Ik ga bij mijn beoordeling uit van alle backend unit tests. Dit zijn de tests waar ik een groot deel aan heb bijgedragen.

Beoordeling criteria PvA

Voor het eerste onderdeel, de beoordeling aan de hand van het PvA, komt er voor mij een 6.9 uit.

Figure 1: mvn test uitgevoerd, alle tests in de backend slagen

Figure 2: geslaagde build in Jenkins

Beoordeling criteria externe bron (Unit Testing Best Practices, 2021)

Al met al komt er voor mijn beoordeling aan de hand van de externe bron een 7.0 uit.

2.6       Deelproduct 6 – Stuk code

Beoordeling aan de hand van backend werkplek overzicht.

Ik heb aan een aantal verschillende onderdelen van het portaal gewerkt (zowel front- als backend, zie hiervoor de factsheet), maar aangezien het werkplekoverzicht een redelijk groot onderdeel is en ik hier het meeste heb geleerd zal ik hierop ingaan (https://bitbucket.aimsites.nl/projects/BUGAYQ/repos/jdi-werknemersbeheer/browse/src/main/java/nl/han/oose/perlman/services/WerkplekService.java?at=refs%2Fheads%2Fmaster).

Zelf heb ik voor het werkplek overzicht de backend code geschreven. Ik ben hier tevreden mee, omdat het goed aansluit op de frontend, en de benodigde functionaliteit bevat om gebruikers van het hr portaal van een plekkenoverzicht te voorzien. Ik heb voor dit onderdeel de structuur aangehouden die ons de vorige periode is aangeleerd, met resources, services, dto’s, dao’s, etc. Om het op deze manier netjes in lagen op te delen. Ook heb ik unit-tests geschreven om de backend voor het werkplek overzicht te testen. Dit zorgt ervoor dat we zeker weten dat de code doet wat hij moet doen.

Huidig is een verbeterpuntje bij dit onderdeel nog de documentatie. Tot nu toe ben ik veel bezig geweest met code schrijven en testen, maar niet zo zeer met de bijbehorende javadoc en uitleg. Ik zal even met het team moeten overleggen hoe we de documentatie willen aanpakken, en vervolgens de werkplek overzicht backend moeten uitbreiden om een duidelijk beeld te geven van de functionaliteit van mijn code.

Nu het project is afgrond realiseer ik mij dat we als team niet meer zijn teruggekomen op de javadoc. Dit houdt in dat in de codebestanden zelf geen documentatie is terug te vinden. Wel hebben we voor alle code, inclusief het werkplek overzicht, api documentatie geschreven in de Confluence (https://confluenceoosevt.aimsites.nl/display/BUGAYQ/Flexwerkplek+overzicht). Dit maakte de coördinatie tussen front- en backend development ook makkelijker, omdat de front-end developers simpelweg in de api documentatie konden kijken om duidelijkheid te krijgen over de verwachtte parameters.

Ik zal het deelproduct code beoordelen aan de hand van de 7 attributen van goede code (Tikayatray, 2022).

Al met al kom ik voor het onderdeel code uit op een 6.7.

2.7       Deelproduct 7 - Testrapport

Net als het SDD, is tijdens dit project ook het testrapport een beetje een ‘afterthought’ gebleven naar mijn mening (neemt niet weg van de kwaliteit, we zijn er alleen laat aan begonnen). We hebben voor de backend alle unittests wel geschreven in combinatie met de code, dus dit is helemaal in orde. Voor de front-end werden de unittests wat langer uitgesteld. Het testrapport zelf hebben we pas helemaal aan het einde opgesteld. Dit betekend dat we wel een algemene beeld hadden van de kwaliteit van onze code, maar het werd pas helemaal aan het einde duidelijk of echt alles fatsoenlijk traceable was. Een groot voordeel met betrekking tot het testen was ook dat door het gebruik van Jenkins en Sonarqube, automatisch onze unittests werden nagelopen om te verifiëren dat er geen foutieve tests meer tussenzaten.

Om het testrapport zelf te beoordelen zal ik gebruik van de (magere) criteria die in het Plan van Aanpak staan:

Opmerking bij de bovenstaande tabel; oorspronkelijk waren alleen de bovenste 2 criteria in het PvA genoemd, maar ik vind de integratie testen ook een belangrijk onderdeel om mee te nemen in de beoordeling.

Ik kom voor het testrapport uit op een mooie 8. Tijdens het schrijven van deze beoordeling missen nog wel een aantal tests uit de front end in het testrapport. Ik ben er bij mijn beoordeling vanuit gegaan dat deze nog tijdig worden toegevoegd.

3          Oordeel kwaliteit geleverd eindproduct

Om het eindproduct te beoordelen zal ik terugkijken op de beoordeling van alle deelproducten bij elkaar. Voordat ik dit doe, zal ik eerst een beoordeling opstellen van de User Stories uit het SRS, omdat deze stories een goed beeld geven van de gewenste functionaliteit.

Al met al kom ik terugkijkend op de originele user stories uit op een 6.6.

Wel wordt dit resultaat sterk naar beneden gehaald door de missende slack koppeling. Het besluit om de slack koppeling niet meer in te bouwen, is genomen in overleg met de opdrachtgever. Daarom zou er beredeneerd kunnen worden dat dit niet meegenomen hoefde te worden in de beoordeling, waardoor het gemiddelde drastisch hoger ligt.

De deelproducten heb ik zoals in bovenstaande hoofdstukken beschreven als volgt beoordeeld;

• PvA: 7.3
• Onderzoeksverslag: 6.7 (discussie onderdeel niet meegenomen in beoordeling)
• SRS: 7.3
• SDD: 6.6
• Unittests: 7.0 (gemiddelde van 6.9 en 7.0 naar boven afgerond)
• Code: 6.7
• Testrapport: 8

Puur gebaseerd op de deelproducten, komt er voor het eindproduct dus een 7.1 uit.

4          Evaluatie PROJECTMETHODE 

Voor dit project gebruiken we de Scrum methode. Ten opzichte van de RUP methode vindt ik het hieraan fijn dat de beginfase wat korter is. Dit zorgt ervoor dat we na het plan van aanpak gelijk aan de slag konden. Het voordeel hiervan is dat het praktische werken duidelijk maakt waar voor mij de knelpunten zitten, en welke onderdelen mij juist goed afgaan. Ook is er voor het hele team meer tijd over om de tools te leren en de code te maken.

Ook vind ik het fijn aan scrum dat er aan aantal vaste momenten bestaan, zoals de retrospective en de sprint review. Dit zorgt ervoor dat we iedere sprint weten waar we aan toe zijn en ook naar het volgende moment kunnen toewerken. Verder geeft de retrospective een duidelijk beeld van hoe we de volgende sprint kunnen optimaliseren.

Om een duidelijke opsomming te geven van de Scrum methode, quote ik hier het Plan van Aanpak hoofdstuk 7 (onderdeel door mij geschreven);

“Binnen dit project zal het ontwikkelteam op een Agile manier te werk gaan. Aan de hand van Scrum wordt iedere sprint een iets groter product opgeleverd, en na de laatste sprint zijn pas alle use cases geïmplementeerd. Dit betekend dat het HR Portaal wat JDI Smart Web applications voor ogen heeft incrementeel tot stand zal komen. Alhoewel er vanaf het begin van het project door het team gekeken wordt naar de globale requirements, wordt bij elke individuele sprint echt vastgelegd welke use cases er na de desbetreffende sprint af moeten zijn. Op deze manier weet de opdrachtgever waar hij aan toe is, omdat er na iedere sprint een concreet resultaat af is (het gaat hier om een subset van de uiteindelijke features). Voordat het ontwikkelteam begint met de incrementele sprints, zal in de eerste week nog een globaal overzicht van het project worden gevormd aan de hand van overlegmomenten en doormiddel van dit Plan van Aanpak.

Om dit project goed via Scrum te kunnen uitvoeren, zijn een aantal vaste momenten van belang. Ten eerste zal het ontwikkelteam dagelijks om 09:30 een daily standup houden. Dit is een kort overleg waarbij wordt afgestemd wat ieder teamlid de voorgaande dag gedaan heeft, en wat hij voor die dag op de planning heeft. Op deze manier zal duidelijk inzichtelijk worden waar iedereen staat, en wordt het duidelijk of er knelpunten in het proces zijn. Naast de daily standup die in de ochtend plaatsvindt, kan er ook nog gekozen worden om een mid-daily standup te houden. Dit is hetzelfde als de daily standup, maar dan om te checken of iedereen die ochtend goed aan de slag is geweest en om een planning te maken voor de rest van de dag. Of er ook ruimte en belang is voor een mid-daily standup zal tijdens de eerste sprint duidelijk worden. Naast de daily standups zullen er tussen de sprints ook sprint planning en sprint retrospective ceremonies plaatsvinden. Dit is om te kijken waar de verbeterpunten van de afgelopen sprint in zitten, en om al vast voor te bereiden op de aankomende sprint. Denk hierbij bijvoorbeeld aan het selecteren van de use cases die in de volgende sprint worden opgepakt. Ten slotte wordt er na iedere sprint ook een sprint review gehouden, waarbij de resultaten van de afgelopen sprint worden gepresenteerd aan de stakeholders, dus o.a. aan Jarno Eggink en Wim Reuterink van JDI.”

Het enige wat onhandig is aan onze methode van werken, is dat taken soms te lang in review kunnen blijven hangen. Voor de veiligheid bestaat een systeem waarbij ieder onderdeel door twee teamleden wordt gereviewed. Op zich is dit een goed idee, maar het zorgt ervoor dat sommige onderdelen soms meer dan een week blijven hangen voordat ze in Done komen te staan. Een manier om dit op te lossen zou zijn om een duidelijk systeem in te voeren waarmee teamleden kunnen aangeven wanneer een nieuwe taak openstaat voor review, zodat hier meer prioriteit aan gegeven wordt.

Om hier in het eindverslag op terug te komen; in de laatste sprint hebben we aan de hand van een Discord kanaal inderdaad meer structuur aangebracht wat betreft de openstaande taken/pull requests. Dit heeft erg geholpen, in plaats van PR’s die meerdere dagen openstaan duurde het nu nog maar maximaal een half uur (en vaak zelf binnen 10 minuten) voordat een PR naar develop kon worden gemerged (of werd afgekeurd, afhankelijk van de kwaliteit van het werk).

Voor de laatste sprint hebben we als team ook nog gekozen om een mid-daily standup toe te voegen aan de scrum ceremonies (zoals in het PvA beschreven zagen we dit als een optioneel onderdeel). Echter zijn we hier minder consistent in geweest dan met de daily standup, waardoor het wat mij betreft helaas niet veel heeft toegevoegd.

5          ROLLENBESCHRIJVING 

In het OOSE project is mijn hoofdrol de Planner. Ik moet ervoor zorgen dat het voor iedereen duidelijk is wat er wanneer af moet zijn en dat er voor iedere sprint realistische taken worden opgesteld.

Tot nu toe vind ik het wel een behoorlijke uitdaging om planner te zijn, omdat ik van mezelf niet zo goed ben in plannen. Aan de andere kant zorgt het er ook voor dat dit een goede ontwikkelkans is, die ik hopelijk ook kan meenemen naar volgende projecten. Naast planner ben ik, net als alle andere teamleden, onderdeel van het Development Team. Dit houdt in dat alhoewel de focus voor mij ligt bij het op orde houden van de planning, ik ook gewoon inhoudelijke taken oppak.

Een uitdaging voor mij is om de taak van Planner goed op mij te nemen en niet per ongeluk uit handen te geven. Zo komt het bij het begin van een nieuwe sprint wel voor dat teamgenoten het plannen tijdens een gesprek een beetje overnemen. Dat is natuurlijk goed bedoelt, maar het beste zou zijn als ik het zelf onder de knie kan krijgen zodat ik de planningspoker efficiënt kan leiden, en de afspraken ook in de Jira kan opnemen. Om een concreet voorbeeld te noemen (aan de hand van STARRT);

Ik ben grotendeels verantwoordelijk geweest voor de planningspoker momenten. Om de situatiebeschrijving van mijn eerste leerdoel te quoten;

“Mijn taak in de planningspoker was om de meeting vantevoren voor te bereiden, zodat de issues in orde waren en de tijd ingeschat kon gaan worden. Ook was mijn taak om de rust te bewaren tijdens het overleg over de tijdsinschattingen, en om tot een inschatting te komen waar ieder teamlid zich in kon vinden. Op meer praktisch niveau werd ook van mij verwacht dat ik de resultaten van de planningspoker in Jira vastlegde, zodat we dit niet zouden vergeten. Zelf wilde ik met de planningspoker meetings bereiken dat er een realistische tijdsinschatting voor alle op te pakken issues zou komen. Ook wilde ik mijn skills als meeting-begeleider verbeteren en iedereen het gevoel geven dat hun mening even zwaar meeweegt als de rest van het team. De andere teamgenoten verwachtten vooral van mij dat ik de poker voor had bereid zodat het duidelijk was welke taken er geschat zouden gaan worden, en dat ik het resultaat vastlegde.”

Zoals het woord al zegt, is van alle scrum-onderdelen de planningspoker het meest direct toepasbaar op mijn rol als Planner. Wat ik voor de volgende keer wil meenemen is om actiever de taken die bij de Planner rol horen op te pakken. Bij dit project werden de eerste twee poker momenten nog grotendeels door het hele team geleid, in plaats van dat ik voortouw nam. In het vervolg zal ik zelf, direct vanaf het eerste planningsmoment, individueel moeten voorbereiden om planningstaken (denk aan het klaarzetten van de in te schatten issues) uit handen van mijn teamgenoten te nemen. Natuurlijk is het plannen zelf wel een teamtaak, omdat iedereen het eens moet zijn over de uiteindelijke planning.

6          Toelichting COMPETENTIES  

In dit hoofdstuk zal ik mijn competenties in detail aantonen aan de hand van situatiebeschrijvingen en voorbeelden in het project.  

6.1       OOSE P-03. De student voert een kwalitatief en kwantitatief onderzoek op een systeem uit en levert hierover een onderzoeksrapport op.

Vroeg in dit OOSE project heb ik mij gefocust op het schrijven van een onderzoek over het Vue.js front-end framework. Dit onderzoek staat ook op confluence onder het kopje 'Onderzoeken' (factsheet 11 t/m 15). Om te beginnen heb ik voor mijzelf duidelijk gemaakt wat er in het onderzoek naar voren moest komen, en waar het onderzoek uiteindelijk voor dient. Een belangrijk onderdeel hiervan is het opstellen van de hoofdvraag, en de daarop volgende deelvragen. Vervolgens heb ik vooral aan de hand van externe bronnen de deelvragen beantwoord. Hierbij heb ik bijvoorbeeld vergelijkende onderzoeken geraadpleegd, wat blijkt uit deze afbeelding:

Terugkijkend op dit onderzoek denk ik niet dat het de 7 uur waard is geweest die ik erin heb gestopt. Aan het begin van het project was het eigenlijk al duidelijk dat Vue.js het front-end framework naar keuze zou worden. Aangezien het rapport voor een groot deel gaat over de criteria aan het front-end framework, en over de vergelijking met andere frameworks, is dit niet helemaal nodig geweest. Gelukkig is uit het onderzoek naar voren gekomen dat Vue ook echt past bij dit project. Hierbij kan het wel zo zijn dat, aangezien we al van plan waren om Vue te gebruiken, dit het onderzoek biased heeft gemaakt. Een goede oplossing was geweest om voor een middenweg te kiezen; dit houdt in, kort uitzoeken hoe Vue in elkaar zit en checken of het ook echt toepasbaar is op ons project. We hadden in dit geval de uitgebreide vergelijking met andere frameworks achter wege kunnen laten, en hierdoor had in ieder geval 3-4 uur bespaard kunnen worden die ik in inhoudelijke taken had kunnen stoppen.

6.2       OOSE P-04. De student ontwerpt de software van een systeem en documenteert deze onder andere met behulp van UML diagrammen en decision templates in een Software Design Specification (SDD)

Om te beginnen zal ik kort weergeven welke onderdelen ik heb gerealiseerd om aan deze competentie te voldoen. Zo heb ik ten eerste het architectural overview gemaakt (factsheet onderdeel 17):

Dit ontwerp geeft een high-level idee van de structuur van het hr portaal. Momenteel is het nog een redelijk eenvoudig ontwerp, en in de laatste sprint zullen hier nog dingen zoals de Slack oplossing aan worden toegevoegd. Ik heb mijn best gedaan om het ontwerp consistent en overzichtelijk te houden, bijvoorbeeld door het gebruik van de icoontjes die visueel weergeven wat ieder onderdeel betekend.

Later is aan dit onderdeel nog een uitgebreide omschrijving toegevoegd in tekstvorm, dit heb ik echter niet geschreven maar is door een teamgenoot toegevoegd.

Ik heb van een teamgenoot gehoord dat een verbeterpunt op dit onderdeel zit bij de icoontjes. Ik heb de icoontjes heel abstract gehouden om het ontwerp een strakke look te geven. Echter zou het beter geweest zijn om de logo’s van de gebruikte frameworks in te voegen. Bijvoorbeeld het Vue logo bij de front-end, en Spring Boot bij de backend.

Ook heb ik voor dit onderdeel het Design class diagram voor de gehele backend gemaakt (factsheet onderdeel 18):

https://confluenceoosevt.aimsites.nl/download/attachments/270041806/OOSE%20project%20backend%20class%20diagram.png?version=1&modificationDate=1654693873978&api=v2           

Dit ontwerp geeft een overzicht van de dto’s, dao’s, services, resources, etc en de relaties hiertussen. Ik heb dit opgesteld om richting mensen die minder bekend zijn met de codebase dan het ontwikkelteam een beeld te geven van hoe de backend in elkaar zit.

Terugkijkend ben ik van mening dat dit diagram te groot is geworden om nog een duidelijk overzicht te kunnen geven van het systeem. Als ik het design class diagram onderdeel opnieuw zou doen, zou ik in plaats van het huidige ontwerp, meerdere diagrammen maken. Ik zou dan kiezen om 1 diagram per onderdeel (werkplekken, verlof, inloggen, etc) te bouwen, zodat de onderlinge relaties tussen dao’s, services, resources, etc nog steeds zichtbaar blijft, maar dan met iets minder context van de andere onderdelen.

Ten derde ben ik ook bezig geweest met het Sub Systeem backend (factsheet 19 en 20). Aangezien dit onderdeel ook overeenkwam met mijn programmeertaken, heb ik het documentatie gedeelte ook op mij genomen. Hier is het sequence diagram dat weergeeft hoe een declaratie kan worden aangemaakt:

Verder heb ik hierbij voor het 'design decisions' onderdeel elke beslissing toegelicht als volgt:

Bij deze onderdelen (de sequence diagrammen en de design decisions) is het grootste verbeterpunt de volledigheid. Momenteel zijn er maar 4 sequence diagrammen aanwezig, en slechts een deel van de beslissingen is vastgelegd. Dit komt voornamelijk doordat we pas aan het einde de documentatie op orde zijn gaan maken, terwijl de meeste grote beslissingen toen al eerder genomen waren. Ook hadden we sub-system onderdeel in de SDD eerst verkeerd begrepen, waardoor we niet het hele backend als 1 sub-system hebben behandeld. Omdat dit heel laat in het project nog verbeterd moest worden hebben we gekozen om simpelweg de bestaande sequence diagrammen over te nemen en samen te voegen in het backend onderdeel.

Voor de beslissingen hadden we eigenlijk tijdens de gezamenlijke overlegmomenten in ieder geval een teamgenoot moeten aanstellen om notities te maken. Op die manier hadden we het of direct na de overlegmomenten, of aan het einde, allemaal bij elkaar in het SDD kunnen plaatsen. Zo aan het einde van het project bleek toch dat het heel ingewikkeld is om met terugwerkende kracht alle ontwerpbeslissingen nog te verwoorden.

6.3       OOSE P-05. De student implementeert een gedistribueerd systeem, evalueert het ontwerp en de realisatie daarvan en zorgt voor traceerbaarheid daartussen en naar de functionele en niet-functionele eisen.

Aangezien ik bij de deelproducten al het werkplekoverzicht heb uitgewerkt, zal ik hier ingaan op de backend voor het reserveren van een werkplek (factsheet onderdeel 22). Dit is een interessant onderdeel omdat de logica zelf, dat wil zeggen de logica voor het aangeven van een reservering, niet moeilijk is. Wat een stuk meer van mij vergde was het afdekken van alle checks die nodig zijn voordat een werkplek gereserveerd kan worden.

Hier volgt een stuk code uit de werkplek service, die het reserveren van een werkplek afhandeld:

public ResponseEntity reserveerWerkplek(String datum, String locatie, String werkpleknaam, int ingelogdeWerknemerId, boolean verwijder) throws SQLException {    if (!locatieBestaat(locatie))
        return new ResponseEntity(locatieBestaatNiet, HttpStatus.NOT_FOUND);

    LocalDate reserveerDatum;
    try {
        Date reserveerDatumDate = new SimpleDateFormat("yyyy-MM-dd").parse(datum);
        reserveerDatum = reserveerDatumDate.toInstant()
                .atZone(ZoneId.of(TIJDZONE))
                .toLocalDate();

    } catch (ParseException e) {
        LOGGER.log(Level.SEVERE, "Datum is incorect geformateerd", e);
        return new ResponseEntity("Ongeldige datum format", HttpStatus.BAD_REQUEST);
    }

    if (!verwijder) {
        LocalDate currentDate = LocalDate.now(ZoneId.of(TIJDZONE));

        if (reserveerDatum.isBefore(currentDate))
            return new ResponseEntity("Reserveerdatum kan niet vóór vandaag zijn", HttpStatus.BAD_REQUEST);

        List<WerkplekDTO> werkplekkenOpLocatie = werkplekDAO.getWerkplekkenOpLocatie(locatie);
        WerkplekDTO targetWerkplek = werkplekkenOpLocatie.stream().filter(w -> w.getWerkplekNaam().equals(werkpleknaam)).findFirst().orElse(null);
        if (targetWerkplek == null)
            return new ResponseEntity("Werkplek bestaat niet voor locatie", HttpStatus.NOT_FOUND);

        List<WerknemerDTO> werknemersGegevensOpWerkplek = werkplekDAO.getWerknemersGegevensOpWerkplek(locatie, werkpleknaam, datum);
        boolean gereserveerd = werknemersGegevensOpWerkplek.stream().anyMatch(w -> w.getWerknemerId() == ingelogdeWerknemerId);
        if (gereserveerd)
            return new ResponseEntity("U hebt deze plek al gereserveerd", HttpStatus.CONFLICT);

        List<WerknemersOpWerkplekDTO> werknemersOpWerkplekByDate = werknemersOpWerkplekDAO.getWerknemersOpWerkplekByDate(datum);
        boolean alGereserveerdVandaag = werknemersOpWerkplekByDate.stream().anyMatch(w -> w.getWerknemerId() == ingelogdeWerknemerId);
        if (alGereserveerdVandaag)
            werkplekDAO.reserveerWerkplek(locatie, werkpleknaam, ingelogdeWerknemerId, datum, true);

        int capaciteit = targetWerkplek.getCapaciteit();
        int hoeveelheidWerknemers = werknemersGegevensOpWerkplek.size();
        if (hoeveelheidWerknemers >= capaciteit)
            return new ResponseEntity("Deze plek zit vol", HttpStatus.CONFLICT);
    }

    werkplekDAO.reserveerWerkplek(locatie, werkpleknaam, ingelogdeWerknemerId, datum, verwijder);

    String response;
    if (verwijder) {
        response = "Reservering is ongedaan gemaakt";
    } else {
        response = "Werkplek is gereserveerd";
    }
    return new ResponseEntity(response, HttpStatus.OK);
}

Zoals in de code te lezen is, heb ik gebruik gemaakt van veel verschillende response entities en meerdere http status codes. Zo wordt allereerst gecheckt of een locatie bestaat, voordat er een werkplek op die locatie gereserveerd kan gaan worden.

Wat ik terugkijkend op dit code onderdeel zou verbeteren, is dat de Response entity logica niet in deze klasse zou moeten worden afgehandeld. Dit is feedback die we tussentijds van de projectbegeleider hebben ontvangen. Idealiter zou de service puur de communicatie met de data access objects afhandelen en zouden we de response in de resource klasse in elkaar zetten. De reden dat we dit niet meer hebben gedaan is voornamelijk een tijdsgebrek. We wilden inconsistente code voorkomen, wat betekend dat als we op 1 plek de response entity code verplaatsen, we dit voor alle onderdelen zouden moeten doen. Hiervoor was geen tijd meer over aan het einde, omdat we nog veel documentatie taken open hadden staan.

6.4       OOSE P-07. De student bewaakt continu de kwaliteit van de software en het proces door o.a. reviews en gestructureerd testen en stuurt waar nodig bij.

Om te beginnen heb ik voor al mijn backend onderdelen zelf de unit tests gemaakt (factsheet 37 t/m 40). Dit houdt in dat, voordat ik een onderdeel op ‘done’ zette, ik eerst al mijn code getest heb. Om terug te koppelen op het code fragment uit hoofdstuk 6.3, zal ik een voorbeeld geven van een test die betrekking heeft op het reserveren van een werkplek:

@Test

public void reserveerNietBestaandeLocatie() throws SQLException {
    var expected = new ResponseEntity("Locatie bestaat niet", HttpStatus.NOT_FOUND);

    when(locatieDAOMock.getLocaties()).thenReturn(null);

    var actualValue = sut.reserveerWerkplek("2022-03-21", "Hoofdkantoor", "Flexwerkplek A", 0, false);

    Assertions.assertEquals(expected, actualValue);
}

Dit is expres een kleine test, zodat ik duidelijk de structuur kan beschrijven. Zoals te zien in bovenstaande code begint iedere (backend) unittest met een expected waarde. Dit is wat ik van de test verwacht als uitkomst. Vervolgens worden eventuele onderdelen gemocked, dit betekend dat als het te testen onderdeel afhankelijk is van code die ik niet wil testen, ik aangeef wat deze externe code moet returnen. Op deze manier houd ik volledige controle over wat er getest word, en kan de test niet worden beïnvloed door andermans code of door de inhoud van mijn database.

Hierna maak ik een variabele aan voor de ‘actual value’. Dit is het echte resultaat wat er uit het geteste stuk code komt. Ten slotte vergelijkt de test de verwachte waarde met de echte waarde om te checken of de test succesvol is geweest.

In sommige gevallen kan de verwachte waarde ook een simpele boolean zijn, in dat geval kunnen andere ingebouwde functies zoals assertTrue worden gebruikt en is er geen losse expected variabele meer nodig.

Terugkijkend op de manier waarop ik unit tests heb verwezenlijkt ben ik eigenlijk heel tevreden. Het enige wat ik beter had kunnen doen was om eerder te leren hoe de unit tests werken. Het duurde een paar weken voordat ik mijn onderdelen echt consistent begon te testen, waardoor ik halverwege het project nog redelijk wat tests moest inhalen van eerder geschreven code (dit gaat in tegen de inleiding van dit hoofdstuk, aangezien ik de workflow zoals in de inleiding beschreven pas later heb opgepakt).

Verder heb ik tijdens het hele project netjes met Pull Requests gewerkt. Dit wil zeggen, voordat code naar de develop toeging hebben twee teamgenoten het gecontroleerd en van feedback voorzien. Zelf heb ik dit ook gedaan (zie factsheet 41 voor een voorbeeld) voor andere teamgenoten. Zo een request ziet er als volgt uit:

Figure 3: beoordeling pull request

Zoals te zien in bovenstaand figuur, heb ik een comment achtergelaten op de code van Connor. Vervolgens kon ook met de knoppen rechtsboven de pull request worden goedgekeurd of afgekeurd. Inmiddels is deze pr goedgekeurd zoals in de afbeelding te zien, maar ten tijden van het commentaar hebben we deze op afgekeurd gezet, zodat het niet per ongeluk gemerged kon worden.

Een verbeterpunt bij deze pull request was dat het door een groot deel van het project heen nog heel lang duurde voordat er twee teamleden naar een request hadden gekeken. Zelf heb ik de pull requests toen ook niet voldoende in de gaten gehouden. Zo konden pr’s soms dagen openstaan en nieuwe taken hinderen. We hebben dit probleem richting het einde van het project nog wel weten op te lossen door middel van een discord kanaal. Hierin kon het team gepinged worden als er een nieuwe request was, waardoor het zelden langer dan een half uur duurde voordat een pull request door meerdere teamgenoten was gekeurd.

Ten slotte voor deze competentie heb ik een groot aantal eerder geschreven testen inzichtelijk gemaakt in het test rapport. Dit rapport geeft een duidelijk overzicht van alle uitgevoerde testen, en van de coverage van onze code. Mijn onderdeel van het testrapport is terug te vinden bij mijn persoonlijke documenten op confluence: https://confluenceoosevt.aimsites.nl/display/BUGAYQ/Testrapport           

Ik ben tevreden met dit onderdeel, maar zoals eerder genoemd had dit een stuk eerder gedaan moeten worden om het overzicht van de tests te behouden.

7          Leerdoelen

In dit hoofdstuk vindt u een verdere toelichting bij mijn leerdoelen. Mijn leerdoelen zijn sinds het ISE project eigenlijk weinig veranderd, want mijn grootste verbeterpunten zitten nog steeds in het plannen en communiceren.

7.1       Eerste leerdoel - Plannen

Ik wil in dit project beter plannen en minder afwachtend te werk gaan. Ik wil meer initiatief nemen om zelf iets te gaan doen, zonder op het team te wachten zodat zij mij vertellen wat ik moet gaan doen. 

Aanleiding 

In eerdere projecten was ik zeer afwachtend, wat betekend dat ik pas productief werd als anderen mij vertelden wat ik moest gaan doen. Dit zorgt voor een minder productieve houding en mijn bijdrage in het project lijdt hieronder. 

Actiepunten 

Het maken van de project-planning, is een belangrijke taak binnen mijn rol. 

Begin van iedere dag een duidelijke lijst met dingen opstellen die ik die dag kan doen. Deze lijst moet voldoende punten bevatten om de rest van de dag productief bezig te kunnen zijn. Dit kunnen bijvoorbeeld ook dingen zijn waar ik de voorafgaande dag nog niet aan toe was gekomen.

Mid-daily standup om te kijken waar ik (en de rest van het team) staan en waar we mee bezig kunnen. 

Einddoel 

Voorkomen dat er momenten ontstaan waarbij ik niet weet waar ik aan kan werken. Dit houdt in dat ik zelf overzicht houd en niet afhankelijk ben van teamgenoten om mij een taak te geven.

Dit leerdoel slaat vooral op de gedragscompetenties Probleemanalyse, Visie en Plannen en organiseren. (Gedragscompetenties, 2007)

7.2       Tweede leerdoel - Communiceren

 Ik wil in dit project mijn ideeën en mijn mening duidelijk op de rest van het team overbrengen. Ik wil mijn communicatie-skills verbeteren zodat het voor teamgenoten direct duidelijk is wat ze van mij kunnen verwachten, of wat ik aan hen vraag. 

Aanleiding 

In het i-project van afgelopen schooljaar kon ik soms onduidelijk doen, waardoor het voor teamgenoten niet helder was waar ik mee bezig was of wat ik aan hun vroeg. Dit levert problemen op omdat het ten eerste inefficiënt is om meerdere keren dingen te moeten herhalen, en ten tweede kan het ervoor zorgen dat ik aan de verkeerde dingen ga werken. 

Ik heb tijdens het OOSE project bij de retrospective ook als feedback gekregen dat ik soms te terughoudend ben, en dat ik moet opletten dat als ik ergens een mening over heb het wel naar voren komt.

Actiepunten 

Ik wil rustig en helder praten. 

Ik wil na mijn woord gedaan te hebben, nagaan of het ook duidelijk is overgekomen. 

Voor de daily standups moet ik zorgen dat ik de dag ervoor mijn logboek in orde heb, zodat ik makkelijker kan vertellen wat ik heb gedaan.

Als ik in groepsverband mijn woord wil doen, niet direct terugtrekken, maar een goed moment zoeken om ertussen te komen.

Einddoel 

Ik wil duidelijk communiceren en zorgen dat het bij overleg direct duidelijk is waar ik het over heb en wat anderen van mij kunnen verwachten.  

Dit leerdoel slaat vooral op de gedragscompetenties Mondelinge presentatie, Mondelinge uitdrukkingsvaardigheid, Optreden en Sociabiliteit. (Gedragscompetenties, 2007)

Ik heb voor deze leerdoelen verdere situatiebeschrijvingen gemaakt in bijlage 10.2.

8          CONCLUSIE 

In dit document heb ik mijn bijdrage beschreven in het OOSE project. Ik hoop dat dit document goed laat zien waar voor mij de uitdagingen liggen in het OOSE project, en waar ik juist goed aan heb kunnen werken. Aangezien mijn leerdoelen voor de projecten tot nu toe veelal hetzelfde zijn gebleven, heb ik ook tijdens dit project erg gefocussed op het verbeteren van mijn communicatie- en mijn planningsvaardigheden (hiervoor heb ik uitgebreide situatiebeschrijvingen gemaakt in hoofdstuk 10.2).

Een groot voordeel van dit project ten opzichte van de twee projecten hiervoor, is dat het voor een echte opdrachtgever is. Voor mij werkt het motiverend om te zien dat Wim van JDI enthousiast is over de producten die we als team hebben gemaakt.

Al met al ben ik heel tevreden met mijn eigen bijdrage aan het OOSE project. Kijkend naar mijn factsheet en de uitwerkingen van mijn competenties ben ik zeker van mening dat mijn bijdrage binnen dit project ruim voldoende is geweest. Ik vond het een leuke uitdaging om mijn tijd niet alleen aan backend taken te besteden, maar ook regelmatig te switchen naar documentatie taken en zelfs een aantal front-end onderdelen. Ik merkte dat waar ik aan het begin van het project nog een beetje opzag tegen de programmeertaken, ik door het project heen juist steeds enthousiaster werd om nieuwe features te implementeren en taken op te pakken.

Ook is de communicatie binnen het team goed verlopen; Hier en daar zaten inhoudelijke verbeterpunten, maar deze zijn tijdens de retrospectives naar voren gekomen. De sfeer was wat mij betreft heel fijn, wat het ook leuker maakte om gezamenlijk voor JDI een HR Portaal te bouwen.

Het belangrijkste wat ik uit dit project meeneem is het overzicht van een hele applicatie; van front-end code tot database structuur. Ik zal deze structuur en de manier van werken ook meenemen naar mijn stage volgend schooljaar.

9          Bronnen

Onderwijsonline documenten. (z.d.). Onderwijsonline. Geraadpleegd op 11 mei 2022, van https://han.onderwijsonline.nl/elearning/lesson/4NoG0RvN

Gedragscompetenties. (2007, 19 juli). www.van-osch.com. Geraadpleegd op 9 juni 2022, van http://www.van-osch.com/lipoweb/opr0.htm

1. (2013, 10 juni). STARRT methode. Meesterschap. Geraadpleegd op 9 juni 2022, van https://meesterschap.wordpress.com/2013/06/09/starrt-methode/

Toelichting op het PvA. (z.d.). han.onderwijsonline.nl. Geraadpleegd op 10 juni 2022, van https://han.onderwijsonline.nl/elearning/lesson/Rq95dp8q

Schrijfwijzer voor Moderne Talen: Onderzoeksverslag. (2020, 3 september). Libguides. Geraadpleegd op 10 juni 2022, van https://libguides.library.uu.nl/c.php?g=202130&p=1331602

Ugochi, U. (2021, 5 augustus). Deployment Diagrams Explained. Plutora. Geraadpleegd op 10 juni 2022, van https://www.plutora.com/blog/deployment-diagrams-explained-in-detail-with-examples             

1. (2021, 12 maart). Unit Testing Best Practices. Www.Testim.Io. Geraadpleegd op 10 juni 2022, van https://www.testim.io/blog/unit-testing-best-practices/

Tikayatray, L. (2022, 6 januari). 7 Simple Attributes of Good Code. Medium. Geraadpleegd op 10 juni 2022, van https://levelup.gitconnected.com/7-simple-attributes-of-good-code-70c24cd75ad7

10      BIJLAGEN 

10.1   Fact sheet 

In deze bijlage vindt u een factsheet die mijn competenties aantoont aan de hand van voorbeelden. De OOSE-competenties zijn als volgt:

Opmerking bij bovenstaand factsheet; ik heb de facts voor competentie 3 opgesplitst in de hoofdstukken van het Vue.js onderzoek, omdat het anders niet aan de 3-5 facts zou voldoen. Ik heb het hele Vue.js onderzoek geschreven.

10.2   Uitgebreide situatiebeschrijvingen bij leerdoelen

In dit hoofdstuk zal ik aan de hand van de STARRT methode (STARRT methode, 2013) situatiebeschrijvingen maken bij mijn eerdergenoemde leerdoelen.

10.2.1   Leerdoel 1 – situatiebeschrijving 1: Leiden planningspoker

Voor elk van de 3 sprints hebben we als team een planningspoker uitgevoerd. Dit is een scrum ceremonie waarbij, na het opstellen van de uit te voeren issues, de tijd voor iedere issue wordt ingepland. Ik heb mijn best gedaan om deze ceremonies te leiden. Dit houdt in dat iedereen de kans kreeg om een tijdsinschatting voor de betreffende issue te maken, en vervolgens ook zijn inschatting kon toelichten. De planningspoker werd op locatie op de Han uitgevoerd, waarbij we met het hele team om de tafel gingen zitten, en op het grote scherm de issues lieten zien.

Mijn taak in de planningspoker was om de meeting vantevoren voor te bereiden, zodat de issues in orde waren en de tijd ingeschat kon gaan worden. Ook was mijn taak om de rust te bewaren tijdens het overleg over de tijdsinschattingen, en om tot een inschatting te komen waar ieder teamlid zich in kon vinden. Op meer praktisch niveau werd ook van mij verwacht dat ik de resultaten van de planningspoker in Jira vastlegde, zodat we dit niet zouden vergeten. Zelf wilde ik met de planningspoker meetings bereiken dat er een realistische tijdsinschatting voor alle op te pakken issues zou komen. Ook wilde ik mijn skills als meeting-begeleider verbeteren en iedereen het gevoel geven dat hun mening even zwaar meeweegt als de rest van het team. De andere teamgenoten verwachtten vooral van mij dat ik de poker voor had bereid zodat het duidelijk was welke taken er geschat zouden gaan worden, en dat ik het resultaat vastlegde.

Mijn aanpak voor de planningspoker was om ten eerste de meeting voor te bereiden met de issues van die sprint. Vervolgens zorgde ik dat iedereen op de hoogte was van de planningspoker en klaar was om te beginnen. Daarna zette ik, of een teamgenoot, het overzicht op het bord. Om de planningspoker gestructureerd te laten verlopen is er besloten om een online planningspoker-tool te gebruiken waarin ieder teamlid een inschatting kon maken. Per issue heb ik samen met het team een middenweg gezocht waar iedereen het mee eens was. Als er te grote discussies ontstonden, of de inschattingen te ver uit elkaar lagen konden we als team twee dingen doen; of we gingen tijdelijk door naar de volgende issue, om deze een tijdsinschatting te geven, of we lieten het met rust om verdere spanning te voorkomen en pakte de planningspoker de volgende ochtend verder op.

De planningspoker zelf heeft heel goed gewerkt, ook al waren er hier en daar onenigheden, uiteindelijk hebben we voor alle sprints de issues weten te schatten. Er was een moment waar een hele grote discussie uitbrak die er uiteindelijk toe leidde om de poker tot de volgende dag uit te stellen. Bij dit moment had ik nog eerder in moeten grijpen, omdat het naderhand al te lang een uitzichtloze discussie bleek. De volgende dag heeft iedereen met heldere argumenten kunnen overleggen en kwamen we er een stuk sneller uit. Persoonlijk denk ik dat ik de taak van leider nog iets beter had kunnen doen. Naast de hiervoor genoemde disscussie, werd mijn taak als poker-leider soms te veel overgenomen door teamgenoten. Bijvoorbeeld het navigeren en voorlezen van de in te schatten issues hoorde eigenlijk bij mijn taak, maar werd soms halverwege de meeting door een teamgenoot overgenomen. Hier had ik nog wat meer het voortouw kunnen nemen, en moet zorgen dat ik de planningspoker duidelijk bleef leiden. Wel heb ik door mijn rol als planningspoker-leider geleerd hoe belangrijk het is om alkaar de ruimte te geven en iedereen het woord te laten doen. Ook heb ik geleerd dat als een discussie uit de hand dreigt te lopen, het over het algemeen een stuk beter werkt om dit zo snel mogelijk te voorkomen (bijvoorbeeld door er een nachtje over te slapen) dan om de meeting alsnog voort te zetten in de hoop eruit te komen. Ik denk zeker dat dit niet alleen bij planningspoker geld, maar eigenlijk bij alle meetings in teamverband waar gezamenlijk beslissingen genomen moeten worden.

10.2.2   Leerdoel 1 – situatiebeschrijving 2: Persoonlijke TODO lijstjes

Regelmatig was ik binnen dit OOSE project met een taak bezig, die aan het einde van de dag nog niet af was. Net als de rest van het team zorgde ik in dit geval ervoor dat ik een tussentijdse commit naar mijn branch op Bitbucket pushte, om zo geen werk te verliezen en de volgende dag verder te kunnen werken. Echter in het kader van mijn leerdoel om beter te plannen, heb ik er ook regelmatig voor gekozen om een persoonlijk TODO lijstje op te stellen, puur zodat ik de volgende dag snel weer kon oppakken wat mij de dag daarvoor nog niet was gelukt. Regelmatig voegde ik dit lijstje toe aan mijn dagelijkse log (ik hield ook voor iedere dag een kort stukje bij in mijn logboek in confluence). Vervolgens kon ik s ’Ochtends na de daily standup direct verder met de taken die nog over waren van de vorige dag, voordat ik nieuwe taken ging zoeken.

Mijn taak bij deze TODO lijstjes is er een die voornamelijk vanuit mijzelf komt. Om efficiënt te werken is het van belang dat iedereen zijn best doet om zelf de planning op orde te houden en actief aan het project deelneemt. Deze lijstjes waren voor mij een manier om het overzicht te bewaren. De verwachting van teamgenoten richting mij was niet dat ik een TODO lijstje bijhield van dag tot dag, aangezien ik zover ik weet de enige ben die dat heeft gedaan. De verwachting was algemener, namelijk dat ik niet afhankelijk was van het team om vlot taken op te pakken.

Zoals eerder beschreven heb ik er vaak voor gekozen om een kort TODO lijstje toe te voegen aan mijn persoonlijke logboek. Soms (bijvoorbeeld als ik wat minder tijd over had aan het eind van de dag) koos ik er ook voor om simpelweg een notepad documentje open te laten staan met een lijst van dingen die nog gedaan moesten worden. Het gaat er naar mijn mening ook niet zo zeer om hoe of waar ik dit bijhoudt, maar meer dat ik zonder enige moeite taken kan oppakken en productief de volgende dag kan opstarten.

Terugkijkend ben ik heel tevreden met de TODO-lijstjes-tactiek omdat het mij geholpen heeft op een simpele manier taken voor de volgende dag te plannen. Dit heeft veel tijd gescheeld, en vragen richting het team voorkomen. Ik heb ervan geleerd dat het zeker een goed idee is om aan het eind van de dag kort op te schrijven waar ik mee bezig ben, omdat het een hele hoop moeie bespaard voor de volgende dag. Het enige wat ik in het vervolg beter zou kunnen doen is om de TODO lijstjes op een centrale plek te bewaren; dus ook al zet ik het tussendoor in een notepad bestandje, dat ik het later alsnog even naar de confluence kopieer om er later op terug te kunnen kijken.

De persoonlijke TODO lijstjes kunnen ook zeker in andere situaties helpen. Het idee om dit toe te passen kwam ook vanuit het feit dat ik zelf TODO lijstjes bijhoudt voor alledaagse bezigheden en afspraken.

10.2.3   Leerdoel 2 – situatiebeschrijving 1: Daily standup/logboek

Iedere dag van het project zijn we in teamverband begonnen met een daily standup. Bij de daily standup gaat het erom dat ieder teamlid duidelijk laat weten waar hij de dag ervoor mee bezig is geweest. Hiernaast laten we aan elkaar weten we voor de komende dag op de planning hebben staan, en of we nog problemen verwachten.

Om efficiënt te kunnen deelnemen aan de daily standup en mijn werkzaamheden goed te kunnen vertellen, heb ik ervoor gekozen om iedere dag een logboek bij te houden. Dit logboek is een korte samenvatting van wat ik die dag heb gedaan. Zo kan ik de volgende ochtend tijdens de daily standup simpelweg mijn logboek voorlezen, en heb ik zelf ook een duidelijk beeld van waar ik mee bezig was.

Mijn taak binnen de daily standup is, net als voor de andere teamleden, om voor het hele team een duidelijk beeld te geven van mijn werkzaamheden. Zij verwachten dus van mij dat als het mijn beurt is, ik zonder moeite kan opsommen waarmee ik bezig ben geweest, en dat ik dit duidelijk weet te verwoorden. Mijn logboek heeft hier zeker bij gewerkt, omdat ik niet meer hoefde na te denken wat ik had gedaan, en ook niet hoe ik het kon verwoorden. Ik hoefde slechts mijn logboek voor te lezen, en op te noemen wat ik voor de komende dag van plan was.

Ik heb vooral geleerd dat een klein beetje voorbereiding al erg helpt in de communicatie. Vooral omdat ik niet meer hoefde na te denken wat ik ging vertellen tijdens de daily standup, ik hoefde alleen te zorgen dat het duidelijk overkwam op mijn teamgenoten. Ik heb bij de daily standup ook zelfden vragen gekregen naar aanleiding van mijn verhaal en vaak bevestigde de gespreksleider (Niels) nog even dat het duidelijk was overgekomen. In dat opzicht is het logboek zeker een succesvolle manier om de communicatie tijdens de daily standup te verbeteren.

10.2.4   Leerdoel 2 – situatiebeschrijving 2: Tweede retrospective

Na iedere sprint deden we als team een retrospective. De eerste retrospective was nog onder leiding van de professional skills begeleider, maar daarna moesten we het zelf als team regelen. Dit betekende dus dat we helemaal zelf de tips & tops opschreven, hierover (onder leiding van een van de teamleden) discussieerden en de belangrijkste onderwerpen meenamen om de uitvoering van het project te verbeteren. Bij de tweede retrospective, onder leiding van Tobias, wilde ik me mengen in de discussie. Net voordat ik mijn woord kon doen wilde iemand anders ook het woord doen, dus liet ik het even zitten. Normaal gesproken zou ik daarbij laten, tenzij het echt een belangrijk punt was. Bij deze retrospective werd de discussie echter onderbroken en gaf de professional skills begeleider aan dat de gespreksleider mij even aan het woord moest laten. Hierdoor kon ik alsnog even mijn woord doen, en vervolgens pakten we de discussie gewoon weer op waar die gebleven was.

Bij deze retrospective was mijn taak als teamgenoot, om samen met het team te evalueren over de eerder opgeschreven aandachtspunten. Hierbij wordt natuurlijk van ieder teamgenoot een goede inzet verwacht, maar moet ook iedereen de kans krijgen om zich in de discussie te kunnen mengen. Mijn aanpak in de eerdergenoemde situatie (ik kreeg het woord van de gespreksleider) was terugkijkend niet heel goed. In plaats van mijn woord te doen en verder te gaan, probeerde ik uit te leggen dat het niet zo erg was en dat ik mijn zegje naderhand wel had kunnen doen. In plaats hiervan was het beter geweest om gewoon te zeggen wat ik wilde zeggen zodat de focus bleef bij de retrospective en hierover niet meer discussie ontstond dan nodig.

Wel heeft het mij geleerd dat altijd een afwachtende houding aannemen ook niet ideaal is, omdat ik dan het risico loop om nooit mijn verhaal te doen. Ik denk, terugkijkend op zowel de betreffende retrospective, als het project in het algemeen, dat het goed is om een balans te vinden. Mijn mening is niet belangrijker dat die van een ander teamlid, dus ik kan niet zomaar mensen gaan afkappen om mijn recht van spreken op te eisen. Wel kan ik opletten dat als het vaak gebeurd, ik hier en daar iets volhoudster ben en me niet in ieder gesprek afwachtend opstel.

Het beste zou zijn als ik dit in volgende projecten ook met de gespreksleider afstem, zodat hij of zij in de gaten houdt dat iedereen genoeg kans heeft om aan het woord te zijn.

10.3   Logboek

Tot vrijdag 08-04-2022:

Plan van aanpak –

Inleiding

Ontwikkelmethode

Planning

Risico’s

SRS –

domein model + beschrijving van de concepten in het model

+ algemene overleg, daily standup, meeting procesbegeleider

11-04-2022 

Nutshell talk van mitch over de tools

Eerste gesprek opdrachtgever → notulen gemaakt

12-04-2022

Planningspoker

SRS → inleiding, domein, requirements, etc

Gezamelijk naar de scrum kaartjes gekeken

13-04-2022

Vue.js onderzoek gedaan en begonnen met het onderzoeksverslag tm de resultaten

SRS → non functional requirements, inleiding, etc

14-04-2022

Daily standup met Jaap erbij

Verder met Vue.js onderzoek

Beetje onderzoek gedaan naar Vue router

s middags naar bedrijvenmarkt

19-04-2022 (na 4 dagen weekend)

onderzoek Vue.js

reviews fixen

ook vue js project gerunt

review spring onderzoek

in de middag van half 2 tot 5 bezig geweest met werkplekoverzicht en onderzoeken

20-04-2022

401, of andere codes die niet ok zijn

assesment plan van aanpak

tobias zn werk gereviewed tot 11

vanaf 11

als locatie niet bestaat een 404 geven

javadoc

tot 12:36

op deze locatie zijn geen werkplekken

backend werkplekken overzicht

21-04-2022

werkplekoverzicht tests gemaakt, niet af en nog geen injection
aan werkplekoverzicht thuiswerk mensen toegevoegd
reserveren werkplek backend

22-04-2022

reserveren werkplek gefixed, de produces weggehaald

voor overzicht backend extra status errors toegevoegd

api documentatie voor reserveren werkplek
+ documentatie geupdatet van werkplek overzicht

dingen gereviewed

verder met unit tests -> ff kijken hoe gino het had opgelost met de database

25-04-2022

reviews gechecked

tests voor overzicht gemaakt (zijn wat problemen mee, dat de sonarcube ze niet goed vindt)

gezorgt dat reserveringen verwijderd kunnen worden met nieuwe delete endpoint

cors headers gefixed

tests voor reserveren werkplek bezig

nutshell talk sprint review

gesprek opdrachtgever

eerste helft van de planningspoker

26-04-2022

gezamelijk reiskosten declaratie ontworpen

unit tests gemaakt voor reserveren/ongedaan maken reservering werkplekken

retrospective met professional skills begeleider

begonnen met backend voor handmatig declareren reiskosten

27-04-2022

koningsdag

28-04-2022

online overleg gehad over de declaratie database structuur

backend voor handmatige declaraties

09 May 2022 

reis afstand api code geupdatet
met front end meegedacht
vue.js nutshell talk
confluence documentatie geupdatet
backend voor handmatige declaraties is af + tests ook

10 mei 2022

bezig met srs fixen, inleiding, requirements, etc
documentatie gereviewd

tests voor handmatige declaratie fixen zodat ze niet de api gebruiken + bestaande routes gebruiken ipv de berekening
logger errors op 70 fixen

2 use case descriptions gemaakt

nu is het een beetje zoeken omdat de taken allemaal op een naam staan

12 mei 2022

srs en sdd sequence en class diagrammen gemaakt
datum check gefixed voor werkplek reserveren

multipart form data

13 mei 2022

groot deel voor uploaden bestanden gemaakt

16 mei 2022

backend voor uploaden bijlage voor de handmatige declaratie

bestand type check gemaakt dat het alleen pdf, png en jpg accepteerd

endpoints verbeterd voor handmatige declaratie waar zelf bedrag kan worden opgegeven

in de confluence documentatie geupdatet voor bestanden uploaden en bedrag

sprint review met de opdrachtgever

voor morgen: ophalen van bestand voor de frontend implementeren → dan kunnen we het laten zien in het declaratie overzicht

17 mei 2022

uuid voor declaratie bijlage naam gemaakt

max upload size voor declaratie bijlagen verhoogt naar 5 mb en confluence documentatie geupdatet

planning poker

begonnen met endpoint waarmee je bijlage bestand kan downloaden

18 mei 2022

wat dingen gefixed voor handmatige declaratie → nog naar de id kijken daarvan

bijlage downloaden gemaakt met meerdere endpoints

bijlage downloaden getest, zat ik nog ff vast op maar is gelukt

19 mei 2022

s ochtends backend gemaakt voor werknemers overzicht

tussendoor connor geholpen met de handmatige declaraties werkend te maken

s middags bezig met vue voor werknemers lijst

todo:
informatie gebruikers -> naam
knop voor editen en verwijderen van gebruiker

werknemer dao en user dao moeten samengevoegd

20 mei 2022

front end gebruikers lijst

backend daarvoor gefixed

23 mei 2022

pull requests voor zowel front als backend gechecked
verwijderen werknemers backend + tests

twee wachtwoord velden dat ze hetzelfde zijn
regex voor nieuwe wachtwoord

beheerder -> dropdown voor gebruiker, alfabetisch weergeven

in de main js nieuwe route voor wachtwoord reset

props van werkplekoverzicht kopieeren en daar checken of iemand de beheerder is

werknemer lijst front end checken als er veel werknemers zijn

24 May 2022 

wachtwoord wijzigen afgemaakt

sprint retrospective

25 May 2022 

wachtwoord wijzigen afgerond en wat debug code weggehaald
backend voor users lijst ophalen geupdatet voor de nieuwe database
pull requests gechecked
backend voor verlof keuring gemaakt + tests

TODO

1. bij het wachtwoord frontend nog de if brackets fixen
2. verlof keuring documentatie/api maken:

verlofAanvraagId -> int
token -> UUID
goed/afgekeurd -> boolean
opmerking(optioneel)

status excepted, denied, pending po, pending lead

30 May 2022 

sprint review gedaan met jaap erbij
pull requests gechecked
aanvragen verlof backend gemaakt, zonder de tests

TODO
nog tests maken voor verlof aanvraag backend

31 May 2022 

tests gemaakt voor verlof aanvraag

nagedacht over verlof in werkplekoverzicht verwerken

TODO: begin uur en eind uur van verlofaanvraag moet in de database komen, niet alleen de uren

01 Jun 2022 

wachtwoord switches

werkplekoverzicht verlof tonen

02 Jun 2022 

wachtwoord switches afgemaakt en ook voor de inlog pagina

in de frontend en backend gefixed dat routes worden opgeslagen na handmatige declaratie

03 Jun 2022 

begonnen met het testrapport

07 Jun 2022 

Testrapport unittesten van de backend geschreven

08 Jun 2022 

Documentatie van het backend sub system geschreven inclusief nieuwe tabellen met design decisions

Klasse diagram opgesteld voor de gehele backend

Rest van de documentatie doorgenomen en hier en daar nog een verduidelijking aangebracht

TODO: voor de front end het sub system documentatie → wat decision tabellen maken en in de discord naar connor sturen

Voor de front end kijken of er een class diagram gemaakt kan worden