Samenwerkingsovereenkomst¶

Dit is het samenwerkingsovereenkomst voor het spel “Dreameon”. Het is een bullet hell spel, maar anders dan normale bullet hells is het een subgenre van beat ‘em ups in plaats van shoot ‘em ups.

Team¶

Rollen¶

Delegated Product Owner¶

De persoon die contact houd met de product owner zelf. Die zorgt ervoor dat er rekening gehouden word met de belangen van de product owner. Ook zorgt hij ervoor dat duidelijk word wat de product owner precies bedoelt en hij vertaalt dit voor de developers.

Daarnaast bewaakt de delegated product owner het process. Bijvoorbeeld ervoor zorgen dat de focus blijft op de mvp en wat de product owner wilt.

Scrum Master¶

De scrum master bewaakt het scrum process. Dat houd in dat er elke schooldag een daily standup word gehouden dat georganiseerd word door de scrum master. Ook zorgt de scrum master ervoor dat userstories goede worden ingevuld, qua of ze af zijn en niet bijvoorbeeld.

Teamleden¶

Process & Communicatie¶

Regels¶

• Respecteer elkaar
• Wees eerlijk
  • Houd ook niet belangrijke informatie tot jezelf
• Wees op tijd
• Vraag op tijd om hulp
• Geef constructieve feedback
• Neem verantwoordelijkheid voor het gehele project

Documentatie¶

Documentatie word in de gitlab pages gezet met markdown. Voor elke userstory/logische gehele gemaakte feature word er een logboek invulling gemaakt. Daarnaast word elke documenten zelf in een ander documenten mapje gezet.

Alle documenten gebruiken de bijbehorende template die dan ook goed word ingevuld. Bijvoorbeeld worden de juiste tags toegevoegd.

Conflict Oplossing¶

Als er een conflict is houden wij een interventie met de conflict persoon en gaan wij samen proberen er uit te komen.

Na elke waarschuwing reageren wij als voort:

1. Gaan wij kijken wat er mis ging en samen zoeken naar een oplossing.
2. Gaan wij goed kijken wat de conflict persoon beter had kunnen doen en wat diegene fout deed.
3. Gaan wij naar een docent toe om hulp van buiten te krijgen.

Programmeren¶

Userstory¶

Template¶

De titel is een korte maar krachtige beschrijving dat snel duidelijk maakt wat de userstory voor is.

# Als [rol] wil ik [feature] zodat ik [(korte) reden].

## Ingangsvoorwarden

> Welke features af moeten zijn voordat aan deze userstory kan worden begonnen.

- [ ] Player bestaat
- [ ] Player kan bewegen


## Acceptatiecriteria

> Wat er gemaakt moet zijn om te kunnen zeggen dat deze userstory af is.

- [ ] Er zijn wapens
- [ ] Wapens kunnen op de grond liggen
- [ ] Wapens kunnen opgepakt worden van de grond
- [ ] Wapens kunnen gebruikt worden wanneer ze vast worden gehouden
- [ ] Wapens veranderen hoe de aanval van de speler werkt (damage, swing snelheid, etc.)


## Definition of Done

> Wanneer deze userstory compleet af is en naar de "klaar" lijst verplaatst kan worden.
> Alleen deel van deze criteria zijn niet nodig voor elke userstory.

- [ ] Functionaliteit werkt volgens beschrijving van de acceptatiecriteria.
- [ ] Game design documentatie (beslissingen m.b.v. game design theorieën) is up-to-date.
- [ ] Technische documentatie (logboek) (inclusief ERD, UML) is up-to-date.
- [ ] Documentatie bevat datum en auteur.
- [ ] Relevante code staat op GitLab.
- [ ] Merge request is aangemaakt en code review is aangevraagd bij andere teamleden.
- [ ] Code review is uitgevoerd.
- [ ] Feature is ingepland voor de eerstvolgende gebruikerstest.


## Gebruikte bronnen

> Bronnen die waarschijnlijk handig zijn voor deze userstory.
> Bronnen die tijdens het maken van deze userstory zijn gevonden kunnen ook hier toegevoegd worden.

