Se på denne hvis det blir tid, noen av underpunktene er allerede utført men må dokumenteres
For denne innleveringen skal dere ha satt opp et ett Github-repository og invitert de forskjellige gruppemedlemmene:
Dere kan eventuelt benytte Bitbucket eller GitLab eller lignende som et alternativ, men Github er sterkt anbefalt.
Repositoriet bør være public slik at emneansvarlige og studasser kan se innhold og aktivitet.
Main-branchen burde bare benyttes til å “publisere” sprints.
Dere bør ha laget en branch ved navn “develop”, eller lignende, som er separat fra main og som vil være branchen dere hovedsakelig legger til funksjonalitet som det utvikles.
Lag individuelle branches for hver “feature”/backlog-item.
Se forelesningene for versjonskontroll (uke 37) for mer informasjon angående punktene over.
Ellers bør dere selv evaluere hva som er de naturlige neste stegene fra den første innleveringen. Altså er det ikke noen helt klare krav til hva som skal leveres, men forslag til hva dere kan levere kan være:
Sprint 1 retrospekt og sprint 2 planlegging
Nye krav i kravspekken og noen flere oppdelte og konkrete backlog-items fra innlevering 1 – Sikt mot items som hver kan gjennomføres innen en dag. Det er på en annen side ikke forventet at dere har laget slike oppdelte items for hele systemet enda.
En rekke “løse” klasser med funksjonalitet og tilhørende enhetstester – Merk at “løse” vil si at klassene ikke trenger å henge sammen for å forme et system, men kan f.eks. være slikt som konseptuelle datatyper i systemet deres. Vær bevisst på at mer implementasjons-spesifikk funksjonalitet (brukergrensesnitt, database osv.) kan måtte endres/refaktoreres betydelig senere i prosjektet etter dere har lært mer om arkitektur og løst koblet kode. Å måtte skrive om koden senere kan på en annen side være meget lærerikt, så dere kan gjerne prøve på dette også så lenge dere er klar over risikoen.
Forskjellige typer modeller for systemet – For eksempel mockups av frontend for å få en følelse av bruk og inspirere til videre krav, klassediagrammer, sekvensdiagrammer, tilstandsdiagrammer osv. Bruk gjerne slikt til å generelt diskutere med hverandre, finne problemer tidlig og generere nye krav.
Generel anbefaling: Bruk veiledninger med deres dedikerte studass for å vite at prosjektet deres går i riktig retning
Selve innleveringen SKAL i det minste inneholde en link til Github-repositoriet deres og eventuelt andre dokumenter, som ikke passer å legge inn i repo-et. For eksempel kan dere levere en form for “sprint-rapport” som legger frem hva dere har gjort siden sist innlevering og inkludere github-linken som del av denne. Det viktigste er at vi får github-linken og en god oversikt over hva dere har gjort siden sist innlevering.
Se på denne hvis det blir tid, noen av underpunktene er allerede utført men må dokumenteres
For denne innleveringen skal dere ha satt opp et ett Github-repository og invitert de forskjellige gruppemedlemmene:
Dere kan eventuelt benytte Bitbucket eller GitLab eller lignende som et alternativ, men Github er sterkt anbefalt. Repositoriet bør være public slik at emneansvarlige og studasser kan se innhold og aktivitet. Main-branchen burde bare benyttes til å “publisere” sprints. Dere bør ha laget en branch ved navn “develop”, eller lignende, som er separat fra main og som vil være branchen dere hovedsakelig legger til funksjonalitet som det utvikles. Lag individuelle branches for hver “feature”/backlog-item. Se forelesningene for versjonskontroll (uke 37) for mer informasjon angående punktene over.
Ellers bør dere selv evaluere hva som er de naturlige neste stegene fra den første innleveringen. Altså er det ikke noen helt klare krav til hva som skal leveres, men forslag til hva dere kan levere kan være:
Sprint 1 retrospekt og sprint 2 planlegging Nye krav i kravspekken og noen flere oppdelte og konkrete backlog-items fra innlevering 1 – Sikt mot items som hver kan gjennomføres innen en dag. Det er på en annen side ikke forventet at dere har laget slike oppdelte items for hele systemet enda. En rekke “løse” klasser med funksjonalitet og tilhørende enhetstester – Merk at “løse” vil si at klassene ikke trenger å henge sammen for å forme et system, men kan f.eks. være slikt som konseptuelle datatyper i systemet deres. Vær bevisst på at mer implementasjons-spesifikk funksjonalitet (brukergrensesnitt, database osv.) kan måtte endres/refaktoreres betydelig senere i prosjektet etter dere har lært mer om arkitektur og løst koblet kode. Å måtte skrive om koden senere kan på en annen side være meget lærerikt, så dere kan gjerne prøve på dette også så lenge dere er klar over risikoen.
Forskjellige typer modeller for systemet – For eksempel mockups av frontend for å få en følelse av bruk og inspirere til videre krav, klassediagrammer, sekvensdiagrammer, tilstandsdiagrammer osv. Bruk gjerne slikt til å generelt diskutere med hverandre, finne problemer tidlig og generere nye krav. Generel anbefaling: Bruk veiledninger med deres dedikerte studass for å vite at prosjektet deres går i riktig retning
Selve innleveringen SKAL i det minste inneholde en link til Github-repositoriet deres og eventuelt andre dokumenter, som ikke passer å legge inn i repo-et. For eksempel kan dere levere en form for “sprint-rapport” som legger frem hva dere har gjort siden sist innlevering og inkludere github-linken som del av denne. Det viktigste er at vi får github-linken og en god oversikt over hva dere har gjort siden sist innlevering.