I etterkant av release 1 møttes gruppen for å reflektere over hva som hadde gått bra, og hva vi ønsket å forbedre til neste release. Forbedringspotensialene gikk hovedsakelig ut på å ha tydeligere kommunikasjon i forkant av arbeidet for å sikre lik forventing til sluttresultatet, og tydeligere arbeidsfordeling. Vi ønsket også å teste ut parprogrammering i større grad. Før vi satt i gang med arbeidet av release 2, brukte vi dermed litt tid på å reflektere over hvordan vi ønsket å gjennomføre det videre arbeidet. Ettersom det ikke var et krav å øke funksjonaliteten til applikasjonen, valgte vi å fokusere på å styrke arkitekturen og kodekvaliteten til prosjektet for denne releasen. Vi ble sammen enige om en del nødvendige 'issues' basert på krav i oppgaveteksten og tilbakemeldinger fra studentassistenten. Deretter fordelte vi inn arbeidsoppgaver ut i fra disse. Videre diskuterte vi hvordan vi ønsket å skrive commit-meldinger, ha utfyllende beskrivelser på issues og merge requests, samt skrive kommentarer når en godkjenner en merge request. Dette klarte vi i stor grad å opprettholde gjennom arbeidet av release 2, men vi ønsker til neste release å lage en template slik at det kan bli enda lettere å følge samme standard.
I starten var vi to som parprogrammerte for å teste ut dette, og to som jobbet på egenhånd. Parprogrammering var en nyttig metode for å gjennomføre inspeksjon av koden, men opplevdes at det tok en del lenger tid. Ettersom vi kom i gang med arbeidet litt sent for denne releasen, endte vi med å gå bort fra denne metoden etter hvert, men vi ønsker å ta parprogrammering i bruk i større grad for release 3 - særlig for implementasjon av mer funksjonalitet. Vi ønsker å bruke denne metoden ettersom det kan bidra til å forbedre kvaliteten på koden, fokuset i teamet og kunnskapen i gruppen.
Under denne iterasjonen har det vært mer eller mindre faste ansvarsområder for medlemmene. Ett medlem på gruppen hadde allerede startet med testing for core-modulen i release 1, og ønsket å fortsette med å lage slike tester også for de andre modulene i release 2. Et annet medlem har hatt fokus på filhåndtering og jsonio-modulen. De to medlemme som parprogrammerte har hatt fokus på kjernelogikken og det grafiske.
På den ene siden fører dette til at medlemmene får god kompetanse på sitt ansvarsområde, men lite kompetanse på andre områder. På den andre siden resulterer dette i at medlemmene blir svært dyktige og trygge på å håndtere sine deler av koden, noe som sikrer høy kodekvalitet. Totalt sett syntes vi at det fungerte bra å la medlemmene bli spesialisert på spesifikke områder i stedet for at flere jobber med samme oppgave.
Til slutt har vi for denne releasen hatt jevnlige oppdateringer på status om hvor langt vi har kommet, og hva vi mangler for å komme i mål. Disse oppdateringene kan til fordel strukturers til å for eksempel forekomme til et avtalt tidspunkt. Til neste release ønsker vi dermed å teste ut det å starte hvert møte med å gå gjennom hva hvert medlem jobber med, eventuelle problemer som har oppstått, og hva en ser for seg neste steg er. Ved bruk av en slik tilnærming ser vi for oss at alle ved starten av dagen tilegner seg et tydeligere overblikk over oppgavene foran seg. I tillegg kan det være at et annet medlem sitter på løsningen til et problem/ kan hjelpe.