---
# System prepended metadata

title: Gruppdynamik

---

# Gruppdynamik

## Projektets medlemmar och fördjupningsområden
Denni Wernersson - Testning
Maria Olsson - DevOps
Sanna Doolk - Projektledning
Sebastian Åkerblom - Kravhantering

## Generell information
Under Inceptionfasen har vi haft en platt gryppdynamik där alla har bidragit till att skriva dokumentation, upprätthålla kontakt med kunden och testat olika tekniker för att utforska hur vår applikation skall byggas. Det har inte funnits behov av en tydligare uppdelning av uppgifterna mer än att vi tittat på olika tekniker. Vi har en slack-kanal för att hålla kontakten i gruppen där vi har länkar till all dokumentation och kod. Vi använder Jira för att ha koll på det som skall göras i varje sprint, under inceptionfasen har sprintarna varat en vecka. Då vi har varsitt fördjupningsområde har vi delat upp dokumentationsansvaret så det överensstämmer så gott som möjligt.

Vi anser att denna gruppdynamik är effektiv, då teamet består av väldigt få medlemmar. Om fler medlemmar tillkommer kan dynamiken behöva ses över, exempelvis med mer konkreta teamroller och ansvarsområden. 

Den nuvarande dynamiken är också mycket passande på grund av projektets experimentella natur. Då nya tekniker och nyheter inom området uppenbarar sig mycket frekvent blir det en stor utmaning att planera för mycket iförväg med bestämda roller och ansvarsområden. I händelse av att projektet transitionerar till en "maintenance"-fas med lägre grad av utveckling kan dynamiken behöva ses över.

## Arbetsrutiner (Utveckling)
Då den mer konkreta kodningen väl kommer igång kommer vi att arbeta med ett utvalt *Git workflow*. Vi kommer använda en branching strategi där vi använder branches:
* *main* - detta är huvudbranchen och markerar applikationens nuvarande driftstatus.
* *develop* - detta är branchen där nya features testas, denna branch är den enda som mergas in i *main*.
* *feature-\** - dessa branches är till för att utveckla nya funktioner och namnges med *feature-* och sedan ett namn som är talande för vad som implementeras. Ex. *feature-ratelimit* för att implementera ratelimit. När den är implementerad mergas den in i develop för att testas tillsammans med övriga funktionaliteter.

![branching strategy](https://i.imgur.com/e3QtYOT.png)
<center><i>Det finns bara en [main] och [develop], flera [feature-*] kan existera samtidigt.</i></center>



