| layout | title | inheader | permalink |
|---|---|---|---|
page |
Syksyn 2023 koe |
false |
/koe2023/ |
Arvostelu valmis, pisteet näkyvät Moodlessa. Huomaa, että Moodlessa tehtävän n pisteet näkyvät tehtävän n+1 kohdalla.
Kurssipalautejärjestelmä Kurppa on osoittautunut menestykseksi ja Helsingin yliopiston (HY) lisäksi sovelluksen ovat ottaneet käyttöön myös Tampereen yliopisto (TAU) ja Jyväskylän yliopisto (JYU). Sovellusta jatkokehitetään nykyään kolmen yliopiston voimin. Jokaisella yliopistolla on oma Kurppabacklog ja product owner. Kehitystyö on jaettu kolmen kuukauden mittaisiin sprintteihin. Sprintti alkaa viikon mittaisella suunnittelutilaisuudella, minkä aikana kukin product owner määrittelee tarkemmalla tasolla backloginsa tärkeimmät user storyt ja estimoi. Tämän jälkeen product ownerit äänestävät, mitkä user storyt otetaan työn alle seuraavaan sprinttiin.
Kehitystyö on organisoitu siten, että Kurpan frontendiä eli selainpuolen toiminnallisuutta toteutetaan HY:n tiimissä, backendiä eli palvelinpuolen koodia TAU:n tiimissä ja Sisu-järjestelmään tapahtuvasta integraatiosta vastaa JYU:n tiimi. Sprintin ensimmäiset kaksi kuukautta kukin tiimi kehittää omalla vastuualueellaan olevaa koodia. Jokaisella yliopistolla on oma Git-versionhallintajärjestelmänsä, johon koodi on synkronoitu sprintin alussa. Kehitys tehdään kunkin yliopiston omassa Gitissä.
Sprintin sisällä kunkin yliopiston tiimin työskentely tapahtuu siten, että tiimin Kurppamestari (tiimien käyttämä nimitys Scrum masterille) suunnittelee kunkin user storyn edellyttämät tekniset tehtävät eli taskit sekä niiden koodiin ja arkkitehtuuriin vaatimat muutokset. Hän myös määrää kullekin tehtävälle koodarin tiimin sisältä. Jos koodari ei ymmärrä hänelle määritellyn tehtävän sisältöä, hän kysyy asiasta omalta Kurppamestarilta, joka tarpeen mukaan varmistaa asian oman yliopistonsa Product ownerilta.
Toiminnan optimoimiseksi kukin koodari työskentelee tavallisesti samaan aikaan useamman teknisen tehtävän eli taskin parissa. Koodari luo kutakin taskia varten versionhallintaan ns featurebranchin, jotta sprintin aikana ei syntyisi sekaannuksia muiden koodareiden kanssa. Featurebranchit mergetään kunkin yliopiston omaan Gitiin sprintin niiden valmistuessa. Usein tämä tapahtuu aikalailla viime tingassa.
Sprintin viimeinen kuukausi käytetään koodin integrointiin ja testaamiseen. Tässä vaiheessa koodi kopioidaan kunkin yliopiston omasta versionhallinnasta HY:n Gitiin, minkä sisällä sprintin loppuajan työskentely tapahtuu. Testaus on ulkoistettu Rovaniemeltä ostetulle etänä työskentelevälle testaustiimille. Testaus tapahtuu pääosin käyttöliittymää klikkailemalla. Sprintin lopuksi Kurpasta julkaistaan uusi versio. Kussakin yliopistossa Kurpan tuotantoon viemisestä ja tuotannossa pyörittämisestä vastaa erillinen IT-tiimi. Esim HY:llä tämä tiimi on TIKE:n eli Tietotekniikkakeskuksen DevOps-tiimi. Uuden version julkaisun yhteydessä he saavat koodin oman yliopistonsa Kurppa-tiimiltä ja käynnistävät sen yliopistonsa palvelimella.
Joka neljäs Kurppasprintti on niin sanottu laatusprintti. Sen aikana järjestelmään ei toteuteta uusia ominaisuuksia (poislukien seuraavassa kappaleessa mainitut kiireelliset yllätysstoryt) ja työ keskittyy teknisen velan maksamiseen ja testaustiimin edellisen kolmen sprintin aikana havaitsemien bugien korjailuun.
Aika ajoin yliopistojen korkeimman johdon tietoisuuteen kantautuu Kurpan esim. Jodelissa tai jopa Helsingin Sanomissa saamaa vihaista palautetta. Tämä johtaa usein siihen, että Kurpan menossa olevaan sprinttiin otetaan erittäin kiireelliseksi määriteltyjä user storyjä, jotka on toteutettava välittömästi.
Lupaavan alun jälkeen Kurpan kehitystyö on hidastunut pelottavaa tahtia, tuotteessa on myös havaittu ikäviä laatuongelmia. Myös koodareiden moraali on laskemaan päin, esim. ennen ylpeydellä pidettyjä Kurppa-huppareita ei oikein enää kukaan viitsi pitää päällä, ainakaan julkisilla paikoilla.
Miten kehittäisit Kurpan sovelluskehityksen prosessia Scrumia, Lean-periaatteita, kurssin osassa 5 käsiteltyjä laajan skaalan ketteriä menetelmiä sekä ketterän manifestin periaatteita noudattaen? Perustele jokainen kehitysehdotus.
Tehtävän arvioi Ville Saastamoinen. Omasta arvioinnista voi tarvittaessa kysyä [email protected] tai Discordissa
Miten kehittäisit Kurpan sovelluskehitystyön teknisiä käytänteitä sekä laadunhallinnan menetelmiä kurssilla esitettyjä periaatteita noudattaen? Perustele jokainen kehitysehdotuksesi. Älä viittaa tässä vastauksessasi edellisen tehtävän vastaukseesi, tehtävät tarkastaa eri henkilö.
Tehtävän arvioi Matti Luukkainen. Omasta arvioinnista voi tarvittaessa kysyä [email protected] tai Discordissa
Kuvitellaan, että ollaan Kurppa-järjestelmän kehityksen alkuvaiheessa. Sinut on nimetty Kurpan product owneriksi. Kirjoita kaksi hyvää user storyä Kurpalle. 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ä.
(a) Aloittelevaa ohjelmoijaa varoitellaan usein siitä, että samaa koodinpätkää ei kannata copypasteta moneen paikkaan yhden ohjelman sisällä. Mikä on syynä tälle ”kiellolle”? Onko olemassa myös tilanteita, joissa copypaste voi olla hyväksyttävää tai jopa kannatettavaa?
(b) Kurssilla puhutaan kahdesta erilaisesta tavasta versionhallinnan hyödyntämiseen: feature branchit ja trunk based development. Kerro, mistä on kyse. Kerro molempien hyvistä ja huonoista puolista.
(c) Ohjelmistossa on käytössä relaatiotietokanta. Lisäksi ohjelmisto hakee säätietoja Ilmatieteen laitoksen avoimesta rajapinnasta. Kerro, miten ohjelmiston automatisoidussa testauksessa tulisi toimia tietokannan ja rajapintojen suhteen.
Tehtävän arvioi Valtteri Kantanen. Omasta arvioinnista voi tarvittaessa kysyä [email protected] tai Discordissa
Palataan ajassa hieman taaksepäin. Linkin https://gist.github.com/mluukkai/9093b1b3715b556ce85af32b571fb6de takana on koodia Kurpan kehityksen alkuajoilta. Kehitystiimin velositeetti oli projektin alussa huipputasoa, mutta Kurppamestari on huomannut vauhdin hiljenneen edellisten sprinttien aikana. Syyksi hidastumiseen diagnosoidaan koodiin pesiytynyt tekninen velka.
Refaktoroi koodissa olevaa luokkaa Kurssi sisäiseltä laadultaan paremmaksi soveltaen suunnittelumalleja tai muita tilanteeseen sopivia ratkaisuja.
Tehtävän arvioi Riku Rauhala. Omasta arvioinnista voi tarvittaessa kysyä [email protected] tai Discordissa