thijs_home

Process en iteraties

Voorbereiding

We zijn begonnen met als team samen te komen en de processen te bespreken. Er is gekeken naar wat iedereens beschikbaarheid is, welke tools we gaan gebruiken etc.

Github We gebruiken github als plek voor de code en het bijhouden van de taken. Voor het bijhouden van de taken hebben gebruiken we Issues, deze zijn vervolgens gelabled als feature, bug, story of task. Er zijn ook andere lables gebruikt zoals blocked, om aan te geven dat een andere issue de isssue blokeert. Om dit in goede banen te leiden is er gebruik gemaatk van Issue Templates.

Sprints Aan het begin hebben we als team afgesproken om in sprints van een week te werken. Elke week bepalen we welke taken/features we gaan uitwerken. Door issues van github in milestones te zetten, kregen we overzicht waar we elke sprint aan moesten werken.

De combinatie van de uitgwerkte features van die week wordt vervolgends gepresenteerd aan de opdrachtgever op maandag. Tijdens deze meeting verzamelen we feedback en bepalen we de planning voor de komende sprint.

Code quality Er zijn afspraken gemaakt over de code quality en editor instellingen, deze zijn vervolgens gedocumenteerd en werden afgedwongen doormiddel van Github Actions en branch protection.

Gitflow Er is afgesproken om met een Gitflow te werken. Dit houdt in dat er een main branch waar na elke sprint een neiuwe versie van de app op staat en een development branch is waar de features op komen die af zijn en getest zijn. Elke nieuwe feature wordt gemaakt op een branch met als prefix feature/. Als een feature klaar is wordt een Pull Request gemaakt en gaan andere teamleden de code een review geven. Na aproval en status checks door Github Actions, wordt de feature gemerged in development.

Eventuele bugfixes zijn op dezelfde manier gedaan, maar dan met de prefix fix/ of hotfix/. Verbetering aan de documentatie zijn gedaan op branches met docs en workflow aanpassing (zoals github actions) via workflows/

Sprints

Sprint 1

De eerste week is gebruikt om het project op te zetten. Vanuit de briefing hebben we User Stories opgezet en nog vragen verzameld. Na een meeting met de opdrachtgever hebben we de User Stories kunnen verfijnen aan de hand van hun verhaal en antwoorden op de vragen.

We hebben per teamlid de User Stories gemaakt en vervolgens besproken en samengevoegd. Er is daarna nagedacht over de prioriteit van de user stories. We hebben besproken wat we aan het einde minimaal moeten hebben om een werkend prototype op te kunnen leveren. Hiervoor hebben we de MoSCoW methode gebruikt. Dit betekend dat als alle stories met een (M) gedaan kunnen worden, het minimale is gedaan om een werkende prototype op te leveren. De (S) zijn alle features die het voor een gebruiker nog prettiger maken de app te gebruiken. De (C) en (W) features zijn leuk om te hebben, maar niet noodzakelijk om de eindstreep (week 5) te halen.

Uiteindelijk hebben we een debriefing gemaakt voor de opdrachtgever om aan te geven wat wij van plan waren en of alles klopt met wat hun voor ogen hebben. Hierdoor weet de opdrachtgever wat ze kunnen verwachten.

Jochem en ik zijn bezig geweest met de opzet van Github en Github actions. Terwijl Roy en Sjoerd alvast zijn begonnen met de eerste user stories.

Voor mij stond de API op de planning en daar ben ik die week mee bezig geweest. Hierin heb ik het filteren op de api gemaakt op basis van een aantal spellen.

Reflectie

Deze eerste week was voor mij belangrijk om niet gelijk alles 'perfect' te willen hebben en gelijk de 'leiding' te willen nemen. Door eerst meer af te wachten en meer te vragen aan de teamleden wat hun ideeën waren, heb ik hier meer rust ervaren en heb ik iedereen onderdeel laten zijn van het team.

