Jarkko Järvenpää

Jarkko Järvenpää

Chief Sales Officer

jarkko.jarvenpaa@vincit.fi
+358 40 722 9656

TwitterLinkedIn

Kinastelin hiljan aiheesta, miten backlog tulisi muodostaa. Tulisiko sillä olla käyttötapauksia vai tehtäviä kehittäjän näkökulmasta, kuten esim. käyttöliittymän komponentti, rajapinta tai tietokanta. Oma näkemykseni on vahvasti käyttötapausten tai käyttäjätarinoiden puolella.

Pohjimmiltaan mielipiteeni juontaa ajatukseen, että ohjelmistoja ei koskaan tulisi kehittää ohjelmistokehityksen näkökulmasta. Lähtökohtana tulisi aina olla arvon tuottaminen käyttäjälle: ratkaisu käyttäjän ongelmaan tai toiminnan tehostaminen. Käyttötapaus mielestäni kuvastaa tätä näkökulmaa paremmin kuin muut lähestymistavat.

Lisäksi käyttötapaukset ohjaavat tekemään toiminnallisuuden kerrallaan, käyttöliittymästä tietokantaan asti. Tällöin toteutuksella on arvoa käyttäjän näkökulmasta toisin kuin vaikkapa yksittäisellä rajapinnalla. Käyttötapaus on myös kaikkien testattavissa ja arvioitavissa, mikä mahdollistaa palautteen saamisen. Se vuorostaan on elintärkeää ketterän kehityksen kannalta.

Tykkäsitkö artikkelista?

Anna pienet aplodit!

