Werkdagen:

• Maandag, donderdag en vrijdag werken we aan ons groepsproject.
• Dinsdag en woensdag werken we aan onze individuele projecten.

Communicatie:

• We communiceren voornamelijk via Teams.
• Voor dringende zaken of snelle vragen kunnen we ook [alternatieve communicatiemethode, bijvoorbeeld een groepsapp] gebruiken.

Coderen:

• We volgen de vastgestelde codeconventies om de code consistent en leesbaar te houden.
• Een kopie van de codeconventies is te vinden in [link naar document of locatie].
• Git Workflow:
• Iedereen werkt in zijn/haar eigen branches.
• Voordat we code samenvoegen (mergen) in de hoofd-branch, vragen we om een code review van minimaal één teamlid.

Projectmanagement:

• Iedereen houdt zijn/haar taken en voortgang bij op het projectboard.
• We hebben stand-up meetings op maandag, donderdag en vrijdag om de voortgang te bespreken en eventuele blokkades aan te pakken.

Project Overname en Prioriterin:

• We hebben dit project overgenomen van de vorige ontwikkelaars en hebben direct de MoSCoW-methode toegepast om prioriteiten te stellen. Zo identificeerden we de essentiële (Must-haves), belangrijke (Should-haves), optionele (Could-haves) en niet-noodzakelijke (Won't-haves) onderdelen. Met Planning Poker hebben we vervolgens de benodigde inspanning voor elk onderdeel ingeschat.

Structurering binnen de Ontwikkelingscyclus:

• Om onze issues binnen de ontwikkelingscyclus (DLC) te structureren, hebben we ze gecategoriseerd op basis van hun fase in de DLC.

Projectfocus en Planning:

• Door de combinatie van de MoSCoW-methode, Planning Poker en de DLC-categorisering hebben we een duidelijke projectfocus gecreëerd, realistische planningen opgesteld en zijn we beter in staat om de projectinspanningen te beoordelen en te beheren.

Refactoring en Tijdlijn:

• We hebben de projecttaken kritisch bekeken en overbodige taken verwijderd. Daarnaast hebben we een gedetailleerde tijdlijn opgesteld waarin de taken per week zijn ingedeeld. Deze tijdlijn is te vinden in [link naar de tijdlijn].

Link naar Projectboard

Projectboard Structuur:

• We hebben kolommen toegevoegd aan ons projectboard om issues op een gestructureerde manier te kunnen sorteren en de voortgang te visualiseren:

• Todo: Nieuwe issues en taken die nog moeten worden opgepakt.

• Progress: Issues en taken waaraan momenteel wordt gewerkt.

• Ready for Test: Issues en taken die klaar zijn voor testen.

• Done: Afgeronde en geteste issues en taken.

Wij hebben als team afgesproken om voor elke issue de MoSCoW-methode te gebruiken en deze prioriteit duidelijk te labelen:

• Must-have: Essentiële issues die absoluut moeten worden opgelost voor een succesvol project.
• Should-have: Belangrijke issues die bij voorkeur worden opgelost, maar niet cruciaal zijn voor de basisfunctionaliteit.
• Could-have: Optionele issues die de gebruikerservaring kunnen verbeteren, maar kunnen worden uitgesteld als de tijd beperkt is.
• Won't-have: Issues die niet binnen de scope van het huidige project vallen en worden uitgesteld naar een later tijdstip of helemaal niet opgepakt.

We hebben als team afgesproken om individueel elke taak die we oppakken te schatten met behulp van Planning Poker. Dit helpt ons om een beter begrip te krijgen van de complexiteit en benodigde inspanning voor elke taak. We gebruiken de aangepaste Fibonacci-reeks (1, 2, 3, 5, 8, 13) om de moeilijkheidsgraad aan te geven:

• 1: Zeer eenvoudige taak, bijna triviaal.
• 2: Eenvoudige taak die weinig tijd kost.
• 3: Taak met gemiddelde complexiteit.
• 5: Uitdagende taak die meer inspanning vereist.
• 8: Complexe taak die aanzienlijke inspanning vereist.
• 13: Zeer complexe taak die veel tijd en samenwerking vereist of mogelijk zelfs te groot is om in één keer aan te pakken.

• We hebben een nieuwe feature toegevoegd aan ons projectboard: een "Timeline". Deze tijdlijn biedt een beter overzicht van de planning en helpt ons om in te schatten hoeveel tijd we nodig hebben voor elke taak. Dit draagt bij aan een realistischere planning en betere inschatting van de doorlooptijd van het project.

link naar Timeline

• Als team hebben we de Team Canvas ingevuld om een beter inzicht te krijgen in onze sterke en zwakke punten, onze doelen en hoe we als team functioneren. Dit helpt ons om onze samenwerking te verbeteren en gerichter te werken aan onze doelstellingen.

Team-canvas

Debriefing

Om onze samenwerking te optimaliseren en de code consistent en begrijpelijk te houden, hebben we de volgende codeconventies vastgesteld:

Algemene Afspraken:

• Duidelijke namen: Klassen, ID's, variabelen en functies krijgen beschrijvende namen die hun doel duidelijk maken.
• Engelse naamgeving: Omdat de website Engelstalig is, gebruiken we ook Engelse namen in de code.
• Dynamische content: Alle content wordt dynamisch opgehaald uit Hygraph.

• Semantisch en gestructureerd: We gebruiken semantische HTML-elementen en zorgen voor een duidelijke structuur.
• Minimalistisch: We vermijden overbodige HTML-elementen.
• Browsercompatibiliteit: De website moet functioneel blijven op alle browsers, zelfs als bepaalde technologieën niet worden ondersteund.
• Alt-teksten en lazy loading: We voorzien afbeeldingen van beschrijvende alt-teksten en implementeren lazy loading voor snellere laadtijden.

• Mobile first: We ontwerpen eerst voor mobiele apparaten en schalen vervolgens op naar grotere schermen.
• Volgorde: We schrijven CSS in dezelfde volgorde als de HTML-structuur.
• Custom properties: We gebruiken CSS custom properties (variabelen) voor kleuren en andere herbruikbare waarden.
• Media queries: Media queries plaatsen we aan het einde van de CSS-bestanden.

• Comments: We voegen comments toe om de code begrijpelijk te houden.
• camelCase: We gebruiken camelCase voor variabelen en functies.
• Structuur: We hanteren de volgende structuur:
• Variabelen declareren
• Logica
• Functie declaraties

Door deze codeconventies te volgen, zorgen we voor een gestroomlijnde samenwerking en houden we onze codebase consistent, leesbaar en gemakkelijk te onderhouden.