Inleiding

We hebben als groep een opdracht van Regterschot Racing gekregen om een dashboard te maken waar een racecrew de data die van een raceauto komt kan analyseren. Voor ons als groep is de uitbreidbaarheid van hetgeen dat wij gaan maken erg belangrijk, omdat de opdrachtgever nog een aantal jaar door moet met ons product. Daar komt dus bij kijken dat de documentatie die wij leveren bij de producten die wij maken ook goed en coherent is, om het zo makkelijk te maken voor andere of volgende groepen die verder gaan met onze software.

Ons product zal dus door een racecrew gebruikt gaan worden in eerste instantie. Later wil de opdrachtgever graag de mogelijkheid hebben om kijkers mee te laten kijken naar de race via hetzelfde platform. Dit is echter nog ver in de toekomst en dus nog niet van belang voor ons.

Voor mij zal de uitdaging liggen bij het maken van ingewikkelde maar toch makkelijk uit te breiden Java-software. Ik heb de neiging om vaak code te schrijven die ik zelf goed snap maar vervolgens niet erg logisch is. Als de code niet logisch is, kan het niet goed door een ander gebruikt worden en zal dat dus voor een slecht product zorgen. Ik moet er dus goed op gaan letten om mijn code kwalitatief goed te maken. Door te reviewen binnen een groepsverband zal dat vast beter lukken.

Ik wil tijdens dit project mijzelf verbeteren op twee punten, namelijk het beter opletten en actief deelnemen aan gesprekken, omdat ik aan mezelf vaak merk dat ik een passieve rol aanneem. Door meer bij een gesprek betrokken te zijn, kan ik meer zinnige vragen stellen en kan ik de opdracht zelf beter begrijpen.

Daarnaast wil ik aan mijn afwachtende houding werken. Ik ben van nature wat afwachtend, wat vaak resulteert in een terughoudende houding. Ik wil graag actiever zijn en misschien wel het voortouw af en toe nemen.

Kwaliteit geleverde deelproducten

Ik had me verheugd op het bouwen van een webapplicatie voor autoraces nadat we de opdracht hadden doorgelezen. Er was na het eerste gesprek met onze opdrachtgever al snel duidelijk wat er van ons verwacht werd. Ik had minder zin in de onderzoeken die we vooraf zouden moeten doen, maar dat hoort er nou eenmaal bij. Na de eerste week van Sprint 1 had ik al wel door dat dit project groter zou zijn dan ik had verwacht. Ik had gedacht de applicatie als geheel binnen een week of twee af te kunnen krijgen met z’n zessen, maar doordat we rekening moeten houden met uitbreidbaarheid, documentatie en het bijhouden van het SRS en SDD, wordt dit toch veel langer.

Plan van aanpak

Het plan van aanpal dat we opgeleverd hadden leek eerst wel goed te zijn, we hadden alle hoofdstukken ingevuld en dachten het wel redelijk gemaakt te hebben. Toch bleek er bij het assessment van het plan van aanpak toch nog het een en ander te missen waardoor ik al snel het gevoel kreeg dat we het echt vernaggeld hadden. Dit bleek uiteindelijk wel mee te vallen, want het was goed genoeg voor een voldoende. Ik heb tijdens het project niet echt teruggekeken naar het plan van aanpak, wat ik misschien wel had moeten doen. Ik had de gemaakte afspraken dan beter in mijn hoofd gehad en had misschien beter kunnen focussen op hetgeen dat we daadwerkelijk moeten opleveren. Ik zou dan ook graag in een volgend project 'via' het plan van aanpak willen werken. Ik zou dan graag goed willen kijken wat er precies van ons gevraagd wordt en precies daar aan werken en zo weinig mogelijk zelf invullen.

Onderzoeksverslag

