Inleiding

Voor het OOSE-project ben ik een van de teamleden van het team Smalltalk. Onze opdracht is vanuit het bedrijf Regterschot Racing. Regterschot Racing wil de data van de sensoren die in een raceauto zitten kunnen zien op een, door ons te maken, website. De sensoren in de auto wordt uitgelezen door andere studenten. Door het gebruik van een broker kunnen wij deze data op de website tonen. Naast dat de data op de website wordt getoond wordt er ook geacht dat deze betrouwbaar is. Ook zullen er sensoren zijn die twintig keer per seconde data versturen. Het is van belang dat al deze data zo snel mogelijk op de website getoond wordt. 

...

In het document zal er worden ingegaan op in ieder geval de volgende hoofdstukken. Allereerst de deelproducten. In het tussentijdse verslag zal er in worden gegaan op in ieder geval het Plan van Aanpak, het SRS en over in ieder geval één stuk code. In het hoofdstuk projectmethode wordt er ingegaan op de methode Scrum. Hierin zal ik aangeven wat goed en minder goed werkt. In het hoofdstuk rollen zal ik ingaan op welke rollen ik heb vervuld tijdens het project. In het hoofdstuk competenties ga ik tenminste in op 2 genomen beslissingen. Dit kan gaan over bijvoorbeeld een design decision of implementatie. In het hoofdstuk leerdoelen zal ik verder ingaan op mijn leerdoelen die hierboven kort benoemd zijn. In de conclusie zal ik reflecteren op alle hoofdstukken en het hele project. Dit gaat over het groepswerk maar ook over bijvoorbeeld mijn leerdoelen. Als laatst zal ik een factsheet toevoegen voor alle competenties. Per compententie competentie zal ik facts en toelichtingen toevoegen die deze competentie aantonen.

