Ajankohtaista

  • Miniprojektit alkavat 9.11. alkavalla viikolla aloitustilaisuuksilla
  • Ilmoittautuminen aloitustilaisuuksiin käynnissä, ja tapahtuu täällä. Ilmoittautuminen päättyy to 5.11. klo 23.59

Tärkeät linkit

Johdanto

  • Kurssin viikoilla 3-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ä

Ryhmän muodostaminen

  • Ryhmät muodostetaan 9.11. alkavalla viikolla pidettävissä aloitustilaisuuksissa
    • aloitustilaisuuden kesto on noin 2 tuntia
  • Aloitustilaisuudet (jokainen osallistuu yhteen)
    • ma 9.11. klo 14–16 C220
    • ti 10.11. klo 14–16 D122
    • ke 11.11. klo 16–18 C220
    • to 12.11. klo 10–12 BK114
    • to 12.11. klo 14–16 B222
    • Aloitustilaisuuksiin ilmoittautuminen alkaa 27.10. ja päättyy to 5.11. klo 23.59
  • Aloitustilaisuuteen tullessa on syytä tuntea materiaalin osien 1 ja 2 asioista ainakin seuraavat:
  • 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

Ohjaaja toimii tapaamisissa kahdessa roolissa:

  1. asiakkaana, jolta saatte sovelluksen vaatimukset, joka hyväksyy toteutetut ominaisuudet ja joka ei välttämättä ole teknisesti kovin osaava
  2. mentorina, joka antaa palautetta teknisestä ja menetelmällisestä työstänne

Ohjaaja kertoo ensimmäisessä tapaamisessa, miten roolin vaihtuminen näkyy. Voitte myös itse pyytää saada puhua mentorin tai asiakkaan kanssa tilanteen tullen. Ohjaajaan voi olla yhteydessä myös tapaamisten välillä, jos ryhmässä on ongelmia. Yhteydenottotapa sovitaan ohjaajan kanssa.

viikko 3 (9.–13.11.)

  • Ryhmä muodostetaan
  • Ryhmät tapaavat asiakkaan aloitustilaisuuksissa
  • Projekti tulee rekisteröidä palautussovellukseen https://study.cs.helsinki.fi/stats/courses/ohtu-2026.
    • 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 (16.–20.11.)

  • Sprintin 1 katselmointi ja sprintin 2 suunnittelu

viikko 5 (23.–27.11.)

  • Sprintin 2 katselmointi ja sprintin 3 suunnittelu

viikko 6 (30.11.–4.12.)

  • Sprintin 3 katselmointi ja sprintin 4 suunnittelu

viikko 7 (7.–11.12.)

  • Loppudemot (jokainen ryhmä osallistuu yhteen tilaisuuteen)
    • ti 8.12. klo 14–16 B123
    • ke 9.12. klo 10–12 B123
  • Jokainen ryhmä osallistuu yhteen loppudemoon
  • Ei erillistä asiakaspalaveria

Toteutettava ohjelmisto

Kuulet lisää asiakkaalta.

Toteutusteknologia

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

  • SQLite ei vaadi erillistä tietokantapalvelinta, katso ohje
  • 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ä, on erittäin tärkeää että luet tämän ohjeen.

Tekniset ja prosessiin liittyvät vaatimukset

  • Ryhmä laatii yhdessä asiakkaan kanssa product backlogin
    • Vaatimukset kirjataan backlogiin user storyina
  • Sprintin suunnittelun yhteydessä ryhmä valitsee toteutettavaksi sopivan määrän backlogin kärjessä olevista user storyistä
    • Ryhmä valitsee ainoastaan ne storyt, jotka se arvioi ehtivänsä toteuttamaan sprintissä definition of donen määrittelemällä laatutasolla. Definition of done on määritelty alla
    • Kannattaa huomata, että valinta on ennuste eikä lupaus: storyja ei ole pakko saada 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ä seuraa sprintin etenemistä valmistuneiden taskien perusteella burndown- tai burnup-kaaviona
      • kaavio voi olla esim. GitHub Projectsin automaattisesti piirtämä
    • Sprint backlogista tulee ilmetä kunkin taskin osalta
      • taskin tila (esim. aloitettu, ohjelmoitu, testauksessa, valmis)
      • taskin tekijä(t)
  • Ryhmä laatii ensimmäisen sprintin aikana yhteiset pelisäännöt (ks. vihjeitä ryhmätyöskentelyyn) ja tallettaa ne repositorioon tiedostoon pelisaannot.md, johon linkitetään README:stä
    • pelisääntöjä päivitetään tarvittaessa, esim. retrospektiivin perusteella
  • Ryhmä pitää jokaisen sprintin lopussa retrospektiivin (ks. retrospektiivin pitäminen)
    • retrospektiivin tärkeimmät havainnot ja vähintään kolme konkreettista parannuskohdetta kirjataan repositorion juureen tiedostoon retro.md, ja parannuskohteet lisätään seuraavan sprintin backlogiin taskeiksi
  • 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 user storyja tai taskeja ei tarvitse estimoida, sprintin etenemistä seurataan valmistuneiden taskien perusteella
  • Tehkää backlogit GitHub Projectsilla boilerplaten esimerkin mukaisesti
    • esimerkki ja ohje backlogien tekemiseen sekä valmis kopioitava pohja löytyvät boilerplaten BACKLOG.md-tiedostosta
    • esimerkin backlogit esitellään myös materiaalin osassa 2, ks. Esimerkki: backlogit GitHub Projectsilla
    • GitHub Projectsin Insights-näkymä piirtää myös sprintin burnup-kaavion

