Eindevaluatie Leerjaar 1

Naam: Menno

Datum voortgangsevaluatie: Tussen 16-6 en 20-6-25

In deze voortgangsevaluatie behandel ik de leeruitkomsten uit semester 2.
Mochten de plaatjes te klein zijn, kun je erop drukken op ze groter in het scherm te zien.

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, vergeleken met de vorige voortgangsevaluatie, veel progressie heb geboekt in mijn programmeervaardigheden. Dit blijkt uit mijn verbeterde codekwaliteit en mijn vermogen om zelfstandig problemen op te lossen. Om tot passende oplossingen te komen voor technische en functionele vraagstukken maar ik regelmatig gebruik van de PDCA cyclus en voer ik zelfstandig onderzoek uit en stel zo nodig bij. Het enige wat ik niet heb kunnen vinden, en daar dus geen gebruik van heb kunnen maken zijn, betrouwbare bronnen om mijn keuzes te onderbouwen. Deze zijn niet te vinden dus door veel testen en eigen initiatief is het uiteindelijk gelukt.

Als product owner was het ook mijn taak om te zorgen dat de oplossingen aansloten bij de behoeften van mijn team. Samenwerking is een belangrijk onderdeel van het ontwikkelproces/ PDCA cyclus. Ik werk actief in een team, houd technische documentatie bij en beheer het ontwikkelproces van het gehele team. Ik zorg ervoor dat de samenwerkingsafspraken worden nagekomen en eventueel worden bijgestuurd. Binnen het team hadden wij regelmatig overleg.

Daarnaast werd ik ook door “andere” klasgenoten/ teams benaderd als zij een technische en functionele probleem hadden. Samen keken wij hier dan naar en heb ik geholpen met een oplossing of ze doorverwezen naar bijvoorbeeld een docent. Doordat ik door medestudenten ben benaderd, buiten mijn team om, en ze heb kunnen ondersteunen/ helpen bij de vraagstukken en/of probleem voel ik mijn gesterkt en kan ik dus volmondig zeggen ik zit op niveau.

Wat heb ik gedaan en geleerd?

Bewijs

Toelichting

Multiplayer Deeldocument Menu Deeldocument

Tijdens de ontwikkeling van de game kreeg ik als eerste feedback op het onderdeel Main Menu, waar ik tot dan toe veel tijd aan had besteed. De visuele kant werd positief beoordeeld; het menu zag er goed uit en had al een mid-fidelity (med-fi) uitstraling. Echter, de inhoudelijke feedback liet zien dat er op andere vlakken nog we aandacht/ verbetering nodig was. Deze reflectie was voor mij aanleiding om mijn werkwijze te evalueren en opnieuw te plannen volgens de PDCA-cyclus: met gevolg dat het onderdeel Main Menu even op pauze te gaan zetten en mijn focus te gaan leggen bij het Multiplayer systeem. Dit systeem was complexer en belangrijker voor de game.

Plan
Op basis van het gesprek heb ik besloten mijn focus te verleggen. Hoewel het Main Menu visueel grotendeels voldeed, bood het nog weinig toegevoegde waarde aan de kernfunctionaliteit van de game. Daarom heb ik besloten om het werk aan dit onderdeel tijdelijk on hold te zetten en mijn aandacht te richten op het ontwerpen en realiseren van het Multiplayer-systeem – een essentieel en technisch veel complexer onderdeel van de game.

Mijn eerste stap in deze nieuwe focus was het concreet uitwerken van het concept. Ik ben gestart met het beschrijven van de gewenste functionaliteiten, gebruikersscenario’s, benodigde netwerkstructuren en interacties tussen spelers. Hierbij maakte ik gebruik van zowel user stories als technische use cases om het systeem volledig in kaart te brengen.

Do
Na de ontwerp- en planningsfase ben ik begonnen met de implementatie. Ik werkte iteratief: eerst ontwikkelde ik een basisversie van het systeem waarin spelers met elkaar konden verbinden. Vervolgens breidde ik dit uit met aanvullende functionaliteiten zoals teamverdeling, een zet kunnen doen en het wisselen van een zet. Tijdens de ontwikkeling hield ik rekening met codekwaliteit, herbruikbaarheid en schaalbaarheid, conform de geldende ontwikkelstandaarden. Ik documenteerde mijn voortgang zorgvuldig en deelde mijn werk regelmatig in het team via GitLab, zodat anderen feedback konden geven en op de hoogte bleven.

Check
Na het realiseren van een eerste werkende versie van het systeem heb ik het getest en laten beoordelen door teamleden. De feedback was positief: het systeem functioneerde stabiel, en de code was overzichtelijk en goed gedocumenteerd. Wel kwamen er enkele aandachtspunten naar voren op het gebied van performance en foutafhandeling bij een trage verbinding. Op basis hiervan heb ik het systeem verder geoptimaliseerd, onder andere door betere logging toe te voegen.

Act
De lessen die ik uit dit proces heb getrokken zijn breed toepasbaar in mijn verdere ontwikkeling als softwareontwikkelaar. Zo heb ik geleerd hoe belangrijk het is om prioriteiten te stellen op basis van toegevoegde waarde en complexiteit, in plaats van visuele of oppervlakkige resultaten. Daarnaast heb ik ervaren hoe waardevol het is om vanaf het begin met een duidelijk ontwerp te werken en regelmatig te evalueren of het werk voldoet aan de gestelde eisen. Deze aanpak neem ik mee in toekomstige projecten, waarbij ik structureel gebruik wil maken van de PDCA-cyclus om mijn werkwijze te verbeteren.

Zie foto:

Hier is te zien dat ik het idee uitleg om een idee te krijgen van wat ik zou willen maken en welke functionaliteiten het dan nodig zou hebben. Dit zorgde ervoor dat als er twijfels waren of iets wel nodig was in de feature je altijd kon terugvallen op de Lo-Fi.

Op de afbeelding is een vroege fase van het ontwikkelproces te zien, waarin een schets is gemaakt van een functioneel onderdeel van de applicatie. Deze schets vormt de visuele representatie van de eerste ideeën en functionele indeling van het systeem dat ik wil realiseren. Hierbij is aandacht besteed aan de gebruikersinterface, de onderlinge relaties tussen componenten en de verwachte interactie van de gebruiker met het systeem.