Mijn eigen werk ging goed, het lukt mij elke dag te werken aan mijn onderdelen, maar ook hulp te bieden aan de andere teamleden. Door met MoSCoW prioriteiten te stellen lukte het mij om niet gelijk aan de details en perfecte dingen te willen werken. Het idee is steeds geweest dat dit een prototype is en niet productie klaar moet zijn aan het einde van de sprint. Dit idee leefde ook binnen het team, maar het was ook niet zo dat we met een 6 genoeg zouden nemen. Hierdoor hebben we toch wat details kunnen uitwerken die net even wat zaken beter maken.

De eerste sprint was een goed begin van het project.

Sprint 2 - Geen internet in de jungle

Deze week stond er op de planning om zowel het inloggen als het offline opslaan op te pakken, gesplit over duos. Jochem en ik zouden meer inloggen oppakken en Roy en Sjoerd zouden offline opslaan doen.

Echter bleek het offline opslaan gecompliceerder dan gedacht omdat een framework anders werkt met offline opslaan. Bij de 2e of 3e dag in de sprint werd duidelijk dat Roy en Sjoerd hier wat moeite mee hadden, daarom ben ik erbij gesprongen om het offline opslaan te fixen. Mijn eigen taken voor inloggen zijn daarbij doorgeschoven naar een latere sprint. Dit is niet erg, want het inloggen is niet belangrijk voor het prototype. Offline opslaan is een grote core functionality van de app en heeft dus meer prioriteit.

Het was voor mij ook even lastig om te zien hoe het offline opslaan werkt binnen ene framework en uiteindelijk binnen Svelte. Dit werd eigenlijk niet better door de missende documentatie en community oplossingen. Uiteindelijk is het wel gelukt om dit voor elkaar te krijgen.

Reflectie

Het was voor mij lastig om te switchen, omdat ik mijn hoofd gezet had op het maken van de backend en inloggen. Deze week lukt het mij erg goed om taken en stories op de planning niet als 'in steen gebeiteld' te zien. Het doorschuiven van taken die een S,C of W zijn is makkelijker, omdat je van te vooren een duidelijk beeld hebt gemaakt van wat belangrijk is en wat niet. Dit soort taken, waarin we uitdenken: 'Wat moeten we minimaal opleveren' is iets wat ik zeker mee wil nemen.

Door vooraf al duidelijk te maken waar de prioriteiten liggen, is het makkelijker om te switchen naar een andere taak. Dit wil ik zeker meenemen voor een volgend project. Deze helderheid in wat belangrijker is geeft een soort rust.

Sprint 3 - Even opnieuw

Deze week is er een grote iteratie geweest op het design. Hier zijn we de hele week mee bezig geweest, ook om gelijk de code te refactoren en schoon te maken.

Er is tijdens het designen veel geitereerd op het uiterlijk van de app. Deze week is heel veel van dit redesign in de app gezet. Mijn taak zat vooral in het schoonmaken van de code, terwijl de rest bezig ging met het redesign.

Het viel mij op dat er veel tijd in de Figma ontwerpen is gestoken, waardoor uiteindelijk pas aan het einde van de week echt code werd gemaakt van het design. Dit vond ik jammer, we hebben veel beter vanuit de code kunnen redesignen dan vanuit Figma. De tijd zat hem hier vooral in het maken van meerdere opties in figma, waarvan het beter was geweest deze te maken en dan de variates te testen. Dit in plaats van steeds maar meerdere designs maken.

Reflectie

Deze week was een lastige test binnen het team. Na de grote iteratie slag van het design, heb ik heel veel bugs en code eruit gehaald en verbeterd. Deze 'refactor' zorgde bij een deel van het team voor een gevoel dat hun 'deel' er niet meer in zat. Dit is natuurlijk nooit de bedoeling geweest.

Het is voor mij wel een lastig dillema, aan de ene kant wil ik graag de code netjes hebben, aan de andere kant is het belangrijk dat we als team dit doen. Deze week heb ik mij daarom ook afgevraagd of ik niet beter het project alleen af kan sluiten, zodat de rest van het team er meer van kan leren. Uiteindelijk gaat het hierom dat ik beter leer samen werken. Alleen doen van de opdracht zou eigenlijk betekenen weglopen van het probleem.

De code aanpassen is het probleem niet, alle teamleden willen een net project qua code. Het probleem zit hem in het samen werken, hierin heb ik een stap moeten maken. Door meer gebruik te maken van de code reviews en de code te bespreken voordat het gemerged wordt.

Deze week ging voor mij dus niet zo heel goed en dit liep eigenlijk door naar de week daarna, hierdoor kan ik uit deze week en volgende week veel aandachtspunten halen voor mijzelf

Sprint 4 - Wie ben jij?

Tijdens deze week is het inloggen afgemaakt en hebben we de iteratie slag gedaan over het offline opslaan. Hierbij hebben we favorieten en offline opslaan samen gevoegd.

Deze week was een drukke week voor mij, waarbij ik ook fouten heb gemaakt in mijn planning, tijdsdruk en wat ik aan energie had. Hierbij heb ik uiteindelijk hulp in moeten roepen bij het team, zodat zij wat zaken over konden nemen. Vooral op de documentatie hebben zij punten overgenomen, zodat ik het complexere inloggen af kon maken.

Reflectie

Deze week ging ik de fout in met het niet/slecht plannen en toch graag weer alles perfect te willen doen. Hierdoor ging ik terugvallen in oude gewoontes zoals het uitstellen van taken.

Het heeft daarna heel erg geholpen om er eerlijk over te zijn. Bespreken met anderen en het hulp te vragen aan andere teamleden. Hierdoor heb ik uiteindelijk toch veel kunnen oppakken.

Sprint 5 (Oplevering) - Puntjes op de i

Mijn gymles is hierin uitgewerkt en verbeterd. We hebben onboarding toegevoegd op de UX. Het eindresultaat is een mooi prototype waarin we voor de klant een mooi resultaat hebben neergezet.

Reflecties

Reflecties op de vakken

Tijdens het project, hebben we zoveel mogelijk rekening gehouden met de vakken. Om zoveel mogelijk toe te passen wat we geleerd hebben. Helaas is niet alles gelukt.

Zo hebben we niet kunnen testen met de daadwerkelijke eindgebruikers. Hierdoor hebben we het leren testen en prototypen, geleerd in HCD, niet echt kunnen toepassen. De testen die we wel hebben kunnen doen, hebben zeker geholpen.

PWA heeft wel een grote impact gehad, omdat PWA het meest te maken had met deze opdracht. Het eindresultaat is ook een PWA. Offline opslaan en het installeren van de app komen dus hieruit voort.

In mindere mate hebben we ook rekening gehouden met BT. De juiste progressive enhancements toegepast, waar mogelijk, door goed de core functionaliteiten uit te zoeken.

Reflectie over mijzelf

Wat ging er goed:

• Elke dag aan de slag door standup, dit gaf een goed begin om te starten aan het werk. Er ontstond duidelijkheid en iedereen wist waar we mee bezig waren. Hierdoor kwam voor mij ook rust om te starten aan mijn eigen taken.
• Het toepassen van MoSCoW en duidelijk kaderen van de opdracht. Er zijn meerdere keren geweest waarin ik mijn te lang bezig zou zijn met een detail, maar waar ik mijzelf kon terugroepen om door te gaan met de hoofdzaken. Wat mij opviel is dat meeste details alsnog opgelost konden worden, omdat ik eerst de hoofdzaken afhad.

Wat ging er minder goed:

• Beter leren samenwerken mbt code van anderen. Het is niet erg om iemands code te willen verbeteren en te helpen, maar het is belangrijk hiervoor de juiste tools en communicatie te gebruiken. In 1 keer een refactor doen van code is niet de juiste manier en geeft anderen het gevoel zich gepasseerd te voelen. Het is beter om tijdens code reviews en merges hier duidelijk over te zijn.