Aan het eind van Sprint 2 hebben we een functionele loginpagina gerealiseerd, een dashboard gemaakt en kunnen we data uit onze database naar de webapplicatie doorsturen. Daarnaast hebben we al onze onderzoeken nu afgerond. Ik heb aan het onderzoek visuele dataweergave gewerkt, samen met Martin. Ik vond dit best een leuk onderzoek om te doen. We hebben gekeken naar de bedrijfswereld en hoe men daar het probleem van Regterschot heeft opgelost. Wat voor een software ze gebruiken en hoe dit gebruikt wordt tijdens de race. Ik heb daarna nog protoypes gemaakt met JFreeChart, wat we uiteindelijk niet zouden gebruiken, maar ons wel meer inzichten gaf in het maken van grafieken a.d.h.v. Java.

SDD

Ik heb me erg veel bezig gehouden met het SDD. We hebben heel fatsoenlijk bij elke taak die gedaan moest worden en het relevant was de taak 'bijwerken SDD' toegevoegd. Dit was om te zorgen dat het SDD niet achter zou lopen op de huidige code en dat het SDD niet twee weken na het maken van code nog geüpdatet moet worden als de helft alweer vergeten is. We hebben bij de tussentijdse beoordeling te horen gekregen dat het SDD zeer ondermaats was en dat het niet coherent was als document zelf, maar ook niet met het SRS. Dit voelde best vervelend, omdat ik toch wel wat tijd in het document gestopt had en ik dacht dat het er wel redelijk aan toe ging. Ik wist dat het niet af was en dat er gaten zaten in een aantal onderdelen. Toch was het vervelend om te horen dat het document onvoldoende was. Ik heb het toen een beetje op me genomen om zowel het SDD als SRS eens flink op de schop te nemen. Ik ben bij het SRS begonnen en heb daarna het SDD aangepst. Ik heb alles van a tot z nagelopen, gecontroleerd op spelling en taal, coherentie ingebracht en figuren duidelijker gemaakt door concepten en attributen te gebruiken door het hele document, in plaats van steeds weer verschillende termen.

SRS

Ik heb het SRS ook grotendeels omgebouwd, na de feedback die we kregen van de tussentijdse beoordeling. Ik heb het domeinmodel helemaal opnieuw gemaakt waarbij ik de opnames van het gesprek met Erik nog een keer goed heb geluisterd. Ik heb de termen die Erik en Dana ons gaven gebruikt om het model op te bouwen en heb direct uitgelegd waarom dit op deze plek staat in het domeinmodel. Na het domeinmodel geüpdatet te hebben, ben ik doorgegaan met de use-cases en heb deze in een volledig nieuwe use-case diagram gezet en ben daarna eens alle use cases die we al uitgewerkt hadden na gaan lopen. Daarbij heb ik een aantal use-cases die niet meer relevant waren verwijderd en nieuwe toegevoegd. Ik heb daarbij ook duidelijk gemaakt aan de rest van de groep dat dit onze 'scope' is, oftewel dat dit alle use-cases zijn die we moeten realiseren en we daarbuiten alleen documentatie hoeven te leveren.

Unit-tests

Ik vond het maken van unit-tests niet zo lastig, maar ik had dan wel het voordeel dat de rest van de groep al unit-tests gemaakt had waardoor ik mijn vragen en onduidelijkheden makkelijk bij hen kwijt kon. Ik had langer gewacht met het maken van unit-tests omdat ik me veel bezighield met de documentatie van onder meer het SRS en SDD. Voor mij zijn de verschillende methodes van Mockito nog altijd een stukje magie, maar met uitleg van onder andere Thomas en Wijnand begon ik het meer en meer te begrijpen. 

Code

Testplan + rapport

Kwaliteit geleverde eindproduct

Voor ons product waren documentatie en uitbreidbaarheid de prioriteiten. We hebben uitendelijk twee producten ontwikkeld en daarbij een boel documentatie geleverd.

Ik vind dat de documentatie die we hebben geschreven bij de producten die we gemaakt hebben best redelijk is. Ik zou het niet perfect noemen, omdat ik vind dat er nog redelijke gebreken zijn. Zo hadden we zowel het SRS als SDD aan het begin van het project zoveel mogelijk moeten maken. Onze aanpak was nu niet goed. We maakten eerst iets en gingen daarna design-decisions vastleggen en schemas maken. We hadden dit beter andersom kunnen doen. Vanuit Astah hadden we de gemaakte UML-diagrammen dan direct kunnen omtoveren tot bruikbare code en hadden we alleen maar de logica binnen de methodes moeten maken, wat waarschijnlijk wel wat werk had gescheeld. Desalniettemin zijn deze twee documenten een goede handleiding voor ons product en met name voor de keuzes die we gemaakt hebben om tot een bepaalde oplossing te komen.