* [Monogame documentation](https://docs.monogame.net/)
*

De template is ook ingesteld in de gitlab omgeving, zodat het gemakkelijk daarin als template gebruikt kan worden.

MoSCoW¶

Samen met het team worden de prioriteiten gewogen met 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¶

Ook word samen met het team de weging van elke userstory gewogen.

Hiervoor worden getallen van de Fibonacci sequence gebruikt worden zodat er niet teveel tijd verloren gaat aan een precieze tijd te kiezen.

• 1 15 minuten
• 2 1 uur
• 3 3 uur
• 5 een dag
• 8 een week
• 13 een gehele sprint

Code standaarden¶

Benaming¶

Wat voor soort benaming en casing gebruikt moet worden bij het maken van verschillende identifiers.

Formatting¶

De code moet een gelijke formatting hebben over het hele project. Elke regel moet juist geïndenteerd zijn vergeleken met waar het in de code staat, met stappen van 4 spaties.

Ook moet er niet te veel of te weinig ruimte zijn tussen regels in de vorm van lege regels. Code dat met elkaar te maken dient dichter bij elkaar te staan. En wat minder met elkaar heeft te maken moet verder uit elkaar staan om een duidelijk verschil te maken met de code dat wel dichterbij elkaar staat. Gebruik hiervoor de theorie van visual hierarchy^{(Visual hierarchy, z.d.)}.

Comments¶

De code moet op een zulke manier geschreven worden dat het zichzelf uitlegt. Comments die letterlijk de code beschrijven dat er bij staat is niet toegestaan.

Comments zijn wel nodig als het niet mogelijk is om de code op zichzelf te lezen, bijvoorbeeld bij een ingewikkelde wiskundige formule. Ook kunnen ze vaak nodig zijn bij het documenteren van methods, wat dan gedaan moet worden met de C# xml comments.

Magic values¶

Het gebruik van magic values is niet toegestaan om de leesbaarheid van de code te behouden. Hieronder vallen getallen en strings. Waardes die zonder uitleg moeilijk te begrijpen zijn en niet gecontroleerd kunnen worden door de compiler.

Dit geld niet voor vanzelfsprekende getallen, bijvoorbeeld \(\text{straal} = \text{diameter} / 2\).

var¶

In de code dient var gebruikt te worden in plaats van de type, bij het definiëren van variabelen. Meestal is de type te begrijpen uit de rest van de code en dit maakt het overzichtelijker.

Git proces¶

Branches¶

Ontwikkelings branch¶

De ontwikkelingsbranche (dev) is waar alle features in gemerged worden, zodat daarin kan gekeken en getest worden of ze wel goed samenwerken. Zonder de live omgeving aan te tasten, omdat het hierdoor platgelegd zou kunnen worden. Voor een publieke release word de ontwikkelingsbranche gemerged met de master branch, het resultaat daarvan word gereleased.

Feature branches¶

Per onderdeel, zoals userstory, dient er een branch gemaakt worden. Dit doen wij om ervoor te zorgen dat iedereen aan elke feature los kan werken, met merge conflicts alleen pas wanneer het klaar is. In plaats van tijdens het process mogelijk bij elke commit.

De branch naam dient het formaat tag/titel te hebben. Waar de tag één van de vier tags, feature, bug, hotfix of doc is. En de titel hoort een korte beschrijving/titel te zijn van wat er op de branch ontwikkeld word.

Merge requests¶

Branches mogen alleen gemerged worden doormiddel van merge requests. Dit is zodat er op een duidelijke plek code reviews uitgevoerd kunnen worden en conflicten worden opgelost. Elke merge requests dient goedgekeurd te worden door tenminste twee andere developers, die zelf niet aan de inhoud van de request heeft gewerkt.

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/
• Diemel, T. & Oskam, B. (2024, 5 maart). Samenwerkingscontract. HBO-ICT Digitale Turn-based Multiplayer Boardgame Blok 3.
  Geraadpleegd op 16 april 2024, van https://vuujoofeexuu44-propedeuse-hbo-ict-onderwijs-2023-ce90f71125f313.dev.hihva.nl/documenten/samenwerkingsovereenkomst/
• Visual hierarchy (z.d.) wikipedia
  Laats geraadpleegd op 16 april, 2024 van https://en.wikipedia.org/wiki/Visual_hierarchy