Käytettävyyssuunnitelman toteuttaminen Scrum-prosessimallissa

Käytettävyyssuunnitelman toteuttaminen Scrum-prosessimallissa Linda Hellman Helsinki 04.03.2008 Pro gradu -tutkielma HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta/Osasto Fakultet/Sektion Faculty/Section Matemaattis-luonnontieteellinen tiedekunta Tekijä Författare Author Linda Marianne Hellman Laitos Institution Department Tietojenkäsittelytieteen laitos Työn nimi Arbetets titel Title Käytettävyyssuunnitelman toteuttaminen Scrum-prosessimallissa Oppiaine Läroämne Subject Tietojenkäsittelytiede Työn laji Arbetets art Level Pro Gradu Aika Datum Month and year 04.03.2008 Sivumäärä Sidoantal Number of pages Tiivistelmä Referat Abstract Tutkielmasuunnitelman tiivistelmä tulee tähän. ACM Computing Classification System (CCS): Avainsanat Nyckelord Keywords Ketterät prosessit, käytettävyys Säilytyspaikka Förvaringställe Where deposited Muita tietoja Övriga uppgifter Additional information

i Sisällysluettelo 1 Johdanto... 1 2 Käytettävyys ketterissä prosesseissa... 1 2.1 Käytettävyyden suunnittelu ja toteutus... 1 2.1.1 Käytettävyyden piirteet... 2 2.1.2 Käytettävyyssuunnittelusta toteutukseen... 3 2.2 Ketterät prosessimallit... 3 2.2.1 Scrum... 4 2.2.2 extreme Programming... 8 2.3 Käytettävyyssuunnittelun lisäys ketteriin prosessimalleihin... 10 3 Käytettävyys osana Scrum-prosessimallia... 10 3.1 Vaatimusten määrittely... 10 3.2 Käytettävyyden huomioiminen sprintissä ja projektissa... 10 3.3 Käyttöliittymien abstraktiotaso ja sisältö... 10 3.4 Vastuu käytettävyydestä ja käytettävyysasiantuntija... 10 4 Tutkimuksen tausta, tutkimusmenetelmät ja toteutus... 10 5 Tutkimuksen tulokset... 10 6 Tutkimustulosten analysointi ja johtopäätökset... 11 7 Yhteenveto... 11 Lähteet... 11

1 1 Johdanto Käytettävyyden suunnittelun tärkeys ja ketterät prosessimallit ovat molemmat kehittyneet vauhdilla 90-luvusta lähtien. Yhtäläisyyksiä näillä kahdella prosessimallilla on se, että ne ovat molemmat iteratiivisia ja inkrementaalisia. Kuitenkaan niiden yhdistämistä samaan prosessiin ei ole paljoakaan tutkittu. Ketterissä prosesseissa kaikkia vaatimuksia ei tiedetä projektin alussa ja muuttuvat vaatimukset ovat tavallisia ja niihin pitää pystyä reagoimaan. Käytetttävyyssuunnittelussa vaatimukset täytyy olla tiedossa ennen suunnittelua, jotta voidaan heti alusta alkaen suunnitella toimiva käyttöliittymä ja sen pohjalta toimiva tuote. Käytettävyyssuunnittelussa on tärkeää ottaa huomioon suunnitelman formaatti ja sisältö, jotta kehittäjien on iteraatioiden aikana helppoa ja nopeaa toteuttaa käytettävyyssuunnitelman mukaista tuotetta. Seuraavat luvut on jaoteltu siten, että luvussa 2 esitellään yleisesti ketterät prosessit, erityisesti Scrum, ja käytettävyyteen liittyviä perusteita. Luvun lopussa tutkaillaan miten käytettävyys soveltuu yhteen ketterien prosessimallien kanssa. Luvussa 3 keskitytään kehittämään Scrumprosessimallia siten, että käytettävyyssuunnittelusta tulee luonnollinen osa mallia. Lopuissa luvuissa kerrotaan empiirisestä tutkimuksesta. Luvussa 4 esitellään tutkimuksen tausta, menetelmä ja ympäristö, jossa tutkimus toteutetaan. Luvussa 5 käydään läpi miten tutkimus on tehty ja millaisia tuloksia siitä saatiin. Luvussa 6 analysoidaan tuloksia ja viimeisenä luku 7 on yhteenveto. 2 Käytettävyys ketterissä prosesseissa 2.1 Käytettävyyden suunnittelu ja toteutus Käytettävyyden suunnittelu kehitettävälle tuotteelle on tärkeää projektin alusta lähtien. Valmista, mutta käyttökelvotonta tuotetta ei osta eikä käytä kukaan. Jotta tuotetta haluaa joku käyttää, sen täytyy sisältää tarvitut toiminnallisuudet ja sen lisäksi tuotteen täytyy olla käytettävä. Toiminnallisuudet kirjataan vaatimusmäärittelyyn vaatimuksiksi ja käytettävyyssuunnittelun tarkoitus on löytää järkevät työnkulut halutuille toiminnallisuuksille. Käytettävyyssuunnittelu varmistaa sen, että tuotteen eri osa-alueet toimivat samankaltaisesti ja että ulkonäkö on koko tuotteessa samanlainen. Kun käytettävyyssuunnittelu aloitetaan heti projektin alussa, saadaan nopeasti asiakkaalle ensimmäisiä paperiversioita käyttöliittymän ulkonäöstä. Näin asiakas pääsee heti projektin alussa arvioimaan tuotteen toiminnallisuuksia sekä käytettävyyttä eikä ikäviä yllätyksiä pääse syntymään. Käytettävyyssuunnittelun alussa käytettävyydelle täytyy määritellä vaatimukset, joiden perusteella käyttöliittymää pystyy testaamaan. Tällaisia yleisiä piirteitä käytettävyydelle on esittänyt esimerkiksi Nielsen [Nie93b]. Käyttöliittymiä aletaan testata heti, kun paperiversiot käyttöliittymistä on

2 saatu valmiiksi. Testausmenetelmiä on useita ja ne voidaan jakaa karkeasti kahteen osaan, testit joissa käyttäjä on mukana tai testit, jotka suorittaa käytettävyysasiantuntija. 2.1.1 Käytettävyyden piirteet Eräs tapa määritellä käytettävyys on kuvata sitä erilaisilla piirteillä [GoL85]. Käyttöliittymän tulee toteuttaa näiden piirteiden vaatimat määritelmät, jotta se olisi käytettävä. Nielsen [Nie93b] on määritellyt käytettävyydelle viisi piirrettä (kuva 1). Kuva 1 Käytettävyyden piirteet [Nie93b] Jos käyttöliittymässä opittavuus on kunnossa, käyttäjän on helppo oppia sen käyttö ja käyttöliittymä tuntuu intuitiiviselta. Käyttöliittymä ohjaa uutta käyttäjää käyttämään toimintoja oikein. Käyttöliittymän tehokkuutta mitataan erilaisten painallusten määränä jonkin toiminnallisuuden läpikäymisessä. Pieni määrä painalluksia viittaa hyvään tehokkuuteen. Siihen liittyy myös erilaisten näyttöjen välillä siirtyminen ja käyttäjän muistikapasiteetin täyttyminen. Käyttöliittymä alkaa muuttua tehottomaksi, jos käyttäjä unohtaa painamiaan painikkeita ja joutuu palaamaan tehtävässään takaisinpäin. Muistettavuuden toteutus on onnistunut silloin, jos käyttäjä osaa käyttää ohjelmaa toisella käyttökerralla tai pitkän tauon jälkeen. Käyttäjän ei pitäisi täytyä opettelemaan ohjelman käyttöä joka kerta uudestaan. Ohjelmiston virhealttius kertoo siitä, miten ohjelma toipuu virheistä ja miten ne näytetään käyttäjälle. Käyttöliittymä ei saisi houkutella käyttäjää painamaan väärää nappia, mutta jos käyttäjän toiminta silti aiheuttaa virheellisen tilanteen, käyttöliittymän pitäisi pystyä selkeästi virhe kertomaan ja mahdollisuuksien mukaan palautumaan tilaan, josta käyttäjä voi jatkaa ohjelman käyttöä. Viimeisenä piirteenä on tyytyväisyys. Ohjelman käytön pitää olla miellyttävää, jotta käyttäjä jaksaa ja haluaa sitä käyttää. Tyytyväisyyteen liittyy käyttöliittymän ulkonäköön liittyvät asiat. Esimerkiksi käyttöliittymän värimaailman pitää olla sopusointuinen eikä ruudulla saa olla vilkkuvia tai liikkuvia kuvia.

3 2.1.2 Käytettävyyssuunnittelusta toteutukseen Ohjelmiston käytettävyys suunnitellaan iteratiivisesti ja inkrementaalisesti. Kuten kuvassa 2 esitetään, käytettävyyttä parannetaan jatkuvasti iteraatioissa. Suunnittelun alussa käyttöliittymissä korjataan isompia käytettävyys- ja toimivuusongelmia, kuten vuorovaikutukseen liittyviä virheitä. Näin saadaan parannettua käyttöliittymän tehokkuutta. Kun ohjelmiston yleinen käyttölogiikka on valmis, käytettävyyssuunnittelussa keskitytään käyttöliittymän ulkoasun hiomiseen, johon sisältyy käyttöliittymän komponenttien valinta ja graafinen ulkoasu. Kuva 2 Käytettävyyden ja suunnitteluiteraatioiden suhde [Nie93a] Erilaisia tapoja suunnitella käyttöliittymää ja sen käytettävyyttä on useita. Käytettävyyden ja oikeanlaisten toiminnallisuuksien kannalta käyttäjäkeskeinen suunnittelu (user-centered design) tuottaa toimivan ratkaisuehdotuksen. Käyttäjäkeskeisiä suunnitteluprosesseja on esimerkiksi Holtzblattin kontekstuaalinen suunnittelu (contextual design) ja Cooperin tavoitepohjainen suunnittelu (Goal- Directed Design) [CRC07]. Näistä suunnitteluprosesseista lopputuloksena on yleensä kuva käyttöliittymästä. Tämän kuvan perusteella kehittäjän pitäisi pystyä toteuttamaan käyttöliittymä käytännössä siten, että kuvaan suunniteltu toimintokulku ja käytettävyys säilyvät. 2.2 Ketterät prosessimallit Ketterät prosessimallit ovat kehittyneet 90-luvulla vastaamaan tarpeeseen saada ohjelmistokehitysprosessit ajallaan ja suunnitellulla budjetillaan läpi. Perinteinen vesiputousmalli [Broo82] ei enää toiminut, kun tuotteiden vaatimukset vaihtuivat muuttuvassa maailmassa. Projektin alussa on vaikea tietää kaikkia vaatimuksia eikä asiakaskaan tiedä aina mitä tuotteelta tarvitsee. Ketterissä pro-

4 sessimalleissa ohjelmistoa kehitetään iteratiivisesti ja inkrementaalisesti, eli tuote valmistuu pala kerrallaan eikä kaikkea edes yritetä saada kerralla valmiiksi [HiC01]. Ketterissä prosesseissa asiakas pääsee iteraation jälkeen aina tutustumaan valmistumassa olevaan tuotteeseen ja näin estetään vääränlaisen tuotteen syntyminen ja edistetään halutun tuotteen valmistumista. Erilaisia ketteriä prosessimalleja on useita, kuten Scrum, extreme Programming (XP), Crystal ja DSDM, joista tässä tutkielmassa keskitytään Scrum-prosessimalliin ja jonkin verran XP-malliin [ASR02]. Ketterät prosessimallit ovat alkaneet yleistyä 2000-luvulla kaikenkokoiseen ja tyyppisiin yrityksiin. Yritykset hakevat ketteristä prosessimalleista ratkaisua jatkuvasti muuttuvan maailman ja vaikeampien ohjelmistojen aiheuttamaan ongelmaan. Ketterät prosessit eivät kuitenkaan ole täysin ongelmattomia eivätkä ratkaise ohjelmistotuotannon haasteita. Ketterät prosessit painottavat kehittäjien ammattilaisuutta ja taitavuutta, mikä ei välttämättä jokaisessa projektissa toteudu. Suuriin projekteihin ihan kaikki ketterät prosessit eivät taivu, koska monet niistä ovat suunniteltu pieniin ja nopeisiin projekteihin ja alle 10 hengen tiimeille. [Som04] Ketteriä prosessimalleja yhdistää Agile Manifestossa [AGI01] esitetyt teesit. Ensimmäisen teesin mukaan ketterissä prosessimalleissa arvostetaan yksilöitä ja yhteydenpitoa enemmän kuin prosesseja ja työvälineitä. Tällä halutaan varmistaa, että tieto liikkuu nopeasti ja suoraa tiimin sisällä ja sidosryhmien välillä. Toisessa teesissä todetaan, että toimiva ohjelmisto on arvokkaampi kuin täydellinen dokumentaatio. Vesiputousmalli ja muut dokumentaatioon painottuvat prosessimallit eroavat suuresti tässä suhteessa ketteristä prosesseista. Toimiva ohjelmisto on ketterien prosessien lähtökohta, mutta dokumentointia ei kuitenkaan saa ketterissäkään prosesseissa unohtaa. Kolmantena teesinä on aito asiakasyhteistyö tärkeämmäksi kuin sopimusneuvottelut. Asiakas on tärkeässä roolissa lopputuotteen onnistumisen kannalta, koska asiakkaan pitää kuitenkin lopulta hyväksyä tuote ennen käyttöönottoa eikä kaikkea mahdollista tietoa voida kirjoittaa sopimuksiin. Sopeutuminen ja vastaaminen muutoksiin on viimeisen teesin ydin. Suunnitelmaa ei kannata pakolla seurata, jos vaatimukset muuttuvat projektin aikana. Lopputulosta ei välttämättä halua kukaan, jos projektin kuluessa ei muutoksiin pystytä vastaamaan. 2.2.1 Scrum Scrumin kehitys on alkanut vuonna 1993 Jeff Sutherlandin ja Ken Schwaberin alkaessa omissa yrityksissään kehittää jotain parempaa ja tehokkaampaa tapaa tehdä ohjelmistoja. Scrum [ScB02, Sut04] on suunniteltu erityisesti hallinnolliseksi prosessimalliksi, joka tarjoaa ohjeita ja välineitä prosessin seuraamiseen. Scrum ei niinkään ota kantaa miten ja millä välineillä ohjelmisto itsessään pitäisi toteuttaa. Scrumissa tärkeää on se, että päätösvalta omaan tekemiseensä on projektiryhmän jäsenille. He saavat itse päättää mitä tekevät ja milloin tekevät, ilman että muut sidosryhmät pääsisivät häiritsemään heidän työskentelyään. Scrum on suunniteltu pienille ryhmille, noin 6-9 hengen

5 ryhmille, joissa kommunikaatio on sujuvaa tiimin sisällä. Jos tiimissä on enemmän henkilöitä kuin mikä on Scrumin ryhmäkoko, kannattaa silloin tehdä useampia Scrum tiimejä. Ryhmäkoolla on merkitystä Scrum-prosessissa, koska se on yksi keino, jolla halutaan varmistaa tiimin sisäinen kommunikaatio ja yhteistyö [Sut05]. Kuva 3 Scrum Prosessimalli [Sut04] Kuvassa 3 on Scrumin prosessimalli. Prosessin perusta on tuote backlog (Product Backlog), joka sisältää listan tuotteeseen liittyvistä vaatimuksista. Tuote backlog on tarkoitettu julkiseksi listaksi, johon kuka tahansa projektiin liittyvä taho voi lisätä haluamiaan vaatimuksia. Tätä listaa kehitetään jatkuvasti projektin kuluessa eikä se ole valmis missään vaiheessa. Kuitenkin vain tuotteen omistaja (Product Owner) saa priorisoida vaatimuslistaa. Vaatimuslista on jatkuvassa muutoksessa ja sitä on tarkoitus priorisoida ja muokata uudelleen usein. Yleensä tuotteen omistaja on projektissa kehitettävän tuotteen tuotepäällikkö, joka vastaa tuotteen lopullisesta muodosta ja sisällöstä. Tuotteen omistaja on myös vastuussa asiakasyhteistyöstä ja vaatimuksista, jotka tulevat asiakkailta. [RiJ00] Scrum-prosessimallissa yhtä iteraatiota kutsutaan sprintiksi ja sen pituus on enintään 30 päivää. Kun sprinttiä lähdetään suunnittelemaan, valitaan ensin tuote backlogista korkeimmin priorisoituja vaatimuksia sprintinbacklogiin (Sprint Backlogiin). Tärkeimpiä vaatimuksia valitaan sprintin backlogiin sen verran, mitä yhdessä sprintissä ehtii saada valmiiksi. Ennen sprintin alkua pidetään sprintin suunnittelukokous, johon osallistuvat Scrum tiimiin osallistuvat työntekijät. Suunnittelukokouksessa sovitaan sprintin tavoite mitä halutaan saada valmiiksi ja käydään läpi vaatimukset, jotka valitaan seuraavan sprintin toteutuslistalle. Kokouksessa on tärkeää, että jokainen tiimiläinen saa itse valita tehtävät, jotka aikoo tehdä seuraavan sprintin kuluessa. Tiimin itsenäisyys ja omatoimisuus on Scrumin ideologian pääperiaatteita, jotka kannustavat tiimiläisiä ottamaan haasteita ja vastuuta omasta tekemisestään. Tuote backlog ja sprintin backlog eroavat toisistaan siten, että tuote backlogissa vaatimukset ovat yleisemmällä tasolla ja joukossa on myös ei-toiminnallisia vaatimuksia, kun taas sprintin backlogissa vaatimukset pilkotaan pienempiin osiin, jotka on helppo hahmottaa ja joille on helpompi antaa työmääräarviot. Esimerkiksi, jos tuote backlogissa on vaatimus

6 Kuukausiraportin näyttö, tämä pilkotaan sprintin backlogiin pienemmiksi vaatimuksiksi, kuten raportin pohjan teko, perustietojen haku raportille ja raportin tulostus. Sprintin käynnistyessä alkavat päivittäiset Scrum-palaverit. Näiden palaverien tarkoitus on seurata projektia ja jakaa tietoa tiimin sisällä. Scrum-palaverissa tärkein rooli on Scrum mestarilla (ScrumMaster). Scrum mestari on Scrum tiimin vetäjä projektissa. Scrum mestarin tehtävä on projektipäälliköllä tai tuotekehityspäälliköllä. Tärkeää kuitenkin Scrum mestarin tehtävässä on, että tehtäväänvalitulla on valtaa tehdä nopeita päätöksiä itsenäisesti. Scrum-palavereissa Scrum mestarin on kokouksen puheenjohtaja. Palaveri on erittäin tarkoin määritelty. Sen kesto saa enintään olla 15-30 minuuttia, se pidetään joka päivä samaan aikaan ja samassa paikassa sekä sallitut puhujat kokouksessa ovat tiimiläiset. Kaikki sidosryhmät saavat osallistua kokoukseen, mutta heillä on lupa ainoastaan kuunnella. Scrum-palaverissa jokainen tiimiläinen vastaa seuraaviin kolmeen kysymykseen, mitä tein eilisen kokouksen jälkeen, mitä aion tehdä tänään ennen huomista kokousta ja mitä esteitä minulla on tehtävien suorittamisessa. Scrum mestari pystyy näiden kokousten avulla seuraamaan sprintin etenemistä. Sprintin tehtävien etenemistä seurataan burn-down kaaviolla (kuva 4), jonka avulla nähdään miten paljon sprintti on edellä tai jäljessä optimaalista toteutusaikataulua. Kuvassa 4 alempi viiva kuvaa suunnitelmaa, jonka mukaan tehtävien pitäisi edetä, jotta sprintin lopussa kaikki tehtävät olisivat valmiita. Ylempi viiva kuvaa toteutunutta tilannetta sprintissä. Kuvan tilanteessa 40% tehtävistä jäi joko suorittamatta tai kesken. Tärkein tehtävä Scrum mestarilla sprintissä on kokouksissa ilmenevien esteiden poistaminen. Esteet voivat liittyä laitteisiin, tiimityöhön tai tuotteeseen ja Scrum mestarilla täytyy pystyä tekemään nopeita päätöksiä, jotta sprint ei esteiden takia hidastu. Scrum-palaverissa ei ole tarkoitus alkaa keskustelemaan mistään ohjelmointiteknisistä ratkaisuista, jos sellaisia tiimiläisillä on, vaan palaverin tarkoitus on vain välittää tietoa muille. Kokouksen jälkeen tiimiläiset voivat keskustella tehtävien toteutukseen liittyvistä ongelmista.

7 Kuva 4 Burn-down kaavio Sprintin kuluessa Scrum tiimi toteuttaa sprint backlogiin valittuja tehtäviä eikä kenelläkään sidosryhmän jäsenellä ole lupaa tulla suoraan tiimiläisten luo vaatimaan uusien toiminnallisuuksien toteuttamista heti. Kaikki uudet vaatimukset täytyy ensin laittaa tuotteen backlogiin, josta sitten tuotteen omistaja niitä voi priorisoida. Ainoastaan tuotteen omistaja voi kesken sprintin erittäin hyvällä syyllä vaihtaa sprint backlogin sisältöä. Sprintin loputtua Scrum-prosessissa on sprintin kastelmointi -kokous, jossa paikalla ovat tiimiläiset sekä edustajia kaikista sidosryhmistä. Näissä kokouksissa tiimiläiset esittävät valmiiksi saamansa osat ja sidosryhmien edustajat saavat kommentoida tuotosta. Katselmointi-kokouksilla on tärkeä rooli prosessissa, koska se on ainut paikka, jossa varmistetaan että tekeillä oleva tuote on varmasti sellainen, jota asiakas haluaa. Jos katselmointikokouksessa ilmenee puutteita tuotteessa tai tuote ei toimi halutulla tavalla, tallennetaan muutospyynnöt ensin tuotteen backlogiin, ja vasta sen jälkeen ne voivat tulla tiimiläisille uudestaan toteutettavaksi. [Sch97] Scrumin on sanottu olevan tehokas siitä syystä, että se keskittyy tiimityöskentelyyn. Prosessi korostetaan ja kannustetaan tiimiläisten omaa vastuuta ja omia päätöksiä. Sprintin aikana kukaan ei tule tiimiä häiritsemään työnteossa ja näin he saavat rauhassa keskittyä toteuttamaan vaadittavia tehtäviä. Koska tiimiläisten ei tarvitse käyttää aikaansa työtä estävien toimintojen poistamiseen, kaiken

8 sprintin ajan pystyy käyttämään tehokkaasti kehittämiseen. Scrum mestarilla on tärkeä rooli pitää huolta siitä, että esteitä ei ole. Scrum ei ota mitenkään kantaa siihen, miten työtä käytännössä tehdään vaan tarjoaa välineet projektin seuraamiseen ja hallintaan. Scrum-prosessiin voi ja on helppo integroida käytäntöjä, jotka tukevat tehtävien suorittamista ja ryhmätyötä. Näitä käytäntöjä voidaan ottaa muista ketteristä prosesseista, kuten extreme Programming (XP)-prosessimallista. 2.2.2 extreme Programming Ketterä prosessimalli extreme Programming (XP) [Bec99] on kehitetty 90-luvun loppupuolella vastaamaan muuttuvien vaatimusten ja toimimattomien tuotteiden aiheuttamaan ongelmaan. XP:n kehittäjä on Kent Beck, joka on yksi Agile Manifeston alkuperäisistä allekirjoittajista. Toisin kuin Scrum, XP painottaa ja ohjeistaa erilaisten menetelmien käyttöä prosessissa. XP perustuu viiteen erilaiseen arvoon. Ensimmäinen arvoista on kommunikaation tärkeys kehitystiimin sisällä. Toinen arvo on yksinkertaisuus, jolla pyritään siihen, että toteutettu ratkaisu on aina yksinkertaisin. Tähän arvoon liittyy refaktorointi, joka on tärkeää XP:ssä. Kuka vain voi milloin vain refaktoroida koodia, jos siihen löytyy yksinkertaisempi ratkaisu. Palaute on kolmas arvo. Palautetta tulee asiakkaalta jatkuvasti, tiimin sisällä kommunikaation yhteydessä sekä koodia yksikkötestatessa. Palaute liittyy vahvasti kommunikaatioon. Neljäs arvo on rohkeus, joka merkitsee sitä, että uskaltaa kehittää yksinkertaisinta ratkaisua ja refaktoroida vapaasti toisen koodia paremman tuloksen syntymiseksi. Viimeinen arvo luottamus yhdistää kaikki edelliset arvot. Luottamus ilmenee tiimin sisäisenä luottamuksena, jolloin luotetaan muiden tekemän koodin luotettavuuteen, ja asiakkaiden ja tiimin luottamukseen, jolloin asiakas aidosti on tiimissä mukana kehittämässä vaatimuksia tuotteelle. Kuva 5 XP prosessimalli [mukaeltu Bec99]

9 XP (kuva 5) koostuu 13 erilaisesta käytännöstä, jotka ohjeistavat projektin kulkua. Projekti ja jokainen iteraatio alkavat suunnittelupelillä (planning game), jossa asiakas määrittelee käyttäjäkertomuksia (user stories) ja päättää mitkä kertomukset haluaa kehitystiimin toteutettavaksi seuraavan iteraation ajaksi. Hyvä käyttäjäkertomus on tavoitepohjainen vaatimus, johon liittyy liiketoimintanäkökulma. Käyttäjäkertomus täytyy olla niin tarkasti määritelty, että sen pohjalta pystyy antamaan aikatauluarvion kertomuksen toteutuksesta. Suunnittelupelin aikana asiakas ja kehitystiimi määrittelevät metaforat, jotka kuvaavat järjestelmän arkkitehtuurista muotoa, jonka pohjalta järjestelmää lähdetään kehittämään.. Vain käyttäjäkertomuksissa määritellyt toiminnallisuudet saa toteuttaa iteraation aikana. Asiakas on tiivisti mukana kehitystiimin päivittäisessä työskentelyssä varmistamassa, että tuotteesta tulee halutunlainen ja että se vastaa vaatimuksia. Iteraation aikana kehitystiimi lähtee liikkeelle yksikkötestien tekemisestä. Kaikille toiminnallisuuksille XP:ssä pitää olla omat yksikkötestit, joilla tulevaa koodia voidaan saman tien testata. Ensimmäiset yksikkötestit tehdään käyttäjäkertomuksen pohjalta. Jatkuva testaus varmistaa sen, että koodia voidaan integroida kokoajan lopulliseen tuotteeseen ja tuote toimii silti. Yksikkötestaus ja testiorientoitunut näkökulma on XP-prosessimallin ydin. Testausta eri tasoilla suositellaan tehtäväksi jatkuvasti. Iteraation aikana asiakas tekee toiminnallisia testejä tuotteelle ja niiden avulla testaa tuotteen toimivuutta. XP:ssä kannustetaan käyttämään mahdollisimman yksinkertaista koodia, jota on helppo myöhemmin muokata. Tähän tavoitteeseen päästään pariohjelmoinnilla, jossa kaksi kehittäjää istuu saman tietokoneen ruudun äärellä kirjoittamassa yhdessä koodia. Pariohjelmointi nopeuttaa uusien kehittäjien integroitumisen tiimiin. Koska kaksi kehittäjää näkee saman koodin ruudulla, koodi tulee katselmoitua samalla, kun sitä kirjoitetaan. Pariohjelmointi tukee myös refaktorointia ja koodin yhteistä omistajuutta. Refaktorointia on tarkoitus tehdä jatkuvasti ja kenen tahansa tiimiläisen toimesta. XP painottaa koodin uudelleenkäytettävyyttä ja yksinkertaisuutta kannustamalla koko tiimiä huolehtimaan koodin laadusta. XP:ssä on myös käytännön asioihin liittyviä sääntöjä. Suositus on, että työviikko ei saa olla pidempi kuin 40 tuntia. Ylityöt koetaan XP:ssä haitallisina ja merkkinä ongelmista, jotka täytyy ratkoa muuten kuin ylitöitä tekemällä. Toinen käytännön sääntö on, että tiimin tulisi työskennellä avoimessa työtilassa, jossa jokaisen on helppo keskustella ja vaihtaa ajatuksia. XP:n käytännöissä todetaan, että edellä mainitut käytännöt ovat kuitenkin ainoastaan sääntöjä, joita voi ja pitää muokata tarpeeseen ja projektiin sopivaksi. Niitä ei kannata noudattaa orjallisesti, vaan tiimi voi yhteisellä päätöksellä muokata käytäntöjä. XP:ssä on paljon erilaisia käytäntöjä, jotka tehostavat projektia. XP ei kuitenkaan tarjoa mitään projektinhallintaan ja seurantaan liittyviä välineitä, jotka varmistaisivat projektin tehostumisen onnistumisen. Toisaalta XP:n käytäntöjen käyttöönotto kokonaisuudessaan voi helposti epäonnistua. XP:n onnistuminen vaatii tiimiltä sekä asiakkaalta paljon. Tiimin täytyy toimia yhdessä erittäin hyvin ja kommunikaation on luonnistuttava, jotta pariohjelmointi onnistuisi odotuksien mukaisesti.

10 Asiakkaalla on suuri rooli XP-projektin onnistumisessa. Jos asiakkaalla ei olekaan aikaa projektille, kukaan ei ole ohjaamassa kehitystiimiä oikeaan suuntaan. Scrum-prosessimalli, joka tarjoaa välineet projektinhallintaan, yhdessä XP-prosessimallin kanssa helpottaa XP:n käytäntöjen integroimista tiimiin. Scrum-prosessiin voi valita tarpeeseen parhaiten sopivat XP:n käytännöt ja yhdistää ne Scrum-prosessiin. Scrum mestarin vastuulla on huolehtia tiimin toimivuus ja auttaa käytäntöjen käyttöönotossa. Yksi suuri eroavaisuus prosessimallien välillä on vastuun jakautuminen kehitystiimin ja asiakkaan välillä. XP-mallissa kaikki vastuu on asiakkaalla ja asiakas päättää seuraavan iteraation toteutettavat toiminnallisuudet. Scrum-mallissa kaikki vaatimukset kerätään tuotteen backlogiin, jota ainoastaan tuotteen omistaja saa priorisoida, ja backlogista kehittäjät saavat itse valita haluamansa tehtävät seuraavaan iteraatioon. - *** 2.3 Käytettävyyssuunnittelun lisäys ketteriin prosessimalleihin 3 Käytettävyys osana Scrum-prosessimallia 3.1 Vaatimusten määrittely - *** - *** - *** - *** - *** - *** 3.2 Käytettävyyden huomioiminen sprintissä ja projektissa 3.3 Käyttöliittymien abstraktiotaso ja sisältö 3.4 Vastuu käytettävyydestä ja käytettävyysasiantuntija 4 Tutkimuksen tausta, tutkimusmenetelmät ja toteutus 5 Tutkimuksen tulokset

11 - *** 6 Tutkimustulosten analysointi ja johtopäätökset 7 Yhteenveto Ketterät prosessimallit perinteisesti mielletään keveiksi prosesseiksi, jotka ratkaisevat ohjelmistokehityksen ongelmat sekä väheksyvät etukäteen suunnittelua ja dokumentointia. Projektit tarvitsevat kuitenkin jonkinasteista suunnittelua ja dokumentointia, jotta lopputulos olisi eheä ja yhtenäinen. Ketterien prosessimallien iteratiivisuus ja inkrementaalisuus tukevat halutunlaisen lopputuloksen syntymistä, koska seuraavaan iteraation siirryttäessä voidaan vaatimuksia priorisoida uudestaan ja uusia vaatimuksia ottaa tuotantoon. Ketterien prosessien näkökulmasta käytettävyyssuunnitteluprosessi on edustanut pitkää etukäteissuunnittelua ennen varsinaisen tuotekehityksen alkua. Kuitenkin myös käytettävyyssuunnittelua toteutetaan iteratiivisesti ja inkrementaalisesti sekä lähellä asiakasta. Käytettävyyssuunnittelun iteraatiot ovat vain lyhyempi kuin ketterien prosessien iteraatiot. Näiden kahden prosessin yhdistämisessä on monia haasteita, mutta lopputuloksena voidaan saada aidosti toimiva tuote, joka julkaistaan aikataulussa ja suunnitellussa budjetissaan. Lähteet AGI01 AbS07 ASR02 Bak05 Bak06 Bec99 BDS02 The Agile Manifesto. [http://agilemanifesto.org/] Abrahamsson, P., Salo, O., An Iterative Improvement Process for Agile Software Development. Software Process: Improvement and Practice, Vol. 12 No. 1, Tammikuu 2007, sivut 81-100. Abrahamsson, P., Salo, O., Ronkainen, J., Warsta J., Agile software development methods, review and analysis. Otamedia Oy, Espoo, 2002. [http://oasis.oulu.fi/publications/vtt-pa.pdf] Baker, S., W., Formalizing Agility: An Agile Organization s Journey toward CMMI Accreditation. Proceedings of the Agile Development Conference (ADC 05), 2005. Baker, S., W., Formalizing Agility, Part 2: How an Agile Organization Embraced the CMMI. Proceedings of AGILE 2006 Conference (AGILE 06), 2006. Beck, K., Embracing Change with Extreme Programming. IEEE Computer, Lokakuu 1999, sivut 70-77. Birk, A., Dingsøyr, T., Stålhane, T., Postmortem: Never Leave a Project without It. IEEE Software, sivut 43-45, touko-kesäkuu 2002.

12 Broo82 CDF96 CoL03 Con01 CRC07 FNB07 Gla02 GoL85 HiC01 Hod05 Hol05 Hum90 Brooks, F. P. Jr., The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 1982. Collier, B., DeMarco, T., Fearey, P., A Defined Process For Project Postmortem Review, vol. 13, no. 4, sivut 65-72, heinä elokuu 1996. Constantine L. L., Lockwood L. A. D., Usage-Centered Software Engineering: An Agile Approach to Integrating Users, User Interfaces, and Usability into Software Engineering Practice. Proceedings of the 25 th International Conference on Software Engineering (ICSE 03), 2003. Constantine, L., L., Process Agility and Software Usability: Toward Lightweight Usage-Centereed Design, Software Developments, kesäkuu 2001. Cooper A., Reinmann R. ja Cronin D., About Face 3. The Essentials of Interaction Design. Wiley Publishing, Inc., Indianapolis, Indiana, 2007. Ferreira J., Noble J., Biddle R., Agile Development Iterations and UI Design, AGILE 2007, Washington, USA, Elokuu 2007. Glass, R., L., Project Retrospectives, and Why They Never Happen, IEEE Software, sivut 111-112, syys-lokakuu 2002. Gould J. D., Lewis, C., Designing for Usability: Key Principles and What Designers Think. Communications of the ACM, Vol 28, No 3, Maaliskuu 1985. [http://portal.acm.org/ft_gateway.cfm?id=3170&type=pdf&coll=guide&dl=&cfi D=15792794&CFTOKEN=90873413] Highsmith J., Cockburn A., Agile Software Development: The Business of Innovation, Computer, sivut 120-122, Syyskuu 2001. Hodgetts, P., Experiences Integrating Sophisticated User Experience Design Practices into Agile Processes. Proceedings of the Agile Development Conference (ADC 05), 2005. Holzinger, A., Usability Engineering Methods for Software Developers. Communications of the ACM Vol. 48, No. 1, Tammikuu 2005. Humphrey, W. S., Managing the Software Process. Addison-Wesley Publishing Company, Inc., 1990.

13 Kan03 Kane, D., Finding a Place for Discount Usability Engineering in Agile Development: Throwing Down the Gauntlet. Proceedings of the Agile Development Conference (ADC 03), 2003. Laa04 Laakso, S. A., Hyvän käyttöliittymän varmistaminen GUIDe-prosessimallilla, 2004. [http://www.cs.helsinki.fi/u/salaakso/papers/guide-suomeksi.pdf] LaL06 LeM07 MeA06 Nie92a Nie92b Laakso, S. A., Latva-Koivisto A., Käyttöliittymät 2006. Luentomoniste, Helsingin yliopisto, tietojenkäsittelytieteenlaitos, sarja D-2006-1, 2006. [http://www.cs.helsinki.fi/u/salaakso/papers/kayttoliittymat-opetusmoniste- 2006.pdf] Lee, J. C., McCrickard, D. S., Towards Extreme(ly) Usable Software: Exploring Tensions Between Usability and Agile Software Development. AGILE 2007, Washington, USA, sivut 59-71, Elokuu 2007. Meszaros, G., Aston, J., Adding Usability Testing to an Agile Project. Proceedings of AGILE 2006 Conference, Heinäkuu 2006. Nielsen, J., The Usability Engineering Life Cycle. Computer, Vol. 25, No. 3, Maaliskuu 1992. Nielsen, J., Finding Usability Problems Through Heuristic Evaluation. Conference on Human Factors in Computing Systems, Monterey, California, 1992. [http://portal.acm.org/ft_gateway.cfm?id=142834&type=pdf&coll=guide&dl=gu IDE&CFID=54354479&CFTOKEN=91151734] Nie93a Nielsen, J., Iterative User-Interface Design. Computer, Marraskuu 1993. Nie93b Nielsen, J., Usability Engineering. Academic Press, 1993. Nie94 NiM90 Nielsen, J., Enhancing the Explanatory Power of Usability Heuristics., Human factors in Computing Systems, CHI 94, Boston, MA, 1994. [http://delivery.acm.org/10.1145/200000/191729/p152- nielsen.pdf?key1=191729&key2=6807662021&coll=guide&dl=guide&cfid=1579 2828&CFTOKEN=32555239] Nielsen, J., Molich, R., Heuristic Evaluation of User Interfaces, CHI 90 Proceedings, Huhtikuu, 1990. Rii98 Riihiaho, S., Käytettävyyden arviointi ilman käyttäjiä. Systeemityö 4/1998. [http://www.pcuf.fi/sytyke/lehti/kirj/st19984/04.pdf]

14 RiJ00 SaA05 Sal04 Sal05 Rising, L., Janoff, N., S., The Scrum Software Development Process for Small Teams, IEEE Software, sivut 26-32, heinä-elokuu, 2000. Salo, O., Abrahamsson P., Integrating Agile Software Development and Software Process Improvement: a Longitudinal Case Study. IEEE, sivut 193-202, 2005. Salo., O., Improving Software Process in Agile Software Development Projects: Results from Two XP Case Studies. Proceedings of the 30 th EUROMICRO Conference (EUROMICRO 04), 2004. Salo, O., Systematical Validation of Learning in Agile Software Development Environment, Lecture Notes in Computer Science, Springer, joulukuu, 2005. Sam07 Who Said Usability Is Free?, Interactions, sivut 10-11, heinä-elokuu 2007. ScB02 Sch97 SJJ08 Schwaber K., Beedle, M., Agile Software Development with Scrum. Prentice Hall, 2002. Schwaber, K., Scrum Development Process, OOPSLA Business Object Design and Implementation Workshop, 1997 Sutherland, J., Jakobsen, C., R., Johnson, K., Scrum and CMMI Level 5: The Magic Potion for Code Warriors, Proceedings of the 41 st Hawaii International Conference on System Sciences, 2008. Som04 Sommerville, I., Software Engineering 7. Pearson Education, 2004. Sut04 Sut05 Sutherland, J., Agile Development: Lessons Learned from the First Scrum, Cutter Agile Project Management Advisory Service: Executive update, vol. 5, sivut 1-4, 2004. Sutherland, J., Future of Scrum: Parallel Pipelinig of Sprints in Complex Projects, of the Agile Development Conference (ADC 05), 2005. Systeemityö, käytettävyys ja ketteryys, vol. 14, no. 4, 2007. Koko lehti.