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 producten

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.

Aan het eind van Sprint 2 hebben we nu 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.

De kwaliteit van onze code was aan het begin ook niet je van het, maar na een aantal reviews werd dat al een stuk beter. Ik merkte dat ik mijn code na een review ook beter snapte, omdat er nu twee mensen naar hadden gekeken, die beide hun eigen ideeën hier over hadden.

Evaluatie gehanteerde projectmethode

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.

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.

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-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 denk 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. Ik denk dat ik echter nog veel meer voortgang kan boeken binnen dit leerdoel, omdat ik denk dat ik eigenlijk 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 denk 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.

Kernkwadranten

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

Factsheet