Kokeen arvostelu valmis, näet pisteesi emailitse lähteteyssä tarkastuslistassa. Näet vastauksesi Moodlesta https://moodle.helsinki.fi/course/view.php?id=67825. Moodleen pisteitä ei ole kirjattu.

Omasta arvioinnista voi tarvittaessa kysyä suoraan kunkin tehtävän arvijoijalta.

Tehtäviin liittyvä tarina

Opiskelijoiden Kevät on alun perin Jyväskylän yliopistossa (JYU) kehitetty mobiiliystävällinen selainsovellus, joka tarjoaa opiskelijoille mahdollisuuden muiden oppiaineiden sekä yliopistojen opiskelijoiden tunnistamiseen.

Sovelluksen toiminta perustuu siihen, että eri opiskelijajärjestöjen edustajat tallettavat järjestelmään kuvia omista haalareistaan sekä tallenteita omista juomalauluistaan. Sovellus hyödyntää moderneja tekoälyratkaisuja siihen, että sovelluksen avulla kuka tahansa opiskelija voi tunnistaa opiskelijatilaisuuksissa, esim. ATK-YTP:ssä, vastaantulevia opiskelijajoukkoja ottamalla valokuvia haalareista sekä nauhoittamalla juopuneiden (tai selvien) kanssaopiskelijoiden lauluja. Havaintoja voidaan jakaa sosiaaliseen mediaan (esim. TKO-älyn TikTokiin) ja näin kasvattaa tietämystä opiskelijakulttuurista. Sovellus toimii myös kansalaistieteen alustana. Sovelluksesta kertyvää dataa käytetään mm. Helsingin yliopiston Historian ja taiteiden tutkimuksen laitoksen tutkimushankkeissa.

Nykyisin sovellusta kehitetään Funidatan, Jyväskylän yliopiston ja CSC:n (Tieteen tietotekniikan keskus) yhteistyönä. Toimijoiden vastuut on jaettu siten, että Funidata huolehtii frontendista, eli sovelluksen web-selaimessa toimivan käyttöliittymän toiminnasta, JYU backendista, eli palvelimilla pyörivästä sovelluslogiikasta, esim. tekoälystä sekä tiedon tallettamisesta, ja CSC:n DevOps-tiimin vastuulla on huolehtia palvelimien asennuksista ja ylläpidosta sekä yksinkertaisimmista bugikorjauksista. Jokaisella toimijalla on oma backlog ja product owner.

Kehitystyö on jaettu neljän kuukauden mittaisiin sprintteihin. Sprintti alkaa viikon mittaisella suunnittelutilaisuudella, jonka aikana kukin product owner määrittelee tarkemmalla tasolla backloginsa tärkeimmät user storyt ja estimoi ne. Tämän jälkeen product ownerit äänestävät, mitkä user storyt otetaan työn alle seuraavaan sprinttiin. 

Toiminnan optimoimiseksi kukin koodari työskentelee tavallisesti samaan aikaan useamman teknisen tehtävän eli taskin parissa. Projektilla on yhteinen GitHub-repositorio ja siellä jokaisella toimijalla puolestaan oma haara (branch), jossa kehitys tapahtuu. Sprintin viimeinen kuukausi käytetään koodin integrointiin ja testaamiseen. Tässä vaiheessa koodi mergetään kunkin toimijan haarasta yhteiseen release-haaraan, jossa sprintin loppuajan työskentely, mukaan lukien testaus, tapahtuu. Testiautomaatiota ei ole, vaan testaus on ulkoistettu Ammattikorkeakoulu Metropolialle, jonka opiskelijat tekevät järjestelmälle tutkivaa testausta opintopistepalkalla. 

