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

Transkriptio

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

2 Dokumentti Historia Revisio Historia Revision päiväys: Seuraavan revision päiväys (päiväys) Revision Numero Revision Päiväys Yhteenveto muutoksista Muutokset merkitty Ensimmäinen versio (Ei) I1 vaiheen havainnot lisätty (Ei) I1 vaiheen havaintoja lisää (Ei) Yhteenveto I1 vaiheen havainnoista (Ei) 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 7

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...7 Aihe: Sivu 3 of 7

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 7

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 7

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ä. 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) - 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? Aihe: Sivu 6 of 7

7 - 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 Tekstiä. 3.4 FD-vaihe Ynnä muuta tekstiä. 3.5 Yhteenveto Tekstiä. Aihe: Sivu 7 of 7