Naast deze twee documenten hebben we een installatiedocument, wat met name voor de volgende groepen die aan dezelfde opdracht als wij zullen gaan werken. Het document helpt deze groepen bij het correct installeren van zowel de front- als backend producten die wij gemaakt hebben. Dit is een va nde belangrijkste documenten die wij inleveren, omdat het er voor zorgt dat dit project niet steeds weer vanaf de grond opgebouwd moet worden en volgende groepen niet eerst twee weken nodig hebben om onze producten überhaupt te kunnen gebruiken. 

Onze front- en backend is van prima kwaliteit. Onze website ziet er goed uit en is gebruikersvriendelijk. Ik ben het zelf niet eens met de keuze om de grafieken op de huidige manier toe te voegen, maar de meerderheid van de groep vond dit een goed idee. Ik had zelf liever de grafieken ten alle tijden zichtbaar gehad aan de linkerkant, om deze dan tijdens een race snel toe te kunnen voegen, zonder drie menu's te openen. De broker laat op het moment tweemaal per seconde data zien, omdat de broker lokaal te veel performance vereist van de machine. Ik denk zelf dat dit beter had gekund. Er is van ons gevraagd om twintig maal per seconde data te proberen weer te geven. We laten nu slechts een tiende van dat zien, wat zeer ondermaats is.

De backend zit goed in elkaar. We hebben tijdens het project gebruik gemaakt van een goedkope server om de database op te hosten, waardoor we soms twijfelden of onze methodes wel goed werkten, maar dit bleek aan de servers te liggen. De data die we ophalen uit de database word vrijwel direct geladen en is ook altijd de juiste data, wat betekent dat onze geschreven methodes goed werken. We hebben tijdens het maken van al deze methodes een aantal keer alle klassen moeten verschuiven omdat we liever een andere indeling hadden. Dit ging niet altijd even goed, omdat er steeds weer merge conflicts ontstonden. Deze conflicts zijn uiteindelijk opgelost en hebben daarna niet meer voor problemen gezorgd.

Evaluatie gehanteerde projectmethode

Tussentijdse evaluatie

Ons plan van aanpak vond ik aanvankelijk niet erg goed. Ik had het idee dat we alles goed beschreven hadden en dat alles er duidelijk in stond, maar ik had toch het gevoel dat er iets miste. Bij het assessment voor het plan van aanpak kwamen dan ook enige gebreken aan het plan van aanpak naar voren. We gingen met name bij de randvoorwaarden en kwaliteitseisen voor mijn gevoel onderuit, omdat we niet goed de 5xW, 1xH en de SMART-formulering hadden toegepast. 

Ook zijn onze SCRUM-ceremonies erg ondermaats. Ik ben nog geen SCRUM-master geweest, maar ik krijg langzaam maar zeker steeds meer in de gaten dat er flinke gebreken zijn. Zo hebben we in het begin niet eens over uren gesproken bij DSU's en hadden we het alleen over onze taken. Waar we mee bezig zijn, wat we nog moeten doen en of we ergens tegen aan gaan lopen. We hebben nog niet het jira-planbord open gehad tijdens een DSU, wat er waarschijnlijk ook voor zorgt dat we als groep niet goed weten wat er gaande is binnen het project. Ik had hier zelf ook wat over moeten zeggen, maar volgens mij hadden we het als groep niet door dat dit een vereiste was.

Definitieve evaluatie

SCRUM is geen slechte manier om een project uit te voeren. Ik vind het zelf niet fantastisch werken, maar het werkt wel effectief. We hebben als groep redelijk ontwikkeld op het gebied van SCRUM. Waar we in sprint 1 een baggere planning hadden gemaakt en eigenlijk helemaal niet zo goed wisten wat we nou aan het doen waren, kwam daar langzaam verandering in.

