Voortgangsevaluaties semester 2

Naam: Menno Weerman

Datum voortgangsevaluatie: 12-5-25 t/m 16-5-25

In deze voortgangsevaluatie behandel ik de leeruitkomsten uit semester 2.

Toekomstgericht Organiseren: Je brengt de doelen, betrokkenen en aandachtspunten van de opdracht in kaart en past de opgedane kennis toe in het project. Hierbij volg je de afgesproken kwaliteitsnormen en bespreek je regelmatig risico’s en kansen met belanghebbenden. Je beschrijft welke ethische en/of maatschappelijke normen en waarden van belang zijn bij je keuzes. Je verdeelt de opdracht in haalbare deeltaken en plant deze in de beschikbare tijd.

Onderzoekend Probleemoplossen: Je onderzoekt mogelijke oplossingen voor een probleem of behoefte binnen je project. Je gebruikt betrouwbare bronnen om je keuzes te onderbouwen, stemt af met belanghebbenden en test de effectiviteit van de oplossingen door veldonderzoek uit te voeren, bijvoorbeeld aan de hand van gebruikersonderzoek of interviews. Je gebruikt de resultaten van je veldonderzoek en de feedback van belanghebbenden om je product te verbeteren. Je presenteert de onderzoeksresultaten helder en gestructureerd aan de hand van een gegeven format.

Leeruitkomst 1: Software

Je ontwerpt, maakt en test een (web)applicatie met een relationele database op basis van requirements en acceptatiecriteria. Je maakt, volgens geldende standaarden, gebruik van opmaaktalen en programmacode en past daarbij standaardmethodes en algoritmes toe voor het ontwerpen en realiseren van onderhoudbare software. Je werkt in een team, houdt technische documentatie bij en beheert het software-ontwikkelproces in GitLab met behulp van gangbare samenwerkingsafspraken. Je verdeelt de opdracht in haalbare deeltaken en plant deze in de beschikbare tijd en bespreekt de risico's en kansen met belanghebbenden. Je onderzoekt mogelijke oplossingen voor een probleem of behoefte binnen je project. Je gebruikt betrouwbare bronnen om je keuzes te onderbouwen en stemt af met de product owner.

Hoe sta ik ervoor?

Verwacht resultaat: * Op Niveau

Ik ben van mening dat ik goed op weg ben met het behalen van dit leerdoel. Hoewel ik nog niet met zekerheid kan zeggen of ik het gewenste eindniveau al volledig heb bereikt, zie ik duidelijke vooruitgang in mijn ontwikkeling gedurende deze periode. Met name op schriftelijk en mondeling vlak merk ik dat ik gegroeid ben. Deze groei is mede te danken aan mijn actieve toepassing van de PDCA-cyclus, waarmee ik mijn werkzaamheden structureel evalueer en verbeter.

Het project waar ik momenteel aan werk, heb ik tot nu toe nog niet met een database gekoppeld. Hierdoor heb ik nog niet aan alle gestelde criteria kunnen voldoen. Desondanks zie ik deze fase als een belangrijk leerproces, waarin ik op andere vlakken veel heb bijgeleerd en mijn professionele vaardigheden heb versterkt.

Wat heb ik gedaan en geleerd?

Bewijs

Toelichting

Er staat dat ik al goed op weg ben met programmeren. En op conceptueel gebied ook ver ben gekomen door de sterke documentatie. En vragen kan beantwoorden van leraren en medestudenten. Dit toont aan dat ik al veel progressie heb gemaakt op het gebied van programmeren en het design proces van tevoren wat ik voor deze opleiding nooit deed naar goede design.

Als ik iets heb gemaakt, dan maak ik hier een commit van en push dit naar github. Dit doe ik meestal alleen als ik het ook echt functionerend heb en niet als hetgeen wat ik gemaakt heb nog niet werkt. Het enige waar ik nog op moet letten is dat ik dus wat vaker ga committen en beter ga letten op de commit messages zelf. Zo bouw je een duidelijker overzicht op van je ontwikkeltraject, wat debugging en samenwerken makkelijker maakt.

Leeruitkomst 2: Gebruikersinteractie

Je verbetert de gebruikersinteractie van je product door UX-standaarden en best practices te gebruiken. Je doet elke sprint een TMC-cyclus waarbij je je product met de eindgebruiker test. Je stelt eigen user stories op vanuit inzichten uit de test en werkt deze uit in je product. Ondersteunend aan dit proces maak je prototypes en bespreek je ontwerpkeuzes met al je stakeholders. Je houdt documentatie bij van het TMC-proces en zet belangrijke inzichten en beslissingen van het game design en interactie-ontwerp bij in een Game Design document, evenals doelen, aandachtspunten en betrokkenen. Hierbij maak je gebruik van bestaande en actuele standaarden. Het bijhouden wordt gedaan in een iteratief proces, waarbij je geregeld je gemaakte keuzes verantwoordt met betrouwbare bronnen. Je presenteert de verschillende iteraties aan je product owner tijdens de product reviews, evenals welke ethische en/of maatschappelijke normen en waarden van belang zijn bij je keuzes.

Hoe sta ik ervoor?

Verwacht resultaat: * In Ontwikkeling

Gedurende dit jaar heb ik via de PDCA-cyclus – plannen, uitvoeren, evalueren en bijstellen – actief gewerkt aan mijn ontwikkeling; ik geloof dat ik goed op weg ben met mijn doel en hoewel ik niet zeker weet of ik al het gewenste eindniveau heb bereikt, zie ik in deze periode duidelijke persoonlijke groei en waardevolle vooruitgang.

Wat heb ik gedaan en geleerd?

Bewijs

Toelichting

De think was goed gedaan omdat ik bezig was met het telkens verbeteren van de GDD en hoe ik de feedback verwerk. Er was een duidelijke focus op de paper prototype en de check had ik een mooi formulier voor gemaakt. De verbeterpunten die ik kreeg was dat de GDD niet op github te vinden was. De make mocht meer bevatten dan alleen de Paper prototype, zoals het werk wat ik had voor de local prototype. De verbeterpunten heb ik gelijk toegepast door de GDD op gitlab correct te zetten, verder te werken aan de game en doelgerichter te testen.

Tijdens de testfase hebben we mensen uit andere projectgroepen gevraagd om onze game te testen, mits zij hier tijd voor hadden. Deze testers hebben het spel gespeeld terwijl ze hardop nadachten over hun keuzes (think-aloud-methode).

Uit deze sessies kwamen verschillende inzichten naar voren:

· De game werd omschreven als zowel 'goofy' als strategisch, wat overeenkomt met onze ontwerpdoelen.

· Het mechanisme waarbij spelers vier beurten moeten wachten voordat ze de grid mogen draaien, werd als een goede snelheid ervaren — het zorgt voor een gebalanceerd tempo in het spel.

· Wel merkten testers op dat het strategisch plannen van je beurt veel vooruitdenken vereist, wat het spel uitdagender maakt.

Verwerking van feedback: Op basis van deze feedback hebben wij de instructies binnen het spel verduidelijkt, zodat spelers beter begrijpen hoe ze strategisch kunnen plannen. Daarnaast hebben we in de documentatie bij het onderdeel "Core Mechanics" extra toelichting toegevoegd over de reden achter de vier-beurten-regel, zodat spelers begrijpen hoe dit bijdraagt aan het speltempo en de strategie.

Leeruitkomst 3: Infrastructuur

Je ontwerpt, realiseert en beheert een nieuwe infrastructuur op basis van de behoeften van de gebruiker. Je beschrijft welke informatie nodig is om deze infrastructuur goed op te zetten, en legt de relevantie hiervan uit. Je hebt de infrastructuur, zowel het geheel, de individuele componenten én de bijbehorende communicatieprotocollen, volledig en correct beschreven in bijbehorende documentatie met betrouwbare bronnen, inclusief testprotocollen. Je hebt de infrastructuur gerealiseerd en getest, zowel op functionaliteit als veiligheid. Je publiceert je game op een bestaande publishing site (zoals itch.io) en stelt daarbij de nodige werkprocedures op voor het publiceren van deze games, alsook voor het onderhouden van deze game door middel van updates.

Hoe sta ik ervoor?

Verwacht resultaat: * Onder Niveau

Aangezien ik nog niet ben begonnen met de ontwikkeling van de infrastructuur van de game, noch met de voorbereiding op de release, beschouw ik mijn voortgang als onvoldoende. Op dit moment ben ik nog niet ver genoeg gevorderd om te voldoen aan de gestelde verwachtingen.

Wat heb ik gedaan en geleerd?

Bewijs

Toelichting

