Sprint 1

Deze week zijn wij als team begonnen met de opzet van de app. Zelf ben ik, samen met Thijs, wat bezig geweest met het opzetten van de GitHub repository. Om alles consistent te houden, heb ik templates voor issues en pull requests gemaakt. Daarnaast heb ik CI geïmplementeerd met behulp van GitHub Actions. Dit alles zorgt ervoor dat wij als team consistent blijven en het beheren van de code wordt een stuk makkelijker/duidelijker.

Daarnaast heb ik mij even verdiept in Svelte(Kit), omdat dit voor mij compleet nieuw was. Hier heb ik niet te veel tijd aan besteed. Ik heb geprobeerd om zo snel mogelijk aan de slag te gaan. Het is en blijft namelijk gewoon een JavaScript framework, dus de basis is altijd wel hetzelfde.

Het eerste gesprek met onze opdrachtgever vond maandag plaats. Hier hebben wij kennis gemaakt met onze opdrachtgevers. Het zijn vier ALO-studenten. Het was voor ons mogelijk om wat vragen te stellen en aan het einde van de meeting was het voor ons grotendeels duidelijk.

Als team hebben wij user stories gemaakt op basis van het eerste gesprek (en de debriefing). Wij hebben ervoor gekozen om de eerste sprint ieder een story op te pakken en deze op te delen in kleinere taken.

De debriefing hebben wij na afloop van het gesprek gemaild naar de opdrachtgever en deze ging akkord.

Wij hebben ervoor gekozen om alles in GitHub te doen. Ik heb nog overwogen om het in JIRA te doen. Zelf vind ik dit wel fijn werken, omdat je in elke branch en commit het JIRA ticket nummer kunt gebruiken, maar wij kozen nu voor een Gitflow Workflow van Atlassian. Door dit te doen, maken wij geen gebruik van branches als JUNG12-add-filter-modal maar van branches zoals feature/add-filter-modal. Uiteindelijk is er geen goed of fout en kozen wij voor deze manier. Bij documentatie gebruiken we weer docs/ en bij workflow (GitHub) dingen gebruiken wij workflow/. Uiteindelijk denk ik dat wij ook maar dingen toevoegde, maar het werkte voor ons goed.

Git Workflow (Atlassian)

Vanuit onze opdrachtgever waren er qua planning/tickets geen verwachtingen. Zij wilden gewoon een app hebben. Hoe wij dat deden, was aan ons. Dit was erg fijn, zodat wij konden doen wat ons handig leek.

Ikzelf had de story over de detailpagina. Elk spel heeft een pagina met de daarbij behorende informatie. Met behulp van bestaande components en een UI kit is er snel een UI ontwikkeld, zodat wij zo snel mogelijk aan de slag konden gaan. Het was ons idee om zo snel mogelijk iets te maken en in de eerste test te vragen of zij het een fijn design vonden. Zo niet, dan kon dit later worden aangepast. Links is het design, rechts is (een gedeelte van) de implementatie ervan. Over dit design gaat nog geïtereerd worden.

Het GamePage component ziet er als volgt uit:

Op het moment dat er op een materiaal geklikt wordt, ziet het er als volgt uit:

Het GamePage.svelte component ziet er als volgt uit:

	<header>
		<h2>{game.category} | {game.title}</h2>
		<small>{game.audience} | {game.difficulty}</small>
	</header>

	<p>{game.description}</p>

	{#if isModalOpen}
		<MaterialModal material={clickedMaterial} on:close={toggleModal} />
	{/if}

	<h3>Materialen</h3>
	<ul class="material-list">
		{#each game.materials as material}
			<li>
				<ButtonLight on:click={toggleModal(material)}>{material.title}</ButtonLight>
			</li>
		{/each}
	</ul>

Aan de toggleModal functie wordt het geselecteerde materiaal meegegeven als parameter, waarna het wordt getoond in de modal.

	function toggleModal(material) {
		isModalOpen = !isModalOpen;
		clickedMaterial = material;
	}

De planning voor de volgende sprint is om dinsdagmiddag om 13:30 te testen. Maandag is het Tweede Pinksterdag en de opdrachtgever kan dinsdag pas vanaf 13:00. De volgende testen vinden maandagochtend om 10:00 plaats. Vrijdag komt voor hen niet uit.

Dinsdagochtend willen wij de meeting/test voorbereiden door alle vragen te bundelen. Er is heel de week een Google Docs beschikbaar waar je vragen in kunt zetten. Als je tijdens het ontwikkelen ergens meer over wilt weten, kun je dat in dit document zetten. Voor de test maken we hier een geheel van, zodat wij de juiste vragen kunnen stellen en de juiste dingen kunnen testen.

Na de test gaan wij weer samen (ons team) zitten om de user stories voor de volgende sprint te bespreken. Wij zijn er ons heel erg van bewust dat wij zo veel mogelijk willen testen tijdens de meetings en daarom kunnen er dingen gefaked worden. Daarnaast willen wij elke sprint een combinatie van UI/UX en (backend) logica toevoegen. Op het moment dat je de ene sprint veel UI/UX dingen oplevert en de andere sprint alleen maar backend dingen doet, dan valt dit erg tegen voor de opdrachtgever. Daarom moet je hier een balans in vinden en dat doen wij ook.

Alle user stories (als Issues) in GitHub

Volgende sprint wil ik specifieke features gaan schetsen om te kijken of ik de UX kan verbeteren. Deze sprint heb ik nog geen schetsen gemaakt, omdat het zaak was om zo snel mogelijk iets neer te zetten en bekend te raken met Svelte.

Code Review

Deze sprint hebben wij geen code review ontvangen.