Miniprojekti

Ajankohtaista

  • Miniprojektin demotilaisuus järjestetään zoomissa tiistaina 26.4. klo 15:00 - 17:00
  • Asiakastapaamisen ajankohta ja zoom-linkki löytyy palautussovelluksen miniproject-sivulta
  • Miniprojekti järjestetään kahtena eri ajankohtana 21.2.-14.3. ja 28.3.-25.4.

Johdanto

  • Kurssin suorittaminen edellyttää hyväksyttyä osallistumista miniprojektiin tai sen hyväksilukemista
  • Voit osallistua miniprojektiin siinä vaiheessa kun olet tehnyt vähintään kurssin neljän ensimmäisen viikon tehtävät
  • Projekti tehdään noin 4-6 hengen ryhmissä
  • Projektissa ohjelmoidaan jonkin verran, pääpaino ei ole ohjelmoinnissa vaan systemaattisen prosessin (tästä lisää myöhemmin) noudattamisessa.
  • Projekti koostuu kolmesta viikon kestoisesta sprintistä
  • Jokaisen ryhmän jäsenen on tarkoitus tehdä kunkin sprintin aikana töitä noin 6 tuntia projektin eteen
    • Asiakastapaamisiin menevää aikaa ei lasketa viikoittaiseen työaikaan!
  • Ryhmä tekee kussakin sprintissä sen minkä se sprinttiin varatussa ajassa pystyy tekemään, ei enempää eikä vähempää
    • Kuuden tunnin työajan reilu ylittäminen siis ei ole järkevää, se on suorastaan kiellettyä
  • Miniprojektin voi aloittaa kahtena ajankohtana:
    • Ensimmäinen mahdollisuus käynnistyy maanantaina 21.2.
    • Toinen mahdollisuus käynnistyy maanantaina 28.3.

Ryhmän muodostaminen

  • Ilmoittaudu miniprojektiin noin viikkoa ennen miniprojekti käymmistymistä
  • Ilmoittautumistietojen perusteella ryhmät muodotostetaan “algoritmisesti”, pääasiassa noudattaen ilmoittautumisessa kerrottuja sopivia työskentelyaikoja
  • Ryhmäsi aloitustilaisuuden ajankohta selviää ilmoittautumissovelluksesta. Kaikkien ryhmäläisten on pakko osallistua tilaisuuteen, jonka kesto on noin 2 tuntia
  • Aloitustilaisuuteen tullessa on syytä tuntea materiaalin osien 1 ja 2 asioista ainakin seuraavat:
    • scrum
    • sprintti
    • user story
    • product backlog
    • sprint backlog
    • hyväksymäkriteeri
    • definition of done
  • Tämä dokumentti ja miniprojektin arvosteluperusteet on myös syytä lukea huolellisesti ennen aloitustilaisuutta
  • Ryhmä keksii itselleen nimen, luo Github-repositorion ja rekisteröi itsensä palautussovellukseen https://study.cs.helsinki.fi/stats/courses/ohtu-avoin-2022
    • Yksi ryhmäläinen kirjautuu järjestelmään, menee välilehdelle miniproject
      • 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

Työn eteneminen

Seuraavien viikkojen asiakastapaaminen (sprintin katselmointi ja uuden sprintin suunnittelu) tapahtuu samana viikon päivänä, saman kahden tunnin sisällä, missä aloitustilaisuus pidetään. Tilaisuuden kesto on 30 minuuttia. Tapaamisen tarkka aika ja sen zoom-linkki kerrotaan palautussovelluksen välilehdeltä miniproject viimeistään tapaamista edeltävänä sunnuntaina.

Viikko 1 (28.3.-3.4.)

  • Ryhmä muodostetaan
  • Ryhmät tapaavat asiakkaan aloitustilaisuuksissa
  • Aloitustilaisuudessa pidettävän asiakastapaamisen pohjalta ryhmä tekee alustavan product backlogin ja sopii asiakkaan kanssa ensimmäisen sprintin tavoitteesta
  • Ryhmä suunnittelee ensimmäisen sprintin ja aloittaa työskentelyn
    • sprintin suunnittelun tuloksena ryhmä tekee sprint backlogin
    • backlogien sisällöstä enemmän täällä
  • Sprintin 1 arvosteluperusteet kannattaa lukea huolellisesti

Viikko 2 (4-10.4.)

  • Sprintin 1 katselmointi ja sprintin 2 suunnittelu
    • Asiakastapaamisen aikataulu selviää palautussovelluksen välilehdeltä miniproject
  • Sprintin 2 arvosteluperusteet kannattaa lukea huolellisesti

Viikko 3 (11-17.4)

  • Sprintin 2 katselmointi ja sprintin 3 suunnittelu
    • Asiakastapaamisen aikataulu selviää palautussovelluksen välilehdeltä miniproject
  • Sprintin 3 arvosteluperusteet kannattaa lukea huolellisesti

Viikko 4 (25.4.-1.5.)

  • Sprintin 3 katselmointi (eli loppudemot). Loppudemot järjestetään myöhemmin ilmoitettavana ajankohtana
  • Jokaisen ryhmäläisen tulee olla mukana loppudemossa. Zoom-linkki loppudemoon löytyy palautussovelluksen välilehdeltä miniproject
  • Miniprojektin lopputoimenpiteisiin liittyvät vaatimukset kannattaa lukea huolellisesti

Toteutettava ohjelmisto

Tekniset ja prosessiin liittyvät vaatimukset

  • Ryhmä laatii yhdessä asiakkaan kanssa product backlogin
    • Vaatimukset kirjataan backlogiin user story:inä
  • Sprintin suunnittelun yhteydessä ryhmä sitoutuu toteuttamaan sopivan määrän backlogin kärjessä olevista user storyistä
    • Jokaisen ryhmäläisen “työaika” on 6 tuntia viikossa
      • Työajan ylittävä sankarikoodaus ei ole suositeltavaa, se on jopa kiellettyä
    • Ryhmä sitoutuu ainoastaan niihin storyihin, jotka se kuvittelee kykenevänsä toteuttamaan sprintissä definition of donen määrittelemällä laatutasolla. Definition of done on määritelty alla
    • Kannattaa huomata, että storyihin sitoutuminen ei tarkoita sitä, että ne on pakko tehdä valmiiksi. Ohjelmistoja tehdessä sattuu ja tapahtuu ennakoimattomia asioita, ja aina suunnitelmat eivät toteudu.
    • Asiakkaalle ei kannata luvata liikaa, ja varsinkin ensimmäisten sprinttien aikana arvioissa on otava varovainen, konfiguroimiseen, testaamiseen ja ryhmän järjestäytymiseen tulee kulumaan paljon aikaa
  • Ryhmä ylläpitää sprint backlogia
    • User storyt jaetaan sprintin suunnittelussa teknisen tason tehtäviksi eli taskeiksi jotka sijoitetaan sprint backlogiin
    • Ryhmä tekee päivittäin jäljellä olevan työajan arviointia ja dokumentoi tämän sprintin burndown-käyränä
    • Sprint backlogista tulee ilmetä kunkin taskin osalta
      • jäljellä olevan työajan estimaatti
      • taskin tila (esim. aloitettu, ohjelmoitu, testauksessa, valmis)
      • taskin tekijä(t)
  • Ryhmä toteuttaa jatkuvaa integraatiota (continuous integration)
    • Oletusarvoisesti kannattaa käyttää laskareista 1 tuttua Github Actionsia, muita vaihtoehtoja esim. TravisCI
  • Koodi on talletettu GitHub:iin
  • Projektin GitHub-repositoriolla on järkevä README.md

Product ja sprint backlog

  • Backlogissa vaatimukset ilmaistaan järkevästi muotoiltuna user storyinä
    • miniprojektissa ei ole tarvetta estimoida user storya, ainoastaan sprintissä olevien taskien työmäärä estimoidaan
  • Kuten edellä todettiin sprint backlogista tulee ilmetä kunkin taskin osalta
    • Jäljellä olevan työajan estimaatti
    • Taskin tila (esim. aloitettu, ohjelmoitu, testauksessa, valmis)
    • Taskin tekijä(t)
  • Backlogit voi toteuttaa esim. Google Docs -spreadsheetinä, mallia voi ottaa seuraavista:
  • Backlogit voi tehdä Google Docsin sijaan myös johonkin backlogien ylläpitämiseen tarkoitettuun työkaluun
    • Kannattaa varmistaa, että työkalu kuitenkin tukee edellä lueteltuja vaatimuksia
    • Esim. https://trello.com ei tue scrum-tyylisiä backlogeja oikeastaan ollenkaan, ja Trelloa kannattaakin välttää tässä projektissa