Mijn grootste probleem lag bij het inschatten van taken. Ik merkte dat onze taken erg krap waren en dat ik vaak nét genoeg tijd had om een taak af te ronden. Daarnaast zit er in een sprint planning géén speling, omdat dat tege nde SCRUM-principes in gaat. Dit was met name voor Bram een probleem, omdat hij steeds weer nieuwe problemen tegen kwam bij het maken van de broker. Dit is dan ook waarom de lijn in de burndown-charts hier en daar plots weer omhoog gaat. Wij hadden dit als groep zelf beter kunnen en moeten opvangen. Wij waren slecht geïnformeerd over de implementatie van de broker. We hadden deze taak beter moeten opdelen en het in behapbare stukken moeten opdelen zodat we niet steeds deze ophogingen hadden. Deze ophogingen waren met name in sprint vier duidelijk. We hadden een goede planning gemaakt en waren allemaal hard aan het werk. In het begin zaten we zelfs onder de trendlijn, maar alle ophogingen zorgden er voor dat we uitendelijk onze sprint toch niet gehaald hadden.

We hadden aan het einde van de sprint ongeveer 20 uur aan taken over. Het aantal uren aan ophogingen kwam uit op 23:15 uur. Dit hadden we met z'n allen kunnen oplossen door bijvoorbeeld een zaterdagmiddag te werken, maar deze taak van Bram was voor ons hocus pocus, dus konden wij niet helpen met deze taak. We hadden dit dus beter op moeten vangen.

Naast het plannen van uren is SCRUM voor mijn gevoel ook niet erg handig qua reviewen. Dit valt een beetje terug op het plannen d.m.v. tijd, want reviewen het verbeteren van producten na een review neemt ook tijd in beslag die of als taak opgenomen zou moeten worden of ope een andere manier ingepland zou moeten worden. Het wordt echter lastig dit als taak in te plannen, want een deeltaak kan some in één keer goed zijn, maar kan soms na vijf reviews nog niet goed zijn. 

Beschrijving rollen binnen projectgroep

Ik heb vanaf begin af aan de rol van ‘agendabeheerder’ op me genomen. Ik wilde graag de agenda bijhouden om zo beter boven op de opdracht te zitten en goed in de gaten te hebben wat er te doen staat voor ons team. Deze rol staat niet uitgelegd in het plan van aanpak, maar blijkt toch erg handig voor het team. Er staan geen dubbele afspraken in de agenda en alle afspraken volgen dezelfde regels. Zo staan er geen verwarrende dingen in de agenda en is alles netjes en geordend.

Ik heb over het algemeen de rol van developer gehad. Naast hier en daar een nieuwe afspraak of deadline in de agenda te zetten ben ik verder goed aan het werk gegaan. Ik heb dit redelijk weten te doen. Ik was niet altijd even ijverig aan het werk, omdat ik soms een taak had die me óf minder interesseerde óf omdat deze taak erg lang en/of saai was. Het compleet omgooien van het SRS en SDD leek me erg leuk om mee bezig te zijn. Dit was ook leuk toen ik er mee begon, maar toen ik een paar uur later steeds hetzelfde moest doen en steeds weer zat te klooien met Astah, merkte ik dat mijn aandacht al snel wegzakte. Ik heb hierdoor denk ik ook anderen afgeleid, wat ik juist probeerde te voorkomen. Ik had dit beter kunnen aanpakken door in plaats van een beetje onderuitgezakt op mijn stoel te zitten even op de gang te lopen en even een rondje door het gebouw te doen. Zo zou mijn brein weer fris en fruitig het lokaal binnenkomen en zou ik er weer even tegenaan kunnen.

In Sprint 5 was ik de SCRUM-master, waarbij ik de groep tijdens de DSU's, retrospective en de sprint-planning een beetej begeleidde. Ik heb dit wel redelijk gedaan. Ik had graag iemand voor mij een DSU-formulier laten invullen, maar door ziekte is dat er niet van gekomen. Als ik deze had laten invullen, had ik misschien een beter inzicht kunnen krijgen in dingen die ik anders kon doen of dingen die ik beter kon doen door andere handelingen aan te nemen. 

Toelichting Competenties

OOSE P-01. De student voert een project uit op basis van Scrum en een plan van aanpak en evalueert en reflecteert hierop, op individueel en projectniveau.

                We hebben als groep op dag één een scrum-master aangewezen per sprint, zodat we nooit zonder scrum-master zouden zitten. Ik heb in Sprint twee de taak van notulist gekregen. Men verwacht dus dat ik de notulen van belangrijke momenten noteer en dat ik de daily-stand-ups (DSU) bijhoud. Ik had hier wel een goed gevoel bij en had het idee dat ik dit wel kon. Ik had dit immers bij het I-project ook al redelijk uitgevoerd. Ik heb mijn werkwijze met name gebaseerd op voorgaande ervaring met onder meer aantekeningen maken bij hoorcolleges en het I-project. Wanneer we een gesprek, meeting of DSU hadden, pakte ik meteen de notities er bij en begon ik te tikken. Ik denk dat ik dit voor de meetings en gesprekken goed gedaan heb, wat teruggevonden kan worden in de notulen van 21 November 2022 in het mapje Notulen op Confluence. Waar ik meer aandacht aan had moeten geven was het noteren van DSU’s. Ik ben dit vergeten en heb hier de hele sprint niet aan gedacht, wat er voor gezorgde heeft dat we als groep nergens de resultaten van onze DSU’s kunnen teruglezen. Ik ben dus best wel teleurgesteld in hoe ik mezelf heb gedragen als notulist, omdat dit vele malen beter kon. Het had dus echt anders gemoeten dan wat ik heb laten zien. Het kan nu zomaar zijn dat een volgende notulist nu ook niet aan de DSU’s denkt en we nog minder DSU’s kunnen teruglezen. In een volgend gesprek wil ik dus echt beter na gaan denken of het handig is om notities te maken als we in een vorm van overleg zitten. Ik kan beter te veel dan te weinig notities maken.

OOSE P-02. De student analyseert de eisen en wensen voor de software van een systeem, en documenteert deze in een Software Requirements Specification (SRS).

                Bij ons eerste gesprek als groep met Erik Regterschot kwamen een hele hoop eisen naar voren. Ik heb aan het begin van Sprint 1 de verantwoordelijkheid op me genomen om de verschillende eisen die in de notulen stonden en de opnames van het gesprek die we hadden te noteren in het SRS. Ik heb eerst de hele opname een keer geluisterd en met pen en papier aantekeningen gemaakt bij opvallende dingen of duidelijke eisen. Daarna heb ik deze aantekeningen samen met de notulen op een rijtje gezet en langzaam omgevormd tot meerdere tabellen, die in het SRS te vinden zijn bij de functionele en non-functionele requirements. Het resultaat was een duidelijke lijst aan eisen die makkelijk aan te vullen is bij eventuele nieuwe esien vanuit de opdrachtgever. Ik zou de volgende keer het luisteren naar de opname anders doen. Ik zat nu bij de rest van de groep aan tafel met oordoppen in te luisteren. De groepsleden praatten nog wel eens of vroegen nog wel eens wat, waardoor ik weer uit het verhaal was en weer een stuk moest terugspoelen. Ik zou in het vervolg dus even ergens apart moeten gaan zitten of duidelijk moeten maken dat ik nu niet gestoord kan en wil worden.

