SEPA päiväkirja. Dokumentti: SEPA_diary_EM_PV.doc Päiväys: Projekti : AgileElephant

Transkriptio

1 AgilElephant T Esa Mommo, 57197J Pauli Vesterinen, 65220P Tekijä: Esa Mommo/Pauli Vesterinen Omistaja: ElectricSeven Aihe: Sivu 1 of 8

2 Dokumentti Historia Revisio Historia Revision Numero Revision Päiväys Yhteenveto muutoksista Revision tekijä Ensimmäinen versio Esa Mommo I1 vaiheen havainnot lisätty Pauli Vesterinen I1 vaiheen havaintoja lisää Esa Mommo Yhteenveto I1 vaiheen havainnoista Pauli Vesterinen Dokumentin rakennetta muutettu Esa Mommo I2 vaiheen tulokset lisätty. Esa Mommo Hyväksyjät Tämä dokumentti vaatii seuraavien henkilöiden hyväksymiset Nimi Seppo Sahi Tehtävä Mentor Jakelu Tämä dokumentti jaetaan seuraaville henkilöille Nimi Projektiryhmä Tehtävä Aihe: Sivu 2 of 8

3 Sisällysluettelo 1. Esittely Tarkoitus Menetelmän kuvaus Viittaukset Käyttöönotto Kokemukset ja muutokset PP-vaihe I1-vaihe I2 -vaihe FD-vaihe Yhteenveto...8 Aihe: Sivu 3 of 8

4 1. Esittely 1.1 Tarkoitus Tämän dokumentin tarkoitus on kuvata AgilElephant projektissa käytettyä SEPA-menetelmää. Menetelmän valinta perustellaan tämän dokumentin luvussa 1, luku sisältää myös menetelmän esittelyn. Luvussa 2 esitellään suunnitelma menetelmän käyttöönotolle. Lukuun 3 kirjataan kokemuksia ja havaintoja menetelmän hyödyistä ja sopivuudesta tämän projektin tarpeisiin. 1.2 Menetelmän kuvaus Käytämämme SEPA menetelmä on heuristinen arviointi (heuristic evaluation), joka suoritetaan järjestelmällisellä katselmoinnilla, jonka avulla pyritään tarkastelemaan käyttöliittymän käytettävyyttä. Arvioinnissa käytetään useita arvioijia, joista jokainen ensin suorittaa arvioinnin yksin ja vasta sen jälkeen arvioijat voivat keskustalla ja koota löydetyt havainnot yhteen. Tällä varmistetaan se että toisten arvioijien löytämät viat eivät vaikuta muiden arviointeihin. Kukin katselmoija kirjoittaa omat havaintonsa arviointitilaisuuden aikana ja yhteenvedon eri havainnoista tekevät tilaisuuden järjestäjät. Valitsimme aiheen jonka tarkoituksena on parantaa tuotteen käytettävyyttä, koska käytettävyys on äärimmäisen tärkeä ominaisuus kehitettävässä järjestelmässä. Käytön helppous vaikuttaa merkittävästi siihen, ottavatko käyttäjät järjestelmän ylipäätään käyttöön. 1.3 Viittaukset Nielsen, Riihiaho, Käytettävyyden arviointi ilman käyttäjiä Aihe: Sivu 4 of 8

5 2. Käyttöönotto Heuristinen arviointi suoritetaan projektin aikana kaksi kertaa, vaiheiden I1 ja I2 loppupuolella. Arvioinnin ajankohta määräytyy melkein suoraan siitä miten projekti etenee, koska tarvitsemme ainakin jossain määrin valmiin käyttöliittymän arvioitavaksi. Käytämme arvioinnin suorittamiseen 2 4 henkilöä riippuen siitä miten katselmoijia on saatavilla. Pyrimme käyttämään katselmointiin projektin ulkopuolisia henkilöitä, mutta jos tarvittavaa määrää ulkopuolisia ei ole käytettävissä niin voimme siinä tapauksessa käyttää katselmoijina myös projektiryhmän jäseniä. Nielsen suosittelee optimaaliseksi määräksi katselmoijia 4 henkilöä. Ennen varsinaista katselmointitilaisuutta järjestetään perehdyttämistilaisuus, jossa katselmoijille esitellään lyhyesti järjestelmä ja selitetään mihin sitä on tarkoitus käyttää. Lisäksi kerrotaan miten heidän tulee toimia katselmointitilaisuudessa, mm. miten havainnot kirjataan ylös ja mihin asioihin on erityisesti kiinnitettävä huomiota. Perehdyttämistilaisuuden kesto on noin 30 minuuttia. Katselmointitilaisuus järjestetään jossain rauhallisessa paikassa, missä kaikki katselmoijat pääsevät ensin yksin mutta samanaikaisesti perehtymään käyttöliitymään. Yksin suoritettavan arvioinnin aikana katselmoijat eivät saa kommunikoida keskenään, tämän osuuden kesto on noin 1 tunti. Välittömästi tämän jälkeen järjestetään keskustelutilaisuus, jossa eri katselmoijat voivat vaihtaa mielipiteitä ja havaintoja järjestelmästä, lisäksi havainnot kootaan yhteen. Aihe: Sivu 5 of 8

6 3. Kokemukset ja muutokset Aikataulu syistä johtuen jouduimme I1 vaiheessa hiukan modifioimaan heuristisen arvioinnin suoritustapaa. Kun alun perin oli tarkoitus suorittaa arviointi yhdessä tilaisuudessa, jossa olisivat mukana kaikki arvioijat, mutta sen sijaan jouduimme suorittamaan kaksi erillistä arviointitilaisuutta ja kokoamaan itse yhteen saadut arviot tuotteen käytettävyydestä. Sovimme että käytämme I2 vaiheen lopussa arvioinnissa SoberIT tutkijoita, jotta saisimme arvioijiksi sellaisia henkilöitä joilla on ymmärrystä ja kokemusta ketteristä menetelmistä ja vielä tarkemmin SEMS menetelmästä. Aikataulujen yhteensopimattomuuden vuoksi jouduimme kuitenkin siirtämään tämän katselmointi tilaisuuden seuraavan vaiheen puolelle, mutta katsoimme kuitenkin asiantuntemuksen tarpeen arvioijille niin tärkeäksi, että päätimme hyväksyä tämän muutoksen ja todeta että I2 vaiheessa keskityimme lähinnä seuraavan katselmointitilaisuuden suunnitteluun. 3.1 PP-vaihe Projektin suunnittelu vaiheessa käyttöliittymä-arviointia on huomattavan hankalaa suorittaa, joten tässä vaiheessa voi ainoastaan tehdä suunnitelman arvioinnin tekemiseksi. 3.2 I1-vaihe Käytettävyyttä arvioitiin I1-vaiheessa tehdyn HTML prototyypin avulla. Esan suorittamassa arviointitilaisuudessa oli kaksi arvioitsijaa, molemmat systeemisuunnittelijoita, heistä toisella ei ollut lainkaan kokemusta ketteristä menetelmistä ja toisella oli jonkin verran kokemusta, lähinnä pariohjelmoinnista. Kummallakaan arvioijista ei ollut luonnollisestikaan mitään tietoa SEMS järjestelmästä. Johtuen arvioijien taustasta aluksi pyrittiin käymään ketterien menetelmien ja SEMS järjestelmän pääpiirteet yleisellä tasolla läpi, minkä jälkeen kerroin arvioijille hiukan AgilElephant järjestelmästä. Lisäksi kerroin arvioijille, että heidän pitää löytää nimenomaan käytettävyyteen liittyviä ongelmia. Perehdyttämistilaisuus kesti noin 30 minuuttia ja itse arviointi havaintojen keräämisineen kesti myös noin 30 minuuttia, eli koko tilaisuuden kesto oli noin 1 tunti. Arviointitilaisuudessa annoin myös hiukan vinkkejä siitä mitä pitäisi tehdä, vaikka sellainen ei periaatteessa kuulu heuristiseen arviointiin. Arviointitilaisuudessa tehdyt havainnot(monet havainnot yhteenvetoja useasta samankaltaisesta havainnosta): - järjestelmä vaikuttaa sekavalta - missä on kehitettävä(t) tuote/tuotteet? - käsitteet epäselviä (Esa kommentti: ymmärrettävää ko. perehdyttämisellä) - miksi toiminnot(actions) ovat omassa laatikossaan - miten näkee tuote backlogissa olevat aiheet(item) - missä ovat release backlogissa olevat aiheet(item) Pauli järjestämässä arvioinnissa oli yksi arvioija, jolla ei ollut aiempaa kokemusta ohjelmistokehityksestä. Myöskin SEMS ja ketterät kehitysmenetelmät olivat uusia asioita. Tältä pohjalta pidetyssä perehdyttämistilaisuudessa tutustuttiin ketterien menetelmien tarkoitukseen ja käyttöön sekä AgilElephant -systeemiin. Aikaa kului opiskeluun noin 25 minuuttia. Varsinaiseen arviointiin kului noin 35 min, jolloin kokonaisajaksi tuli tunti. Myöskin itse arvioinnin aikana piti arvioijalle selittää käsitteitä ja käyttötarpeita, johtuen arvioijan taustasta. Seuraavassa lista havainnoista käyttäjältä: - Keltainen on huono väri, näkyy huonosti (prioriteetti) Aihe: Sivu 6 of 8

7 - Jokaisella sivulla olevat laatikot pitäisi olla suhteutettuja toisiinsa, ei silmäänpistäviä porrastuksia laatikoiden välillä. esim actions-laatikon ja päälaatikon alareunojen välinen porrastus, tyhjää tilaa liikaa alareunassa - Visuaalisesti ankea = visuaalisesti yksinkertainen. Muutenkin esim. voisi miettiä fonttien kokoja, itse fontti on kuitenkin selkeä - Actions-laatikon merkitys? Miksi asiat omassa osassaan? - Tietojen muokkaaminen; esim. item:n muokkauksessa jokaisen rivin lopussa edit -nappi tai rasti ruutuun ja muokkaa jolloin voi siis valita, mitä riviä haluaa muokata (samalla lailla kuin movejuttu ). - Timeline-listan laatikkoon on ahdettu paljon asioita pieneen tilaan, selkeämmäksi! Miksi ei voi käyttää sivun tilaa, kun sitä kerran on? Yhteenvetona tehdyistä arviointitilaisuuksista voidaan todeta, että arvioijat pitivät järjestelmää hiukan sekavana ja visuaalisesti ankeana mm. tietyt värit fonteissa näkyivät huonosti. Arvioijat kaipasivat erityisesti kehitettäviä tuotteita, niitä kun ei tuntunut löytyvän mistään. Toimintojen(Actions) kokoamista yhteen erilliseen ikkunaan vierastettiin myös jonkin verran ja se myös koettiin hankalaksi käyttää, toivottiin mieluummin esim. editointi -näppäimiä. Järjestelmässä olevien ikkunoiden informaation sullomista pieneen tilaan pidettiin myös huonona ratkaisuna eli toivottiin ilmavuutta järjestelmään. Noin yleisesti voidaan pohtia, onko järkevää lähteä suorittamaan heuristista arviointia näin varhaisessa vaiheessa projektia prototyypin avulla. Mutta tulimme kuitenkin siihen tulokseen, että mitä aikaisemmin käytettävyyden ongelmat havaitaan, sitä nopeammin ne ovat ratkaistavissa. Tässä nimenomaisessa arviointikierroksessa suurimpia ongelmia olivat aikataulu, emme pystyneet järjestämään yhtä ainoaa arviointitilaisuutta, arvioijien kokemattomuus ketterien menetelmien osalta sekä arvioitavan prototyypin keskeneräisyys. 3.3 I2 -vaihe Aikataulujen yhteensopimattomuuden vuoksi I2 vaiheen katselmointitilaisuus siirrettiin seuraavan vaiheen alkuun. Tässä vaiheessa lähinnä tehtiin suunnitelma seuraavan vaiheen arviointitilaisuuteen. Suunnitelma katselmointitilaisuuteen: - kaksi katselmoijaa, SoberIT:n tutkijoita (Jarno Vähäniitty ja Kristian Rautiainen) - katselmoinnissa keskitytään käytettävyyteen mutta arvioijat saavat ottaa kantaa myös ohjelman toimitaan muultakin kannalta (arvioijien asiantuntemusta kannattaa käyttää hyväksi) - käytetään bannedwagonilla olevaa ohjelmaversiota - tilaisuuden kesto 1 tunti - järjestelmään perehdyttäminen, 10 minuuttia - arvioijien itsenäinen järjestelmään tutustuminen, 20 minuuttia - keskustelu ja havaintojen kirjaaminen, 20 minuuttia - lisäksi jätetään 10 minuuttia ns. pelivaraa Yleisesti on huomattava, että yksi tunti on sangen lyhyt aika heuristisen käytettävyyden arviointiin. Mutta koska järjestelmämme on kuitenkin suhteellisen kompakti, niin uskomme että tilaisuus on suoritettavissa yhden tunnin aikana varsinkin jos pyrimme tiukasti pitämään agendasta kiinni. 3.4 FD-vaihe Ynnä muuta tekstiä. Aihe: Sivu 7 of 8

8 3.5 Yhteenveto Tekstiä. Aihe: Sivu 8 of 8