Professional Skills & Manage and Control

Waar gaat hoofdstuk 2 in essentie over?

Over de niet-technische professionele vaardigheden die tijdens de stage zijn ontwikkeld: planning samenwerking en communicatie en hoe daarmee is omgegaan tijdens het project.

Welke werkwijze heb je gehanteerd voor je planning?

Een lichte vorm van Scrum met dagelijkse stand-ups (samen met medestagiairs en begeleider) en wekelijkse voortgangsgesprekken met de begeleider.

Waarom is er gekozen voor Scrum terwijl het developmentteam van Spaux dat zelf niet structureel gebruikt?

Omdat gemerkt werd dat er niet effectief gewerkt werd door afleidingen van buitenaf. Scrum-achtige stand-ups hielpen om elkaar scherp te houden en op koers te blijven.

Wat gebeurde er tijdens de wekelijkse voortgangsgesprekken met de begeleider?

Er werd getoond wat er gerealiseerd was welke designkeuzes gemaakt waren en welke problemen er speelden. De begeleider gaf vervolgens advies om de aanpak tussentijds bij te sturen in plaats van pas aan het eind problemen te ontdekken.

Noem een voorbeeld van een planning die niet volgens schema verliep en hoe daarmee is omgegaan?

Het debuggen van de feedback loop en het veilig laten werken van de complexe Python worker-architectuur kostten meer tijd dan ingeschat. Openstaand werk werd meegenomen naar de volgende week wat soms een drukke week opleverde maar de planning bleef over het geheel genomen op koers.

Wie was de belangrijkste stakeholder en waarover werd met deze persoon gesproken?

De bedrijfsbegeleider (Ruben van Gemeren) met wekelijks contact over voortgang en sparsessies op cruciale momenten over architectuurkeuzes (bewijs hiervan staat in de gespreksverslagen in hoofdstuk 4: Adviseren).

Hoe verliep codereview binnen het team?

Code werd tijdens de realisatiefase op meerdere momenten beoordeeld in GitHub zowel door de begeleider als door een ervaren developer uit het team wat bijdroeg aan kwaliteit en onderhoudbaarheid.

Leg de gehanteerde Git-branchstrategie uit?

De "main"-branch bevatte altijd een stabiele release. "Development" was de integratiebranch waarin nieuwe features samenkwamen voordat ze naar main gingen. Voor elke nieuwe functionaliteit werd een aparte feature branch gemaakt en bugs binnen een feature kregen een eigen bug branch die na de fix werd teruggemerged in de feature branch.

Wat was het doel van deze branchstrategie?

Het werk overzichtelijk houden en zorgen dat bugfixes traceerbaar bleven.

Welke vormen van informele samenwerking worden genoemd en waarom zijn die relevant voor dit hoofdstuk?

Deelname aan een voetbaltoernooi met KPN-partners de vrijdagmiddagborrel en samen lunch boodschappen doen met medestagiairs. Dit wordt genoemd omdat het bijdroeg aan het gevoel van verbondenheid met het team wat onderdeel is van professionele samenwerking.

Wat is de belangrijkste les die je trekt uit de reflectie in dit hoofdstuk?

Door gestructureerd te werken (wekelijkse check-ins duidelijke Git-strategie open communicatie) heb je geleerd je eigen voortgang kritisch te evalueren en tijdig bij te sturen. Daarnaast leerde je feedback te zien als kans tot verbetering in plaats van kritiek.

Hoe hangt deze reflectie samen met latere technische keuzes in de scriptie?

Het inzicht dat feedback een kans tot verbetering is komt terug in hoe de hybride validatiestrategie tot stand is gekomen zoals beschreven in hoofdstuk 4 (Adviseren).

Welke bewijsstukken horen bij dit hoofdstuk?

Een screenshot van de GitHub-branchstructuur (main development feature en bug branches) en een screenshot van de GitHub Projects-planning.