Miniprojektin arvosteluperusteet

Miniprojektista saa maksimissaan 9 kurssipistettä seuraavien kriteereiden ja periaatteiden mukaan:

Jokaisesta sprintistä on jaossa ryhmälle 2.5 kurssipistettä, eli maksimissaan kolmesta sprintistä ryhmä voi saada 7.5 pistettä
- Ensisijainen arvostelukriteeri on prosessin seuraaminen, tasainen eteneminen ja ohjelmaan toteutettujen ominaisuuksien laatu
- Toteutettujen ominaisuuksien määrän merkitys arvostelussa on aika pienempi
- Tarkemmat sprinttikohtaiset arvosteluperusteet alla
Henkilökohtainen suoriutumisesta on jaossa -1.5p … 1.5p, poikkeustapauksissa -2p tai 2p on mahdollinen
- Henkilökohtaisen suoriutumisen pisteet perustuvat lopussa tehtävään vertaisarvioon sekä ryhmän repositoriosta ja backlogeilta näkyvään “digitaaliseen jalanjälkeen”
- Henkilökohtaista suoriutumista arvioidessa arvostetaan seuraavia asioita:
  - Fyysistä ja henkistä läsnäoloa
  - Aktiivista otetta
  - Luotettavuutta
  - Ryhmätyön sujuvuutta
  - Työskentelyn tasaisuutta
  - Kontribuutiota ryhmän tuotoksiin (koodi, testit, deployment pipeline, backlogit)
    - varmista, että committisi näkyvät githubissa oikein
- Sankarikoodauksella ei voi kompensoida muuten puutteellista ryhmätyöskentelyä

Perusteeton osallistumattomuus johonkin sprinttiin johtaa miniprojektisuorituksen hylkäämiseen.

Ensimmäisen sprintin arvosteluperusteet

Projekti tulee olla rekisteröity osoitteeseen https://study.cs.helsinki.fi/stats/courses/ohtu-avoin-2022.

Yksi ryhmäläinen kirjautuu järjestelmään, menee välilehdelle miniprojects
- Luo projektin create project -napista avautuvasta lomakkeesta
- Ja jakaa muille ryhmäläisille luodun projektin id:n
Muut ryhmäläiset kirjautuvat järjestelmään ja liittyvät id:n avulla ryhmään join project -napista avautuvasta lomakkeesta

Jokaisen ryhmäläisen on oltava rekisteröitynyt projektiin viimeistään ensimmäisen sprintin lopuksi pidettävässä asiakastapaamisessa.

Linkit projektin backlogeihin ja muihin dokumentteihin (ja niihin tulee olla koko maailmalla lukuoikeus), ja GitHub Actionsiin (tai muuhun käytössä olevaan CI-palveluun) tulee laittaa projektin GitHub-repositorion README:hen!

Pisteitä kertyy seuraavista asioista:

(0.25p) product backlog
- Backlog on DEEP (storyjä ei tarvitse estimoida)
(0.5p) sprintin 1 backlog
- Sprintiin valitut user storyt jaettu teknisen tason taskeiksi
- Päivittäinen jäljellä oleva työmäärä arvioitu taskeittain
- Burndown-käyrä olemassa
- Jokaiseen taskiin on merkitty sen tekijä(t)
- Taskin status on näkyvissä (esim. todo, doing, done)
(0.25p) sprintiin 1 valittujen storyjen hyväksymiskriteerit kirjattu
(0.25p) testaus
- Toteutettua koodia on yksikkötestattu kohtuullisella tasolla
- Ainakin jossain storyssa hyväksymiskriteerien testausta (Cucumber tai Robot Framework)
(0.25p) jatkuva integraatio
- Koodi GitHubissa
- GitHub Actions (tai jokin muu CI-palvelu) suorittaa ainakin yksikkötestit ja ne menevät läpi
(0.25p) toteutus
- Ainakin yksi sprintin tavoitteeseen sovituista storyista toteutettu definition of donen mukaisella tasolla
(0.25p) työtä tehty tasaisesti
- Kaikki työ ei saa olla yhtenä päivänä tehty
(0.25p) GitHub README:
- README:sta löytyy linkki backlogeihin
- Definition of done kirjattu eksplisiittisesti
- Linkki sovellukseen jos kyse web-sovelluksesta
- Jos kyse työpöytäsovelluksesta: ohjelman asennus- ja käyttöohje
(0.25p) sprintin katselmointiin on valmistauduttu asiallisesti
- Katselmoinnin pitäjä on sovittu ja tarvittavat esivalmistelut on tehty etukäteen
- Katselmoinnin aikana asiakkaalle näytetään, että jokainen sprinttiin valittu user story on toteutettu hyväksymiskriteerien mukaisesti

Sprintin maksimi on 2.5 pistettä.

Toisen sprintin arvosteluperusteet

Pisteitä kertyy seuraavista asioista:

(0.25p) product backlog
- Backlog on DEEP (storyjä ei tarvitse estimoida)
(0.25p) sprintin 2 backlog
- Sprintiin valitut user storyt jaettu teknisen tason taskeiksi
- Päivittäinen jäjellä oleva työmäärä arvioitu taskeittain
- Burndown-käyrä olemassa
- Jokaiseen taskiin on merkitty sen tekijä(t)
(0.25p) sprintiin 2 valittujen storyjen hyväksymisehdot kirjattu
(0.25p) kattavahko testaus yksikkö- ja storytasolla
(0.25p) jatkuva integraatio
- CI-palvelu suorittaa testit
(0.125p) GitHubin README:stä linkki testikattavuusraporttiin
(0.25p) projektille määritelty järkevät Pylint- tai checkstylesäännöt jotka tarkistetaan CI:n toimesta
(0.5p) suurin osa sprintin user storyistä toteutettu definition of donen mukaisella tasolla
(0.125p) toimivasta, demossa näytettävästä versiosta on luotu GitHubiin release.
- Jos kyseessä on konsolisovellus, releaseen liitetään projektin ajettava jar-tiedosto
(0.25p) sprintin katselmointiin on valmistauduttu asiallisesti
- Katselmoinnin pitää eri henkilö, kuin edellisessä katselmoinnissa
- Katselmoinnin pitäjä on sovittu ja tarvittavat esivalmistelut on tehty etukäteen
- Katselmoinnin aikana asiakkaalle näytetään, että jokainen sprinttiin valittu user story on toteutettu hyväksymiskriteerien mukaisesti

Sprintin maksimi on 2.5 pistettä.

Kolmannen sprintin arvosteluperusteet

Pisteitä kertyy seuraavista asioista:

(0.25p) product backlog
- Backlog on DEEP (storyjä ei tarvitse estimoida)
- Backlogiin ei jää sinne kuulumatonta roskaa, storyjen statukset on kirjattu oikein, jne…
(0.25p) sprintiin 3 valittujen storyjen hyväksymisehdot kirjattu Cucumber- tai Robot Framework -tiedostoihin
- Hyväksymisehtoja ei kirjoteta erikseen backlogiin, vaan backlogista on linkki hyväksymistestin tiedostoon
(0.25p) sprintin 3 backlog
- Vaatimukset kuten edellisissä sprinteissä
(0.5p) kattavahko testaus yksikkö- ja storytasolla
(0.25p) jatkuva integraatio
- CI-palvelu suorittaa testit
- Master-branch ei ole hajonnut
(0.25p) GitHubin README:stä linkki testikattavuusraporttiin
(0.25p) suurin osa sprintin user storyistä toteutettu definition of donen mukaisella tasolla
(0.25p) toimivasta, demossa näytettävästä versiosta on luotu GitHubiin release.
- Jos kyseessä on konsolisovellus, releaseen liitetään projektin ajettava jar-tiedosto
(0.25p) loppudemoon on valmistauduttu asiallisesti (valmistautuminen arvioidaan sen perusteella miten demo menee)
- Sovittu etukäteen kuka tekee mitäkin
- Mietitty mitä esitetään
  - Kannattaa esitellä tärkein toiminnallisuus, aikaa demossa on vähän joten ei kannata rönsyillä
- Testidata on järkevää
  - tietokanta ei saa olla etukäteen tyhjä
  - tietokannassa oleva data ja testeissä käytettävät syötteet järkeviä, eli ei esimerkiksi 12345, asdf, nimi1, nimi2

Sprintin maksimi on 2.5 pistettä.

Lopputoimenpiteet

Vertaispalaute

Arvosteluperusteiden alussa mainittu henkilökohtainen pisteytys perustuu mm. vertaispalautteeseen
Jokaisen ryhmäläisen tulee antaa vertaispalaute viimeistään sunnuntaina 1.5. klo 23:59
- Vertaispalautteen antaminen on pakollista. Jos vertaispalaute puuttuu, ovat miniprojektin henkilökohtaiset pisteet -1.5p
Vertaispalautteen antaminen tapahtuu tehtävänpalautussovelluksen miniproject-tabissa
- Ryhmäläiset eivät näe toistensa vertaispalautteita

Raportti

Vertaispalautteen lisäksi ryhmä laatii projektin kulusta pienen raportin (noin 2 sivua)

Kerrataan jokaisen sprintin aikana kohdatut ongelmat (prosessiin-, projektityöskentelyyn- ja teknisiin asioihin liittyvät)
Mikä sujui projektissa hyvin, mitä pitäisi parantaa seuraavaa kertaa varten
Mitä asioita opitte, mitä asioita olisitte halunneet oppia, mikä tuntui turhalta
Jos raportti puuttuu, vähennetään ryhmältä 2 pistettä
Raportti palautetaan lisäämällä raporttiin linkki projektin GitHubin README:hen
Raportista tulee ilmetä jokaisen projektiin osallistuneen nimi
Raportin deadline sunnuntaina 1.5. klo 23:59

Varmista, että commitisi näkyvät GitHubissa oikein

Koska Githubiin tehtävien commitien määrä (ja laatu) vaikuttaa henkilökohtaisiin pisteisiin, varmista, että olet konfiguroinit email-osoitteesi gitiin (ks. viikon 1 laskareiden tehtävä 2), ja että commitatessasi ryhmäsi repositorioon tunnuksesi näkyy oikein repositorion commit-listalla, ja että tunnuksesi tulee repositorion contributors-listalle.

On suositeltavaa, että jokainen tekee (omalta koneeltaan) heti alussa yhden testicommitin ja tarkastaa, että Git on konfiguroitu oikein.

Commitit kadoksissa

Jos committisi yhteydessä näkyy (gitin email-osoitteen konfiguroinnista huolimatta) harmaa symbooli kuten seuraavista alempi

Klikkaa harmaan commitin nimeä katso mikä on email-osoite, joka commitiin liittyy mutta mitä github ei tunnista osoitteeksesi.

Lisää osoite settings-valikosta: