Versjon 1.1
Her kommer noen tips og forslag til teamarbeidet:
Gruppeavtale
Lag en kort teamavtale med forventinger til hverandre i starten. Noen eksempler til forventinger man kan ta med i denne er:
- Vi forventer at vi møter at vi til avtalte tid, hvis vi ikke får muligheten (av en eller annen grunn) skal vi si i fra til teamet så fort som mulig
- Vi forventer at vi kan be hverandre om hjelp og at alle tilbyr sin hjelp der de kan
- Vi forventer at vi sier i fra til hverandre hvis det blir for mye i god tid, slik at vi kan delegere om
- Vi forventer at vi er realistiske mtp arbeidsmengde
- Vi forventer at alle er med på å lage god stemning i teamet
Hva skal vi gjøre dersom noen på gruppa ikke bidrar?
Send en mail til personen som ikke bidrar og spør hvordan det går med obligen. Dersom det er et vedvarende problem/dere ikke får kontakt med personen kontakt Marlen på marleja@ifi.uio.no
Samarbeide med å skrive kode
For samarbeidet rundt programmeringsdelen av oblig 4 foreslår vi å bruke en variant av parprogrammering. Dette foregår normalt ved at man sitter to eller fler rundt én datamaskin.
I parprogrammering har vi en driver (den som skriver koden), og navigatør(er) som guider driveren. Navigatøren(e) forteller driveren hva som skal skrives og driveren skriver ned dette. Den som skriver kan si stopp om det er noe den er uenig i, ikke forstår eller er usikker på.
Det er viktig å bytte på hvem som er driver ofte, rundt 25 minutter mellom hvert bytte kan være en grei start. (Her er en timer som er satt til 25 min! )
Hvor lenge burde man holde på hver gang?
Hvor lenge en økt er, er opp til dere, men det kan lønne seg å bestemme seg for dette på forhånd. Dersom dere holder på i 90 minutter og er 3 i teamet vil man kunne dele opp økten i 3 deler på 25 min med 5 min pause imellom. Det er viktig at alle på teamet får skrevet noe kode i løpet av en økt. Snakk om hva dere syntes man kan gjøre bedre til neste gang på slutten av møtet.
Hvordan løser vi det med å bytte på hvem som skriver kode digitalt?
I løpet av en økt burde det bare være en maskin med koden og editor åpen. Bruk skjermdeling fra denne via zoom og gi «» tilgang til driveren. Dette må skrus på i innstillingene på uio.zoom.us før man starter møtet.
Når dere er ferdig med en økt lagrer dere koden ett sted alle har tilgang til den. Her er noen forslag til hvor man kan dele det med hverandre:
- UiO sin GSuite, (Lag en der alle i teamet har tilgang)
- Mail/Mattermost-chat
- Git og Github
Dele opp oppgaven i mindre deloppgaver
Når dere skal løse en stor oppgave/prosjekt kan det lønne seg å dele opp hovedoppgaven i mindre oppgaver for å få kontroll over hvordan man ligger an. Til å dele opp en større oppgave i mindre deler kan dere f.eks. bruke trello eller (logg inn med uio-mail), det er ett brettbasert system der man lager tavler man kan putte oppgaver på. Ett forslag til faner man kan bruke er:
- ting som skal gjøres
- ting som gjøres
- ting som er ferdig
- (+ ting man står fast med)
Her har jeg laget ett enkelt brett der jeg har delt opp en større oppgave i mindre deloppgaver. Innad i hver oppgave kan man legge inn mer detaljerte beskrivelser.
Disclaimer: Dette betyr IKKE at man skal dele opp oppgaven i deler som man så gir i oppgave til de forskjellige på gruppa å løse. Dersom man skal gjøre dette burde man se spesielt på testdreven utvikling og enhetstester, code review og git og github. Man må også ha en klar spesifikasjon over hvordan metoder og objekter skal fungere (signatur og semantikk). Dette er ikke poenget at man skal bruke mye tid på å lære seg verktøy som dette i oblig 4 og derfor ikke det vi anbefaler de fleste. Så dersom dere har mulighet, hold dere til parprogrammering så slipper man å måtte gjøre dobbeltjobb når man skal integrere systemet.
Lagre kode
Det er viktig at alle i teamet har tilgang til koden. Ingen andre enn de i teamet skal ha tilgang til denne. For å dele koden er noen foreslåtte alternativer:
- UiO Gsuite/UiO onedrive
- Mattermost/Teams
- Git og Github
De enkleste måtene er de dere sikkert kjenner til fra før av som UiO sin Gsuite (google drive) og Mattermost. Git og Github er en del å sette seg inn i, og det er viktigere å komme i gang med programmeringen, så om du syntes det virker som mye styr er det nok lettere å bruke en av de andre løsningene. Vi legger ved en liten guide her til hvordan komme i gang med dette: