Samalla kun ketterien menetelmien avulla yritetään selviytyä käytettävyysesteistä perinteisessä kehityksessä, ne saavat aikaan uusia uhkia käyttökokemuksen laadulle, tiivistää Jakob Nielsen uusimmassa, ketteriä kehitysmenetelmiä (agile development methods) ja käytettävyyttä tarkastelevassa kolumnissaan.
Amen.
Olen viime aikoina törmännyt useammassakin yhteydessä ketteriin menetelmiin, enkä vielä kertaakaan ole nähnyt tai kuullut, että niillä saataisiin aikaan parempaa tai edes yhtä hyvää käytettävyyttä perinteisellä vesiputousmallilla tehtyihin projekteihin verrattuna. Käytettävyys- ja ketterien menetelmien yhdistäminen ei sekään tunnu olevan homma ihan sieltä helpoimmasta päästä. Lisäksi olen ihmetellyt sitä, että vaikka puhutaan nimenomaan ketteristä menetelmistä, niin eipä se hyvä käyttökokemus siinä ihan niin ketterästi synnykään. Miksei?
”Agile’s biggest threat to system quality stems from the fact that it’s a method proposed by programmers and mainly addresses the implementation side of system development. As a result, it often overlooks interaction design and usability, which are left to happen as a side effect of the coding. This, of course, contradicts all experience of the last 30 years, in which user experience’s importance in system development has steadily increased as we moved from mainframes to PCs to the Web. As the user base and the use cases have expanded, the need for top-notch usability has grown.”
Tuntuu siltä, että ketteryyden nimissä ohitetaan helposti minkä tahansa projektin tärkein tekijä: ihmiset (eli käyttäjät). Jos oikeat käyttäjäkontaktit puuttuvat, määrittelyt jätetään tekmättä ja edetään tekniikka edellä, on tiedossa kosolti arvailua, yrityksiä ja erehdyksiä. Koska oma pääni on ohjelmoitu syntymässä maksimitehovaiheelle, on joskus vaikea ymmärtää miksi asioita on vääntämällä väännettävä sen sijaan, että näin käyttäjätutkimuksen näkökulmasta ne voisi tehdä kerralla oikein. Se ei tarkoita sitä, että unohdetaan iterointi kokonaan, vaan sitä, että tehdään oikeita asioita oikeassa paikassa. Aloitetaan homma käyttäjistä, tutkitaan tarpeet, suunnitellaan – ja otetaan sitten toteutusvaiheessa käyttöön ne ketterät menetelmät. Haluaisin kernaasti uskoa, että sekin olisi mahdollista.
Asiaa Marjut, juuri näin!
Ketterien menetelmien akilleen kantapää on minusta nimenomaan siinä, että tekijät _uskovat_ ottavansa käyttäjien tarpeet hyvin huomioon, koska koko ajan kysytään asiakkaan edustajalta _palaverissa_, että onko tämä nyt hyvä näin, tai voiko tässä kohdassa ryömiä aidan alitse. Samoin tietysti asiakkaan edustajatkin ovat hyvässä uskossa, että he ohjastavat venettä oikeaan suuntaan.
Ehkä ongelma johtuu osittain siitä, että monet tekniikan ihmiset eivät edelleenkään kunnolla ymmärrä, että käyttöliittymä- ja käytettävyyssuunnittelu on ihan yhtä eksaktia menetelmätiedettä kuin ohjelmointikin, vaan sitä pidetään jonain mystisenä taideprosessina.
Käyttäjien tarpeiden selvittämistä ketterän toteutusprojektin aluksi on käsitellyt ainakin Sari A. Laakso GUIDe-paperissaan (http://www.cs.helsinki.fi/u/salaakso/papers/GUIDe-suomeksi.pdf).
Hyvähyvä! GUIDe on kieltämättä oikeilla jäljillä.
Samoja ajatuksia on pyöritelty muuallakin. Selkeästi jotain on pahasti vialla kun implementointi haluaisi iteroida nopeasti, ja UX ihmiset ihmettelee että miten noita nyt sitten voisi auttaa.
Itse olen ajatellut asian niin, että agile-menetelmien suuri virheoletus on siinä, että iterointiin tarvitaan koodaamista.
Ilkan kommenttiin lisäyksenä, että pahimmillaan asiakasta edustaa palaverissa yksi koodareista, jonka tehtävänä on eläytyä asiakkaan rooliin parhaan taitonsa mukaan.
Toisaalta en ole ihan vakuuttunut siitä, että käyttäjätutkimusmenetelmät olisivat ihan kehityksen huipussa vielä nekään. Itse ajattelen, että ketteryyttä tarvitaan myös niihin, jotta niitä voitaisiin herkemmin ottaa käyttöön. (Kevyet menetelmätkin ovat parempia kuin ei mitään.)
En näe suurta ristiriitaa siinä, että ketterää kehitystä hyödynnettäisiin jo suunnitteluvaiheessa, jos vain käyttäjät otetaan jo siinä vaiheessa mukaan. Pitäisihän senkin olla mahdollista.