Sprint 2

Sprintin tavoitteet projektille:

• Samat tavoitteet kuin edellisellä sprintillä.
• Ainakin osalle Sprintin user storyista on tehty työmääräarviot ja ne on jollain tavalla nähtävillä backlogista.
• Ainakin osassa feature-haarojen pull requesteissa on tehty koodikatselmointeja ja ne on mergattu päähaaraan vasta koodikatselmoinnin jälkeen. How to Review a Pull Request in GitHub the RIGHT Way -video esittelee GitHubin koodikatselmointiprosessia.
• ⭐ Bonus: Voitte halutessanne hyödyntää joissain koodikatselmoinneissa GitHubin Copilot-tekoälyagenttia. Tämä vaatii GitHub Education -lisenssin aktivointia.
• Sovellukselle on toteutettu joitain testejä ja ne suoritetaan onnistuneesti jatkuvan integraation avulla.
• Sovellus on julkaistu tuotantoympäristössä.
• Projektin dokumentaatioon on lisätty toteutusteknologiat (ohjelmointikielet ja niiden versiot sekä olennaisimmat kirjastot) ja tekniset käyttöohjeet (esim. sovelluksen käynnistäminen komentoriviltä).

Viikko 1

• Valitkaa sprintille uusi scrum master.
• Järjestäkää retrospektiivi, jossa käsittelette edellisen sprintin onnistumisia ja haasteita. Keksikää konkreettisia parannusehdotuksia prosessillenne tulevaa sprinttiä varten. Ottakaa retrospektiivistä talteen muistiinpanoja seuraavaa retrospektiiviä varten. Voitte hyödyntää retrospektiivin järjestämisessä esimerkiksi Flinga-työkalua.
• Muodostakaa sprinttiä varten user storyja sekä niihin liittyviä taskeja ja lisätkää ne backlogille.
• Keskustelkaa tiimin kesken user storyjen toteutuksen suhteellisesta työmäärästä ja muodostakaa ainakin osalle niistä työmääräarviot. Merkatkaa työmääräarviot (esim. “t-shirt size”-skaalalla) backlogin user storyihin (esim. labeleina).
• Alkakaa toteuttamaan backlogin user storyja.

Viikko 2

• Julkaiskaa sovellus tuotantoympäristössä. Tässä ohjeita julkaisuun:
  • Spring Boot backend sovelluksen julkaisu
  • Vite frontend sovelluksen julkaisu
• Lisätkää linkit sovelluksen julkaistuihin versioihin repositorion README.md-tiedostoon.
• Edistäkää projektin dokumentaatiota. Ainakin sovelluksen tekinen käyttöohje (sovelluksen käynnistäminen, testien suoritus, jne.) ja toteutuksessa käytetyt ohjelmointikielet, sovelluskehykset ja tärkeät kirjastot on dokumentointu.
  • REST API:en dokumentaatiossa kannattaa hyödyntää Swagger-työkalua. Esimerkkisovelluksesta löytyy esimerkkejä Swaggerin käytöstä.
• Toteuttakaa sovelluksen joitain automatisoituja testejä. Esimerkkisovelluksesta projektista voi ottaa mallia REST API:n integraatiotestaukseen.

Viikko 3

• Jatkuva integraatio mahdollistaa automatisoidun laadunhallinnan ohjelmistoprojekteissa. Lukekaa GitHubin Continuous integration -ohje ja ottakaa projektissanne käyttöön jatkuva integraatio GitHub Actions -palvelun avulla. Jatkuvan integraation tulee ainakin suorittaa testit ja varmistaa, että ohjelma kääntyy (esim. JAR:in muodostus Maven-projektissa ./mvnw package-komennolla). Esimerkkisovelluksesta löytyy GitHub Actions workflow-esimerkki.
• Lisätkää GitHub Actions workflow status badge README.md-tiedoston alkuun.
• Tehkää sprintin päätteeksi sprintille GitHub release. Lisätkää releasen kuvaukseen lyhyt kuvaus sprintin aikana toteutetuista toiminnallisuuksista.
• Varmistakaa, että tuotantoympäristössä on sovelluksen toimiva versio ennen sprintin katselmointia. Jos mahdollista, esitelkää katselmoinnissa sovelluksen toiminnallisuuksia tuotantoympäristössä.