Samenwerkingscontract¶
Inleiding¶
In dit contract bespreken wij de afspraken die wij hebben gemaakt voor het project, hierin bespreken wij de afspraken over de meetings, code conventions, git conventions, documentatie, scrum master en expert review en code reviews.
Meetings en daily standups¶
Iedere keer als wij elkaar op school, of online spreken doen wij meteen in het begin een korte daily standup, hierin bespreken wij, hoe het de afgelopen tijd ging, waar je tegen aanliep, wat er nog moet gebeuren, en wat je nog gaat doen.
Meetings en daily standups:¶
Iedere keer als wij elkaar op school, of online spreken doen wij meteen in het begin een korte daily standup, hierin bespreken wij, hoe het de afgelopen tijd ging, waar je tegen aanliep, wat er nog moet gebeuren, en wat je nog gaat doen.
In de Sprint meetings gaan wij kijken naar de afgelopen sprint, daarbij kijken we naar hoe het ging, wat we hebben afgerond, of wij nog op schema lopen, dit documenteren wij in een Markdown document en in een persoonlijk scorion formulier. In de sprint kunnen ook nog andere onderwerpen aan bod komen zoals een korte code review, om te kijken of de norm wordt gehaald.
In de retro geven wij elkaar feedback, hierin bespreken wat er goed of fout ging in de laatste sprint, dit documenteren wij ook in een Markdown document en een persoonlijk scorion formulier
Als een teamgenoot merkt dat er iets niet goed gaat gaan wij een extra meeting inplannen, dit kan met of zonder coach, de bedoeling van deze meetings is enkel om het probleem dat de teamgenoot heeft op te lossen. Als de vergadering veel invloed heeft, kan ervoor worden gekozen dit te documenteren in een Markdown document om de vergadering te bespreken.
Scrum master¶
De scrum master is verantwoordelijk voor het project, hieronder valt bijvoorbeeld de taakverdeling, git repo en de user stories. De scrum master is ook verantwoordelijk voor de sprint meetings, de daily standups en de retro.
In de eerste sprint is Bartek de scrum master, In de tweede sprint is Thomas de scrum master, In de derde sprint is Jayden de scrum master.
Expert review en code reviews In dit project gaan we tussendoor ook met elkaar zitten om een korte code review of andere expert review te doen, dit gaan wij doen om de norm bij te houden. Ook kunnen wij van deze feedback leren en een beter eindproduct neer zetten.
Userstories¶
Template¶
Bij het maken van nieuwe userstories hoort de gemaakte template gebruikt te worden, zodat elke userstory dezelfde structuur heeft. Ook bij het maken van de userstories zelf dient de template ingevuld te worden.
MoSCoW¶
Userstories krijgen prioriteiten op basis van de MoSCoW methode.
- Must zijn dingen die gemaakt moeten worden voor het project, dingen die nodig zijn voor de MVP.
- Should zijn dingen die belangrijk zijn en ook gedaan zijn, maar niet nodig zijn voor de MVP.
- Could zijn extra dingen die toegevoegd kunnen worden wanneer de basis van het project klaar is.
- Would zijn kleine extraatjes die als laatste toegevoegd kunnen worden als er niks anders te doen is.
Fibonacci poker weging¶
De zwaarte, hoeveelheid benodigde tijd, dient bij elke userstory toegevoegd te worden, door middel van een poker spel waar elke developer stemt en beredeneerd hoe lang hij/zij denkt dat de userstory zal duren.
Voor de zwaartes worden de eerste paar Fibonacci getallen gebruikten met de volgende betekenissen, zodat niet te lang word besteed aan het kiezen van een hele specifieke hoeveelheid tijd.
- 1 30 minuten
- 2 1 uur
- 3 3 uur
- 5 een dag
- 8 een week
- 13 een gehele sprint
Git Conventions¶
Branch names, In dit project gebruiken wij een branch per user stories, dit doen wij om merge conflicts te voorkomen, een user story heeft 1 van de 4 tags, feature, bug, hotfix en doc, een branch naam start met 1 van de 4 tags, daarna komt een korte titel van de user story, je krijgt dus een branch naam zoals bijvoorbeeld, feature/canvas-responsive
Merge request, In dit project gebruiken wij merge request om te voorkomen dat wij merge conflicts krijgen, het is belangrijk dat als je niet weet of wat je gaat merge goed is dat je iemand anders zou kunnen laten nakijken, anders zou je het gewoon zelf mogen merge als er geen merge conflicts zijn.
Ontwikkelingsbranche, in dit project werken wij aan de ontwikkelingsbranche, dit doen wij zodat de live omgeving niet wordt aangeraakt. Voor het einde van iedere sprint doen wij een test run op de ontwikkelingsbranche en dan merge wij deze met de main branch. De scrum master is hier verantwoordelijk voor.
Documentatie¶
In dit project bouwen wij de documentatie op door per functie/user story documentatie te toevoegen onder een tab Documentatie, voor afbeeldingen in de documentatie wordt de subfolder image gebruikt.
In een stukje code wordt uitgelegd wat de code doet, waarom dit nodig is, en waarom je voor die oplossing hebt gekozen,
Onderaan de pagina komt een tabel met de bronnen. De documentatie kun je pushen met de user story, mocht je te laat zijn zou je de doc tag kunnen gebruiken, bijvoorbeeld doc/canvas-responsive.
Code conventions¶
In dit project werken wij met dezelfde code conventions hieronder bespreken wij de duidelijke code conventies zodat onze code overzichtelijk is.
PascalCasing
, In dit project gaan wij werken met PascalCasing
, hierdoor is het duidelijk wanneer een lange naam uit meerdere woorden bestaat. Dit gebruiken we voor variabele namen en functienamen.
dromedaryCasing
, In dit project gaan wij werken met dromedaryCasing
, voor bestandnamen en variablen die niet globaal zijn.
Spacings, In dit project werken we met spacings, wij gebruiken spacings om code van elkaar te halen, na een functie komt er een wit regel voordat je pas begint, ook na een if-statement komt bijvoorbeeld een wit regel.
Indentatie, In dit project werken we met de juiste indentatie, wij gebruiken indentatie om overzichtelijke functies te krijgen, de basisregels voor indentatie is dat na elke functie je 1 indentatie (tab) doet, en bijvoorbeeld voor if statement ook.
Regels¶
- Respecteer elkaar
- Wees op tijd
- Wees eerlijk
- Vraag optijd om hulp
- Geef feedback
Mocht iemand vaak de regels overtreden, kan er een extra meeting worden ingepland om dit te bespreken. Mocht het team hier niet uit kunnen komen, kan er een coach worden ingeschakeld voor een crisis meeting.
Bronnen¶
- (z.d.) Chiel van Heerwaarden
Laatst geraadpleegd op 20 november, 2023 in persoon (email) - Base code conventies (z.d.) knowledgebase
Laats geraadpleegd op 20 november, 2023 van https://knowledgebase.hbo-ict-hva.nl/1_beroepstaken/software/realiseren/code_conventies/0_code_conventies/ - Documentation comments (z.d.) Microsoft .NET documentation
Laats geraadpleegd op 13 februari, 2024 van https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/xmldoc/
Gecreëerd: February 13, 2024