OOSE P-03. De student onderzoekt voor het project relevante (technologie)keuzes en rapporteert hierover gestructureerd.

                Ik heb het onderzoek ‘visuele dataweergave’ gedeeltelijk in elkaar gezet. Dit heb ik samen met Martin gedaan. We hebben al wel eens vaker aan een opdracht samen gewerkt, dus ik had er alle vertrouwen in dat dit goed zou gaan. Ik heb de hoofd- en deelvragen opgesteld en vervolgens de kopjes “5. Hoe wordt de data van een raceauto bij een autorace weergegeven”, “7.1 JfreeChart” en “8. Wat zijn de voor- en nadelen van de verschillende geïmplementeerde API’s?” gemaakt. Ik heb kop 5 gemaakt door veel onderzoek te doen op het internet en dus te lezen over de praktijk. Kopje 7.1 heb ik beantwoord door een prototype te maken, waarbij ik meerdere grafiektypes heb gemaakt en hierbij heb gekeken naar de implementeerbaarheid, documentatie, prestatie, uitbreidbaarheid en de uiteindelijke gemakkelijkheid van het maken van het prototype. Deze resultaten heb ik vervolgens in een grote tabel gegooid om snel een makkelijk overzicht te krijgen van alle voor- en nadelen. Ik ben erg tevreden over dit onderzoek, omdat ik vind dat we een net en strak onderzoek hebben neergezet, waarbij we onze bevindingen goed in woorden hebben kunnen brengen. Door dit onderzoek is het voor anderen duidelijk waarom we voor de Google Charts API hebben gekozen. Dit onderzoek heeft er ook voor gezorgd dat andere groepen die na ons zullen komen niet een nieuw API onderzoek moeten gaan doen, omdat dit onderzoek de keuze al goed verwoord. Ik zou in een volgend project of in het bedrijfsleven wel vaker zo’n onderzoek willen doen, al zou ik dan een uitgebreider onderzoek willen doen, waar meer tijd voor staat, want een onderzoek doen in 3 à 4 dagen is nogal kort en geeft weinig tijd of ruimte om uitgebreidere prototypes te maken.

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 Description (SDD).

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-funcitonele eisen.

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

                De kalender van Confluence is mijn speeltuin. Tijdens de start van het project heb ik meteen aan de groep gemeld dat ik het leuk zou vinden om de agenda te beheren. De groep vond dit meer dan oké, omdat zij volgens mij wel inzagen dat één beheerder van de agenda makkelijker en efficiënter is dan een hele groep die tegelijkertijd met de agenda bezig is. Wanneer we een afspraak maken als groep of er een deadline, meeting of nutshell-talk gepland wordt of staat, is deze gebeurtenis  meestal binnen vijf minuten in de kalender te vinden. Door dit soort dingen meteen in de agenda te zetten, worden er geen meetings of dergelijken gemist en komen we als groep veel professioneler over. De rest van de groep vindt het erg fijn dat ik deze taak heb opgepakt, omdat ze nu makkelijk in de agenda kunnen zien wat er te doen is op een dag en hebben ze een beter overzicht van de aankomende week. Ik vind dat ik nog wel kan verbeteren in de kalender, omdat de meeste gebeurtenissen geen omschrijving hebben of een hele magere. Door de omschrijving goed en duidelijk te maken, zullen er minder snel vergissingen komen. Zo was er voor een aantal deadlines de vraag of het tijdstip wel klopte, omdat er in de kalender 4 uur stond maar in iSas 5 uur. Door in de omschrijving te zetten dat dit een uur voor de deadline is, vervalt deze verwarring. Ik ga in een volgend project zeker vragen om dit weer te mogen doen, omdat ik dit leuk vindt om te doen en het de groep als geheel enorm helpt.

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.

                Bij het onderzoek ‘CSS-framework’ heb ik gereviewed op de spelling. Ik heb met name in de conclusie en de alinea daar voor veel opmerkingen kunnen plaatsen over onder meer zinsopbouw, spelling en taal. Door alle zinnen eens grondig te lezen en daarna alles nog een keer door te nemen, heb ik nagenoeg alle fouten er uit kunnen halen. Door deze spellingscontrole verbeterde de kwaliteit van het onderzoek, waardoor het voor anderen makkelijker te lezen is. Een verbetering voor een volgende keer zou zijn om spellingscontrole en taalhulp pas toe te passen tijdens het reviewen, omdat ik merk dat ik nu nog veel van deze controle/hulp tijdens het maken van de onderzoeken doe. Hierdoor is het moeilijk om te zien wat ik heb gerievewed of waar ik geholpen heb met spelling en taal. Ik denk dat ik door deze controles uit te voeren in volgende projecten gezien kan worden als iemand die betrouwbaar kan schrijven met weinig taalfouten. Daarnaast kan ik ook andere groepsleden goed helpen als zij het niet snappen.

OOSE P-08. De student kan zich zelfstandig verder verdiepen in de beroepstaak.

                Ik heb samen met Martin aan het onderzoek ‘Visuele Dataweergave’ gewerkt. We deden onderzoek naar het weergeven van data binnen applicaties. Hoe wordt dit gedaan en wat zijn de populaire trends hierbij? Bij dit onderzoek hebben we ook gekeken naar de verschillende implementaties van API's die het mogelijk maken om grote hoeveelheden data weer te geven. Ik heb bij dit onderzoek de hoofd- en deelvragen opgesteld die verderop in het onderzoek beantwoord zullen worden. Ik wilde hier graag een goede set vragen opstellen die ons door het onderzoek heen zouden leiden in een logische volgorde, om niet halverwege het onderzoek nieuwe vragen te moeten toevoegen. Bij de deelvraag ‘Hoe wordt de data van een raceauto bij een autorace weergegeven?’ heb ik me veel verdiept in de baan van een race-analyticus, wat voor aardig wat inzichten gezorgd heeft. Zo ben ik veel te weten gekomen over racedashboards bij de Formule 1 en hoe deze dashboards in elkaar steken. Door wat afbeeldingen aan de rest van de groep te laten zien, gekoppeld met wat uitleg, kreeg de rest van de groep snel een idee van het product dat verwacht wordt van ons. Voor mij was dit deel van het onderzoek best belangrijk, omdat ik zo een betere voorstelling had van het op te leveren product. Wat ik de volgende keer wel beter zou kunnen doen is het lezen van meer artikelen of onderzoeken. Ik heb het bij deze deelvraag grotendeels bij één artikel gehouden, wat de betrouwbaarheid van het onderzoek wat minder maakt. Door dit onderzoek ben ik nu zeker in staat om in volgende projecten een goed onderzoek uit te voeren.

Leerdoelen

Leerdoelen

Bij eerdere gesprekken met zowel groepsgenoten als opdrachtgevers, merkte ik zelf op en kreeg ik te horen dat ik vaak wat stil bleef en niet veel vragen stelde. Daarom wil ik beter opletten bij gesprekken zodat ik meer zinnige vragen kan stellen en kan blijven doorvragen over het onderwerp. Ik wil hier aan gaan werken door van tevoren een gesprek goed voor te bereiden zodat ik alvast zinnige vragen kan bedenken om te kunnen stellen. Daarnaast wil ik een actievere rol binnen een gesprek aannemen om zo beter in aan een gesprek deel te kunnen nemen.

Ik ben van nature wat afwachtend, wat kan resulteren in een terughoudende houding in een gesprek of bij een overleg. Ik wil dus graag minder de kat uit de boom kijken en juist direct overgaan tot actie. Ik kan dit doen door actiever deel te nemen aan een gesprek door bijvoorbeeld het gesprek te openen of kritische vragen stellen. Op die manier kan ik beter bijhouden waar we in een gesprek zijn en kan ik de aandacht er beter bij houden.

Tussentijdse Reflectie

Ik merk dat ik mezelf al enigszins heb kunnen ontwikkelen bij het stellen van vragen. Ik stelde tijdens ons gesprek met Erik Regterschot veel vragen en probeerde actief deel te nemen. Er is echter nog veel meer voortgang te boeken binnen dit leerdoel, omdat ik alleen binnen dat gesprek heb kunnen laten zien dat ik het wel in me heb. Ik wil met name in gesprekken met onder meer Erik en andere mensen die bij Regterschot werken meer vragen kunnen stellen en actiever deelnemen met de gesprekken.