Definition of done

Seuraavassa lähtökohta definition of 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äksymiskriteerit 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)

Tekoälyn käyttö

Koodausagenttien ja muiden tekoälytyökalujen käyttö miniprojektissa on sallittua. Definition of done koskee myös tekoälyn tuottamaa koodia: sen on oltava testattua ja ylläpidettävää samalla tavalla kuin itse kirjoitetun koodin. Ryhmä vastaa kaikesta repositorioon päätyvästä koodista, ja jokaisen ryhmäläisen tulee ymmärtää, mitä hänen kauttaan repositorioon tuleva koodi tekee. Tekoälyn hallitusta käytöstä lisää materiaalissa Tekoäly ohjelmistotuotannossa.

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ä.

Pelisäännöissä kannattaa sopia ainakin siitä, mitä viestintäkanavaa käytetään ja kuinka nopeasti viesteihin vastataan, miten poissaoloista ja myöhästymisistä ilmoitetaan, miten päätökset tehdään ja mitä tehdään, jos joku ei pysy sovitussa. Ryhmän kannattaa myös tavata ainakin kerran epämuodollisesti, esim. kahvin tai pelien merkeissä, sillä tutustuminen helpottaa yhteistyötä. Ensimmäisessä sprintissä tällaisesta tapaamisesta voi laskea 30 minuuttia sprintin työaikaan.

Ongelmista kannattaa kertoa ryhmälle heti, kun ne huomaa. Jos työ myöhästyy tai jää kesken, ryhmä ehtii vielä priorisoida tehtävät uudelleen. Kun jokin menee pieleen, syytä kannattaa etsiä prosessista eikä ihmisistä, ks. psykologinen turvallisuus. Avun pyytäminen ja oman osaamattomuuden myöntäminen ovat projektissa täysin odotettuja asioita, erityisesti kun ryhmän jäsenten kokemustaso vaihtelee.

Ryhmällä ei ole nimettyä johtajaa, joten aloitteen ottaminen voi tuntua hankalalta. Kannattaa vuorotella palaverien ja retrospektiivien vetäjänä, ja kun joku ottaa vetovastuun, sitä kannattaa myös kiittää. Johtamisesta saa myös puhua: on täysin ok kertoa, että arvostaa sitä, kun joku ottaa vetovastuun, tai että itse pitää vetämisestä.

Pariohjelmointi ja yhdessä 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, product backlogille ja sprint backlogille kannattaa 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.

Retrospektiivin pitäminen

Retrospektiivissä tiimi tarkastelee omaa työskentelyään: mikä sprintissä sujui hyvin, mitä voisi parantaa ja miten parannukset otetaan käyttöön seuraavassa sprintissä. Retrospektiivin voi pitää millä tahansa tekniikalla. Tässä kolme vaihtoehtoa:

  • Start, Stop, Continue, More of, Less of Wheel: tiimi kerää asioita, jotka pitäisi aloittaa, lopettaa tai joita kannattaa jatkaa, sekä asioita, joita pitäisi tehdä enemmän tai vähemmän.
  • Glad, Sad, Mad: jokainen kertoo, mikä sprintissä ilahdutti, harmitti ja suututti, ja niistä etsitään yhdessä parannettavat asiat.
  • Kierroksiin perustuva malli, joka on kuvattu alla.

Lisää tekniikoita löytyy esim. Retrospective Wikistä.

Jos ette tiedä mistä aloittaa, kokeilkaa kierroksiin perustuvaa mallia. Siinä kenenkään ei tarvitse keksiä kerralla kuin yksi asia:

  1. Valitkaa kirjuri, joka kirjaa esiin nousseet asiat ylös.
  2. Käykää läpi, miten edellisen retrospektiivin parannuskohteet toteutuivat.
  3. Jokainen miettii hiljaa minuutin ajan yhden asian, joka sujui sprintissä hyvin. Sen jälkeen kukin kertoo omansa lyhyesti, ja asiasta keskustellaan. Miettimisaikaa voi tarvittaessa pidentää kahteen minuuttiin.
  4. Sama toistetaan yhdelle asialle, jota voisi parantaa.
  5. Sama toistetaan yhdelle asialle, jonka tekeminen kannattaisi lopettaa.
  6. Kierros käydään läpi kaksi kertaa tai enemmän, jos aika riittää.

Lopuksi sovitaan vähintään kolme konkreettista parannuskohdetta seuraavaan sprinttiin. Parannuskohteen toteutumisen pitää olla sprintin lopussa tarkistettavissa, esim. jokainen pull request katselmoidaan ennen mergeämistä eikä kommunikoidaan paremmin. Retrospektiiviin kannattaa varata noin puoli tuntia, tarvittaessa hieman enemmän. Retrospektiiviin ei kuitenkaan saisi kulua yli tuntia, koska miniprojektiin on varattu vain noin 6 tuntia työaikaa sprintissä.

Työn arvostelu

Arvosteluperusteet löytyvät täältä