De schets dient als uitgangspunt voor het verdere ontwerpproces en is bedoeld om zowel voor mezelf als voor mijn teamleden een helder beeld te scheppen van wat er gebouwd gaat worden. In deze fase draait het vooral om het vertalen van functionele eisen en gebruikersbehoeften naar een concreet werkend ontwerp Zie voorbeelden hieronder:

.
Na het afronden van het ontwerpproces zet ik de volgende stap in de ontwikkeling van het systeem: het vertalen van de gemaakte ontwerpen naar concrete code. Deze fase vraagt om een nauwkeurige en gestructureerde aanpak, waarbij ik de eerder opgestelde specificaties, logica en interactiepatronen omzet in goed onderhoudbare en functionele code.

Een van de functies die ik heb geïmplementeerd is het automatisch en willekeurig toewijzen van teams aan spelers binnen de multiplayeromgeving. Dit mechanisme zorgt ervoor dat spelers bij het opstarten van een sessie automatisch worden ingedeeld in een team, waarbij eerlijkheid en variatie tussen de teams gewaarborgd blijven.

Onderstaande codefragment laat zien hoe ik dit proces heb gerealiseerd. In deze implementatie worden spelers willekeurig gekoppeld aan een team, waarna deze informatie wordt opgeslagen in de relationele database. Vervolgens wordt de relevante teamdata via het netwerk verzonden naar beide spelers, zodat zij direct over de juiste informatie beschikken.

Deze aanpak sluit aan bij de eisen rondom gebruikerservaring, dataconsistentie en netwerkbetrouwbaarheid, en is ontwikkeld met oog voor schaalbaarheid en uitbreidbaarheid van het systeem. Bovendien is de code opgebouwd volgens geldende conventies en goed gestructureerd, zodat deze eenvoudig is te onderhouden en te testen binnen het team.

Voor het beheren van mijn codebase en het gestructureerd samenwerken met mijn teamleden maak ik gebruik van Git in combinatie met GitHub. Binnen dit project heb ik mijn werkproces rondom versiebeheer op een professionele manier ingericht, met duidelijke stappen voor het ontwikkelen, testen, reviewen en integreren van nieuwe functionaliteit.

Ontwikkelproces en commits

Tijdens de ontwikkeling van een nieuwe feature begin ik met het lokaal programmeren in een aparte feature branch. Zodra ik een deels werkend en stabiel onderdeel van de feature heb gerealiseerd, commit en push ik deze voortgang naar GitHub. Dit stelt mij in staat om:
· Mijn werk tussentijds veilig op te slaan;
· Altijd te kunnen terugvallen op eerdere versies;
· Mijn voortgang inzichtelijk te maken voor mijn teamleden.

Ik herhaal dit proces meerdere keren – bij elke significante verbetering of uitbreiding – totdat de volledige feature functioneel en getest is. Hierdoor ontstaat een overzichtelijke reeks commits, die samen het ontwikkeltraject van de feature documenteren. Deze commits zijn gestructureerd op datum en voorzien van duidelijke beschrijvingen, zodat zowel ikzelf als anderen kunnen volgen wat er per stap is aangepast.

Merge request en code review

Na afronding van de feature open ik een merge request richting de develop-branch. Dit is een belangrijk moment in het proces waarin ik bewust stilsta bij de kwaliteit van mijn code en de impact ervan op de rest van het project.

De merge request wordt in mijn werkwijze altijd voorgelegd aan ten minste twee teamleden. Zij beoordelen onder andere:
· De codekwaliteit en structuur;
· De functionaliteit en werking;
· Mogelijke bugs of onvolkomenheden;
· Of de feature voldoet aan de gestelde requirements.

De ontvangen feedback verwerk ik in een nieuwe commit, waarbij ik eventuele aanpassingen of verbeteringen doorvoer. Dit proces draagt bij aan de kwaliteitsborging en voorkomt dat ongeteste of foutgevoelige code in de hoofdversie van het project terechtkomt.

Goedkeuring en samenvoegen

Wanneer ik van ten minste twee teamleden een approval (goedkeuring) heb ontvangen, wordt de merge request samengevoegd met de develop-branch. Dit betekent dat de nieuwe feature officieel is opgenomen in de hoofdontwikkelversie van het project en beschikbaar is voor integratie met andere onderdelen.

Het bijgevoegde bewijs toont een overzicht van de gemaakte commits, gesorteerd van nieuw naar oud, en geeft inzicht in mijn gestructureerde werkwijze en voortgang. Hieronder zijn ook enkele concrete voorbeelden van mijn commits opgenomen, inclusief korte toelichting per commit.

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: * Op Niveau

Ik ben van mening dat vergeleken met de vorige voortgangsevaluatie ik veel progressie heb gemaakt met mijn programmeer skills en denk daarom dus ook dat ik op het gewenste niveau zit. Dit omdat het;
· Gebaseerd is op gebruikersbehoeften;
· Consistent en intuïtief is vormgegeven;
· Feedback geeft op gebruikersacties;
· Toegankelijk is voor verschillende doelgroepen;
· Continu is getest en verbeterd;
· Aansluit op de functionele werking van het systeem.

Een belangrijk onderdeel van een (web)applicatie is vormgeven van de gebruikersinteractie (ook wel user interaction of UI/UX genoemd). In mijn project heb ik hier bewust en doordacht aandacht aan besteed. De gebruikersinteractie die ik heb ontwikkeld is naar mijn mening op niveau, omdat deze voldoet aan meerdere belangrijke ontwerpprincipes die bijdragen aan een effectieve, toegankelijke en gebruiksvriendelijke ervaring.

Gebruikersgericht ontwerp

Mijn ontwerp is tot stand gekomen op basis van de behoeften en het gedrag van de beoogde gebruikers. Door het analyseren van gebruikersscenario’s, het opstellen van user stories en het in kaart brengen van de gewenste functionaliteit heb ik gezorgd dat de interactie aansluit bij de verwachtingen van de eindgebruiker. De gebruiker staat dus centraal in het ontwerp, wat kenmerkend is voor een professioneel UI/UX-proces.

Consistente en intuïtieve navigatie

De gebruikersinterface is logisch opgebouwd, met consistente plaatsing van knoppen, iconen en navigatie-elementen. De gebruiker hoeft niet na te denken over waar bepaalde functies zich bevinden – de interactie voelt intuïtief aan. Dit bevordert de efficiëntie van het gebruik en voorkomt frustratie.

