| layout | title | inheader | permalink |
|---|---|---|---|
page |
Miniprojektin arvosteluperusteet |
false |
/miniprojektin_arvosteluperusteet/ |
- Ensimmäisen sprintin arvosteluperusteet
- Toisen sprintin arvosteluperusteet
- Kolmannen sprintin arvosteluperusteet
- Lopputoimenpiteet
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)
- Sankarikoodauksella ei voi kompensoida muuten puutteellista ryhmätyöskentelyä
Perusteeton osallistumattomuus johonkin sprinttiin johtaa miniprojektisuorituksen hylkäämiseen.
Projekti tulee olla rekisteröity osoitteeseen <{{site.stats_url}}>.
- 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ä.
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ä.
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 demottaessa käytettävät syötteet järkeviä, eli ei esimerkiksi 12345, asdf, nimi1, nimi2
- Lue viimeinen bullet uudelleen jostain syystä se jää 25% huomaamatta...
- jos tuollainen syöte nähdään niin pisteitä tulee heti nolla
Sprintin maksimi on 2.5 pistettä.
- Arvosteluperusteiden alussa mainittu henkilökohtainen pisteytys perustuu mm. vertaispalautteeseen
- Jokaisen ryhmäläisen tulee antaa vertaispalaute viimeistään perjantaina 23.12. 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
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 perjantaina 23.12. klo 23:59
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.
Jos pariohjelmoit (se kannattaa!) saat commitit näkyviin molemmille tämän ohjeen mukaan.
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:
