Skip to content

Kokeen mallivastaukset ja arvosteluperusteet

Matti Luukkainen edited this page May 23, 2015 · 12 revisions

Tehtävä 1: (korjasi mluukkai, [email protected])

Scrum-guidessa menetelmän kehittäjät toteavat, että menetelmän taustalla on kolme peruspilaria: läpinäkyvyys (engl. transparency), tarkkailu (engl. inspection) ja sopeuttaminen (engl. adaptation). Kerro miten Scrum eri osaalueittensa kautta ilmentää näitä kolmea peruspilaria.

Läpinäkyvyys

  • product backlog kertoo toteutettavat vaatimukset, niiden tärkeysjärjestyksen ja työmääräarviot ja tuotteen valmistumisen asteen
  • definition of done määrittelee tuotteen halutun laatutason
  • sprintin suunnittelussa product owner selvittää toteutettavien asioiden tarkat vaatimukset kehitystiimille
  • sprint backlog kertoo sprinttiin valittujen vaatimusten tilanteen: mitä ollaan tekemässä, valmistumisen aste, kuka tekee mitäkin etc.
  • päivittäiset daily scrum -palaverit tuovat jatkuvan läpinäkyvyyden se suhteen miten sprintti etenee, mitä kukakin tekee, onko kehityksessä ongelmia
  • sprintin katselmointi mahdollistaa product ownerille ja muille sidosryhmille projektin etenemisen seuraamisen

Läpinäkyyys mahdollistaa tarkkailtavuuden

  • sprint backlog ja päiväpalaverit: kehittäjätiimi ja scrum master
  • product backlog ja sprintin katselmointi: product owner ja sidosrymät

Sopeuttaminen

  • sprintin päättävässä retrospektiivissa kehittäjätiimi tarkastelee omia toimintatapojaan, ja korjaa havaittuja epäkohtia
  • Scrum master auttaa kehittäjätiimiä ja product owneria poistaen tuotannon esteitä
  • Produc baclogin luonne (DEEP) ja sprinttien tarjoama kehitystyön jaksottuminen mahdollistavat product ownerille projektin suunnan muokkaamisen

pisteytys

  • Scrumin tehtävän kannalta relevanttien elementtien mainitseminen ja merkityksen selittäminen 3p
  • Asioiden perusteltu jaoittelu teemojen suhteen 1p

Tehtävä 2 (korjasi doge, [email protected]):

Mikä on User story?

Ketterän vaatimusmäärittelyn tärkein työväline. User Storyt kuvaavat loppukäyttäjän kannalta arvokkaita toiminnallisuuksia. User story on karkean tason tekstuaalinen kuvaus ja lupaus/muistutus siitä, että toiminnallisuuden vaatimukset on selvitettävä asiakkaan kanssa. Kun User story päätetään toteuttaa, on pakko selvittää tyhjentävästi, mitkä ovat Storyn kirjaamaan toiminnon vaatimukset. Story on lupaus kommunikoinnista asiakkaan kanssa vaatimuksen selvittämiseksi. User storyyn kuuluu testit/vaatimukset, jotka määrittävät milloin User story on toteutettu.

1p selitetty: vaatimusten määrittelyyn tarkoitettu, asiakkaalle arvoa tuottava ominaisuus, asiakkaan kielellä speksattu, hyväksymiskriteerit Noin -0,25p per puuttuva kohta.

Minkälainen on hyvä User Story?

INVEST:in mukaisesti:

  • Independent: User storyjen pitäisi olla toisistaan mahdollisimman riippumattomia.
  • Negotiable: Hyvä User story ei ole tyhjentävästi kirjoitettu vaatimusmäärittely vaan lupaus siitä, että asiakas ja toteutustiimi sopivat User storyn toiminnallisuuden sisällön ennen toteutusvaihetta.
  • Valuable: User story kuvaa loppukäyttäjän kannalta arvoa tuottavaa toiminnalisuutta.
  • Estimable: User storyn toteuttamisen vaativa työmäärä pitää olla arvioitavissa kohtuullisella tasolla.
  • Small: Työmäärän arviointi onnistuu paremmin jos User storyt ovat riittävän pieniä. User storyä pidetään yleensä liian isona jos se ei ole toteutettavissa noin viikon työpanoksella.
  • Testable: User storyjen pitää olla sellaisia että niille on mahdollista tehdä testit, joiden avulla voi yksikäsitteisesti kertoa onko Story toteutettu hyväksyttävästi.

1p jos pääosin selittänyt hyvän User storyn ominaisuudet, vähintään arvo, koko, riippumattomuus ja testattavuus. Noin -0,25p per oleellinen puuttuva kohta.

Mikä on Product backlog?

Product backlog on priorisoitu lista asiakkaan tuotteelle asettamista vaatimuksista eli toivotuista ominaisuuksista ja toiminnoista. Hyvänä käytänteenä pidetään sitä, että backlogissa olevat vaatimukset ovat asiakkaan tasolla olevia mielekkäitä toiminnallisuuksia. (1p)

Usein on tarkoituksena myös estimoida eli arvioida backlogissa olevien vaatimusten toteuttamisen vaatima työmäärä. Tämän takia kärjessä olevat vaatimukset on yleensä kirjattu tarkemmin kuin backlogin häntäpään vaatimukset.

Vastaukseksi ei riittänyt, että Product backlog koostuu User Storyistä.

Millainen on hyvä Product backlog?

DEEP

  • Detailed appropriately eli sopivan detaljoitu: suuremmalla prioriteetilla olevat User storyt ovat suhteellisen pieniksi jaettuja ja yleisesti tarkemmin estimoituja ja kuvailtuja.
  • Estimated: User Storyihin kuluva aika on estimoitu suhteellisella tasolla esim. Story pointtien tai ideaalipäivien avulla.
  • Emergent: Backlogin sisältö muuttuu ja kehittyy jatkuvasti. Sen sisältö tarkentuu ja vaatimuksia lisätään tai poistetaan asiakkaan ja käyttäjien palautteen perusteella.
  • Prioritized: Backlog on priorisoitu. Tärkeimmät vaatimukset ovat kärjessä ja ne valitaan toteutettavaksi ensimmäisinä.

1p, jos pääosin selitetty kaikki kohdat. 0,5p 2-3 oikein. 0p 0-1 oikein.

Tehtävä 3 (korjasi Vaakapallo, [email protected]):

Jokaisesta oikein selitetystä termistä 1/3 piste (15 termiä). Viimeinen piste tuli mietitystä etenemisestä termistä toiseen ja niiden koostamisesta fiksuiksi kokonaisuuksiksi.

Tehtävä 4 (korjasi Loezi, [email protected]):

Jokaisesta kohdasta 0, ½ tai 1p. Täysiin pisteisiin riittivät erittäin lyhyetkin vastaukset.

a) Definition of done on eksplisiittisesti kirjattu listaus asioista jotka vaatimuksen täytyy toteuttaa ennen kuin sen voidaan katsoa olevan valmis.

b) Arkkitehtuurimalli on hyväksi havaittu ja dokumentoitu malli toteuttaa ohjelmiston arkkitehtuuri erittäin yleisellä ja abstraktilla tasolla.

c) Inkrementaalinen arkkitehtuuri on toimintatapa jossa ohjelmiston arkkitehtuuria ei lyödä lukkoon projektin alussa, vaan sen annetaan kasvaa ja muuttua projektin edetessä jopa jo toteutettujen komponenttien osalta.

d) Suunnittelumalli on dokumentoitu ja hyväksi todettu ratkaisumalli johonkin yleiseen ohjelmointiongelmaan.

e) Minimal viable product on ohjelmiston versio joka sisältää vain kriittisimmät ydintoiminnallisuudet jotka vaaditaan (rajoitetuun) tuotantoon siirtämiseen.

f) Tekninen velka on metafora joka kuvaa ohjelmiston kehityksessä tehdyistä ratkaisuista myöhemmin seuraavaa refaktorointitarvetta: "muuten helppo feature on vaikea vanhan koodikannan takia".