Yliopistokohtaisten haarojen sisällä toimitaan vaihtelevasti. Funidata käyttää feature brancheja, kun taas Jyväskylä ja CSC pyrkivät (kumpikin oman branchinsa sisällä) trunk-based -mallin mukaiseen toimintaan. Kummassakin tapauksessa ongelmana on, että muutokset tuodaan kehittäjän koneelta yhteiseen versionhallintaan aika lailla viime tingassa. Lisäksi loppukäyttäjälle näkyvän toiminnallisuuden valmistumiseen kestää joskus aika kauan, sillä toiminnallisuus (esim. parhaillaan kehityksen alla oleva sitsilaulujen ennustava tekstitys, joka mahdollistaa sovelluksen käyttäjän karaokemaisen osallistumisen laulantaan) vaatii yleensä sitä, että jokainen tiimi tekee valmiiksi toimintoon liittyvät storynsä. Eri tiimien storyt pitää tehdä usein myös tietyssä järjestyksessä, esim. Funidatan kehittäjistä koostuvan frontend-tiimin on todella vaikea edetä, jos JYU:n kehittäjien muodostama backend-tiimi ei ole tehnyt omaa saman toiminnallisuuden storyään valmiiksi jo edellisessä sprintissä.

Kun jokin toiminnallisuus on vihdoin kokonaisuudessaan “valmis”, käy kuitenkin usein ilmi, että frontend- ja backend-tiimit ovat toteuttaneet oman storynsä hieman epäyhteensopivalla tavalla ja kokonaisuus ei toimi. Aika usein syy on kuitenkin DevOps-tiimissä: vaikka toiminnallisuus on koodattu hyvin, ei DevOps-tiimi ole ehtinyt tai kyennyt viemään toiminnallisuutta tuotantoon, usein myöhästyneen testauksen takia. Joskus tuotantoonvienti tapahtuu vasta DevOps-tiimin jossain myöhemmässä sprintissä. Näin on erityisesti keväällä, kun testaajina toimivien Metropolian opiskelijoiden fokus on välillä jo tulevassa kesässä.

Vaikka vika on yleensä muissa, Jyväskylän yliopiston johto saa usein vihaista palautetta, joka johtaa suureen määrään pieniä bugitikettejä ja feature-toiveita, jotka kehitykseen osallistuvien tiimien on pakko suorittaa kesken menossa olevien sprinttien.

Tehtävä 1

Tehtävän arvioi Pooki Vehviläinen. Omasta arvioinnista voi tarvittaessa kysyä etunimi.sukunimi@helsinki.fi tai Discordissa

On herännyt epäilys, että nykyisessä prosessissa on paljon ns. lean-hukkaa (engl. waste, jap. muda, muri, mura).

Tunnista kertomuksesta mahdollisimman monipuolisesti lean-hukaksi tulkittavia asioita. Perustele esiin nostamistasi seikoista lyhyesti, minkä takia ne ovat tulkittavissa hukaksi.

Parannuskeinoja ei tässä tehtävässä tarvitse esittää.

Tehtävässä annettiin pisteitä seuraavasti:

Tehtävän arvioinnissa on 9 alikohtaa, joista jokaisesta on mahdollista saada 2p. Yhden pisteen saa siitä, että on tunnistanut hukan ja toisen saa siitä että perustelee hukan. Jos jokin hukka on tuotu esille hyvin tekstissä (esim. toista hukkaa perustellessa), mutta sitä ei ole eksplisiittisesti tunnistettu, saa siitä myös yhden pisteen. Toisen saman tyyppisen hukan mainitsemisesta ei saa pisteitä. Yhteensä näistä osakohdista saa 18 pistettä, mutta täysiin pisteisiin riittää 14 pistettä.

Nämä pisteet muunnetaan kurssin käyttämälle skaalalle 0-14p -> 0-4.5p.

Tehtävä 2

Tehtävän arvioi Sini Arkko. Omasta arvioinnista voi tarvittaessa kysyä etunimi.sukunimi@helsinki.fi tai Discordissa

On olemassa viitteitä siitä, että sovelluksen kehittämisessä käytetty tiimirakenne ei ole optimaalinen.

Kerro, miten sovelluskehitys kannattaa organisoida kurssilla esille tuotujen hyvien käytänteide mukaisesti tiimirakenteen sekä tiimien välisen työnjaon suhteen. 

Perustele, miksi ehdottamasi tiimirakenne on parempi kuin ylläkuvattu.

Pisteitä sai seuraavasti:

  • Tiimirakenne: pienet, itsenäiset, fullstack-, feature-tiimit (max 1,5p)
  • Yhteinen suunta ja priorisointi: yksi tuotteenomistaja ja product backlog (max 1,5p)
  • Synkronointi: lyhyt sprintti, yhteinen sprintin suunnittelu, katselmointi ja retro, Scrum of Scrums (max 1,5p)
  • Kommunikointi: “just talk”, “communicate in code”, CI (max 1p)
  • Muita osuvia huomioita (max 1p)

