Ajankohtaista

  • Aloitustilaisuudet (jokainen osallistuu yhteen)
    • ma 10.11. 14-16 C222
    • ti 11.11. 14-16 C321
    • ke 12.11. 10-12 C222
    • ke 12.11. 12-14 C222
    • to 13.11. 14-16 B222
    • to 13.11. 16-18 B222
  • Ilmoittaudu (eli kerro aikatoiveesi) viimeistään lauantaina 8.11. klo 23:59 osoitteessa https://study.cs.helsinki.fi/assembler/course/789ea450-0494-44d8-804c-0d545e0b537c
    • Valitse ajat jotka sopivat sinulle myös kolmen seuraavan viikon asiakastapaamisiin
    • Ryhmäjako tapahtuu aloitustilaisuuksissa

Johdanto

  • Kurssin viikoilla 4-7 tehdään miniprojekti

  • Kurssin läpipääsy edellyttää hyväksyttyä osallistumista miniprojektiin tai sen hyväksilukemista

  • 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.
  • 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ä
  • Sovellus tulee toteuttaa kurssilta Tietokannat ja Web-ohjelmointi tutulla Flask-sovelluskehyksellä, ja sen tulee tallentaa tietonsa PostgreSQL-tietokantaan
  • ohje Flaskin käyttöön täällä, on erittäin tärkeää että luet tämän ohjeen

Ryhmän muodostaminen

  • Ryhmät muodostetaan 10.11. alkavalla viikolla pidettävissä aloitustilaisuuksissa
    • aloitustilaisuuden kesto on noin 2 tuntia
  • Aloitustilaisuudet (jokainen osallistuu yhteen)
    • ma 10.11. 14-16 C222
    • ti 11.11. 14-16 C321
    • ke 12.11. 10-12 C222
    • ke 12.11. 12-14 C222
    • to 13.11. 14-16 B222
    • to 13.11. 16-18 B222
  • 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

Työn eteneminen

Seuraavien viikkojen asiakastapaaminen (sprintin katselmointi ja uuden sprintin suunnittelu) tapahtuu saman 2h sisällä missä aloitustilaisuus pidetään. Tilaisuuden kesto on 30 minuuttia. Aika kerrotaan palautussovelluksen välilehdeltä miniproject

viikko 3 (11-15.11.)

  • Ryhmä muodostetaan
  • Ryhmät tapaavat asiakkaan aloitustilaisuuksissa
  • Projekti tulee rekisteröidä palautussovellukseen https://study.cs.helsinki.fi/stats/courses/ohtu2025.
    • 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.
      • Ne ryhmäläiset joita ei ole rekisteröity ensimmäisen sprintin asiakastapaamiseen mennessä, eivät saa ryhmälle sprintistä tulevia pisteitä

viikko 4 (17-21.11.)

  • Sprintin 1 katselmointi ja sprintin 2 suunnittelu

viikko 5 (24-28.11.)

  • Sprintin 2 katselmointi ja sprintin 3 suunnittelu

viikko 6 (1-5.12.)

  • Sprintin 3 katselmointi ja sprintin 4 suunnittelu

viikko 7 (9-13.12.)

  • Loppudemot (jokainen ryhmä osallistuu yhteen tilaisuuteen)
    • ke 10.12. klo 10-12 B123
    • to 11.12. klo 10-12 A111
  • Jokainen ryhmä osallistuu yhteen loppudemoon
  • Ei erillistä asiakaspalaveria

Toteutettava ohjelmisto

Paljastuu aloitustilaisuudessa…

Toteutusteknologia

Sovellus tulee toteuttaa kurssilta Tietokannat ja Web-ohjelmointi tutulla Flask-sovelluskehyksellä, ja sen tulee tallentaa tietonsa PostgreSQL-tietokantaan

  • Riittää että sovellus toimii kehitysvaiheessa sovelluskehittäjien koneella

Flaskia ei kannata missään tapauksessa käyttää miten sattuu, muuten sovelluksen konfiguroinnissa saattaa ajautua pahoihin vaikeuksiin. Lue ohje Flaskin käytöstä täältä

Tekniset ja prosessiin liittyvät vaatimukset

  • Ryhmä laatii yhdessä asiakkaan kanssa product backlogin
    • Vaatimukset kirjataan backlogiin user storyina
  • 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 oltava 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 arvioinnin 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) GitHub Actionsin avulla
  • Koodi on talletettu GitHubiin
  • 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, yksi aika hyvä vaihtoehto on GitHub projects
    • kannattaa varmistaa, että työkalu kuitenkin tukee edellä lueteltuja vaatimuksia

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 sprintistä 2 alkaen Robot Frameworkin syntaksilla
    • hyvänä käytäntönä on laittaa README:stä linkki hyväksymäkriteerit määritteleviin tiedostoihin
  • Toteutetun koodin testikattavuuden tulee olla kohtuullinen
  • 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 (valvotaan Pylintin avulla)

Repositorio ja README

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

Vihjeitä ryhmätyöskentelyyn

Melko varma resepti epäonnistumiseen on huono kommunikaatio. Tehkää siis asioita mahdollisimman paljon yhdessä, mieluiten paikan päällä kampuksella tai jos se ei onnistu niin esim. Discordin voice chatissa. Ylipäänsä on hyvä kommunikoida ryhmälle mitä lähtee tekemään ja milloin on saanut sen valmiiksi, tällöin vältytään päällekkäisyyksiltä. Erityisesti projektin alkuvaiheessa esim. GitHub-actionsia konfiguroitaessa yhdessä tapahtuvaan työskentelyyn kannattaa panostaa. Projektin kuluessa omatoiminenkin työskentely muuttuu jo helpommaksi jos ja kun ryhmä on sopinut työskentelyn periaatteista ja pelisäännöistä.

Pariohjelmointi/konfigurointi on havaittu erittäin hyödylliseksi. Voikin olla hyvä idea, että jokaista user storya työstää aina kaksi henkilöä.

Jokaiselle asialle, kuten vaikkapa README.md-tiedostolle, project backlogille ja sprint backlogille kannattanee nimetä vastuuhenkilö joka varmistaa, että ryhmä hoitaa asian. Asian X vastuuhenkilö ei välttämättä siis tee asiaa itse, vaan varmistaa että se tulee tehdyksi.

Pitäkää ohjelma koko ajan toimintakykyisenä. On erittäin huono idea koittaa saada viikon aikana eri ihmisten koodaamat tuotokset integroitua tunti ennen asiakaspalaveria…

Katso myös checklist projektin alkuun.

Työn arvostelu

Arvosteluperusteet löytyvät täältä