Tijdens het project ben nog geen grote uitdagingen tegen gekomen. Het eerste onderdeel waar ik mogelijk problemen zou verwachten was Angular. Angular is het front-end framework wat wij gebruiken voor de website. Angular was ons nog niet bekend. Martin is hier mee begonnen en de rest van het team heeft tijd gestoken in de tutorial op de website van Angular zelf (https://angular.io/start). Naast dat deze tutorial en de extra Tour of Heroes tutorial (https://angular.io/tutorial) enorm veel duidelijke informatie geven is er ook veel over te vinden op verschillende websites. Dit alles maakt dat Angular niet moeilijk te leren was. Wat wel een obstakel kan worden is dat wij dit keer niet een database hebben met alle data. De meeste data die wij zullen gaan krijgen gaat over een broker komen die in C++ is gemaakt. Deze taal is ons niet bekend en wordt ook niet door ons gemaakt. Het is afwachten hoe we met deze broker kunnen communiceren en of de data dan ook goed en snel genoeg binnen komt. Dit is nog iets waar we problemen tegen zullen kunnen komen. Ook heb ik door omstandigheden niet de hele opdracht kunnen maken van DEA. De kennis die ieder zou moeten hebben heb ik grotendeels wel. Ook denk ik dat als het zo mocht zijn dat ik vast loop er genoeg teamleden zijn die mij wel zouden kunnen en willen helpen. Verder zijn er tijdens dit blok niet veel andere obstakels die ik nu kan voorzien. Ik verwacht dat er verder weinig problemen kunnen zijn. 

Deelproducten

Plan van Aanpak

Tijdens het eerste deel van het project is het Plan van Aanpak (PvA) een van de belangrijkste onderdelen om goed en duidelijk te maken. In het PvA zet je een aantal basis dingen op. Dit geeft het team duidelijkheid over wat er moet gebeuren maar ook wat er niet moet gebeuren. Dit geeft ook een terugkoppeling aan de opdrachtgever, Is dit wat de opdrachtgever wil, of hebben we het niet goed begrepen? Snappen we überhaupt voor wie we het maken? Naast deze vragen maak je ook een aantal afspraken voor in je team. Willen we dat we de hele periode 1 scrummaster hebben, of elke week een andere? Willen we altijd dezelfde tijd op school zijn of bepaalt de scrummaster dat? Welke afspraken hebben we en wanneer is iets "klaar". Dat zijn allemaal vragen die je in het PvA tegen gaat komen.

In eerste instantie denk ik dat wij een goed PvA hebben neergezet. Voor mij was alles duidelijk en konden we ook daadwerkelijk wat met het PvA. In het PvA staat voor ons maar ook voor anderen duidelijk wat wij gaan doen en op welke manier. Ook staat er duidelijk aangegeven welke dingen wij bijvoorbeeld nodig hebben, zoals een lokaal waar we in ieder geval met het hele team kunnen zitten. Wij hadden als team grotendeels duidelijk wat er allemaal in stond en toch waren er een aantal kleine aanpassingen. Dit waren vooral kleine onduidelijkheden waar wij overheen hebben gelezen. Het uiteindelijke PvA (29/11/2022) is een goed product. Alles wat een PvA moet hebben staat er in en ook zijn alle aanpassingen die gedaan moesten worden zijn verwerkt.

SRS

Code

De code die voor mij een groot deel van de tijd in beslag heeft genomen en ook nog niet volledig af is is de login. Als we het hebben over de backend van deze code dan gaat het vooral over de code die Thomas geschreven heeft, en later aangepast is door Wijnand. Zelf heb ik hier niet aan gewerkt, maar wel gereviewd. Zelf ben ik bezig geweest met de front-end van de login, de koppeling van de front-end en backend en moet ik nog werken aan de foutafhandeling en het doorgeven van een token. De token is nodig om op elke pagina te kijken of de gebruiker hier mag zijn, en als dit het geval is, wat deze gebruiker mag en kan. Als ik kijk naar de backend is hier veel tijd aan besteed. Er zijn tijdens het maken van de login aanpassingen geweest, grotendeels door meerdere invalshoeken. Iedereen kijkt er toch net wat anders naar. De één vindt het beter om de gebruiker te laten weten of zijn wachtwoord of gebruikersnaam misschien niet klopt, terwijl de ander juist denkt dat er maar één bericht moet komen dat er iets fout is. Dit zijn constant kleine aanpassingen, maar kunnen later op andere stukken weer een grotere impact hebben. Ik durf niet met zekerheid te zeggen of het allemaal veel sneller had gekund omdat mijn focus niet lag op waar Thomas precies mee bezig was. Ik denk echter wel dat het sneller had gekund als we gelijk de uiteindelijke richting hadden gekozen zoals: het wachtwoord moet gehasht in de database staan en er komt 1 foutmelding.
De Backend van de login werkt nu en is klaar, de front-end heb ik met behulp van Angular ook snel in elkaar weten te zetten. Ook door het feit dat er veel over te vinden is het een redelijk snel en makkelijk proces. toch ben ik meerdere obstakels tegen gekomen. Allereerst wou ik een Toastr toevoegen voor foutmeldingen. Toastr's  zijn gekleurde berichten die vaak rechts bovenin een scherm te zien zijn (bijvoorbeeld https://codepen.io/RaiseTheBahr/pen/JOybye). Dit leek ook in Angular makkelijk te kunnen al kreeg ik foutmeldingen waar ik geen raad mee wist en ook na veel onderzoek nog niet uit ben gekomen. Ik heb mij voor nu neergelegd bij het niet kunnen gebruiken van toastrs en ben verder gegaan met de koppeling. De koppeling tussen de twee was er snel en werkte goed. Op het moment dat de login backend af was kon je ook gelijk met de front-end inloggen, al deed deze verder nog niks. De vervolgstap is het doorgeven van een token aan de user. Ook hier heeft al wat tijd ingezeten, al denk ik nu te weten hoe ik dit kan oplossen. Ik denk niet dat hier veel tijd bespaard had kunnen worden. Het gebruik van Toastr's heb ik misschien te graag gewild terwijl een rode tekst voor nu ook genoeg zou zijn geweest. Dit is ook de oplossing die we hier gaan gebruiken. De oplossing voor het meegeven van een token komt uiteindelijk af van Meron Brouwer. Als ik hier eerder de vraag aan had gesteld in plaats van het onderzoek zelf vanaf 0 te doen was misschien de hele login ook al klaar.

Projectmethode

Rollen

Competenties

Leerdoelen

Conclusie

Factsheet

Tijdens het maken van het PvA zijn er bij ons al snel een aantal vragen naar bovengekomen. Wat gaan we nou eigenlijk doen en wat is de opdracht eigenlijk precies? We hebben de vragen opgesteld voor een volgend gesprek terwijl we bezig zijn gegaan met andere dingen die ook zeker moesten gebeuren. Doordat we aan verschillende dingen konden werken hebben we daar niet hoeven te wachten op de antwoorden van onze vragen. Het PvA is na onze oplevering terug gekomen met een paar kleine punten. Op een aantal plekken hebben wij verkeerde termen gebruikt wat bij ons tot verwarring zorgde. Dit ging vooral over de softwarehandleiding wat bij ons niet gelijk klikte als Software Design Document. Ook miste er een aantal punten zoals waarom de opdrachtgever juist nu bezig wil met deze opdracht. Deze punten hebben we zo snel en goed mogelijk opgelost om tot het uiteindelijke PvA te komen.

Als ik kijk naar een PvA zijn er een aantal dingen die belangrijk vind. Zo is het belangrijk om de opdrachtgever duidelijk te maken wat wij zien als opdracht en hoe wij het bedrijf van hen voor ons zien. Als hier fouten in staan kunnen deze zo snel mogelijk worden opgelost om uiteindelijk de opdracht duidelijk te krijgen. Ook is het belangrijk om de opdrachtgever vertrouwen te geven. Als een opdrachtgever bij een bedrijf een goed gevoel heeft dat hij daadwerkelijk krijgt wat hij verwacht dan is hij vaak verzekerd genoeg om met dat bedrijf in zee te gaan. Ook is het belangrijk om aan de opdrachtgever duidelijk te maken wat wij als team nodig hebben. Het kan zijn dat wij bepaalde hard- en software nodig hebben om ons systeem te kunnen testen. Als ik terug kijk naar wat wij hebben op kunnen leveren als PvA ben ik daar best tevreden over. Er zijn zeker een aantal punten, zoals het kunnen aanscherpen van wat we gaan opleveren in hoofdstuk 6. Daarnaast hadden we ook meer tijd moeten nemen om de afspraken binnen onze groep aan te scherpen. 

SRS

Het SRS is een belangrijk document bij het maken van een product als hier gestructureerd gewerkt wordt. Tijdens de uitleg deed mij een onderdeel hiervan wel verbazen. Tijdens deze opdracht is het eigenlijk de bedoeling dat tijdens het maken van het product het SRS (en SDD) wordt aangepast. Normaal zou je eerst het SRS (en SDD) maken en daarna aan de hand daarvan gaan programmeren, in plaats van een stukje SRS maken en dat gelijk implementeren. Het is natuurlijk wel zo dat dit soort bestanden tijdens een project veranderen en aangepast worden. De gebruiker kan bijvoorbeeld toch iets er bij willen of wil iets net even wat in elkaar hebben zitten. Dit geeft als resultaat dat er dingen aangepast moeten worden in bijvoorbeeld het SRS.\Het maken van een SRS tijdens het programmeren, afwisselend waar je aan werkt kan ook problemen met zich mee brengen doordat je niet weet wat er nog meer moet komen. Het kan zo zijn dat het SRS compleet en goed is voor de eerste tien stukken code, maar dat door stuk elf veel aangepast moet worden. Om dit te voorkomen zou je misschien toch liever een compleet SRS hebben alvorens je gaat programmeren. Het is voor ieder van ons geen favoriet onderdeel, maar nodig.

Op het moment dat wij het SRS (tussentijds) gingen opleveren wisten we eigenlijk al dat de kwaliteit hiervan zwaar onder de maat was. Er was veel feedback van docenten die we hier in hebben kunnen verwerken. Eén van de belangrijkste dingen in een SRS is misschien wel dat alles coherent en consequent is. In het SRS moet je namelijk dezelfde termen gebruiken als in het PvA. Dit was bij ons niet het geval. Ook is het zo dat we in het SRS verschillende termen hebben gebruikt voor dezelfde gebruiker zonder deze verder toe te lichten. Dit zorgt ervoor dat iemand niet goed zou kunnen begrijpen wat het uiteindelijke product nou wordt. Dit is echter wel de hoofdbedoeling van een SRS. De opdrachtgever heeft een opdracht, deze werk je voor een opdrachtgever (en mogelijk andere programmeurs) uit in een SRS. We moeten als groep alles op alles zetten om dit document duidelijk en goed te krijgen omdat ook andere groepen dit document zullen moeten gaan gebruiken. De documentatie is voor deze opdracht dan ook belangrijker dan de code zelf.

Code

Code is (wat de opdrachtgever betreft) een stuk minder belangrijk dan de documentatie zelf. Het is dan ook zo dat we hier in principe minder goed hebben gekeken wat betreft de kwaliteit van. We zijn beginnen met opzetten van zonder te bedenken hoe de structuur van de mappen en bestanden er uit komt te zien. Ook hebben we niet gekeken naar de kwaliteit van de code zelf. Momenteel is er bijvoorbeeld veel dubbele (en daardoor slechte code) te zien. Als ik nadenk of we gebruik maken van design pricniples zoals GRASP of SOLID dan denk ik dat deze er per ongeluk hier en daar inzitten. Daarnaast was het ook voor de kwaliteit van de code beter geweest als we niet alleen meer tijd hadden besteed aan het opzetten van regels voor code en kijken hoe we dingen zoals GRASP en SOLID zouden kunnen gebruiken, maar ook hadden we meer tijd moeten nemen voor het bedenken van hoe onderdelen zouden moeten werken. Als ik hier bijvoorbeeld kijk naar de login zijn er veel te veel iteraties en aanpassingen geweest. Dit heeft gezorgd voor code die onnodig is en soms stukken code die compleet niet gebruikt werden door het systeem. Dit had, helemaal als ik terugkijk op de vorige lessen, gelijk beter gemoeten.

Eindproduct

Projectmethode

We zijn deze periode aan het werk gegaan met scrum. Scrum is een methode waar je een to-do lijst hebt. Iedereen weet wat er nog moet gebeuren. Als je een taak oppakt sleep je deze naar "in progress". Door dat te doen kan iedereen zien wie waar mee bezig is. Na het afronden kan de taak naar het vak "ready to review". Dit houdt in dat het maken van de taak klaar is, maar dat deze nog wel moet worden gereviewd. Hierna kan de taak terug naar "in progress" omdat er nog aanpassingen moeten worden gedaan, of naar done wat aangeeft dat de taak volledig goed is. Deze methode werkt goed. Op elk moment van de dag kan er gekeken worden wie waar mee bezig is, wat er nog gedaan moet worden en wat niet afkomt. Tijdens de Daily stand up bespreken we elke ochtend wie waar mee bezig was, of er problemen waren en wat ze die dag gaan doen. Naast dat we dit bespreken hebben we het ook over het aantal gereserveerde uren, en de gewerkte uren. Voor elke taak staat een aantal uren. Als je met een taak bezig bent geweest geef je het aantal uren op dat je er aan gewerkt hebt. Aan het eind kunnen we kijken of de schatting overeenkomt. Als je minder uren hebt gebruikt is er niks aan de hand. Echter, als er meer uren zijn gebruikt dan verwacht, dan is er dus een probleem ontstaan. We kunnen dan overleggen met hoe het zit en wat er anders moet. Kunnen we dit probleem nog eens tegenkomen, of was het een complexere, eenmalige uitdaging? Dit zorgt ervoor dat de hele groep op de hoogte is van de voorgang.

Rollen

In het Plan van Aanpak (PvA) Hebben we een aantal rollen beschreven. In ieder geval de rol scrummaster die iedereen zal krijgen tijdens het project. Deze rol krijg ik als derde van 30-11-22 tot 09-12-22. Iedereen heeft een aantal niet beschreven rollen zoals, onderzoeker, programmeur en reviewer. Dit zijn rollen die niet beschreven staan omdat ze een standaard zijn. Tijdens het gehele project wil ik ook een beetje proberen het voortouw te nemen op sommige punten. Ik heb met het zicht op de vorige projecten dit gedaan omdat ik merk dat er anders nog wel eens gaten ontstaan in de code of documenten. Ik wil tijdens dit project meer vragen en duidelijkheid creëren voor zowel mijzelf als anderen.

In de eerste sprint ben ik vooral bezig geweest met het onderzoek data transfer. Het is tijdens dit onderzoek duidelijk geworden hoe we de data van punt a naar punt b kunnen krijgen, en dit in realtime op de website weer kunnen geven. In dit onderzoek heb ik naderhand ook 2 stukken code geschreven om dingen uit te testen. Als eerste, wat als beste uit het onderzoek kwam, een web socket. Dit is een manier om in realtime data van a naar b te krijgen. Ik heb een kleine chatapplicatie gemaakt, vergelijkbaar met een chatroom of WhatsApp. Daarna heb ik een Broker opgezet. De broker is uiteindelijk wat we gaan gebruiken om de data te ontvangen. De Raspberry pi data wordt opgehaald door de broker en naar verschillende kanalen, waaronder de backend van de applicatie, verstuurd. Tijdens de eerste sprint heb ik ook werk van anderen gereviewd. Dit geeft als gevolg dat ik in de eerste periode grotendeels de rollen van onderzoeker en reviewer op me hebt genomen. Ook heb ik een stukje van de rol programmeur gehad, al was dit alleen voor het onderzoek van belang.

Tijdens de tweede sprint ben ik vooral bezig geweest met programmeren en reviewen. Ik heb ook deze sprint verder geen specifieke rol gehad. Ook heb ik natuurlijk geprobeerd hier meer het voortouw te nemen en meer vragen te stellen waarom iets op een manier gedaan is. Dit laatste werkt heel goed tijdens het reviewen van bijvoorbeeld de login aan de backend. Ik heb hier niet alleen gekeken naar of de code werkt en of deze netjes is tot op bepaalde hoogte, maar ook hoe deze werkt. Hierdoor zijn er een aantal punten naar boven gekomen die vervolgens weer leidde tot andere punten. Dingen zoals geen gehashte wachtwoorden. Dit heb ik bijvoorbeeld in de groep aangekaart met de vraag wat we hier alle van vonden. Zelf heb ik een enorme voorkeur (en het is eigenlijk ook wel een must) voor gehashte wachtwoorden. Dit is dan ook aangepast. Normaal had ik hier waarschijnlijk minder of niks van gezegd.  

Competenties

OOSE P-06. De student past de aangereikte ontwikkeltools om het project te organiseren toe.

Tijdens het maken van het project zijn er een aantal tools die gebruikt worden. De aangereikte ontwikkeltools zijn Confluence, Jira, Bitbucket en Jenkins + SonarQube.

Confluence is een soort van online Wordt. Het is te vergelijken met bijvoorbeeld google Drive, alleen is Confluence niet in realtime. Je kan wel samen in hetzelfde document werken en ook kan je dat tegelijk doen, maar de aanpassingen krijg je pas te zien op het moment dat iemand deze opslaat. Verder werkt Confluence wel goed met het toevoegen van bijvoorbeeld commentaar. Je voegt commentaar toe en iedereen kan dat zien. Vervolgens kan iemand het probleem oplossen wat vervolgens ook weer voor iedereen te zien is. Toch zou ik zelf liever een ander systeem gebruiken zoals Word online. Deze aanpassingen zijn echt in realtime te zien. In Confluence kan het zo zijn dat je hetzelfde aan het aanpassen bent en dus een foutmelding ziet bij het opslaan.

Jira is een heel fijn systeem om samen in te kunnen werken. Het is een online versie van een scrumboard. Je hebt je "to-do", "In progress", "ready to review" en "done" vakjes. Aan het begin van een sprint maak je een back log aan en vervolgens kan je de juiste taken naar de juiste vakken slepen. De meeste taken hebben kleinere sub taken die je individueel af kan sluiten. Aan elke tijd zit een aantal uren gekoppeld. Tijdens het werken aan een taak kan je ook je werktijd loggen. Door het gebruik van Jira wordt het snel duidelijk wie waar mee bezig is, hoelang ergens aan besteed is en kan ook naar gerefereerd worden tijdens de DSU. Door het gebruik van Jira wordt het al een beetje duidelijker waar mogelijke problemen zitten en wie waar mee bezig is. Door gebruik van Jira is het ook te zien of je een beetje binnen de tijden blijft die gepland zijn. Een Burn down chart laat een lijn zien die de perfecte lijn zou zijn. Als je deze lijn aanhoudt krijg je alles precies op tijd af. Zit je boven de lijn dan mis je nog dingen die afgerond worden. Als je onder deze lijn zit dan zijn alle taken eerder afgerond. Dit laatste komt alleen vrij weinig voor.

Bitbucket is een soort van Github. Op Bitbucket maak je een repository aan met branches, Iedereen kan zijn eigen branches maken en hier commits opzetten. Iedereen kan de code van anderen inzien, en zo nodig, downloaden (pullen) aanpassen en weer uploaden (pushen). Ook kan je een pull request aanmaken. Dit is zodat jouw eigen branch op de hoofd branch komt de staan. Daarvoor moet je code wel eerst getest en gereviewd zijn door andere van het team. Ook hier kan je tijdens het reviewen comments toevoegen. Uiteindelijk kan je op deze manier zorgen dat alle gemaakte code op de main branch komt de staan. Dit is de code die je uiteindelijk oplevert. Het reviewen is dus belangrijk werk. Niet alleen moet de code werken, maar hij moet ook werken met de andere componenten.

Jenkins en SonarQube zijn twee ontwikkeltools waar we nog niet veel mee gedaan hebben. Gelukkig zijn deze componenten ook niet cruciaal. We hebben het geprobeerd op te zetten alleen is het nog niet gelukt. Later in het project gaan we zeker kijken of dit nog nodig is en of we er iets mee kunnen. Mocht het blijken dat deze tools ook heel handig zijn of gaan worden gaan we er zeker alles aan doen om ook deze tools werkend te krijgen.

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.

Tijdens het maken van een project is het controleren van andermans werk een belangrijk onderdeel. Niet alleen de code maar ook gewoon documenten zijn belangrijk om te controleren. Bij documenten let je in eerste instantie of het foutloos en duidelijk is geschreven. Lange zinnen kunnen bijvoorbeeld onduidelijk worden als er geen of slecht gebruik wordt gemaakt van leestekens. Fouten in de tekst zijn vaak slordig en onnodig. Ook deze maken de tekst minder makkelijk en minder fijn te lezen. Als een woord of concept niet duidelijk is voor de gemiddelde lezer kan ook hier niet veel over gezegd worden. Dit zijn de meeste dingen waar je naar kijkt tijdens het reviewen van geschreven documenten. Als er een spelfout in staat kan je deze direct aanpassen. Gaat het echter over de inhoud of missen er dingen is het handig om hier commentaar over te schrijven. Iemand anders kan vervolgens de problemen verhelpen en dan kunnen mensen weer reviewen. Bij het reviewen van code is de spelling en dergelijke minder belangrijk. Duidelijke namen voor documenten en variabelen zijn bijvoorbeeld wel heel handig. Ook moet de foutafhandeling gedaan zijn en het testen van de code. Ook moet de code werken met andere componenten die geschreven zijn en moet er gekeken worden dat de code geen andere dingen kan overschrijven, Ook hier wordt er goed gekeken naar dingen die onnodig zijn, missen of misschien anders moeten of kunnen. Ook hier kan weer commentaar worden toegevoegd waar nodig. Tijdens dit project wil ik meer focus leggen op het reviewen wanneer nodig. Eerdere projecten is dit niet heel nauwkeurig gedaan wat kan zorgen voor problemen,

Leerdoelen

Leerdoelen

Tijdens de eerste paar weken van dit project heb ik al geprobeerd om te werken aan mijn leerdoelen. Helaas heb ik bij de IPV's te horen gekregen dat dit niet veel heeft geholpen voor mijn team. Bij de IPV's kreeg ik bijvoorbeeld nog steeds te horen dat niet iedereen heel duidelijk wist waar ik mee bezig was. Dit is dus iets wat ik beter of meer zal moeten doen, Wel heb ik gehoord dat ik af en toe goeie ideeën inbreng in de groep. Dit is mijn tweede leerdoel en zal ook vooral mij blijven mengen met de gesprekken en discussies.

Leerdoel 1

Tijdens dit project wil ik meer transparant zijn richting mijn teamleden. Als ik (buiten de DSU om) geen vragen hoor waar ik mee bezig ben, waarom ik iets aan het doen ben of er geen vragen zijn waar ik mee bezig ben is mijn doel in principe wel bereikt. Dit geld ook voor de momenten dat ik niet op locatie kan werken, Dit kan bijvoorbeeld doordat we allemaal thuis werken of dat ik ziek ben, Hiervoor hebben wij in het plan van aanpak maatregelen opgesteld zoals constant in een Discord call zitten. De uitdaging zit het hem in het deel dat ik vaak wel bezig ben, zoals ook bijvoorbeeld te zien is in Jira door gelogde uren, maar anderen pas weten dat ik ergens mee bezig ben op het moment dat het al klaar is. Ik wil proberen om vanaf 21 Nov 2022 minder of geen vragen meer te horen waar mee ik bezig ben. Dingen die ik ga doen zijn:

• Mijzelf zo snel mogelijk afmelden bij het team. Als het mogelijk is om die dag nog te werken zal ik ook proberen aanwezig te zijn bij de DSU's. Als dit niet mogelijk is zal ik door middel van een bericht laten weten waar ik die dag mee bezig ga.
• Tijdens de DSU's wil ik zo goed mogelijk aangeven waar ik mee bezig ben, bezig mee ga en bezig mee ben geweest.
• Tijdens het werken laat ik aan mijn team weten wanneer ik iets klaar heb en als ik een nieuwe taak op wil gaan pakken. 
• Als ik een nieuwe taak op ga nemen controleer ik eerst of niet iemand anders met deze taak bezig wil gaan.

Leerdoel 2

Ik wil tijdens het project wat meer van mezelf laten zien tijdens overleg en keuzes die we maken. Ik wil wekelijks bij minimaal 3 overleggen/ vergaderingen etc. extra informatie en mijn ideeën hebben (op het moment dat er genoeg overleggen die invloed hebben op mij/ de groep). Tijdens deze momenten wil ik vooral mijn ideeën en argumenten naar voren brengen naast het opnemen en overwegen van andere ideeën en argumenten. Mijn prioriteit ligt vooral op het verbeteren van het proces en eventueel ook het eindproduct. Ook wil ik kijken of er momenten zijn waarop ergens tegen aan loopt, en of die manier dan wel de beste keuze is, of dat een andere manier te overleggen is. Aan het eind van het project hoop ik te horen dat ik mijzelf heb kunnen laten zien met (nuttige) inbreng. Dingen die ik wil gaan doen zijn:

• Mij mengen met gesprekken en vragen stellen over de ideeën van anderen
• Mijn eigen ideeën over het onderwerp benoemen en onderbouwen met argumenten

Kernkwadranten

Kernkwadrant 1

Kernkwadrant 2

Conclusie

Tijdens de volgende paar sprints denk ik dat ik vooral door moet gaan zoals ik nu bezig ben. Er zijn zeker een aantal punten, zoals mijn eigen leerdoelen, waar ik wat meer op kan focussen. Ik denk dat we als groep goed begonnen zijn, maar ook dat het nog beter kan worden. We weten nu een beetje hoe iedereen in de groep in elkaar zit en wat iedereen zijn sterke en zwakkere punten zijn. Voor de hele groep zijn er in eerste instantie al dingen te verbeteren. Eén van deze onderdelen zijn bijvoorbeeld de DSU's. Als we de deze verbeteren kunnen we veel meer duidelijkheid halen op punten. We zullen beter weten wie waar mee bezig is en of we de komende sprint gaan halen of niet. Ik denk dat wij als groep bezig zijn om op het eind een product op te kunnen leveren waar Regterschot Racing ook daadwerkelijk wat aan heeft.

We gaan nu als groep echt beginnen met het programmeren, testen en reviewen van code. Deze periode is waarschijnlijk de leukste voor ons en is ook zeker belangrijk. De periode van onderzoeken en oefenen is klaar. Het is ook belangrijk om vooral meer te gaan programmeren en te reviewen om deze competenties later aan te kunnen tonen. Uiteraard zal ook meer moeten gaan werken aan mijn leerdoelen om ook op deze manier deze doelen te gaan halen.

Factsheet

...