← Terug naar leeswijzer

Discussie

Uitvoering opdracht

Tijdens de stage is goed gepland. Op het begin was er een grove planning gemaakt met de algemene stappen die ondernomen moesten worden. Dit is maar 1 keer aangepast om de prototypes toe te voegen. Wellicht had er in de planning meer tijd ingepland moeten worden voor feedback momenten, maar dit is een ander probleem (wordt verderop besproken).

Af en toe was de uitvoering een beetje sloom. In Jira werd per onderdeel een aantal uren ingepland. Deze werden bijna altijd overschreden. Echter kwam de planning toch elke keer uit. Dit betekent dat er op andere taken minder tijd is besteed dan verwacht. De tijdsplanning voor de gehele sprint klopte dus wel, maar de planning van de individuele taken niet.

Er is niet echt in sprints gewerkt volgens het systeem van Jira. Dit had als voornaamste reden dat de bedrijfsbegeleider van mening was dat het geen nut had om sprints op te stellen voor de fases van het project vóór de ontwikkeling van het eindproduct. Deze mening deelde ik niet met hem. Daarom is er alsnog informeel met sprints gewerkt door taken in te plannen in groepen per week of twee weken. Aan het einde van zo’n sprint werd het portfolio vaak geüpdatet.

Er is zelfstandig gewerkt. Dankzij de goede planning was er altijd wat te doen, zonder dat er hulp nodig was van de bedrijfsbegeleider. Dit is goed, omdat het betekent dat ik kan werken zonder constant hulp nodig te hebben van anderen. Ik zou kunnen werken ook als er niemand in de buurt is. Echter is dit niet altijd goed, omdat het er ook toe geleid heeft dat het bedrijf geen idee had wat er gemaakt werd. Door wellicht iets te zelfstandig te werken, zijn er weinig feedback momenten geweest met het bedrijf. De deelproducten hadden vaker gepresenteerd kunnen worden aan het bedrijf.

Onderzoek

Bij het beantwoorden van de onderzoeksvragen zijn verschillende onderzoeksmethoden gebruikt, zoals te zien is bij de verschillende deelproducten in het portfolio. Verschillende deelproducten werden als basis gebruikt bij het ontwikkelen van andere deelproducten (bijvoorbeeld ux onderzoek + prototypes + testverslag => AED les).

De volgorde waarin de deelproducten gemaakt zijn was goed. Er is eerst onderzoek gedaan naar wat er bestaat en wat er nodig is, zodat er een onderbouwde keuze gemaakt kon worden over hoe het eindproduct eruit zou zien. Er is niet gehaast om iets te ontwikkelen. In plaats daarvan is er eerst uitgebreid geanalyseerd.

Wel had er vaker getest mogen worden. Er is nu elke keer een hele tijd aan een aantal onderdelen gewerkt om deze dan in een keer te testen. Bij de prototypes was het zo besloten, omdat het makkelijker was deze in een keer te testen. Het was geen probleem, omdat elk prototype iets anders testte. Echter had het eindproduct wel vaker getest mogen worden, om te kijken of het nog de goede kant op ging.

Communicatie met school

Er is niet veel communicatie geweest met de docentbegeleider. Er was ook niet veel te melden. Wellicht had er vaker om feedback gevraagd kunnen worden op specifieke documenten of onderdelen van het portfolio.

Een gezamenlijke Discord server was opgezet voor alle afstudeerders van GD&T. Hierin werden regelmatig dingen besproken en gedeeld. Dit gaf een duidelijk beeld van wat anderen aan het doen waren. Dat kon ik vergelijken met mijn eigen handelen en waar nodig dingen aanpassen.

Richting het einde van het stagetraject is twee keer een call gedaan met twee andere studenten die met een portfolio afstuderen. Tijdens deze calls zijn de verschillende portfolio’s besproken. Opvallend was dat iedereen het heel anders aanpakte. Uit deze gesprekken zijn nuttige tips en feedback gehaald.

Begeleiding vanuit het bedrijf

Vanuit het bedrijf is weinig begeleiding ontvangen, voornamelijk omdat er ook niet specifiek om gevraagd werd. Het bedrijf liet me voornamelijk mijn eigen ding doen. Dit heeft niet direct voor problemen gezorgd. Er kon goed zelfstandig gewerkt worden, omdat de opdracht duidelijk was en er een goede planning was gemaakt. Echter is hierdoor ook de algemene communicatie tussen mij en het bedrijf slechter geworden. Zo had het bedrijf op een gegeven moment geen idee meer waar ik mee bezig was. Een gedeeltelijke oorzaak hiervan is ook dat ik op een gegeven moment niet meer mee kon doen aan de stand-ups, omdat deze te lang gingen duren door het groeiende aantal personen dat ’s-ochtends hun verhaal moesten vertellen.

Er hadden meer feedback momenten ingepland moeten worden. Zoals al vaker benoemd is inmiddels, was het bedrijf na een tijd niet meer op de hoogte van mijn werkzaamheden. Hierdoor kon er niet gecontroleerd worden of de producten nog voldeden aan het beeld dat het bedrijf bij de opdracht had. Echter was er van tevoren duidelijk gedefinieerd wat er gemaakt moest worden voor de opdracht, waardoor dit uiteindelijk geen probleem bleek te zijn. Toch is het goed om hier in de toekomst wel rekening mee te houden.

BuildingBlocks

Tijdens het maken van het eindproduct is er gebruik gemaakt van de verschillende buildingblocks van BlueTea. Hierbij hebben zich een aantal problemen voorgedaan. Daarnaast zijn er nog een aantal opmerkingen over de structuur van de buildingblocks.

Er is vrijwel geen documentatie, behalve een enkele pagina met een paar basisconcepten die een jaar geleden zijn opgesteld en niet onderhouden worden. Er is wel gegenereerde documentatie van de code, maar deze is alleen nuttig als je iets moet weten over een bepaalde klasse of methode. Het is lastig om een overzicht te krijgen van de manier waarop de buildingblocks in elkaar zitten. Hierdoor zijn er mogelijk een aantal dingen gemaakt die eerder al in een van de buildingblocks verwerkt waren.

De buildingblocks zitten veel te ingewikkeld in elkaar. Om een enkele functie uit te voeren (bijvoorbeeld het versturen van een authenticatie request naar Virtual Studio) moet je door 7 of 8 verschillende lagen heen om bij de daadwerkelijke definitie te komen. Dit maakt de code vrijwel onmogelijk te debuggen. Daarnaast is het ontzettend lastig te ontdekken waar een performance issue zit. Bij gelimiteerde hardware zoals de HoloLens is het heel belangrijk dat elk proces zo efficiënt mogelijk uitgevoerd wordt.

Het idee van de buildingblocks is handig, omdat alle functionaliteiten zijn opgedeeld in verschillende delen. Een project kan de buildingblocks gebruiken die de functionaliteiten bevatten die voor dat project relevant zijn. Echter zijn er een aantal buildingblocks die afhankelijk zijn van elkaar (als je bijvoorbeeld de Virtual Studio buildingblock gebruikt, heb je al vrijwel alle andere buildingblocks nodig). Er is nergens gedocumenteerd wat deze dependencies zijn.

Makkelijk zou zijn als er een soort package manager gemaakt wordt voor de buildingblocks. Hiermee zouden buildingblocks en hun dependencies makkelijker geïmporteerd kunnen worden in een project.