Ik merk dat ik qua afwachtende houding nog niet veel verbetering heb laten zien. Ik probeer het voortouw in een gesprek te nemen, maar ik merk al snel dat ik zelf wat naar de achtergrond verplaats als anderen proberen te praten. Ik ben iets te afwachtend met het delen van mijn ideeën of ingeving, waardoor ik soms mijn kans mis om nog inbreng te geven, omdat het gesprek dan al weer verder is gegaan naar een ander onderwerp. Ik zou dus graag nog wat sneller willen reageren en misschien de spotlight van iemand anders stelen om mijn inbreng te kunnen delen met de rest van de groep.

Reflectie eindverslag

Ik stel nu goede vragen bij gespreken met een assessor of opdrachtgever. Ik heb onder meer bij het bespreken van de feedback op de tussentijdse producten effectieve en doelgerichte vragen gesteld over hoe we nu verder moeten werken, zoals: "Is het verstandig om in het SRS een lopen verhaal te maken zodat het niet alleen voor onszelf maar ook voor de opdrachtgever duidelijker is waarom we zo'n document maken en hoe dit doucment in elkaar steekt? We hebben nu namelijk een inleiding die vrij abrupt eindigt en dan zomaar een groot domeinmodel, zonder uitleg, naar voren schuift."

Dit werkte vrij goed op mijn zelfvertrouwen, ik kreeg het idee dat ik best wel goed vragen kon stellen en dat er helemaal geen probleem was met het voortouw te nemen. Deze vraag met name voelde als een soort kantelpunt. Ik kreeg meer zelfvertrouwen en het werdt veel makkelijk om vragen te stellen, ook al dacht ik er niet eens zo lang bij na. In een volgend project zou ik graag op dit punt willen doorontwikkelen, omdat ik merk dat het formuleren van vragen nog een lastig punt is. Het nadenken over de juiste formulering is iets waar ik beter op wil letten, omdat ik mezelf nu nog wel eens verspreek of het naar mijn idee onduidelijk verwoord.

Ik heb de afwachtende houding wat achter me kunnen laten. Na het uitvallen van Helen en het zijn van SCRUM-master merkte ik dat ik het voortouw nam en snel antwoord gaf op vragen. In een tweede gesprek met de skills-begeleider gaf ik snel antwoord op de gestelde vragen en reageerde ook goed op de andere groepsleden als deze aan het spreken waren. Ik merkte nog wel dat ik er soms wat moeilijk tussen kwam, omdat ik niet graag door anderen heen praat. Dit is soms wel nodig, omdat het moment om te reageren anders weg is en ik niet meer de gelegenheid heb binnen dat gesprek om mijn mening te delen. Ik zou graag in het volgende project graag daar op willen focussen, het directer 'discussiëren' met anderen. Hoe lief het ook is om de ander uit te laten praten, is het soms simpelweg nodig om er snel tussen te komen.

Conclusie

Ik denk dat ik niet heel sterk aan het project begonnen ben, maar dat zal denk ik voor de hele groep zo zijn. We hebben veel dingen maar half gedaan en we kunnen enorm veel winst boeken op sommige onderdelen. Zo zouden we onze DSU's toch echt moeten verbeteren. We moeten ons Jira bord open hebben en ik wil de feedbackkaart voor de DSU minimaal drie keer per week in gaan vullen. Zo kan ik een beter inzicht krijgen in hoe ik er op dat moment voor sta, maar ook hoe de rest van de groep op het moment bezig is. 

Daarnaast wil ik wat meer aan code gaan werken. Ik heb naast het maken van een prototype en het maken van een Angular workshop alleen een kleine hoeveelheid code geleverd aan het project. Om mijn competenties op dit vlak beter te laten zien, zal het dus van belang zijn om meer code te gaan schrijven. Op die manier kan ik in het eindverslag goed laten zien dat ik ook kwalitatief goede code kan schrijven waar goed over na is gedacht en waar de juiste afwegingen voor gemaakt zijn. De eerste twee sprints bevatte van nature meer onderzoek- en documentatiewerk, dus ik denk dat dit vanzelf goed gaat komen naarmate we verder in het project komen. 

Bronnenlijst

Bijlagen

Opnames gesprek Regterschot

Opname van het gesprek met Erik Regterschot op 4 November 2022

AUD-20221108-WA0000.m4a

Kernkwadranten

Factsheet