Als er een tag wordt aangemaakt, dan wordt er ook gekeken naar fouten in de code. Dan wordt er een windows build gemaakt en door butler gepushed naar Itch. Op de foto's (onder bewijs) zijn de variabele te zien. Waarbij de Itch User gelijk staat aan mijn itch username. De Project name gelijk staat aan de naam van het project op Itch. Butler Api key heb ik verkregen door Butler via itch te installeren. Dan in Git Bash de command $ butler login te doen en in te loggen op het account. Als je dat gedaan hebt, dan kan je naar verkenner gaan, %userprofile% invoeren, naar .config gaan, de itch folder ingaan en dan in de folder staat een bestand met butler_creds waar je de Butler Api key kan vinden. De Api Access token heb ik verkregen door op mijn profiel een personal access token aan te maken en de opties api en read_api aan te tikken, dan de token aan te maken. Als dat gedaan is kan je de token kopieëren en invullen in de Api Access token variabele. De build zal drie fases doorlopen om te kijken of deze op itch gezet kan worden, de eerste is om te kijken of de tag bij de release branch hoort, zo ja gaat hij door. Daarna zal er een executable van de game gemaakt worden en zal de build gedeployed worden op itch. De naam van de release staat gelijk aan de naam van de tag.

Leeruitkomst 4: Persoonlijk Leiderschap

Je reflecteert op je gedrag en het effect daarvan op anderen binnen een team. Je neemt verantwoordelijkheid voor je rol in de samenwerking en betrekt je team actief bij je persoonlijke ontwikkeling door open te staan voor feedback. Je herkent en benoemt je sterke punten en ontwikkelpunten. Op basis van deze inzichten ontwikkel je een realistisch beeld van je functioneren als professional ter ondersteuning van je oriëntatie op de arbeidsmarkt.

Hoe sta ik ervoor?

Verwacht resultaat: * In Ontwikkeling

Ik geloof dat ik goed op weg ben met dit doel, of ik op het gewenste eindniveau ben dat weet ik niet maar heb deze periode mijns inziens goede progressie laten zien.

Wat heb ik gedaan en geleerd?

Bewijs	Toelichting
	Bryan geeft hier aan dat ik meer open sta voor feedback vergeleken met de eerste weken van dit blok. Dit is mede door het feedback vragen en zoveel mogelijk communiceren. Over mijn communiceren is ook bart tevreden aangezien ik dit duidelijk doe en snel reageer. En voor de rest voer ik mijn rol als Delegated Product Owner goed uit.
	Op basis van ontvangen feedback heb ik mijn userstories concreter gemaakt door duidelijke acceptatiecriteria toe te voegen en de prioritering scherper aan te geven met behulp van de MoSCoW-methode. Ook heb ik de leesbaarheid en onderhoudbaarheid van mijn code verbeterd door beter te letten op naming conventions, het vermijden van duplicatie, en het toevoegen van relevante comments. Daarnaast ben ik actiever gaan bijdragen aan teamprocessen door gebruik te maken van branches en merge requests, wat ook samenwerking en code review bevordert.
Ik wil mijn communicatievaardigheden verbeteren door wekelijks opdrachten/ documentatie (gerelateerd aan het project) te maken, feedback te vragen en maandelijks mijn voortgang met mijn studentmentor te bespreken. Met mijn rol als product owner en online tools werk ik gericht aan mijn ontwikkeling. Na vier maanden wil ik overtuigender presenteren met duidelijkere en gestructureerde communicatie. Bekijk mijn SMART geformuleerde leerdoel	Ik heb dit leerdoel gekozen aangezien ik in het begin van dit semester moeite had met het ontwerpen en documenteren van het werk wat ik aan het doen was. De feedback die ik tot nu toe heb gehad was dat ik op conceptueel gebied enorm gegroeid ben. Ik ben al goed op weg om overtuigender en duidelijker te presenteren en communiceren alleen moet ik soms mijn presentatie nog ietsje beter voorbereiden.

Leeruitkomst 5: Doelgericht Interacteren

Je communiceert zowel schriftelijk als mondeling op professionele wijze met belanghebbenden, en stemt behoeften en verwachtingen op elkaar af. Je presenteert verkregen resultaten en je aanbevelingen op professionele wijze volgens de daarvoor geldende kwaliteitsnormen. Je werkt bewust samen met je team, volgens de HvA HBO-ICT Agile/Scrum-methodiek en de daarbij behorende waarden, waarbij je verantwoordelijkheid neemt voor jouw deel in de samenwerking.

Hoe sta ik ervoor?

Verwacht resultaat: * In Ontwikkeling

Ik hebt in deze periode mijn best gedaan en ik voel dat ik vorderingen maakt, wat ik als een succes zie.

Ik heb momenten gehad waarin ik het gevoel had dat het werk veel was, of misschien zelfs een beetje te veel leek. Toch heb je jezelf steeds weer weten te motiveren om door te zetten en dat zegt veel over mijn veerkracht en discipline. De balans tussen hard werken en het vinden van motivatie is soms een uitdaging, maar door zelfreflectie heb ik toch al veel bereikt.

Al met al ben ik trots op de progressie die ik hebt geboekt, ook al is het einddoel nog niet helemaal in zicht. Het feit dat ik mezelf blijft motiveren en niet opgeeft, laat zien dat ik op de goede weg bent. Ik heb het vermogen om door te zetten, en dat is misschien wel het allerbelangrijkste om uiteindelijk mijn gewenste eindniveau te bereiken.

Wat heb ik gedaan en geleerd?

Bewijs	Toelichting
	Bart geeft aan dat ik op een duidelijke manier communiceer en altijd snel reageer als er berichten verstuurd worden. Maar dat ik iets meer mijn teamgenoten op de hoogte mag houden waar ik mee bezig ben. Verder gaat de samenwerking goed vindt hij, en dat ik mijn rol als Delegated Product Owner goed vervul. Maar alleen soms te streng ben op de code. Bryan geeft aan dat ik goed communiceer. Dat ik goed bereikbaar ben zowel fysiek als op teams. En over mijn samenwerking is hij ook tevreden en noemt het professioneel. Ik help veel met problemen en code. Alleen moet ik wat duidelijker zijn met het maken van afspraken om zeker te weten dat iedereen het er mee eens is.
	Op basis van de ontvangen feedback heb ik ervoor gezorgd dat de userstories en de bijbehorende issues beter gedetailleerd en meer concreet zijn. Ik heb extra aandacht besteed aan het duidelijk definiëren van de acceptatiecriteria per userstory en ervoor gezorgd dat de issues goed omschreven waren, zodat het voor het ontwikkelteam duidelijk is wat er verwacht wordt. Daarnaast heb ik per feature beschreven hoe het issue precies uitgeschreven zou moeten worden, inclusief verwachte uitkomsten en eventuele afhankelijkheden. Verbeteringen na feedback: · Duidelijkere userstories: Ik heb de userstories herzien en voorzien van extra details en concrete acceptatiecriteria, zodat er geen ruimte meer is voor onduidelijkheid over wat er moet worden opgeleverd. · Betere beschrijving van issues: Iedere feature is nu duidelijker beschreven als een issue, met duidelijke stappen, verwachte resultaten en afgebakende scope.
	In de retrospective werd over het algemeen een positief resultaat behaald. Het proces van het verdelen van de issues en het daadwerkelijk maken van de features ging soepel. Ook het design van de game en de communicatie tussen de teamleden en de product owner verliepen goed, wat de samenwerking aanzienlijk verbeterde. Toch kwamen er enkele verbeterpunten naar voren: 1. Te snel beginnen met programmeren: Er was een tendens om sneller met de ontwikkeling te starten zonder voldoende aandacht voor het design en de planning. Dit leidde tot vertragingen en onduidelijkheden later in het proces. 2. Betere afspraken maken: Er ontbrak soms duidelijkheid over de verwachtingen en de rolverdeling, wat zorgde voor verwarring in het team en tussen het team en de product owner. Op basis van deze feedback heb ik de volgende actiepunten opgesteld: · Design eerst: Voordat we met programmeren beginnen, gaan we eerst volledig de designfase afronden. Dit zorgt ervoor dat we een duidelijk beeld hebben van hoe de uiteindelijke feature eruit moet komen te zien en voorkomt onduidelijkheden of herontwerpen tijdens de implementatie. · Duidelijkere afspraken: We gaan explicietere afspraken maken over verantwoordelijkheden, planning en communicatie. Dit zorgt ervoor dat iedereen weet wat er van hem of haar verwacht wordt en voorkomt misverstanden. · Minder lang vastzitten met problemen: Als er een probleem optreedt, gaan we sneller om hulp vragen of de situatie herzien. Hierdoor blijven we niet onnodig vastzitten, maar kunnen we snel door naar de oplossing.
	Ik heb in mijn communicatie met teamleden vaak handige tips gedeeld, zoals het belang van het gebruik van de juiste NameSpaces, wat de leesbaarheid en het onderhoud van de code ten goede komt. Ook heb ik regelmatig herinneringen gegeven aan mijn teamgenoten om hun GitLab-branches correct te benoemen, zodat we overzicht hielden over de voortgang van de verschillende onderdelen van het project. Als ik tijdens het project nuttige bronnen tegenkwam, deelde ik die met het team en gaf ik suggesties over hoe deze mogelijk verwerkt konden worden in het project. Dit stimuleerde een cultuur van kennisdeling en zorgde ervoor dat we van elkaar konden leren.