Kommentit

  • Marko Perälä

    Käyttötapaukset toimivat varmasti parhaiten sovelluksissa, joissa ohjelmistolla on käyttöliittymä ja kontrolloitava syöte (esim. UI MS-Word). Uusien ominaisuuksien kehittäminen onnistuu käyttäjän näkökulmasta ketterän kehityksen metodeilla tällöin hienosti. Homma kuitenkin tyssää siihen jos sovellukseksen toiminta ei juurikaan ole käyttäjän kontrolloitavissa, mutta taustalla voi olla hyvinkin monimutkainen järjestelmä. Tällöin ainoaksi vaihtoehdoksi jää kehittäjän näkökulmasta kehitys, jossa ohjelmistoa kehitetään ja testataan ilman suoranaista käyttötapausta. Hyviä esimerkkejä löytyy sulautettujen järjestelmien maailmasta, jossa olennainen osa ohjelmistokehitystä on monimutkaisten virhemekanismien testaaminen (virhetilanteiden, joita ei välttämättä ole edes mahdollista tuottaa muuten kuin ohjelmallisesti pakottamalla).

    • Jarkko Järvenpää Marko Perälä

      Hyvä pointti Markolta. Käyttötapaukset toimivat huomattavasti luontevammin, jos ohjelmistolla on käyttöliittymä.

      Vierastan kuitenkin ajatusta, että ohjelmistoja kehitetään ilman käyttötapauksia (oli ne sitten määritelty kirjallisesti tai ei). Miten ja kenelle ohjelmisto silloin tuottaa arvoa?

      Tietämättä nyt tarkalleen, mitä Marko tarkoittaa virhetilanteilla, voisin olettaa ei-toiminnallisten vaatimusten kuuluvan tähän kategoriaan. Esimerkkinä offline-tila meidän projekteissa.

      Mielestäni nämä ovat kuitenkin reunaehtoja käyttötapauksille tai syy tehdä erillinen käyttötapaus virhetilanteen varalle ja käyttötapauksen testaaminen ko. reunaehdoilla luonnollinen osa sen toteutusta.

      • Veikko Punkka Jarkko Järvenpää

        On erittäin mielenkiintoista kysyä, miten ja kenelle ohjelmisto tuottaa arvoa silloin kun sillä ei ole itsestään selvästi nimettävää käyttäjää. Lisäarvon saaja ei kuitenkaan ole ohjelmiston käyttäjä. Tällaisia ohjelmistoja on käytössä yhä enemmän yleistyvissä autonomisissa tai semiautonomisissa järjestelmissä. Konkreettisina esimerkkeinä mainittakoon vaikka Marsissa tälläkin hetkellä toimiva Curiosity luotain, matkapuhelinverkon tukiasemaohjain, vesikiertoisen patterilämmityksen shuntin säädin tai suihkumoneen moottorinohjausjärjestelmä koneen lentäessä autopilotin valvonnassa. Kaikki nämä järjestelmät sisältävät runsaasti ohjelmistoa. Kaikki ne reagoivat itsensä ulkopuolelta tuleviin ”syötteisiin” ja kaikki ne tuottavat toiminnallaan lisäarvoa jollekin. Nämä ulkopuolelta tulevat syötteet eivät vain tyypillisesti tule tulta lisäarvon saajalta. Keinotekoinen käyttötapausten tekeminen lisäarvon saajan näkökulmasta tekisi käyttötapauksista erittäin teennäisiä.

      • Jarkko Järvenpää Jarkko Järvenpää

        Kiitos Veikko hyvistä esimerkeistä. Itse näen mainitsemasi projektit hyvin ääripään projekteina. En ole varma sopiiko ketterä kehitys ylipäätään näihin projekteihin. Jo se, että ne ovat täysin sidoksissa ”rautaan” tekee niistä omanlaisensa. Saati sitten niiden poikkeukselliset vaatimukset turvallisuudelle ja käyttövarmuudelle. Itse asiassa käytän Curiosity luotainta hyvin usein esimerkkinä ohjelmistosta, johon meidän oppeja ei kannata soveltaa, kun olen käynyt puhumassa näistä aiheista.

  • Nimetön

    Meidän maailmassa sovelletaan kahdenlaista backlogia – on Product Backlog jossa on kuvattu User Story lähtöisesti kokonaisuutta ja sitten tiimillä on aina sprinttikohtainen Sprint Backlog, joka linkkautuu Product Backlogiin ja toimii tiimin Task Breakdown:na. Ja nämä luonnollisesti linkkautuvat yleisemmin koko elinkaarenhallintaan.

    • Kirjoituksessa mielessäni oli nimen omaan Product Backlog tällä jaottelulla. Olennaista on mielestäni se, että sprintin suunnittelu tehdään nimenomaan käyttötapauksilla ja vasta niiden valmistuminen tuottaa arvoa (ja esimerkiksi pisteitä).

      Keskustelussa, joka kirvoitti tämän kirjoituksen, haluttiin koko Product Backlog koostaa Sprint Backlogin tyyliin ”taskeista”.

      • Lauri Hahne Jarkko Järvenpää

        Kun tässä kerran ollaan tekemässä scrumia, niin vastaushan on hyvin selvä. Product backlog ei voi sisältää taskeja, sillä ominaisuuksien ja vaatimusten muuttaminen taskeiksi on tiimin vastuulla, kun taas product backlog on PO:n omaisuutta. Taskien laittaminen backlogiin on pikemminkin perinteistä projektinhallintaa, jossa koitetaan vaikuttaa lopputulokseen nakituksen kautta, eikä antamalla ihmisille vastuuta omista tekemisistään asettamalla tavoitteita.

        Jos tehdään esimerkiksi sulautettuja juttuja tai muita käyttöliityttömiä sovelluksia, niin se ei muuta tilannetta vaan product backlogin tulisi edelleen koostua ominaisuuksista tai vaatimuksista taskien sijaan. Mikäli product backlogiin alkaa kertyä taskeilta näyttäviä juttuja, niin tämä kertoo lähinnä siitä, että joko definition of donissa on korjaamisen tarvetta tai että vaatimukset eivät ole olleet tarpeeksi hyvin tiedossa toteutuksen alkaessa.

        Omasta mielestäni käyttötapauksiin rajoittuminen puolestaan tuo omat ongelmansa, sillä kaikkia vaatimuksia esimerkiksi virhetilanteiden osalta ei välttämättä ole mielekästä esittää käyttötapauksina. Lisäksi oikeasti arvoa tuottava tiimi kuitenkin tuntee loppukäyttäjän näkökulman yhtä hyvin kuin PO, jolloin varsinaisen käyttötapauksen kirjoittaminen auki ainoastaan product backlogia varten tuo ylimääräistä työtä ilman että asiakkaalle toimitettava arvo nousee.

        Mikäli tiimin oma ymmärrys loppukäyttäjän toiveista on sillä tasolla, että auki kirjoitetuista käyttötapauksista on iloa, niin tällöinkään käyttötapaukset eivät yleensä kerro asioista niin paljoa, että ne voisivat oikeasti korvata käyttäjän tekemisten ymmärtämistä. Tämä nyt ei kuitenkaan tarkoita, ettei product backlogia pitäisi miettiä joukkona käyttötapauksia ja muita asiakkaalle arvoa tuottavia juttuja, vaan koitan lähinnä kyseenalaistaa käyttötapausten auki kirjoittamisesta syntyvää arvoa.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *