Käyttäjäkeskeisen suunnittelun ja ketterien menetelmien yhdistäminen prosessimallien näkökulmasta

Transkriptio

1 Aalto-yliopisto Informaatio- ja luonnontieteiden tiedekunta Tietotekniikan tutkinto-ohjelma Käyttäjäkeskeisen suunnittelun ja ketterien menetelmien yhdistäminen prosessimallien näkökulmasta Kandidaatintyö 2. joulukuuta 2010 Frans Joonas Wärn

2 Aalto-yliopisto Informaatio- ja luonnontieteiden tiedekunta Tietotekniikan tutkinto-ohjelma Kandidaatintyön tiivistelmä Tekijä: Frans Joonas Wärn Työn nimi: Käyttäjäkeskeisen suunnittelun ja ketterien menetelmien yhdistäminen prosessimallien näkökulmasta Päiväys: 2. joulukuuta 2010 Sivumäärä: iii + 36 Vastuuopettaja: Professori Ilkka Niemelä Työn ohjaajat: TkL Johanna Viitanen TkT Casper Lassenius Tuotteen käytettävyyttä voidaan edistää käyttämällä kehitystyössä apuna käyttäjäkeskeistä suunnittelua, joka integroidaan osaksi olemassaolevaa ohjelmistokehitysprosessia. Käyttäjäkeskeiset suunnittelumenetelmät ovat olennainen täydennys ohjelmistokehityksen menetelmiin ja prosessimalleihin, jotka ovat usein yksinään käytettävyyden näkökulmasta riittämättömiä. Ohjelmistokehityksessä ovat viime vuosina niin kutsutut ketterät menetelmät kasvattaneet huomattavasti suosiota, mutta niitä on yhtälailla syytetty riittämättömiksi käytettävyyden näkökulmasta. Tässä työssä on tutkittu käyttäjäkeskeisen suunnittelun ja ketterien menetelmien yhdistämistä prosessimallien näkökulmasta ja esitellään havaitut edut ja ongelmat. Ongelmien osalta käydään lisäksi läpi niihin ehdotettuja ratkaisuja. Tutkimustyössä rajoituttiin ketterien menetelmien osalta XP:hen ja Scrumiin. ja käyttäjäkeskeisten suunnittelumenetelmien Usability Engineering Life Cycleen, ISO :een ja LUCIDiin. Verrattaessa perinteisiin kehitysmenetelmiin havaittiin tutkimuksessa ketteriin menetelmiin liittyvän sekä selkeitä etuja että ongelmia käyttäjäkeskeisen suunnittelun näkökulmasta. Ongelmien ratkaisuksi ehdotettuja ideoita löytyi myös runsaasti, mutta lähes poikkeuksetta ehdotusten todellisesta kyvystä ratkaista ongelmia ei esitetty empiiristä tutkimusnäyttöä lainkaan tai se pohjautui tutkijoiden subjektiivisiin arvioihin. Avainsanat: Kieli: ketterä, scrum, xp, käytettävyys, käyttäjäkeskeinen suunnittelu Suomi i

3 Sisältö 1 Johdanto 1 2 Tausta Ohjelmistokehityksen prosessimallit Paradigmat Vesiputousmalli Iteratiivinen kehitys Ketterät menetelmät Käyttäjäkeskeinen suunnittelu Yhteenveto Yhdistämisessä havaittuja etuja Iteratiivisuus Käyttäjä mukana kehitystyössä Ei jäykkää vaatimusmäärittelyä Ketterien menetelmien parantaminen käyttäjäkeskeisin suunnittelumenetelmin Yhdistämisessä havaittuja ongelmia Iteratiivisuuden nopeus Kulttuurierot Eri näkemys käyttäjästä ii

4 5 Keinoja ongelmien ratkaisemiseksi Muutoksia syklijärjestelmään Käyttöliittymäsuunnittelun jakaminen osiin Kevyempiä käyttäjäkeskeisiä menetelmiä Käytettävyysasiantuntijoiden ulosanti ketteräksi Käytettävyysasiantuntija edustamaan käyttäjää Yhteenveto ja pohdinta 30 Lähteet 33 iii

5 Luku 1 Johdanto Tuotteen käytettävyyttä voidaan edistää käyttämällä kehitystyössä apuna käyttäjäkeskeistä suunnittelua (engl. user-centred design). Käytännössä tämä toteutetaan integroimalla käyttäjäkeskeinen suunnittelu ja sen periaatteet osaksi olemassaolevaa ohjelmistokehitysprosessia. Käyttäjäkeskeiset suunnittelumenetelmät ovatkin olennainen täydennys ohjelmistokehityksen menetelmiin ja prosessimalleihin, jotka ovat usein yksinään käytettävyyden näkökulmasta riittämättömiä. Ohjelmistokehityksessä 2000-luvun trendi on ollut ketterien menetelmien suosion kasvu. Niitä on yhtälailla syytetty yksistään riittämättömiksi käytettävien ohjelmistojen tuottamiseen. Ketterät menetelmät ovat kuitenkin käyttäjäkeskeisen suunnittelun näkökulmasta mielenkiintoinen muutos, vaikka useimmat käyttäjäkeskeisen suunnittelun menetelmät ja ohjeistot väittävät olevansa riippumattomia ohjelmistokehitysprosessista johon ne integroidaan. Väitteisiin on kuitenkin syytä suhtautua varauksella, onhan koko käyttäjäkeskeisen suunnittelun synnyn edellytys ollut olemassaolevien prosessimallien puutteet. Lähtökohta vaikuttaa lupaavalta, ketterät menetelmät näyttävät nimittäin painottavan samoja teemoja kuin käyttäjäkeskeinen suunnittelukin: iteratiivista kehitystyötä ja käyttäjän tuomista lähemmäksi suunnittelu- ja toteutusprosessia. Syvemmälle mennessä kuitenkin paljastuu, että käyttäjäkeskeisen suunnittelun yhdistämisessä ketteriin menetelmiin esiintyy ihan uusia ongelmia. Tämä tutkimus pyrkii vastaamaan kahteen kysymykseen: Mitä etuja ja ongelmia kohdataan kun käyttäjäkeskeisiä suunnittelumetodeja yritetään yhdistää ketteriin ohjelmistokehitysprosesseihin? 1

6 LUKU 1. JOHDANTO 2 Mitä ratkaisuja edellämainittuihin ongelmiin on ehdotettu? Näkökulmaksi on valittu prosessimallit ja niiden yhteensovittaminen. Tarkastelun ulkopuolelle on siten jätetty ketterien menetelmien osalta muut kuin välittömästi prosessimalleihin liittyvät toimintatavat ja ohjeistot. Lisäksi ketterien menetelmien osalta rajoitutaan XP:n (Extreme Programming) ja Scrumin prosessimallien tarkasteluun. Käyttäjäkeskeisten suunnittelumenetelmien osalta rajoitutaan tarkastelussa Usability Engineering Life Cyclen, ISO :n ja LUCIDin esittelemiin periaatteisiin ja suosituksiin. Tutkimuksessa esitellään ensin taustatietoa ohjelmistokehityksen prosessimalleista ja paradigmoista, mukaanlukien ketterät menetelmät. Taustatiedon parissa jatketaan käyttäjäkeskeisen suunnittelun periaatteilla ja suosituksilla. Taustan jälkeen siirrytään tarkastelemaan ketterien menetelmien ja käyttäjäkeskeisen suunnittelun yhteensovittamisessa havaittuja etuja ja ongelmia. Lopuksi käydään läpi yhdistämisessä havaittuihin ongelmiin esitettyjä ratkaisuja, ennen loppuyhteenvetoa ja pohdintaa.

7 Luku 2 Tausta 2.1 Ohjelmistokehityksen prosessimallit Tässä luvussa esitellään ohjelmistokehityksen tunnetuimpia prosessimalleja. Niitä voidaan jäsentää monella tavalla ja alan kirjallisuutta lukemalla voi nopeasti saada tuntuman, että määrityksiä on yhtä monta kuin määrittelijöitä. Tässä tutkimuksessa tehdyt jaoittelut ja määritelmät pohjautuvat Sommervillen (2007) näkemykseen. Ohjelmistoprosessi (engl. software process) on tapahtumasarja, jonka tarkoituksena on tuottaa valmis ohjelmistotuote tai -järjestelmä. On kolme perustoimintoa, jotka ovat yhteisiä kaikille ohjelmistoprosesseille: määrittely (engl. software specification), kehitys (engl. software development) ja todennus (engl. software validation). Ohjelmistokehityksen prosessimalli (engl. software process model) on yksinkertaistettu kuvaus ohjelmistoprosessista, joka edustaa yhtä näkökulmaa tähän prosessiin. Prosessimallit voivat sisältää toimia jotka ovat osa ohjelmistoprosessia, ohjelmistokomponentteja, sekä rooleja joita eri ihmisillä on osana ohjelmistokehitystä. Ohjelmistokehityksen paradigmat (engl. paradigm of software development) ovat yleisiä prosessimalleja, joihin ohjelmistokehityksen prosessimallit perustuvat. 3

8 LUKU 2. TAUSTA Paradigmat Ohjelmistokehityksen paradigmoja kutsutaan lähteestä riippuen myös ohjelmistokehityksen yleisiksi prosessimalleiksi (engl. general process model), lähestymistavoiksi (engl. approach), elinkaariksi (engl. life cycle) tai viitekehyksiksi (engl. framework). Sommervillen (2007) mukaan useimmat ohjelmistokehityksen prosessimallit perustuvat yhteen kolmesta paradigmasta: Vesiputousmalli (engl. waterfall model/approach) Tässä lähestymistavassa ohjelmistoprosessin perustoiminnot ovat prosessissa ajallisesti toisiaan seuraavia vaiheita ja ne suoritetaan yksi kerrallaan toisensa jälkeen. Vesiputousta kutsutaan myös usein lineaariseksi lähestymistavaksi. Iteratiivinen kehitys (engl. iterative development) Tässä lähestymistavassa ohjelmistoprosessin perustoiminnot sijoittuvat ajallisesti limittäin. Ensimmäinen versio järjestelmästä kehitetään nopeasti hyvin abstrakteista määrittelyistä. Tämän jälkeen ohjelmistoa parannellaan asiakkaan palautteen perusteella niin että lopulta pystytään tuottamaan ohjelmisto joka täyttää kaikki asiakkaan tarpeet ja vaatimukset. Komponenttipohjainen ohjelmistotekniikka (engl. component-base software engineering) Tämä lähestymistapa olettaa että osa järjestelmästä on jo olemassa. Prosessi keskittyy eri osien integrointiin sen sijasta että niitä kehitettäisiin tyhjästä. On myös useita prosessimalleja, jotka perustuvat useampaan paradigmaan, kuten esimerkiksi Rational Unified Process (RUP) joka yhdistelee piirteitä kaikista kolmesta. (Sommerville, 2007) Seuraavissa luvuissa käsitellään kaksi ensinnä mainittua paradigmaa. Viimeisintä paradigmaa ei tässä tutkimuksessa sen sijaan käsitellä tarkemmin. On myös huomattava, etteivät kaikki Sommervillen tapaan miellä komponenttipohjaista ohjelmistotekniikkaa samantasoiseksi paradigmaksi ensinnämainittujen kanssa Vesiputousmalli Vesiputousmalli on ohjelmistokehityksen tunnetuin prosessimalli. Syynä lienee sen selkeys ja ymmärrettävyys myös maallikoille. Mallin juuret ovat järjestelmäsuunnittelun (engl. systems engineering) prosessimalleissa, joista se

9 LUKU 2. TAUSTA 5 on lainattu ohjelmistokehityksen käyttöön tietokoneiden alkutaipaleella luvulla (katso esimerkiksi Benington, 1983). Puhdasoppinen vesiputousmalli tarkoittaa lineaarisesti vaihe vaiheelta etenevää prosessia, jossa yhden vaiheen ollessa valmis, siirrytään seuraavaan (kuva 2.1). Tyypillisesti kunkin vaiheen tuotoksena syntyy dokumentti tai dokumentteja, joiden hyväksyntä oikeuttaa seuraavaan vaiheeseen siirtymisen. Tästä syystä vesiputousmallia luonnehditaan dokumenttiohjatuksi (engl. document-driven) prosessimalliksi. Kuva 2.1: Vesiputousmalli (kuva Royce, 1987, s. 329) Usein vesiputousmalli yhdistetään Roycen paperiin vuodelta 1970 (Royce, 1987). Tähän viittaaminen on kuitenkin kyseenalaista. Royce esittää kyllä paperissaan vesiputousmallia vastaavan mallin (käyttämättä tosin tätä nimistystä), mutta ainoastaan ohimennen esimerkkinä prosessimallista joka ei voisi käytännössä ikinä toimia kuin ihan pienimpien projektien kanssa (tämä prosessimalli esiintyy kuvassa 2.1). Sen sijaan hän esittelee paperin lopputuloksena tästä huomattavasti poikkeavan mallin (Royce, 1987, s. 338), joka sisältää piirteitä iteratiivisesta paradigmasta. Ironisesti hänen paperistaan on kuitenkin useimmissa yhteyksissä jäänyt elämään vain se osuus, jota hän itsekin jo alunperin kritisoi. Useat asiantuntijat (muun muassa Cockburn, 1993) ovat sitä mieltä, ettei

10 LUKU 2. TAUSTA 6 niin sanotun puhdasoppisen vesiputousmallin noudattaminen käytännössä ole mahdollista, ja että nekin jotka väittävät näin tekevänsä, todellisuudessa käyttänevät jollain tavoin sisäisesti inkrementaalista lähestymistapaa (katso seuraava luku). Vesiputousmalli voidaan tosin käsittää myös vähemmän puhdasoppisena, jolloin vaiheet voivat olla osittain päällekkäisiä ja tarvittaessa aiempiin suljettuihin vaiheisiin voidaan palata tekemään muutoksia. Monet näkevät tässä tapauksessa mallin edelleen käyttökelpoisena (näin myös esimerkiksi Sommerville, 2007), osa taas on sitä mieltä ettei vesiputousmalli ole milloinkaan hyvä ajatus ohjelmistokehityksen prosessimalliksi Iteratiivinen kehitys Iteratiivinen kehitys, jota nimitetään myös evolutiiviseksi kehitykseksi (engl. evolutionary development) on paradigma jonka ydin on kehitysprosessin (ja siten sen perustoimintojen määrittelyn, kehityksen ja todennuksen) toistaminen useita kertoja ohjelmistoprosessin aikana. Päinvastoin kuin vesiputousmallissa, prosessia ei siis suoriteta vain kertaalleen alusta loppuun, vaan sitä toistetaan useampia kertoja. Nykyään käsitteeseen ymmärretään vaiheiden toiston lisäksi liittyvän myös ohjelmiston parantelu ennakoitavaa prosessia noudattaen. Inkrementaalisella kehityksellä (engl. incremental development) puolestaan viitataan siihen, että ohjelmiston osat kehitetään eri aikaan tai eri tahdissa ja integroidaan niiden valmistuttua. Iteratiivinen kehitys ilman inkrementaalisuutta tarkoittaa, että koko ohjelmisto kehitetään kerralla, mutta sen pariin palataan uudelleen seuraavassa iteraatiossa, tarkoituksena parantaa aiempaa versiota. Inkrementaalinen kehitys ilman iteratiivisuutta puolestaan viittaa prosessiin, jossa ohjelmiston eri osat kehitetään täysin valmiiksi ja lopullisiksi ennen integroimista. (Cockburn, 1993) Iteratiivis-inkrementaalisella kehityksellä viitataan prosessimalliin, jossa prosessi on toistuva ja ohjelmistoa rakennetaan pala palalta kohti täydellistä versiota. Iteratiivisuus ja inkrementaalisuus kulkevatkin ohjelmistokehityksessä lähes aina käsi kädessä. Ideana on rakentaa ensin minimaalinen lähtöversio ja sen jälkeen lisätä uusia osioita ja ominaisuuksia sekä parantaa olemassaolevia osia, julkaisten tasaisin väliajoin uusia yhä täydellisempiä versiota siihen saakka kunnes tuote tai järjestelmä on lopulta riittävä. Vähemmän ohjelmistokehityksen historiaa tuntevat saattavat kuvitella iteratiivis-inkrementaalisten prosessimallien olevan moderni, ketterien mene-

11 LUKU 2. TAUSTA 7 telmien myötä esiin noussut lähestymistapa. Iteratiivis-inkrementaalisen kehityksen historia alkaa kuitenkin ihan yhtä kaukaa kuin vesiputousmallinkin (Larman ja Basili, 2003). Mielenkiintoinen huomio on myös aiemmin viitatun Beningtonin (1983) esipuhe vuoden 1956 paperin uudelleenjulkaisussa, jossa hän paljastaa SAGE-projektissa (josta hän paperinsa vesiputousmallia noudattavan prosessikuvauksen kirjoitti) kehitystyötä käytännössä tehdyn myös inkrementaalisin menetelmin Ketterät menetelmät Ketterät menetelmät (engl. agile methods) ovat iteratiivis-inkrementaalisen paradigman ohjelmistokehitysmenetelmiä, edustaen arvoja jotka käyvät ilmi ketterästä manifestista : Olemme päätyneet arvostamaan Yksilöitä ja vuorovaikutusta enemmän kuin prosesseja ja työkaluja Toimivaa sovellusta enemmän kuin kokonaisvaltaista dokumentaatiota Asiakasyhteistyötä enemmän kuin sopimusneuvotteluita Muutokseen reagoimista enemmän kuin suunnitelman noudattamista (Beck et al., 2001, käännös Wikipedia) Ketterät menetelmät keskittyvät nopeaan ensimmäisen toimivan ohjelmistoversion toimittamiseen, inkrementaaliseen julkaisuun, tiimin tiiviiseen kommunikointiin ja yhteistyöhön, sekä nopeaan ja vaivattomaan kykyyn vastata muutoksiin. Yhden näkemyksen mukaan ketterien menetelmien voidaan katsoa syntyneen ratkaisemaan ongelma, jonka Nandhakumar ja Avison (1999) havaitsevat suurta kehitysorganisaatiota seuratessaan. He väittävät, että tietojärjestelmien perinteiset kehitysmetodologiat ovat vain kuvitelma tarpeellisen kontrollivaikutelman ja symbolisen statusarvon luomiseksi, ja ne ovat liian mekaanisia ollakseen paljoakaan hyödyksi kehittäjien tehtävien päivittäisessä organisoinnissa. Abrahamsson et al. (2002) jatkavat tämän tutkimuksen päälle ja toteavat ketterien menetelmien mallintavan huomattavasti paremmin kehitystyön todellisuutta, ja siten todennäköisesti vastaavan ohjelmistokehittäjien tarpeisiin paremmin kuin perinteiset näkökulmat ohjelmistokehitykseen. Vaihtoehtoisena näkemyksenä Armitage (2004) esittää, että ketterät menetelmät saattoivat olla ratkaisu hyvien ohjelmistosuunnittelijoiden, arkkitehtien ja strategien puutteeseen. Armitagen mukaan ohjelmistot ovat vaikeita mallintaa

12 LUKU 2. TAUSTA 8 ja ketterät menetelmät voidaan nähdä raa an voiman (engl. brute-force) menetelmänä saada hyväksyttävä työ aikaiseksi ilman suunnitelmaa tai suunnittelijoita. Ketteristä menetelmistä tunnetuimpia ovat XP ja Scrum, joiden tarkasteluun tässä tutkimuksessa keskityttiin. Kummankin tapauksessa kehityssyklit ovat aikarajoitettuja ja tyypilliseltä pituudeltaan viikosta neljään. Prosessin näkökulmasta merkittävin uutuus aiempaan verrattuna on näiden verrattain lyhyiden syklien tuoma nopea iteratiivisuus ja lähes olematon määrittelyvaihe (yhden kokouksen mittainen). XP (Beck ja Andres, 2004) on vuosituhannen vaihteessa näyttävimmin pinnalle noussut ketteristä menetelmistä. Beck ja Andres listaavat XP:n arvoiksi tiiviin kommunikoinnin niin tiimin sisällä kuin sidosryhmien kanssa, yksinkertaiset suunnitteluratkaisut, jatkuvan palautteen vastaanoton eri tasoilla, rohkeuden, sekä kunnioituksen muita tiimin jäseniä kohtaan. XP:n periaatteet ja toimintavat puolestaan pohjautuvat näihin arvoihin. XP metodologiana keskittyy näiden hyvin pragmaattiselle tasolle menevien toimintatapojen ympärille ja luottaa paljolti itseohjaavien tiimien kykyyn parhaiten organisoida oma työnsä. months weeks Releaseplan days hours Iteration plan minutes Acceptance Test Stand up meeting Pair Negotiation Unit Test Pair Programming Code Kuva 2.2: XP:n prosessin ydin, palautesilmukka (CC-BY-SA Marcel Dekker)

13 LUKU 2. TAUSTA 9 Scrum katsoo ketteryyttä XP:tä enemmän projektinhallinnan näkökulmasta. Se voidaan nähdä prosessin rungon kuvauksena johon kuuluvat tietyt roolit ja prosessimalli, mutta vähemmän toimintatapoja. Rooleja ovat scrummaster, joka löyhästi määritellen voidaan nähdä projektipäällikköä vastaavana roolina, tuoteomistaja (engl. product owner), joka toimii kehitystiimin ulkopuolisten sidosryhmien ja erityisesti asiakkaan ja kaupallisten realiteettien edustajana, sekä itse kehitystiimi, jonka vastuulla on varsinainen ohjelmistokehitys. XP:n tavoin kehitystiimi on hyvin itseohjaava, eikä scrummaster ei ole varsinaisesti tiimin johtaja, vaan ainoastaan avustaa tiimiä ongelmien ratkaisussa. 24 h 30 days Product Backlog Sprint Backlog Sprint Working increment of the software Kuva 2.3: Scrumin prosessimalli (CC-BY-SA LakeWorks) Scrumissa prosessimalli on kohtuullisen yksinkertainen (kuva 2.3). Tuoteomistaja ylläpitää tuotteen kehitysjonoa (engl. product backlog), josta kehitystiimi poimii joka sprintin (scrumin nimitys kehityssyklille) alussa tietyn määrän ominaisuuksia sprintin tehtävälistaan (engl. sprint backlog). Kehitystiimi kokoontuu joka päivä maksimissaan 15 minuutin pituisissa seisomapalaverissa, jossa käydään läpi edistymistä ja kehitystyön esteenä olevia ongelmia. Sprintin lopussa saavutettu lopputulos esitellään tuoteomistajalle ja muille kiinnostuneille sidosryhmäläisille ja aloitetaan sitten uusi sprintti. XP ja Scrum noudattavat kumpikin samaa filosofiaa, suurimpana erona ehkä se, että XP on keskittynyt enemmän kehityksessä käytettyjen toimintapojen ja -menetelmien tarkasteluun, kun taas Scrum enemmän projektinhallintaan littyviin asioihin. Koska varsinaista ristiriitaa niiden välillä ei ole, voidaan ne myös sovittaa yhteen (Vriens, 2003).

14 LUKU 2. TAUSTA Käyttäjäkeskeinen suunnittelu Käyttäjäkeskeinen suunnittelu (engl. User-centred Design tai Human-centred Design) on vuorovaikutteisten järjestelmien suunnittelemisen ja kehittämisen lähestymistapa, joka keskittyy järjestelmien käytettävyyteen. Käytettävyys (engl. Usability) puolestaan on mitta, miten hyvin määrätyt käyttäjät voivat käyttää tuotetta tietyssä käyttötilanteessa saavuttaakseen määritetyt tavoitteet tuloksellisesti, tehokkaasti ja tyytyväisinä. (ISO :2010) Sharp et al. (2007, s. 14) määritelmän mukaisesti käyttäjäkeskeisiin suunnittelumenetelmiin perehtyneitä henkilöitä kutsutaan käyttöliittymäsuunnittelijoiksi (engl. user interface designer) ja tuotteiden käytettävyyttä arvioivia henkilöitä käytettävyysinsinööreiksi (engl. usability engineer). Tässä tutkimuksessa on pyritty käyttämään näitä käsitteitä silloin kun on haluttu painottaa eroa näiden välillä. Muissa tapauksissa on käytetty yleisempää käsitettä käytettävyysasiantuntija (tämä on verrattavissa Sharp et al. englanninkieliseen määritelmään user experience designer/architect/researcher). Käyttäjäkeskeisellä suunnittelulla sanotaan myös usein olevan omia prosessimallejaan, viitaten esimerkiksi Usability Engineering Life Cycleen (Nielsen, 1992), ISO :aan (ISO :2010) ja LUCIDiin (Kreizberg, 2008). Tutustumalla näihin kolmeen selviää kuitenkin ettei mikään niistä ota kantaa tuotteen varsinaiseen kehittämiseen, vaan tarkastelee ainoastaan käyttöliittymäsuunnittelijoiden tehtäviä. Näistä kahden ensimmäisen sisältöä voi prosessimallin sijasta ajatella tarkistuslistoina kohdistettavaksi varsinaiseen tuotekehitysprosessiin. LUCID taas sisällyttää ohjelmistokehityksen kokonaisuudessaan yhden vaiheen sisään, eikä ota sen sisältöön mitään kantaa. Seuraavissa kappaleissa esitellään nämä kolme tarkemmin. Usability Engineering Life Cycle (Nielsen, 1992) sisältää suosituksen kymmenestä toiminnosta, jaoiteltuna vaiheen mukaan. Ennen suunnittelua Nielsen suosittelee (1) tunnistamaan käyttäjän, (2) analysoimaan kilpailevia tuotteita ja (3) asettamaan käytettävyystavoitteet. Suunnittelun aikana (4) ottamaan käyttäjän mukaan suunnitteluun, (5) suunnittelemaan käyttöliittymän koordinoidusti kokonaisuutena, (6) käyttämään käyttöliittymäohjeistuksia ja heuristisia analyyseja, (7) tekemään prototyyppejä, (8) testaamaan käyttöliittymää ja (9) suunnittelemaan iteratiivisesti. Suunnittelun jälkeen (10) keräämään palautetta kentältä. Nielsenin mukaan hyötyjen saavuttamiseksi ei ole välttämätöntä ottaa käyttöön kaikkia näitä toimintoja, vaan jo osittaisellakin hyödyntämisellä parannetaan käytettävyyttä.

15 LUKU 2. TAUSTA 11 Standardi vuorovaikutteisten järjestelmien käyttäjäkeskeisestä suunnittelusta (ISO :2010) sisältää suosituksia suunnittelutoiminnoista interaktiivisten järjestelmien toteuttamiseen. ISO julkaistiin maaliskuussa 2010, syrjäyttäen vanhemman ISO standardin (SFS-EN ISO 13407:1998). Mielenkiintoisimmat muutokset tämän työn kannalta olivat sanan prosessi poistuminen standardin nimestä, sekä iteraation tarkentaminen koskemaan koko suunnitteluprosessia, eikä pelkästään käytettävyysarviointia. Standardi esittää käyttäjäkeskeisen suunnittelun pohjana olevan kuusi yleistä periaatetta, jotka ovat riippumattomia käytetyistä prosessimalleista tai suunnittelumenetelmistä: Suunnittelu pohjautuu yksikäsitteiseen ymmärrykseen käyttäjistä, tehtävistä ja ympäristöstä. Käyttäjät ovat osallisina suunnittelu- ja kehitystyössä koko tämän työn ajan. Suunnittelua ohjataan ja jalostetaan käyttäjäkeskeisillä arvioinneilla. Prosessi on iteratiivinen. Suunnittelu huomioi koko käyttäjäkokemuksen. Suunnitteluryhmä edustaa monialaisia taitoja ja perspektiivejä. Näiden periaatteiden lisäksi standardi esittää neljä käyttäjäkeskeistä suunnittelutoimintoa, joiden tulisi olla osa jokaista interaktiivisen järjestelmän kehitysprojektia. Nämä suunnittelutoiminnot ja niiden keskinäinen suhde esitetään kuvassa 2.4. Usein tämä standardissa esitetty kaavio mielletään virheellisesti tuotekehityksen prosessimalliksi käyttäjäkeskeisestä näkökulmasta, mutta tosiasiallisesti se korkeintaan ilmaisee missä järjestyksessä käyttäjäkeskeisiä suunnittelutoimintoja tulisi tehdä. Sen sijaan standardi neuvoo (ISO :2010, luku 5) miten liittää suunnittelutoiminnot osaksi tuotteen kehitysprosessia. Tämä prosessin suunnitteluvaihe tulisi tehdä ensimmäisenä ennen varsinaisia käyttäjäkeskeisiä suunnittelutoimintoja, kuten kuvasta 2.4 ilmenee. LUCID (Kreizberg, 2008) on käyttäjäkeskeisen suunnittelun viitekehys, joka sisältää kuusivaiheisen prosessimallin tuotteen suunnitteluun. Neljä ensimmäistä vaihetta liittyvät tuotteen käyttöliittymän määrittelyyn ja suunnitteluun. Varsinainen tuotteen kehittäminen (sisältäen tuotteen määrittelyn ja

16 LUKU 2. TAUSTA 12 Suunnittele käyttäjäkeskeinen suunnitteluprosessi Järjestelmä täyttää vaatimukset Ymmärrä ja määrittele käyttötilanne Määrittele käyttäjävaatimukset Tuota suunnitteluratkaisuja Arvioi suunnitelmat Iteroi Kuva 2.4: Käyttäjäkeskeisten suunnittelutoimintojen liittyminen toisiinsa suunnittelun muun kuin käyttöliittymän osalta) sijoittuu prosessin viidenteen vaiheeseen ja julkaisu kuudenteen. Kreizbergin mukaan hänen mallissaan käyttöliittymäsuunnittelijoiden ja kehittäjien väliseen kanssakäymiseen on vain hyvin vähän tarvetta, koska kehittäjät saavat täydelliset määrittelyt ennen työnsä aloittamista. LUCIDia voisikin ihan aiheellisesti kutsua käyttäjäkeskeiseksi vesiputousmalliksi. Kreizbergin suhtautuminen ketteriin menetelmiin on irrationaalinen ja tähän liittyvä argumentointi ontuvaa. Hänen mukaansa LUCID on ketterä prosessi, koska suunnittelu suoriutuu luonnostaan parhaiten iteratiivisella tavalla. (Kreizberg, 2008, käännös kirjoittajan). Kreizberg esittää, että LUCID soveltuu hyvin sovellettavaksi myös iteratiivisten kehitysmenetelmien kanssa, kunhan kaikki kehitys suoritetaan hänen mallinsa viidennessä vaiheessa. Voinee väittää, ainakin kärjistämällä, ettei LUCIDia voi integroida minkään ohjelmistokehityksen prosessimallin kanssa, vaan ohjelmistokehityksen prosessi voidaan ainoastaan upottaa LUCIDin viidenteen vaiheeseen. Toisinsanoen LUCID ei tue minkäänlaista käyttöliittymäsuunnittelun ja ohjelmistokehityksen rinnakkaisuutta. 2.3 Yhteenveto Yhdistämistä silmälläpitäen käyttäjäkeskeisten suunnittelumenetelmien suurin ongelma on se, etteivät ne ota juurikaan kantaa varsinaiseen ohjelmistoke-

17 LUKU 2. TAUSTA 13 hitykseen. Täten ne eivät pysty riittävästi huomioimaan käytännön ohjelmistokehityksessä tapahtuvia muutoksia. Scott (2009) tuo esille, että tapa kehittää ohjelmistoja on muuttunut paljon viimeisen kymmenen vuoden aikana ja että käytettävyysalan on tarpeellista muuttua tämän mukaisesti. Tänä päivänä ohjelmistoja tehdään iteratiivisesti ja paljon nopeammalla syklillä kuin aiemmin. Siinä missä ennen käytettävyystestausta tehtiin paperiprotoilla, tänä päivänä sitä tehdään oikealla tuotteella, jota voidaan muokata reaaliajassa. (Scott, 2009) LUCIDin kohdalla voimme lisäksi todeta tilanteen vielä ongelmallisemmaksi. Sitä ei ole tarkoitettu varsinaisesti integroitavaksi ollenkaan, vaan kehitystyö sisältyy kiinteästi sen yhden vaiheen sisälle. Tämä ei sovi ketterien menetelmien filosofian kanssa yhteen ollenkaan. Silminpistävin ketterien menetelmien ongelma käyttäjäkeskeisen suunnittelun kannalta on se, etteivät nämä sisällä ollenkaan erillistä vaihetta vaatimusmäärittelylle tai suunnittelulle, vaan ohjelmakoodin ja toteutuksen pariin mennään samantien. Ongelma tämä on siksi, että useat käyttäjäkeskeiset suunnittelumenetelmät odottavat löytävänsä prosessista vaiheita ennen käyttöliittymän implementointiin siirtymistä.

18 Luku 3 Yhdistämisessä havaittuja etuja Tässä luvussa käydään läpi ketterien menetelmien ja käyttäjäkeskeisen suunnittelun yhdistämisessä havaittuja etuja (verrattuna ketteriä menetelmiä perinteisiin ohjelmistokehitysmenetelmiin). Havaittiin kolme selkeää etua: iteratiivisuus, käyttäjän osallistuminen kehitystyöhön ja vaatimusmäärittelyn joustavuus. Lisäksi neljännessä alaluvussa käydään läpi muutamia esimerkkejä tutkimuksista, joissa käyttäjäkeskeisten suunnittelumenetelmien avulla on onnistuneesti korjattu ketterien menetelmien kanssa havaittuja käytännön ongelmia. 3.1 Iteratiivisuus Sekä ketterät menetelmät että käyttäjäkeskeinen suunnittelu nojaavat vahvasti iteratiiviseen kehitysparadigmaan. Kummankin kohdalla tuotetta rakennetaan ja parannetaan aiemmista sykleistä tai kierroksista saadun palautteen pohjalle. Esimerkiksi XP:ssä yksi kantavista arvoista on palautteen huomioiminen, ja sitä pyritään tekemään monella eri tasolla (katso kuva 2.2). Yhtälailla käyttäjäkeskeisen suunnittelun yksi peruspilareista on iteratiivinen suunnitteluprosessi. (Chamberlain et al., 2006) Kuitenkin prosessin inkrementaalisuuteen ketterät menetelmät ja käyttäjäkeskeinen suunnittelu suhtautuvat hieman eri tavalla. Ketterät menetelmät luottavat myös inkrementaalisuuteen (ollen siten iteratiivis-inkrementaalisia), kun taas käyttäjäkeskeisen suunnittelun kohdalla inkrementaalisuus ei olekaan enää toivottu asia. Jo ensimmäisen suunnitteluversion toivotaan sisältävän kaikki käyttöliittymän osat, jolloin käyttöliittymä voidaan suunnitella koko- 14

19 LUKU 3. YHDISTÄMISESSÄ HAVAITTUJA ETUJA 15 naisuutena. Käyttöliittymäkehitys osissa voi olennaisesti heikentää käyttöliittymän yhtenäisyyttä. (esimerkiksi Nodder ja Nielsen, 2008) 3.2 Käyttäjä mukana kehitystyössä Ketterät menetelmät asettavat painoa käyttäjän kanssa kommunikointiin, rohkaisten osallistumiseen koko kehitysprosessin aikana. Scrumissa kuukausittaiseen käyttäjätestaukseen rohkaistaan tuomalla joka kehityssyklin päätteeksi viimeisin versio tuotteesta loppukatselmointiin ja XP:ssä käyttäjä ideaalitilanteessa kuuluu yhtenä jäsenenä kehitystiimiin. Myös yksi käyttäjäkeskeisen suunnittelun pääperiaatteista on aikainen ja jatkuva huomion keskittäminen käyttäjään. (Chamberlain et al., 2006) Käytännössä asiasta löytyy kuitenkin pieniä painotuseroja. Ketterien menetelmien kohdalla ideaalikäyttäjänä nähdään maksava asiakas, jonka uskotaan olevan tietoinen käyttäjistä ja heidän tarpeistaan, ja siksi hyvä valinta edustamaan loppukäyttäjiä. Käyttäjäkeskeisessä suunnittelus painotus on tuotteen lopullisessa käyttäjässä. Yhteistä ketterille menetelmille ja käyttäjäkeskeiselle suunnittelulle kuitenkin on ymmärrys siitä, että onnistuneen lopputuloksen aikaansaamiseksi kehitystyötä ei voida tehdä suljettujen ovien takana. Palautetta on haettava aika ajoin myös kehitystiimin ulkopuolelta ja tarkistettava että kehitystyön alla oleva tuote täyttää asiakkaan tai käyttäjän odotukset. 3.3 Ei jäykkää vaatimusmäärittelyä Yksi ketterien menetelmien näkyvimmistä piirteistä on raskaiden vaatimusmäärittelyjen korvaaminen kevyemmilla ilmaisutavoilla. Esimerkiksi XP:ssä vaatimukset kirjoitetaan käyttäjätarinoiden (engl. user stories) muotoon, jotka on kirjoitettu seinään kiinnitettävälle kortille. Näiden on tarkoitus ajaa samaa asiaa kuin formaalimmankin vaatimusmäärittelyn, mutta esitettynä selkokielellä ja rajoitetun pituisena, mahdollistaen myös muiden kuin ohjelmistokehittäjien osallistumisen niiden määrittelyyn. Ketterien menetelmien vahvuus on vaatimuksien nopea ja vaivaton muokattavuus kehitystyön keskelläkin. Käyttäjäkeskeisen suunnittelun kannalta tämä on hyvä asia, koska näin esimerkiksi käytettävyystestauksesta saadut havainnot voidaan viiveettä ottaa huomioon kehitystyössä.

20 LUKU 3. YHDISTÄMISESSÄ HAVAITTUJA ETUJA 16 Lisäksi Constantine (2002) toteaa, että kevyimmät käyttäjäkeskeisen suunnittelun menetelmät käyttävät samankaltaista korttijärjestelmää tehtävätapausten (engl. task case) kanssa. Constantinen mukaan samoja kortteja voidaan hyvin yhdistää käytettäväksi sekä käyttöliittymien kehityksessä että ohjelmistokehityksessä. 3.4 Ketterien menetelmien parantaminen käyttäjäkeskeisin suunnittelumenetelmin Kirjallisuudessa raportoidaan myös hyödyistä joita käyttäjäkeskeisen suunnittelun menetelmät voivat tarjota avuksi joihinkin ketterien menetelmien kohdalla havaittuihin ongelmiin. Tässä luvussa kerrotaan kaksi esimerkkiä. Patton (2005) esittelee artikkelissaan yrityksen, joka siirtyy käyttämään ketteriä menetelmiä halutessaan parantaa mahdollisuuksia reagoida projektien aikana muuttuviin asiakasvaatimuksiin. Pilottiprojektissa siirrytään käyttämään XP:tä, mutta törmätään uuteen ongelmaan. Johtuen pilotoitavan ohjelmistotuotteen kompleksisuudesta, käyttäjätarinoita syntyy lähdes 700 ja haasteeksi muodostuu näiden priorisointi. Käyttäjätarinoiden keskinäisiä riippuvuuksi oli määrästä johtuen lähes mahdotonta hahmottaa, eikä ryhmä täten pystynyt tekemään päätöksiä siitä, mitkä ominaisuudet olisi valittava ensimmäiseen iteraatioon. Patton kertoo avun löytyneen Garretin käyttäjäkokemuselementitmallista (engl. Elements of User Experience Model) sekä Cockburnin tavoitetaso (engl. goal level) konseptista. Näiden kahden käyttäjäkeskeisen suunnittelumenetelmän avulla saatiin lähes 700 käyttäjätarinaa muunnettua noin 80:ksi tehtäväksi (engl. user task) joista 30 valittiin toteutettavaksi ensimmäiseen julkaisuun. Tämän lisäksi kehittäjien ymmärrystä käyttäjien kohtaamista todellisista ongelmista kohennettiin seuraamalla käyttäjiä heidän päivittäisessä työympäristössään, joka lisäsi kehittäjien ymmärrystä tärkeimmistä prioriteeteista. (Patton, 2005) Myös Nodder ja Nielsen (2008) raportoivat käyttäjäkeskeisten suunnittelumenetelmien antamista hyödyistä ketterien menetelmien yhteydessä. He toteavat, että käyttäjätarinoita voidaan olennaisesti parantaa hyödyntämällä käyttäjäkeskeisiä suunnittelumenetelmiä, muun muassa käyttämällä persoonia sekä tutkimalla käyttäjävaatimuksia. Tuotteen kehitysjonon (engl. product backlog) priorisointia voidaan heidän mukaansa olennaisesti avustaa käyttäjäskenaarioilla, kuvakäsikirjoituksilla ja rautalankamalleilla. Lisäksi Nodder ja

21 LUKU 3. YHDISTÄMISESSÄ HAVAITTUJA ETUJA 17 Nielsen toteavat, että laadunvarmistuksen kannalta on hyödyllistä, jos käyttäjätarinoiden läpäisykriteereihin voidaan asetettaa käytettävyystavoitteita ja todentaa ne käytettävyystestauksella.

22 Luku 4 Yhdistämisessä havaittuja ongelmia Tässä luvussa käydään läpi ketterien menetelmien ja käyttäjäkeskeisen suunnittelun yhdistämisessä havaittuja ongelmia. Näkökulma vertailee ketteriä menetelmiä ensisijaisesti perinteisiin ohjelmistokehitysmenetelmiin ja siten tästä tarkastelusta on jätetty pois yleisen tason ongelmia, jotka ovat yhteisiä kaikille ohjelmistokehitysmenetelmille. Ongelmat on jaettu kolmeen ryhmään, jotka kukin on esitelty omassa alaluvussaan. Jako on vain ohjeellinen, useissa kohdin käytännön tason ongelmissa voidaan nähdä piirteitä useammasta ryhmästä. 4.1 Iteratiivisuuden nopeus Ketterien menetelmien ja käyttäjäkeskeisen suunnittelun välillä on selkeä filosofinen ero: Käyttäjäkeskeisen suunnittelun periaatteet kannustavat loppukäyttäjän ymmärtämiseen mahdollisimman aikaisessa vaiheessa ja ennen varsinaisen kehitystyön aloittamista, kun taas ketterät menetelmät vastustavat vahvasti etukäteen tehtävää määrittely- ja tutkimustyötä (engl. Big Design Up Front) ohjelmakoodin kirjoittamisen sijasta (Chamberlain et al., 2006). Constantine (2002) toteaa myös saman ongelman. Onnistuneen ja käytettävän käyttöliittymän suunnittelu vaatii kuitenkin jonkinlaisen kokonaisarkkitehtuurin miettimistä heti kehityksen alkuvaiheessa (Constantine, 2002). Ketterässä ohjelmistokehityksessä koodin kirjoittaminen alkaa tyypillisesti samantien kun projekti on käynnistetty, eikä käytettävyysasiantuntijoilla enää ole projektin alussa käytettävissä aikaa syvälliseen käyttäjien, tehtävien tai ympäristön analysointiin. Tästä voi seurata ainakin kolme käytännön on- 18

23 LUKU 4. YHDISTÄMISESSÄ HAVAITTUJA ONGELMIA 19 gelmaa. Ensiksi, käytettävyysasiantuntijoiden vastuulla olevat käyttöliittymäsuunnitelmat voivat muodostua kehitystyön aloittamisen pullonkaulaksi, kun ohjelmistokehittäjät joutuvat odottelemaan niitä. Toiseksi, kiireessä ja kiristetyillä aikatauluilla tehtyjen käyttöliittymäsuunnitelmien laatu on heikompi. Kolmanneksi, kiireellä tehtyjä käyttöliittymäsuunnitelmia ei ehditä tarkistaa käytettävyystestein. Tällöin myös suunnittelupäätöksistä käyttävä keskustelu voi muuttua puhtaaksi mielipideväittelyksi, kun käytettävissä ei ole mitään käyttäjäpalautetta päätöksenteon tueksi. (Miller ja Sy, 2009) Toisaalta, Nodder ja Nielsen (2008) pohdiskelevat edeltävän kaltaisen kritiikin ketteriä menetelmiä kohtaan kielivän joustamattomuudesta. Heidän mukaansa käytettävyysasiantuntijoiden tarve etukäteen tehtävälle suurelle työmäärälle ei ole todellinen, vaan pohjautuu vain aiempaan tottumukseen. Sen sijaan vesiputousmallin mukaisissa prosesseissa etukäteen tehtävän työn tarve oli todellinen, koska muutoksien tekeminen prosessin myöhemmissä vaiheissa oli hyvin vaikeaa tai mahdotonta. Ketterien menetelmien kanssa sen sijaan tilanne on eri, ja suuren työmäärän uhraaminen etukäteen ei ole enää järkevää. Lisäksi analyyseja ja käytettävyystestausta on paljon järkevämpi tehdä todellisen ohjelmiston kanssa, jos ja kun se ketterien menetelmien kanssa on mahdollista. (Nodder ja Nielsen, 2008) Sen lisäksi, että kehitystyö alkaa välittömästi projektin alussa, voivat ketterien prosessien lyhyet ja nopeat kehityssyklit olla ongelma, kun käyttöliittymäkehitystä tehdään samoissa aikarajoissa. Syklit voivat olla liian lyhyitä käytettävyysasiantuntijoille yksittäisten työvaiheiden alusta loppuun saattamiseksi. Ongelmat voivat ilmentyä suunnitelmien saamisessa ajoissa valmiiksi tai siinä ettei aikaa ole riittävästi käytettävyystestaukselle. (Sy, 2007; Miller ja Sy, 2009) Samaa ongelman yhtä puolta edustaa kokonaiskuvan hämärtyminen suunnittelutyön keskellä. Wolkerstorfer et al. (2008) kokemusten mukaan käyttäjät kokevat ohjelmistotuotteen usein tilkkutyöksi, mikäli se on kehitetty XP:n tavalla alhaalta ylös. Heidän mukaansa tämä johtuu kokonaiskuvan puuttumisesta projektien alussa. Miller ja Sy (2009) listaavat tästä ongelmasta seuraavien oireiden joukkoon muun muassa jaetun näkemyksen puuttumisen lopullisesta tavoitteesta, keskittymisen liiaksi yksityiskohtiin, sekä priorisoinnin ja päätöksenteon hankaluuden käyttöliittymäsuunnitelmissa. Nodder ja Nielsen (2008) arvioivat käytettävyysasiantuntijoiden kokemukset liian lyhyistä sykleistä johtuvan osittain aikaavievän käytettävyystestauksen dominoivasta asemasta menetelmänä. Moni käytettävyysasiantuntija nimittäin pitää käytettävyystestejä ainoana luotettavana menetelmänä käytettävyy-

24 LUKU 4. YHDISTÄMISESSÄ HAVAITTUJA ONGELMIA 20 den mittaamiseksi ja parantamiseksi. Nodder ja Nielsen mukaan tämä on saattanut nostaa käytettävyystestauksen tärkeämpään asemaan kuin mitä se todellisuudessa ansaitsisi. He huomauttavatkin, että käytettävyystestit ovat vain yksi tapa löytää ongelmia käytettävyydessä. Käytettävyystestauksen lisäksi on olemassa myös paljon muita menetelmiä ja tekniikoita, joilla saadaan aikastakin palautetta käyttäjiltä. Nodder ja Nielsen muistuttavat, että käytettävyysinsinöörin ensisijainen tavoite ei tulisi olla käytettävyystestauksen läpikäynti, vaan laadullisesti parempien ohjelmistojen julkaisu. 4.2 Kulttuurierot Ohjelmistokehittäjät ja käytettävyysasiantuntijat tulevat eri taustoista, erilaisilla asenteilla ja lähestymistavoilla ja usein jopa ilmaisevat itseään erilaisilla tavoilla. Ketterät menetelmät edellyttävät tiivistä yhteistyötä tiiminjäsenten kesken, mikä voi tuoda ohjelmistokehittäjien ja käytettävyysasiantuntijoiden väliset ajatusmaailmalliset erot kuuluvammin esiin. Ohjelmistokehittäjillä on tyypillisesti hyvin tekninen lähestyminen tuotekehitykseen, kun taas käytettävyysasiantuntijat psykologisen taustan kanssa näkevät tuotteen kehittämisen kognitiivisestä nakökulmasta. Nämä näkemyserot voivat johtaa ongelmiin työilmapiirissä. (Wolkerstorfer et al., 2008) Lievesley ja Yee (2006) nostaa myös esiin riskin liittyen käytettävyysasiantuntijan liian läheiseen osallistumiseen ketterän tiimin toimintaan, erityisesti projektin alkuvaiheessa. Käytettävyysasiantuntijan aloittaessa tuotteen tutkimusta, yksi arvokkaimmista asioista on rajoittamaton tutkimusmatkailu aihepiirissä yrittäen luoda kokonaisvaltaista ymmärrystä aihealueesta koostaen ja yhdistellen tietoja. Tällaisen yhdistelevän tutkimuksen tekeminen voi muodostua käytettävyysasiantuntijalle vaikeaksi osana yksityiskohtiin keskittyvää ketterää ohjelmistotiimiä. (Lievesley ja Yee, 2006) Kolmas ongelma ketterien tiimien kanssa työskentelyssä voi nousta esiin mikäli yksi käytettävyysasiantuntija jakaa työaikaansa useamman tiimin kanssa. Usean tiimin kanssa työskennellessä osallistuminen kaikkien tiimien kokouksiin voi viedä työajasta kohtuuttoman paljon aikaa verrattuna itse suunnittelutyöhön (Miller ja Sy, 2009). Mikäli vähäisiä resursseja lisäksi käytetään epätasaisesti tiimien välillä, voi käytettävyysasiantuntijan osoittamalla priorisoinnilla olla vaikutus myös vähemmälle huomiolle jäävän tiimin työmoraaliin. Myös dokumentointikäytäntöjen erot saattavat aiheuttaa ongelmia. Useimmat

25 LUKU 4. YHDISTÄMISESSÄ HAVAITTUJA ONGELMIA 21 käytettävyysasiantuntijat mieltävät tietyt suunnitteludokumentit välttämättömiksi asioiden eteenpäin kommunikoimiseksi (esimerkiksi ohjelmistokehittäjille), kun taas ketterien menetelmien filosofia on tuottaa mahdollisimman vähän dokumentaatiota ja luottaa suullisesti käytyihin keskusteluihin (Chamberlain et al., 2006). Erot dokumentointitavoissa saattavat johtaa myös kommunikaatiokatkoksiin, jos toinen osapuoli luottaa kirjoitettuihin raportteihin ja toinen suullisiin raportteihin. Kommunikaatiokatkokset saattaa ilmetä esimerkiksi väärinymmärrettyinä käyttöliittymäsuunnitelmina, tiimin erimielisyytenä suunnitellusta käyttöliittymästä sekä tärkeän informaation katoamisena (Miller ja Sy, 2009). 4.3 Eri näkemys käyttäjästä Ketterät menetelmät keskittyvät asiakkaaseen, mutta asiakas ei usein ole itse tuotteen loppukäyttäjä. Tämä aiheuttaa ongelmia, mikäli ketterässä tiimissä ei ole henkilöä, joka pystyy edustamaan todellista käyttäjää kehitettävälle tuotteelle. (Nodder ja Nielsen, 2008; Wolkerstorfer et al., 2008) Silloinkin kun asiakas ja käyttäjä ovat sama taho, Sy (2007) havaitsee ongelmaksi ketterien menetelmien suuren riippuvuuden palautteesta. Käyttäjien mielipiteen kuuntelua parempi menetelmä on usein käyttäjien havainnointi. Väite pohjautuu monien käytettävyysasiantuntijoiden (muun muassa Nielsen, 1993; Shneiderman ja Plaisant, 2005) näkemykseen, että käyttäjän tarkkailussa syntyvät havainnot ovat olennaisempia kuin käyttäjän suullisesti esittämät ideat.

26 Luku 5 Keinoja ongelmien ratkaisemiseksi Tässä luvussa esitellään edellisessä kappaleessa havaittujen ongelmien ratkaisuideoita. Ratkaisuideat on ryhmitelty neljään päätason ideaan, jotka kukin on esitelty omassa alaluvussaan. 5.1 Muutoksia syklijärjestelmään Luvussa 4.1 käytiin läpi ongelmia liittyen välittömään kehitystyön aloittamiseen projektin alussa. Tässä luvussa käsittelemme ehdotettuja muutoksia ketterien menetelmien syklijärjestelmään, jotka pyrkivät korjaamaan tätä ongelmaa. Detweiler (2007) ehdottaa lobbaamaan erillisiä, pelkästään vaatimusmäärittelyyn omistautuneita kehityssyklejä ja pitää tätä tärkeänä erityisesti projekteja käynnistettäessä. Hänen mukaansa kehittäjiä voi näissä sykleissä hyödyntää asiakaskäynneillä kerätyn tietoaineiston jalostamiseen. Myös Ungar ja White (2008) ja Sy (2007) ehdottavat niin sanotun syklin nolla (engl. cycle zero) käyttöä projektien alussa antamaan käyttöliittymäsuunnittelijoille etumatkaa kehittäjiin, joskaan eivät vaadi niiden keskittyvän pelkästään vaatimusmäärittelyyn. Budwig et al. (2009) ehdottaa lisäksi neljännesvuosittaisia visiointisyklejä (engl. design vision sprint) normaalin syklikierron lomaan estämään kokonaiskuvan kadottamista (katso luku 4.1). Budwig et al. suorittaman casetutkimuksen mukaan tämän avulla saavutetaan yhtenäisempiä ja parempia käyttöliittymäsuunnitelmia. 22

27 LUKU 5. KEINOJA ONGELMIEN RATKAISEMISEKSI 23 Nielsen (1992) taas esittää, että alkuvaiheen käytettävyyteen liittyviä työtehtäviä voi teetätyttää osana markkinatutkimusta, jolloin ne on tehty jo ennen ohjelmistosuunnittelun aloittamista (tämä ohje on annettu jo ennen ketterien menetelmien yleistymistä, mutta lienee nyt entistä ajankohtaisempi). Constantinen (2002) mukaan etukäteen tehtävien asioiden määrä ei kuitenkaan tarvitse olla niin suuri kuin usein mielletään, vaan kolme asiaa riittää. Ensiksi yleisen rakenteen kuvaus kaikille käyttöliittymän osille, siten että se sopii käyttäjän tehtävien rakenteeseen. Toiseksi joustava yleiskaavio navigointiin eri käyttöliittymän osien välillä. Kolmanneksi visuaalinen suunnitelma ja vuorovaikutussuunnitelma, joka takaa yhtenäisen käyttötuntuman (engl. look-andfeel) eri eri osioiden välillä. (Constantine, 2002) Kuva 5.1: Rinnakkaiset polut (kuva Sy, 2007, s. 118) Sen lisäksi, että käyttöliittymäsuunnittelijat tarvitsevat etumatkaa projektin alussa, on huolehdittava että etumatka säilyy projektin aikana. Sy (2007) esittää ratkaisuksi rinnakkaisia polkuja ohjelmistokehittäjille ja käytettävyysasiantuntijoille (kuva 5.1). Ideana on se, että käytettävyysasiantuntijat suunnittelevat syklissä yksi käyttöliittymän niille ominaisuuksille, joita ohjelmistokehittäjät arvioivat tekevänsä syklissä kaksi. Lisäksi käytettävyysasiantuntijat tekevät syklissä yksi jo käyttäjätutkimusta ja -analyysia ominaisuuksille, joita ohjelmistokehittäjät tekevät arviolta syklissä kolme. Lisäksi käytettävyysasiantuntijat suorittavat käytettävyystestausta edellisessä syklissä valmiiksi saatuun ohjelmistoon, tarkistaakseen että lopullinen ratkaisu on toimiva. Ongelmaksi jää enää vain ihan projektin alku ja ensimmäiset syklit, mutta tämä voidaan ratkaista aloittamalla ohjelmistokehitys ohjelmistoarkkitehtuu-

28 LUKU 5. KEINOJA ONGELMIEN RATKAISEMISEKSI 24 rista, mikä vaatii tuekseen vain vähän tai ei ollenkaan käyttöliittymäsuunnitelmia. (Sy, 2007) Kuva 5.2: Erilliset ketterät tiimit ohjelmistokehittäjille ja käytettävyysasiantuntijoille (kuva Budwig et al., 2009, s. 3082) Edellä esitetyssä Syn rinnakaisten polkujen mallissa ohjelmistokehittäjät ja käytettävyysasiantuntijat ovat edelleen samassa tiimissä. Budwig et al. (2009) puolestaan kertoo case-tutkimuksesta, jossa päädyttiin hajottamaan nämä kaksi ryhmää kokonaan erillisiin ketteriin tiimeihin. Kummallakin tiimillä oli myös omat tuoteomistajat (kuva 5.2). Syn ja Budwig et al. näkemykset ovat mielenkiintoisella tavalla ristiriitaiset. Sy painottaa omassa esimerkissään kommunikoinnin tärkeyttä tahojen välillä ja sitä kuinka käytettävyysasiantuntijoiden on osana ketterää prosessia otettava myös ketterän filosofian kanssa paremmin yhteensopiva lähestymistapa kommunikointiin (katso lisää luvusta 5.4). Budwig et al. toisaalta puolustavat heidän päätöstään jakaa tahot eri tiimeihin, vaikkakin myös he näkee runsaan kommunikoinnin tahojen välillä tärkeänä. Myös Nodder ja Nielsen (2008) pohtivat rinnakkaisten syklien riskejä ja näkevät kommunikoinnin puutteen eri leirien välillä vakavana riskinä. Olivat käyttöliittymäasiantuntijat ja ohjelmistokehittäjät samoissa tai eri tiimeissä, Chamberlain et al. (2006) havaitsevat tutkimuksessaan, että ohjelmistokehittäjien ja käytettävyysasiantuntijoiden välille syntyy merkillisen helpos-