Responsiviteit en directe feedback

Een belangrijk aspect van goede gebruikersinteractie is dat het systeem reageert op de acties van de gebruiker. In mijn applicatie wordt visuele en functionele feedback gegeven bij bijvoorbeeld klikken of het invoeren van gegevens. Dit versterkt het gevoel van controle en duidelijkheid.

Toegankelijkheid en toegankelijk design

Ik heb bij het ontwerpen rekening gehouden met toegankelijkheid, zoals voldoende contrasten, leesbare lettertypes en duidelijke visuele hiërarchie. Daarnaast is de applicatie goed te bedienen met zowel muis als toetsenbord, en zijn interactieve elementen groot genoeg voor de gebruikers.

Testen en bijstellen op basis van feedback

De gebruikersinteractie is niet statisch gebleven. Gedurende het ontwikkelproces heb ik gebruikerstests en peer reviews ingezet om verbeterpunten te identificeren. Op basis van deze feedback zijn iteratief aanpassingen gedaan aan bijvoorbeeld knoppen en schermindeling. Dit toont aan dat het ontwerp evidence-based is verbeterd en afgestemd op daadwerkelijke gebruikerservaring.

Samenhang met functionele werking

Tot slot sluit de gebruikersinteractie goed aan op de technische logica van de applicatie. De interface is niet slechts een visueel laagje, maar vormt een functionele brug tussen de gebruiker en het systeem. Elk interactiepunt heeft een duidelijke functie, die correct wordt verwerkt in de onderliggende programmatuur en database.

Wat heb ik gedaan en geleerd?

Bewijs

Toelichting

GDD Link
TMC 1 Link
Feedback TMC 1 en GDD:

TMC 2 Link
Feedback TMC 2:

<br TMC 3 Link
Feedback Expert Review:

De feedback op zowel de GDD als TMC 1 is zorgvuldig geanalyseerd en direct toegepast in de opvolgende versies. Door op basis van concrete punten structurele verbeteringen door te voeren en deze zichtbaar te maken in de documentatie, tonen wij aan dat wij als team op een professionele manier leren, verbeteren en documenteren. De ontvangen vervolgfeedback bevestigt dat deze aanpak effectief is en bijdraagt aan de kwaliteit van ons project.

Tijdens het projecttraject heb ik actief gebruikgemaakt van de feedback die we hebben ontvangen op zowel de Game Design Document (GDD) als op onze eerste Think-Make-Check (TMC 1). Deze feedback is niet alleen geïnventariseerd, maar ook direct en doelgericht doorvertaald naar concrete verbeteringen in onze projectdocumentatie en werkwijze.

Verbeteringen in de GDD
De feedback op onze GDD richtte zich met name op de onduidelijke beschrijvingen van de game mechanics, het gebrek aan visuele ondersteuning bij bepaalde concepten en het ontbreken van duidelijke scope-afbakening. Op basis van deze opmerkingen hebben we het volgende ondernomen:

· De beschrijvingen van de gameplay-elementen zijn herschreven en uitgebreid, zodat deze nu concreet en toetsbaar zijn geformuleerd;
· We hebben visuals toegevoegd om abstracte concepten visueel te ondersteunen;
· Daarnaast is er een duidelijke afbakening van de scope toegevoegd, inclusief prioritering van de features op basis van MVP-criteria.

Deze aanpassingen zijn terug te vinden in de geüpdatete versie van de GDD. Een specifiek voorbeeld van een verbeterde sectie is de core concept/mechanic en de formal elements, die te vinden is op: GDD Link

Na het verwerken van deze verbeteringen hebben we opnieuw feedback ontvangen van onze begeleider. Die gaf aan dat de documentatie nu aanzienlijk helderder is en de visuele toevoegingen het begrip van de gameconcepten versterken. Dit bevestigde dat de aangebrachte verbeteringen effectief waren.

Verwerking van feedback uit TMC 1

De TMC 1-feedback gaf inzicht in de manier waarop wij als team samenwerkten en hoe wij onze voortgang structureerden. De belangrijkste punten van feedback betroffen:
· Meer diepgang toegevoegd bij de feedback loops en Flow Theory en het uitgebreider toegelicht;
· Spellingcontrole uitvoeren op de documenten;

Om deze punten aan te pakken, hebben wij voor TMC 2 structurele verbeteringen doorgevoerd:
· We hebben een duidelijke rolverdeling vastgelegd en toegevoegd aan onze teamdocumentatie;
· We zijn elkaar gaan controleren op spellingsfouten;
· Daarnaast hebben we met elkaar telkens gekeken naar de documentatie en van feedback voorzien .

Deze verbeteringen zijn zichtbaar in TMC 2 en te vinden via: TMC 2 Link

Ook op TMC 2 hebben we opnieuw feedback ontvangen, waarin bevestigd werd dat ons team een duidelijke groei heeft doorgemaakt in communicatie en samenwerking. Deze positieve feedback vormt een bevestiging dat het verwerken van eerdere aandachtspunten daadwerkelijk heeft bijgedragen aan de professionalisering van ons teamproces.

Resultaat van de uitgevoerde playtests

Uitvoering van de playtests

Om de gebruikservaring van de gameobjecten, mechanics en spelverloop te evalueren, heb ik meerdere playtests uitgevoerd. Deze tests zijn opgezet met het doel om inzicht te krijgen in de bruikbaarheid, spelbalans, technische stabiliteit en algehele spelbeleving. De testgroep bestond uit externe testers binnen de doelgroep, zodat de resultaten representatief en gevarieerd waren.

De tests zijn uitgevoerd aan de hand van een vooraf opgestelde testlijst met observatiepunten, waaronder:
· Begrijpelijkheid van gameplay-doelen;
· Balans tussen spelers in multiplayer-modus;
· Technische stabiliteit (zoals bugs of vastlopers);

Tijdens de tests observeerde ik het gedrag van de spelers en vroeg ik hen na afloop om gestructureerde feedback via een korte vragenlijst. Deze bestond uit zowel gesloten (op schaal van 1-5) als open vragen over hun ervaring.

Resultaten en bevindingen