Definition of done

Seuraavassa lähtökohta definition donelle. Ryhmän tulee määritellä GitHub-repositorioon oma, omiin lähtökohtiin sopiva DoD

  • User storyille tulee määritellä hyväksymiskriteerit, jotka dokumentoidaan Cucumberin tai Robot Frameworkin syntaksilla
    • Hyvänä käytänteenä on laittaa README:stä linkki hyväksymäkriteerit määritteleviin tiedostoihin
  • Toteutetun koodin testikattavuuden tulee olla kohtuullinen (esim. noin 70% muiden paitsi triviaalin koodin, kuten gettereiden/settereiden osalta)
  • Asiakas pääsee näkemään koko ajan koodin ja testien tilanteen CI-palvelusta
  • Koodin ylläpidettävyyden tulee olla mahdollisimman hyvä
    • Järkevä nimeäminen
    • Järkevä/selkeä ja perusteltu arkkitehtuuri
    • Yhtenäinen koodityyli (noudattaa pylintin tai checkstylen avulla määriteltyjä sääntöjä)

Repositorio ja README

README:ssa tulee löytyä ainakin seuraavat asiat:

  • Linkit backlogeihin (backlogeista tulee olla luettavissa olevat versiot julkisessa internetissä)
  • Linkki CI-palveluun
  • Linkki sovelluksen toimivaan versioon (jos sovellus on verkossa)
  • Jos kyse työpöytäsovelluksesta, tulee ohjelmalle olla asennus- ja käyttöohje
  • Työlle tulee määritellä lisenssi https://help.github.com/articles/licensing-a-repository/

Teknologisia vihjeitä

  • Kokonaan uusien teknologioiden opettelu miniprojektin yhteydessä ei ole järkevää
  • Mahdollisten ulkoisten kirjastojen käyttöönotto, testien tekeminen ja CI:n konfigurointi tulee viemään ainakin alussa todella paljon aikaa
  • Komentoriviltä toimiva sovellus on teknologioiden suhteen riskittömin vaihtoehto ainakin Javaa käytettäessä
  • Web-pohjaiselle Python-sovellukselle voi ottaa mallia kurssin esimerkkisovelluksesta
  • Jos haluatte käyttää tietokantaa, on Tikapestakin tuttu SQLite hyvä vaihtoehto
    • SQLiten käyttöön Pythonilla löytyy ohjeita ainakin Ohjelmistotekniikka-kurssin materiaalista
    • Ohjelmistotekniikka-kurssin todo-sovellus on esimerkkisovellus SQLiten tietokannan käytöstä Python-projektissa
    • Huomaa, että jos tarkoituksena on julkaista sovellus esimerkiksi Heroku-palveluun, SQLiteä parempi vaihtoehto on PostgreSQL. Mallia PostgreSQL:n käyttöön Python-sovelluksessa voi ottaa esimerkiksi kurssin esimerkkisovelluksesta
    • Tikapen laskareissa käytetty todo-sovellus on esimerkkisovellus SQLite tietokannan käytöstä Gradle-pohjaisessa Java-projektissa
  • Viikon 3 laskareista kannattaa ottaa mallia Robot Frameworkilla, tai Cucumberilla tapahtuvaan storyjen testaamiseen
  • JavaFX:llä tehtyjen sovellusten automatisoitu testaaminen on mahdollista TestFX-kirjaston avulla. Kirjaston dokumentaatio ei ole parhaasta päästä
    • yksinkertainen Gradle+JavaFX+Cucumber+Circle esimerkkikonfiguraatio löytyy täältä
    • Java Swing-sovellusten Cucumberilla tapahtuva käyttöliittymätason testaus on täysi mysteeri
  • Edellisinä vuosina on huomattu, että Java Springin konfigurointi (toimimaan yhdessä gradlen, cucumberin ja GitHub Actionsin kanssa) miniprojektille varatun ajan puitteissa on osoittautunut haastavaksi. Käyttäkää siis springiä omalla vastuulla
    • yksinkertainen Gradle+Spring+Cucumber+Circle esimerkkikonfiguraatio löytyy täältä
  • Pythonin Tkinter-kirjastolla tehtyjen käyttöliittymien automatisoitu testaaminen on täysi mysteeri, sen takia kannattaa ehkä välttää kirjaston käyttöä

Työn arvostelu

Arvosteluperusteet löytyvät täältä.