Tehtävä 3

Tehtävän arvioi Antti Vuorenmaa. Omasta arvioinnista voi tarvittaessa kysyä etunimi.sukunimi@helsinki.fi tai Discordissa

Kuvitellaan, että ollaan Opiskelijoiden Kevät -järjestelmän kehityksen alkuvaiheessa. Tässä vaiheessa kehityksestä vastasi vain yksi tiimi, jonka product owner sinä olet.

Kirjoita kaksi hyvää user storyä Opiskelijoiden keväälle. Saat keksiä niiden kuvaaman toiminnallisuuden itse. Toinen user storyistä on sellainen, että sen kuvaama toiminnallisuus tullaan toteuttamaan seuraavassa sprintissä. Toinen storyistä tullaan toteuttamaan aikaisintaan kahden vuoden päästä. Perustele, miksi kirjoittamasi storyt ovat hyviä.

Tehtävässä annettiin pisteitä seuraavasti:

  • User story 1 seuraavaan sprinttiin (3,7p):
    • Prioriteetiltään korkea story (0,5p)
    • Story on kirjoitettu selkeästi ja asiakkaan kielellä. Ei teknistä jargonia. (0,3p)
    • Hyväksymiskriteerit olemassa. Järkevät storyn suhteen, testattavat. (1p)
    • INVEST mainittu (0,4p)
    • INVEST osa-alueet toteutuvat kirjoitetussa storyssa (1,2p)
    • Tekniset taskit mainittu, taskeihin jako kehittäjätiimin vastuulla (0,3p)
  • User story 2 kahden vuoden päähän (2p):
    • Laajempi story (epiikki tasolla) ja tarkkuudeltaan löyhempi kuin story 1, mutta kuitenkin järkevä. Jos on hyväksymiskriteerit, ne ovat karkeat. (1p)
    • Ei korkean prioriteetin story (esim DEEP kriteerien mukaisesti) (0,3p)
    • Ei estimointia / epämääräinen työmääräarvio (0,2p)
    • Ei vielä testattava (0,2p)
    • Ei INVEST (0,3p)
  • Perustelujen laatu vaikuttaa pisteisiin.

=5,7p / 4,5p. Eli kaikkea ei tarvitse sisällyttää vastaukseen saadakseen täydet pisteet.

Tehtävä 4

Tehtävän arvioivat Riku Rauhala ja Taneli Härkönen. Omasta arvioinnista voi tarvittaessa kysyä etunimi.sukunimi@helsinki.fi tai Discordissa

Aika usein huomataan, että jotkut uudet Opiskelijan Kevät -sovelluksen ominaisuudet eivät olekaan käyttäjien mieleen. Esimerkiksi edellisessä sprintissä tehty siirtymä Comic Sans fontin käyttöön johti siihen, että iso osa rekisteröityneistä käyttäjistä lopetti sovelluksen käyttämisen parissa viikossa.

  • Miten hyödyntäisit kurssilla opittuja asioita tällaisten tilanteiden välttämiseksi?
  • Kirjoita tiimeille riittävän yksityiskohtaiset ohjeet, joita myös tämän kurssin sisältöä tuntemattomat kehittäjät osaavat seurata.

Pisteitä sai seuraavasti:

Tuotannossa testaaminen:

  • 1p jos mainittu eksplisiittisesti tai selvästi ymmärretty sen merkitys
  • 0.5p jos mainittu tekniikoita mutta ei selvästi ymmärretty mistä on kyse

Tuotannossa testaamisen menetelmät, 0.5p/maininta

  • A/B-testaus
  • rajattu koekäyttäjien joukko
  • MVP
  • feature toggle

Analytiikka

  • 1p jos ymmärretty merkitys ja selitetty tarkemmin
  • 0.5p jos vaan mainittu että joo jotain dataa olis hyvä kerätä tjsp.

Huolellisempi vaatimusmäärittely

  • 1p jos avattu tarkemmin ja/tai kommentoitu huonoja puolia
  • 0.5p jos tajuttu ennakoinnin merkitys

Muuta

  • 0.5p muista hyvistä huomioista