Uit de playtests kwamen meerdere waardevolle inzichten naar voren. Enkele belangrijke conclusies waren:
· Positieve waardering over strategie: Spelers gaven aan dat de speelervaring erg goed in elkaar zat en de game er visueel ook mooi uitzag, wat positief bijdroeg aan de spelbeleving.
· Onzekerheid over doelen: Sommige testers begrepen niet direct wat het doel van een bepaalde gamefase was. De main menu en tutorial-sectie waren niet duidelijk genoeg.
· Positieve waardering voor de besturing: De besturing werd als intuïtief en responsief ervaren, wat positief bijdroeg aan de spelbeleving.
· Kleine bugs en prestatieproblemen: In enkele gevallen ontstonden verbindingsproblemen of werd data tussen spelers niet correct gesynchroniseerd. Of waren er visuele afwijkingen die niet klopte met wat er daadwerkelijk hoorde te gebeuren.

Wat is er gedaan met de resultaten?
·De feedback is zorgvuldig geanalyseerd en waar mogelijk direct omgezet in verbeteracties:
· Tutorial uitgebreid en verduidelijkt: Op basis van de verwarring over de speldoelen is de tutorial herschreven en verrijkt met duidelijke aanwijzingen, zodat er duidelijkheid is hoe de speler kan functioneren in het spel.
· Bugs opgelost: De technische fouten met betrekking tot datasynchronisatie zijn opgespoord en verholpen. Daarnaast is er een verbeterde foutafhandeling toegevoegd voor verbindingsproblemen.

Conclusie
De playtests hebben een essentiële bijdrage geleverd aan de verbetering van zowel de technische als de gebruikersgerichte aspecten van de game. Door gestructureerd feedback te verzamelen, te analyseren en toe te passen heb ik kunnen zorgen voor een meer gebalanceerde en gebruiksvriendelijke spelervaring. Dit iteratieve proces sluit goed aan bij een professionele ontwikkelaanpak waarbij continue kwaliteitsverbetering centraal staat.

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: * Op Niveau

Binnen het project heb ik aantoonbaar op hbo-niveau gefunctioneerd bij het ontwerpen, realiseren en beheren van de benodigde infrastructuur voor onze game. Deze infrastructuur vormt de technische ruggengraat die essentieel is voor het correct functioneren, distribueren en onderhouden van het eindproduct. Hiermee toon ik dan ook aan dat ik funtioneer op hbo-niveau.

Wat heb ik gedaan en geleerd?

Bewijs	Toelichting
DeelDocumentatie Multiplayer	Reflectie op expert meeting en resultaat – multiplayer infrastructuur Tijdens de laatste expert meeting heb ik waardevolle feedback ontvangen op mijn bijdrage aan het ontwerp en de realisatie van de multiplayer-infrastructuur binnen ons gameproject. Op de eerste foto is te zien dat ik van expertbegeleider Jur een positieve terugkoppeling heb gekregen, met de opmerking "lekker bezig". Deze opmerking vormde voor mij een bevestiging dat mijn inzet en aanpak in dit onderdeel van het project werden gewaardeerd. Het bijbehorende deeldocument dat ik heb opgeleverd toont het volledige traject dat ik heb doorlopen bij het ontwerpen en uitwerken van de multiplayerfunctionaliteit. Hierin zijn onder andere de volgende onderdelen opgenomen: · De analyse van gebruikersbehoeften met betrekking tot multiplayergebruik; · Het technische ontwerp van de infrastructuur (zoals client-serverarchitectuur); · De opbouw en werking van de serveromgeving; · Het testen van functionaliteit, betrouwbaarheid en veiligheid. Deze documentatie laat niet alleen mijn technische kennis zien, maar ook mijn vermogen om gestructureerd te werken volgens professionele standaarden, met duidelijke onderbouwing en testresultaten. Op basis van dit werk heb ik voor het onderdeel infrastructuur het cijfer 7,5 behaald. Dit cijfer weerspiegelt zowel de inhoudelijke kwaliteit van mijn technische realisatie als de volledigheid en professionaliteit van mijn documentatie. De combinatie van positieve feedback tijdens de expertmeeting en het behaalde resultaat toont aan dat ik dit onderdeel van het project op hbo-niveau heb uitgevoerd.
DeelDocumentatie Multiplayer Helpen Liam Multiplayer:	In het opgeleverde deeldocument wordt inzichtelijk hoe ik het volledige proces rondom de multiplayerfunctionaliteit van onze game heb ontworpen en gerealiseerd. Dit document vormt het bewijs van mijn systematische en technisch onderbouwde aanpak, waarin ik stap voor stap heb vastgelegd hoe de multiplayerarchitectuur tot stand is gekomen — van concept en ontwerp tot implementatie en testen. Ontwerp en realisatie van multiplayer Voor de multiplayercomponent heb ik een functionele en schaalbare infrastructuur opgezet. Dit omvat onder meer: · De keuze voor een geschikte client-serverarchitectuur; · De inrichting van sessiebeheer en spelerverbindingen; Deze onderdelen zijn nauwkeurig beschreven in het document, inclusief de afwegingen die ik heb gemaakt bij het kiezen van bepaalde technologieën en oplossingsrichtingen. Uitbreiding met chat- en emotesysteem Naast de kernfunctionaliteit van de multiplayer heb ik ook de technische basis gelegd voor het chat- en emotesysteem binnen de game. Hiervoor heb ik de benodigde server- en databasekoppelingen opgezet, inclusief logica voor het verzenden, ontvangen en correct verwerken van berichten tussen spelers. Hierbij is rekening gehouden met: · Realtime communicatie; · Efficiënte opslag en afhandeling op de backend. Deze uitbreidingen zorgen voor een rijkere gebruikerservaring en versterken de sociale interactie tussen spelers in de gameomgeving. Ondersteuning en samenwerking Naast mijn individuele technische bijdragen heb ik ook actief gefunctioneerd als ondersteunende kracht binnen het team. Wanneer groepsgenoten of klasgenoten vastliepen bij het implementeren van multiplayer-gerelateerde onderdelen, heb ik hen geholpen door mee te denken in oplossingen, code na te kijken of technische toelichting te geven op het netwerkverkeer en de interactie met de backend. Deze vorm van samenwerking draagt bij aan de algemene voortgang van het project en onderstreept mijn rol als betrokken en deskundig teamlid.
Itch.io game pagina	Geautomatiseerde build- en deploypipeline met Butler voor Itch In mijn project heb ik een CI/CD-proces ingericht waarmee een gamebuild automatisch wordt gecontroleerd, gebouwd en gedeployed naar het distributieplatform Itch.io, met behulp van Butler. Dit proces is onderdeel van de infrastructuur en releaseprocedure van de game, en laat zien dat ik in staat ben om geautomatiseerd softwarebeheer toe te passen op een manier die past binnen een professioneel ontwikkeltraject. Build- en deploytriggers via GitLab Tags Het proces start op het moment dat er een nieuwe tag wordt aangemaakt in GitLab. Deze tag is gekoppeld aan een releaseversie van de game. Wanneer de tag wordt gepusht naar de release-branch, fungeert dit als trigger voor het CI/CD-proces. Binnen de pipeline wordt vervolgens eerst gecontroleerd of de tag daadwerkelijk behoort tot de juiste branch. Deze controle is essentieel om te voorkomen dat builds ongewenst of onvolledig naar productie worden uitgerold. Fasegewijze opbouw van de pipeline De pipeline doorloopt drie hoofdfasen: 1. Validatie van de release-tag: Er wordt gecontroleerd of de tag correct is gekoppeld aan de release-branch. 2. Bouwen van de Windows executable: Met behulp van een vooraf geconfigureerde buildomgeving wordt een werkende .exe-bestand van de game gegenereerd. 3. Deploy naar Itch via Butler: De gegenereerde build wordt met Butler geüpload naar de juiste projectpagina op Itch. Configuratie van de variabelen en authenticatie Op de foto’s in het bewijsstuk zijn de gebruikte CI/CD-variabelen te zien die cruciaal zijn voor het deployproces: · ITCH_USER: Deze variabele bevat mijn Itch-gebruikersnaam en wordt gebruikt om te authenticeren tegen mijn account. · PROJECT_NAME: Deze variabele is gelijk aan de naam van het gameproject zoals dat op Itch is aangemaakt. Hiermee wordt bepaald waar de build geplaatst moet worden. · BUTLER_API_KEY: Deze sleutel heb ik verkregen via een installatie van Butler. Na installatie heb ik via Git Bash de command $ butler login uitgevoerd, waarmee ik op mijn account heb ingelogd. De credentials worden lokaal opgeslagen onder %userprofile%.config\itch\butler_creds. Hierin bevindt zich de API-sleutel die ik heb toegevoegd als variabele. · API_ACCESS_TOKEN: Voor communicatie met de GitLab API heb ik een persoonlijke access token aangemaakt op mijn profiel. Daarbij heb ik de rechten api en read_api geselecteerd. Deze token is opgeslagen als CI/CD-variabele om pipeline-acties te autoriseren. Naamgeving van builds en releases De naam van de build die wordt gedeployed naar Itch.io is automatisch gekoppeld aan de naam van de Git-tag. Hierdoor is iedere versie eenduidig traceerbaar binnen zowel GitLab als Itch.io, wat bijdraagt aan transparantie en versiebeheer. Conclusie Dit proces laat zien dat ik op hbo-niveau functioneer binnen het domein van softwaredeployment, automatisering en infrastructuurbeheer. Ik toon hiermee aan dat ik in staat ben om geavanceerde tools zoals Butler, GitLab CI/CD en API-authenticatie effectief in te zetten in een professionele ontwikkelomgeving. De opzet maakt het mogelijk om snel, veilig en reproduceerbaar een nieuwe gameversie te publiceren, inclusief de noodzakelijke controlemechanismen en veiligheidsmaatregelen.

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: * Op Niveau

Reflectie op samenwerking en professionele ontwikkeling

Gedurende het project heb ik laten zien dat ik op hbo-niveau functioneer binnen een teamcontext, doordat ik bewust reflecteer op mijn eigen gedrag en de impact daarvan op anderen. Ik ben mij er steeds beter van bewust geworden welke rol ik vervul binnen het team, hoe mijn gedrag bijdraagt aan het groepsproces, en waar ik nog kan groeien als professional.

Verantwoordelijkheid en teamgerichtheid

In de samenwerking met mijn groepsleden heb ik actief verantwoordelijkheid genomen voor mijn rol, met name op het gebied van de technische infrastructuur en multiplayerontwikkeling. Ik zorgde ervoor dat mijn taken tijdig werden opgepakt, maar ik nam ook initiatief om andere teamleden te ondersteunen wanneer zij vastliepen bij complexere technische vraagstukken. Hierdoor werd ik binnen het team vaak gezien als een betrouwbaar aanspreekpunt, wat de samenwerking en efficiëntie ten goede kwam.

Openstaan voor feedback

Een belangrijk onderdeel van mijn persoonlijke ontwikkeling is mijn vermogen om constructieve feedback te ontvangen én toe te passen. Tijdens teamvergaderingen en expertmeetings heb ik actief om feedback gevraagd en die input vervolgens serieus meegenomen in mijn werkwijze. Dit gold niet alleen voor technische verbeterpunten, maar ook voor mijn manier van communiceren en het afstemmen met anderen. Door open te staan voor deze feedback kon ik mijn werkwijze steeds beter laten aansluiten op de behoeften van het team.

Inzicht in sterke en ontwikkelpunten

Door regelmatig te reflecteren op mijn functioneren heb ik een realistisch beeld ontwikkeld van mijn kwaliteiten en ontwikkelpunten. Mijn sterke punten liggen duidelijk in het zelfstandig oplossen van technische vraagstukken, het efficiënt structureren van werk en het ondersteunen van anderen bij technische implementaties. Tegelijkertijd herken ik dat ik mij nog verder kan ontwikkelen in het proactief afstemmen van werkzaamheden binnen teamverband, bijvoorbeeld door frequenter voortgangsupdates te geven of eerder knelpunten te bespreken.

Professioneel zelfbeeld en arbeidsmarktoriëntatie

Op basis van deze ervaringen ontwikkel ik steeds scherper een professioneel zelfbeeld. Ik zie mijzelf als een oplossingsgerichte ontwikkelaar met een sterke focus op techniek en betrouwbaarheid. Tegelijkertijd weet ik dat samenwerking, communicatie en flexibiliteit cruciaal zijn binnen professionele omgevingen. Deze inzichten neem ik mee in mijn oriëntatie op de arbeidsmarkt; ik ben me ervan bewust in wat voor type rol ik goed tot mijn recht kom en op welke vlakken ik me nog verder wil ontwikkelen om als professional duurzaam inzetbaar te zijn.

Conclusie

Door mijn houding in het team, het actief verwerken van feedback, en mijn reflecties op persoonlijke groei, toon ik aan dat ik functioneer op hbo-niveau. Ik werk doelgericht aan mijn professionele ontwikkeling en weet mijn ervaringen effectief te vertalen naar concrete leerdoelen en toekomstgerichte keuzes.

Wat heb ik gedaan en geleerd?

Bewijs	Toelichting
Feedback eerder: Bart: Bryan: Elias: Feedback nu: Bart: Feedback Bryan: Feedback Elias:	Reflectie op ontvangen feedback en professionele ontwikkeling binnen het team Tijdens het project vervulde ik de rol van Delegated Product Owner, waarin ik verantwoordelijk was voor het bewaken van de voortgang, het aansturen van teamleden en het behouden van overzicht over de ontwikkelrichting. Hoewel deze rol mij goed ligt, kreeg ik in een eerdere feedbackronde van mijn groepsgenoten te horen dat ik mijn rol soms te streng of te kritisch invulde. Mijn feedback naar teamleden werd als direct ervaren, wat af en toe de open samenwerking belemmerde. Ook werd benoemd dat ik vaker moest aangeven wanneer ik zelf vastliep tijdens het programmeerproces, in plaats van problemen zelfstandig te blijven proberen oplossen. Daarnaast werd mij geadviseerd om actiever feedback te vragen op mijn eigen code, om zo mijn technische keuzes beter te kunnen onderbouwen en verbeteren. Verwerking van feedback en concrete verbeteracties Naar aanleiding van deze feedback heb ik mijn communicatie en samenwerking actief bijgestuurd. Ik ben bewust gaan werken aan het zachter formuleren van feedback, het meer delen van mijn eigen struggles binnen het ontwikkelproces, en het actiever opzoeken van meningen van teamleden over mijn werk. Tijdens de meest recente feedbackronde gaven mijn groepsgenoten aan dat zij duidelijke verbetering merkten in mijn communicatie. Tegelijkertijd werd er opgemerkt dat ik nog wat duidelijker kan zijn in het maken van afspraken, en dat ik attent moet blijven op het juiste moment voor informele opmerkingen of grapjes, om de professionele sfeer in stand te houden. Ik heb deze opmerkingen besproken in het team en we hebben samen concrete afspraken gemaakt over hoe we met elkaar communiceren, wanneer we feedback geven, en hoe we omgaan met informele momenten. Hierdoor is onze samenwerking nog effectiever en prettiger geworden. Herverdeling van taken en prioriteiten Daarnaast werd tijdens de feedback ook benoemd dat ik iets meer aandacht mocht besteden aan de documentatie, met name de TMC. Dit onderdeel was bij mij wat meer op de achtergrond geraakt doordat ik intensief bezig was met de implementatie van de multiplayerfunctionaliteit, een technisch complex en tijdrovend proces. De feedback hielp mij om mijn prioriteiten beter in balans te brengen. Sindsdien ben ik weer actiever gaan bijdragen aan de documentatie en heb ik mijn verantwoordelijkheid op dit vlak opnieuw opgepakt. Ik zorg er nu voor dat mijn technische keuzes, voortgang en overwegingen ook helder worden vastgelegd voor het team en voor beoordelaars. Conclusie De manier waarop ik omga met feedback laat zien dat ik bewust reflecteer op mijn gedrag en dit vertaal naar concrete verbeteracties. Ik betrek mijn team bij mijn leerproces, ben open over mijn ontwikkelpunten en neem verantwoordelijkheid voor mijn rol in de samenwerking. Daarmee ontwikkel ik een realistisch en professioneel zelfbeeld dat aansluit bij de eisen van de beroepspraktijk. Mijn groei in communicatie, taakverdeling en documentatie bevestigt dat ik functioneer op hbo-niveau, met een duidelijke focus op professionele ontwikkeling en teamgericht werken.
	Overzicht van uitgevoerde issues en Personal Learning Stories In deze periode heb ik gewerkt aan een aantal specifieke issues binnen het project, die nauw samenhingen met mijn persoonlijke ontwikkeldoelen. Tijdens het uitvoeren van deze taken heb ik steeds de bijbehorende Personal Learning Stories (PLS) opgepakt en toegepast. Hierbij heb ik zorgvuldig gekeken naar de context waarin deze leerdoelen van toepassing waren, conform de beschrijvingen en vereisten die vooraf waren opgesteld. Mijn aanpak bestond uit het systematisch integreren van deze learning stories in het ontwikkelproces, waardoor ik niet alleen de technische vraagstukken heb opgelost, maar ook mijn persoonlijke vaardigheden heb verdiept en verbreed. Door deze werkwijze heb ik de issues die aan mij waren toegewezen succesvol kunnen afronden, waarbij ik tevens mijn persoonlijke leerdoelen concreet heb weten te realiseren. Mijn bijdrage aan planning en voortgang Ik heb de benodigde stappen verdeeld in overzichtelijke deeltaken en deze gestructureerd ingepland, zodat ik mijn eigen voortgang kon monitoren. Hierbij heb ik regelmatig geëvalueerd of de uitvoering nog aansloot bij de vooraf geformuleerde leerdoelen en waar nodig mijn aanpak bijgesteld om het maximale uit de Personal Learning Stories te halen. Mijn voortgang op het gebied van de learning stories is daarmee positief. Ik heb alle toegewezen PLS afgerond, waardoor ik een duidelijk en inzichtelijk overzicht heb van mijn professionele ontwikkeling binnen dit project. Deze werkwijze helpt mij om niet alleen technisch te groeien, maar ook mijn reflectieve en organisatorische vaardigheden te versterken.
	Reflectie op werkveldoriëntatie en presentatie In het kader van mijn werkveldoriëntatie heb ik onderzoek gedaan naar relevante vacatures binnen de game-industrie en hier een presentatie over opgesteld en gegeven aan mijn team en begeleiders. Tijdens dit proces heb ik me verdiept in de eisen en wensen van werkgevers, met name gericht op de technische vaardigheden die gevraagd worden in de praktijk. Tijdens mijn onderzoek en het voorbereiden van de presentatie realiseerde ik mij dat ik een sterke voorkeur heb voor het werken met Unreal Engine. Dit komt mede doordat ik al enige ervaring heb met deze engine en mij hier prettig bij voel. Tegelijkertijd zag ik ook duidelijk dat de vacatures vaak vragen om kennis van meer gevorderde, zogenaamde intermediate onderwerpen binnen Unreal Engine. Dit betekent dat ik mijn huidige kennis moet uitbreiden en verdiepen om volledig aan te sluiten bij de verwachtingen van werkgevers in deze sector. Deze inzichten heb ik verwerkt in mijn presentatie, waarbij ik op een specifieke dia, de verbeteringen-dia, heb toegelicht welke onderwerpen ik van plan ben om verder te ontwikkelen. Denk hierbij aan bijvoorbeeld geavanceerde scripting, optimalisatietechnieken en het werken met complexe physics systemen binnen Unreal Engine. Door deze doelen concreet te benoemen, kan ik mijn persoonlijke ontwikkeltraject gericht vormgeven en mijn kansen op de arbeidsmarkt vergroten.
SMART Leerdoel volledig uitgewerkt	Reflectie op persoonlijke leerdoelen: Communicatievaardigheden Mijn persoonlijke leerdoel voor dit semester was gericht op het verbeteren van mijn schriftelijke en mondelinge communicatievaardigheden. Vanuit mijn rol als Product Owner binnen het projectteam besefte ik al snel hoe essentieel het is om helder en effectief te communiceren, zowel in documentatie en presentaties als in gesprekken met teamleden, stakeholders en begeleiders. Dit inzicht ontstond tijdens de eerste projectfasen, waarin ik merkte dat onduidelijkheden en miscommunicaties het ontwikkelproces konden vertragen. Daarom stelde ik mij ten doel mijn communicatiebewustzijn en vaardigheden op dit vlak aanzienlijk te versterken. Ontstaan en realisatie van de leerdoelen Ik heb deze leerdoelen concreet geformuleerd door terug te kijken op eerdere feedbackmomenten waarin werd aangegeven dat mijn teksten soms onvoldoende gestructureerd waren en mijn presentatievaardigheden nog onder druk stonden. Ook merkte ik in gesprekken dat ik nog niet altijd mijn standpunten overtuigend overbracht. Sindsdien heb ik consequent gewerkt aan het aanbrengen van meer structuur in mijn schriftelijke uitingen en heb ik actief geoefend met presenteren, onder andere door gebruik te maken van de PDCA-cyclus (Plan-Do-Check-Act). Dit stelde mij in staat om systematisch mijn aanpak te evalueren en te verbeteren. Voortgang en behaalde resultaten In de afgelopen vier maanden heb ik mij stap voor stap ontwikkeld. Waar ik in het begin nog worstelde met een heldere opbouw en het duidelijk formuleren van mijn gedachten, kan ik nu zowel schriftelijk als mondeling op een gestructureerde en overtuigende wijze communiceren. Mijn zelfvertrouwen tijdens presentaties is aanzienlijk toegenomen, waardoor ik mijn rol als Product Owner effectiever kan vervullen. Dit zie ik terug in mijn vermogen om helder te argumenteren, complexe informatie toegankelijk te maken en het team beter aan te sturen. Omgaan met obstakels Een van de uitdagingen in dit traject was de beperkte beschikbaarheid van mijn docent en het uitvallen van geplande evaluatiemomenten met mijn studentmentor. In plaats van te wachten, heb ik een proactieve houding aangenomen. Ik heb gebruikgemaakt van zelfreflectie, feedback van medestudenten actief opgezocht en veel geoefend om mijn communicatie verder te verbeteren. Deze zelfstandige aanpak heeft mijn leerproces versterkt en mijn professionele groei versneld. Feedback en bevestiging De feedback op mijn eindpresentatie en einddocumentatie was positief en bevestigde mijn vooruitgang. Er werd specifiek genoemd dat mijn communicatie nu helder, overtuigend en goed gestructureerd is, en dat ik deze met meer zelfvertrouwen breng. Dit sluit naadloos aan bij mijn oorspronkelijke leerdoelen en motiveert mij om deze vaardigheden verder te blijven ontwikkelen.

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: * Op Niveau

Professionele communicatie en samenwerking binnen het project

Ik functioneer op hbo-niveau omdat ik in staat ben om zowel schriftelijk als mondeling professioneel te communiceren met diverse belanghebbenden binnen het project. Dit betekent dat ik niet alleen duidelijk en gestructureerd mijn ideeën en voortgang rapporteer, maar ook actief luister naar de wensen en verwachtingen van teamleden, begeleiders en andere betrokkenen. Door deze open en transparante communicatie zorg ik ervoor dat de behoeften en verwachtingen van alle partijen goed op elkaar worden afgestemd, wat bijdraagt aan een efficiënte en succesvolle samenwerking.

Daarnaast presenteer ik de verkregen resultaten en mijn aanbevelingen op een professionele wijze. Dit gebeurt volgens de geldende kwaliteitsnormen binnen het vakgebied, waarbij ik let op helderheid, onderbouwing met feiten, en een logische opbouw van mijn betoog. Of het nu gaat om een tussentijdse rapportage, een eindpresentatie of het delen van technische inzichten, ik zorg ervoor dat mijn communicatie aansluit bij het niveau dat binnen een hbo-omgeving verwacht wordt.

Op het gebied van samenwerking werk ik bewust en doelgericht samen binnen mijn team. We hanteren de HvA HBO-ICT Agile/Scrum-methodiek, waarbij de bijbehorende waarden zoals openheid, respect, verantwoordelijkheid en commitment centraal staan. Ik neem actief verantwoordelijkheid voor mijn eigen taken en lever mijn bijdrage binnen de afgesproken sprints en deadlines. Daarbij stel ik mijn teamgenoten op de hoogte van mijn voortgang en bespreek ik tijdig eventuele knelpunten of risico’s. Door deze professionele houding zorg ik ervoor dat de samenwerking soepel verloopt en het team gezamenlijk de projectdoelen behaalt.

Door deze combinatie van professionele communicatie, resultaatgerichte presentatievaardigheden en effectieve samenwerking binnen een Agile/Scrum-kader, functioneer ik op het niveau dat van een hbo-professional wordt verwacht en draag ik bij aan het succes van het project.

Wat heb ik gedaan en geleerd?

Bewijs	Toelichting
Feedback eerder: Bart: Bryan: Elias: Feedback nu: Bart: Feedback Bryan: Feedback Elias:	Reflectie op ontvangen feedback en persoonlijke ontwikkeling Tijdens het project heb ik waardevolle feedback ontvangen van mijn groepsgenoten die mij hielp mijn functioneren als Delegated Product Owner kritisch te evalueren en te verbeteren. In eerdere feedback werd aangegeven dat ik mijn rol soms iets te serieus nam, waarbij ik wat te kritisch was richting mijn teamgenoten. Dit kon de samenwerking en de teamdynamiek negatief beïnvloeden. Daarnaast werd mij geadviseerd om beter aan te geven wanneer ik vastliep tijdens het programmeerproces, zodat het team mij tijdig kon ondersteunen. Ook werd het belangrijk gevonden dat ik vaker en actiever feedback zou vragen op mijn code om de kwaliteit te verhogen en kennisdeling te stimuleren. In de meest recente feedback werd mijn communicatie als positief ervaren; ik was hierin duidelijk vooruitgegaan. Echter, er werd aangegeven dat ik nog kan werken aan het duidelijker maken van afspraken binnen het team. Daarnaast werd mij geadviseerd om meer rekening te houden met informele momenten, zoals het maken van grapjes, om zo de onderlinge sfeer te verbeteren en de samenwerking te versterken. Naar aanleiding van deze feedback heb ik het open gesprek met mijn team gezocht. Samen hebben we concrete afspraken gemaakt over hoe ik mijn communicatie en houding kan verbeteren. We hebben besproken hoe ik helderder kan zijn in het formuleren van afspraken en hoe ik meer kan bijdragen aan een positieve, ontspannen teamcultuur. Daarnaast kwam naar voren dat ik mijn aandacht voor de documentatie, zoals de TMC verslagen, iets meer moet versterken. Deze was enigszins naar de achtergrond verdwenen door mijn focus op de complexe implementatie van de multiplayer-functionaliteit. Naar aanleiding van deze feedback heb ik bewust tijd vrijgemaakt om mijn documentatiewerk te hervatten en te verbeteren, zodat zowel de technische als procesmatige aspecten van het project goed worden vastgelegd en gedeeld. Deze reflectie en de acties die ik heb ondernomen laten zien dat ik mijn professionele houding kritisch benader, opensta voor feedback en gericht werk aan mijn persoonlijke ontwikkeling en samenwerking binnen het team.
Daily Standup Formulier	Beheer en planning van issues als Delegated Product Owner Als Delegated Product Owner heb ik alle issues binnen ons project nauwkeurig van duidelijke titels en uitgebreide beschrijvingen voorzien. Dit zorgt ervoor dat ieder teamlid precies weet wat er verwacht wordt en welke acties nodig zijn om een issue op te lossen. Om het werk beter te kunnen prioriteren en de complexiteit in kaart te brengen, heb ik voor elk issue een zogenaamde weight (gewicht) toegekend. Hierbij staat een gewicht van 1 voor een klein, relatief eenvoudig issue, terwijl een gewicht van 3 wordt toegekend aan grote en complexe issues die meer tijd en aandacht vragen. Onze projectplanning is ingericht rond vaste deadlines die telkens aan het begin van de werkweek worden vastgesteld. Om ervoor te zorgen dat deze planning realistisch blijft en aansluit bij de voortgang, evalueren we elke week gezamenlijk de tijdsplanning. Indien nodig worden aanpassingen gemaakt om de haalbaarheid van de deadlines te waarborgen. Deze wekelijkse evaluatiemomenten gebruiken we ook om volgens de PDCA-cyclus (Plan-Do-Check-Act) te werken: we plannen, voeren uit, controleren de voortgang en sturen waar nodig bij. Tijdens deze sessies bespreken we de status van openstaande issues, stellen we nieuwe deadlines vast en wijzen we nieuwe of opgepakte issues toe aan teamleden. Dit gestructureerde overleg zorgt ervoor dat het team voortdurend inzicht heeft in de actuele voortgang en dat knelpunten tijdig worden opgepakt. De voortgang van ons werk en de mate waarin we op schema liggen, wordt nauwkeurig bijgehouden en gedeeld via het Daily Standup Formulier in Microsoft Teams. Dit overzicht biedt een transparante blik op de stand van zaken en helpt ons om gezamenlijk de juiste prioriteiten te stellen en efficiënt samen te werken. Door deze gestructureerde aanpak van issuebeheer en tijdsplanning functioneer ik op het niveau dat van een HBO-professional wordt verwacht, waarbij ik zorg voor overzicht, duidelijkheid en effectieve samenwerking binnen het team.
	Bijdrage aan communicatie en kennisdeling binnen het team Tijdens het project heb ik actief bijgedragen aan de communicatie binnen het team door regelmatig waardevolle tips en adviezen te delen met mijn teamleden. Zo heb ik bijvoorbeeld het belang benadrukt van het correct gebruiken van NameSpaces in de code. Het consequent toepassen van NameSpaces draagt aanzienlijk bij aan de leesbaarheid en het onderhoud van de software, doordat het code-overzichtelijker maakt en naamconflicten voorkomt. Door deze best practice onder de aandacht te brengen, heb ik bijgedragen aan het verhogen van de codekwaliteit binnen ons team. Daarnaast heb ik mijn teamgenoten meerdere keren herinnerd aan het belang van het juist benoemen van hun GitLab-branches. Dit is cruciaal om een helder overzicht te houden over de voortgang van de verschillende onderdelen van het project. Door gestructureerde en eenduidige branch-namen te hanteren, konden wij eenvoudig zien welke functionaliteiten in ontwikkeling waren en waar mogelijke knelpunten zaten. Dit heeft de samenwerking en het beheer van de codebase efficiënter gemaakt. Verder heb ik tijdens het project nuttige en relevante bronnen, zoals artikelen, tutorials en documentatie, met het team gedeeld. Daarbij gaf ik ook suggesties over hoe deze informatie toegepast kon worden binnen ons project. Dit stimuleerde een cultuur van kennisdeling en samenwerking, waardoor teamleden van elkaars expertise konden profiteren en we gezamenlijk konden groeien in onze vaardigheden en het eindresultaat konden verbeteren. Door mijn proactieve houding in communicatie en het delen van kennis heb ik bijgedragen aan een open en leerrijke teamsfeer, wat essentieel is voor het succesvol realiseren van complexe projecten binnen een professionele context.