Avainsana: sovelluskehitys

Sovelluskehityksen vihreällä lehdellä

Ohjelmistojen tehokkuudesta puhutaan aina välillä ja viime aikoina asiaa on käsitelty vihreämmällä otteella Green ICT:n ja Vihreä koodi -teemojen kautta. Etenkin Exoven Janne Kalliola on edistänyt vihreän koodin ajatusmaailmaa ja kirjoittanut aiheesta kirjan: Vihreä koodi. Helmikuun alussa (8.2.2023) Koodia Suomesta järjesti vihreästä koodista webinaarin ja tässä on muutamia muistiinpanojani siitä.

Vihreä koodi (kirjan kansikuva)

Muistiinpanot Vihreä koodi -webinaarista

ICT-ala ja kasvihuonepäästöt

  • ICT-ala vastaa 4-10% maailman energiankulutuksesta ja 2.1-3.9% kasvihuonepäästöistä (lentoteollisuuden kokoinen)
  • 3% => 1 580 000 000 tonnia / vuosi
  • päästöt tulevat monesta asiasta, käyttäjien laitteista, siirtoverkoista, datakeskuksista
  • sekä niiden rakentamisesta että käytöstä

Rauta

  • elektroninen jäte on maailman nopeiten kasvata jätemäärä, vain 17% jätteestä käsitellään asiallisesti
  • kierrätys on energiaintensiivista

Ohjelmistot

  • Tehokkuus ja ympäristönäkökulmat ovat toissijaisia asioita kehityksessä
  • Lisää rautaa rajalle (eri budjetista)
  • Olisi tärkeää ulottaa vastuu sovelluskehitykseen

Energiantuotanto tuottaa eri määrän hiilijalanjälkeä riippuen maasta

  • Suomi 54gCO2/kWh, Saksa 349gCO2/kWh

Laitteet ja päästöt

  • Valmistus vie suurimman osan päästöistä
  • Käyttö 15-18% koko elinkaaresta -> Älä osta turhaan uusia laitteita

Päästöjen mittaaminen

  • Monimutkaista mitata eri osa-alueiden takia
  • Joten, mitä tehokkaampi ohjelmointikieli ja mitä vähemmän aikaa se on ajossa, sen vähemmän käyttää sähköä, mitä vähemmän siirretään dataa, sen vähemmän tuottaa päästöjä -> Hukan ja päästöjen vähentäminen (Lean)

Hukan tyyppejä

  • ylimääräiset sovellukset
  • sovellusta käytetään vääriin tehtäviin
  • käyttäjävirheet: ei saada aikaan mitä halutaan
  • väärä arkkitehtuuri: ei täytä tarkoitusta tai vaatimuksia
  • väärä datamalli: datamalli ei vastaa käyttöä
  • ylimääräinen data: tyypillisesti vanhan datan säilyttäminen, tarpeettomat raportit ja siihen datan keruu
  • ei optimoitu data: ei pakattu
  • siirretään dataa varmuuden vuoksi: ei siirretä vain deltaa
  • algoritmien tehottomuus: vanhalle arkkitehtuurille tehty
  • käyttäjän huijaus: dark patternit
  • liikaa koodia: ei poisteta vanhaa koodia (ihmiset käyttää vaan 5% kirjastojen koodista)
  • väärä ohjelmointikieli: ei käytetty tehtävään optimointia kieltä
  • initialisoinnin hukka: run-once ohjelmistokielet kuten PHP
  • liikaa tavaraa: silmäkarkki tai videot, jotka eivät tuo arvoa käyttäjälle, esim. turha animaatio että algoritmi tekee jotain

Hukan poistaminen

  • vaatii analysointia, mitä poistetaan
  • iso vaikutus, pieni työmäärä => tee heti
  • iso työmäärä, pieni vaikutus => mieti asiaa
  • iso vaikutus, käyttökokemus heikkenee => mieti asiaa
Hukan vähentäminen: arvioi vaikutus ja työmäärä

Minimaalinen ratkaisu

  • tee pieni sovellus, joka keskittyy päätoiminnallisuuksiin ja tekee ne hyvin

Käytännön ratkaisuja

  • vähennetään datan määrää (jota siirretään)
    • valitaan oikeat kuvamuodot (webp)
    • välimuistetaan kaikki mikä järkevää
    • pakataan kaikki
    • minimoidaan virheiden mahdollisuudet
    • vähennetään videoiden määrää, korvataan ne animaatioilla tai kuvilla
    • kasvatetaan datan lähettämisen aikaväliä
    • poistetaan fonteista turhat leikkaukset ja glyphit
  • vähennetään koodin määrää
    • poistetaan kuollut koodi
    • mietitään uusien kirjastojen käyttöönottoa, tarkistetaan niiden koko, älä tee itse jos voit käyttää kirjastoa
    • parsi kirjastosta se osa, jota tarviit (jos lisenssi sallii)
  • paranna koodin tehokkuutta
    • etsi ohjelmiston hot spotit ja optimoi ne, mutta älä muuta
    • älä optimoi ennenaikaisesti, keskity isoon kuvaan
    • käytä oikeita algoritmeja tehtävään
    • harkitse kriittisten osien kirjoittamista eri kielellä (tehokkaammalla), jos mahdollista

Energiansäästö on matka

  • tärkeintä on ottaa ensi askel
Vihreä koodi: tärkeintä on ottaa ensiaskel.

Agile Community -päivä 3.6.2015

Ketterien menetelmien hyödyntäminen sovelluskehityksessä on nykyään arkipäivää, mutta ketteryyttä voi harjoittaa monella eri tapaa. Erilaisia menetelmiä on useita ja harvoin ne aivan suoraan soveltuvat käytettäväksi ketterissä projekteissa, joten oli hyvä kuulla CGI:n Agile Community -päivässä, miten SAFe oli otettu käyttöön asiakkaalla, miten DSDM:ää hyödynnetään Iso-Britanniassa ja mikä on LeSS. Hyvää jatkumoa viime syksynä Agile Community -päivälle. Tässä lyhyt yhteenveto tilaisuudesta.

Käytännön kokemuksia SAFen käyttöönotosta

SAFe eli Scaled Agile Framework on yksi menetelmä ketterän kehityksen, tai tässä tapauksessa, Scrumin skaalaamiseen isompia projekteja ajatellen, josta Anna Ferguson kertoi käytännön kokemuksia. Vuoden aikana on vesiputous-mallia käyttävästä kehityksestä siirrytty SAFen soveltamiseen, joka ei ole ollut aivan yksinkertaista, sillä muutos ei tapahdu hetkessä, jos kehitystä on tehty vesiputous-mallilla 20 vuotta. Tärkeänä osana muutosta on ketterän kehityksen perusperiaatteiden ja ketterien julkaisujunien valmentaminen. Käytännönläheistä tekemistä. Ei ole yhtä oikeaa tapaa toteuttaa SAFea, vaan se vaatii soveltamista.

Tavoitteena oli saavuuttaa niitä etuja, joita ketterä kehitys mahdollistaa, eli aikaista arvontuottoa, nopeuttaa läpimenoaikaa pienentämällä eräkokoa, saada parempi palautesykli asiakkailta ja rajoittaa yhtä aikaa käynnissä olevan työn määrää. Lean-periaatteita. Asiaa lähdettiin edistämään kahdella pilotilla ja SAFen julkaisujunien valmennuksella. Tavoitetilassa ylläpitotiimeissä käytettäisiin Kanbania ja kehityksessä SAFea palveluiden tuottamiseen ketterien julkaisujunien kautta. Tärkeänä osana muutosta oli myös koulutus SAFeen ja henkilökohtaisten kehityssuunnitelmien tekeminen.

Tehtävien osa-alueet

Tavoitteet

Työvälineinä käytössä olivat muun muassa JIRA ja siihen saatava Structure-lisäosa, joskin Portfolio-lisäosa olisi parempi. Testiautomaatiossa oli hyödynnetty CA Service Virtualisointia ja Silk Testiä.

Poimintoina kokemuksista mainittakoon, että muutos ketteryyteen vaatii valmennusta. Aikaa menee keskusteluun käyttäjätarinoiden ja määrittelyiden suhteesta ja edelleen tehdään helposti liian tarkkoja määrittelyitä jo alkuvaiheessa. Pienien eräkokojen, ketteryyden minimikriteerien määrittely ja testiautomaation tärkeyttä ei voi myöskään sivuuttaa. Ongelmana voi olla myös henkilöiden allokaatio. Testauksen kannalta oleellista on, miten ominaisuudet ovat jaettu, että ne ovat järkevästi testattavissa.

Uuden työtavan käyttöönotto ei koskaan suju ilman muutosvastarintaa, mutta asioihin tottuu. Omissa huoneissa -tekemisestä on vaikea siirtyä yhdessä tekemiseen, sopiiko menetelmä juuri meidän liiketoimintaan, jos ei tehdä määrityksiä ennalta, miten tiedetään mitä tehdään ja koska tarinat ovat pieniä, miten nähdään kokonaiskuva. Tekemistä ei kannatakaan verrata suoraan SAFe-malliin, vaan siihen, missä vuosi sitten oltiin ja kuinka pitkälle ollaan päästy. Vaikka tekemissä ei ollut erikoisia metriikoita, on vuoden julkaisuaikataulusta päästy kolmeen kuukauteen.

Dynamic Systems Development Method, eli DSDM

Päivän toinen aihe käsitteli DSDM:ää, eli Dynamic Systems Development Methodia. Tämä oli itselle uusi tuttavuus ketterien menetelmien osalta ja hieman avoimeksi se kyllä esityksenkin jälkeen jäi. DSDM:stä kuultiin videon välityksellä, joka nopeaan puhumiseen yhdistettynä ei ollut se tehokkain media esittää asia.

Ketteryys on jo vakiinnuttanut asemansa ja erilaisia metodeita on kehitetty erilaisiin lähestymistapoihin ja konteksteihin. Valinnanvaraa oikean työkalun valinnassa tehtävään riittää: Scrum, Kanban, SAFe, Xp ja DSDM. DSDM:n voi kiteyttää olevan iteratiivinen ja inkrementaalinen ketterämalli, joka on saanut alkunsa sovellusten kehityksestä, mutta kattaa nykyään näkymän tietojärjestelmään (bisnes, projekti, teknologia). Vuonna 1994 julkaistiin ensimmäinen versio mallista, 2007 toinen Atern -nimellä ja 2014 APF.

DSDM:n Atern -versiota voi kuvata lyhyesti seuraavien kuvien avulla, jotka esittävät projektin muuttujia ja elinkaarta.

DSDM ja projektin elinkaari (dsdm.org)

DSDM ja projektin muuttujat (dsdm.org)

DSDM:stä ei oikein selkeää kuvaa tullut, mitä se käytännössä tarkoittaa ketterän kehityksen kannalta, mutta jos asia kiinnostaa, niin siitä voi lukea lisää vaikka Wikipediasta.

LeSS is more

Vähemmän on enemmän? Kysymys pitää paikkansa, mutta tällä kertaa ei ole kyse sananmukaisesti vähemmästä tai tarkoiteta CSS-tyylien kirjoittamiseen tarkoitettua kieltä, vaan ketterän teeman hengessä puhe on Large-scale Scrumista. Tiina Jääheimo kertoi suhteellisen uudesta menetelmästä skaalata Scrum isompaan kontekstiin, joka tekee asian kevyemmällä ja enemmän Scrum-tyylisellä otteella kuin SAFe. LeSS:n säännöt vakiinnutettiin 2013 ja SAFen tapaan se on lähtöisin Nokiasta. Suomessa on vain yksi sertifioitu LeSS-kouluttuja, Ran Nyman Goseilta.

LeSS on tuotekehitys-kehys, joka laajentaa Scrumia skaalautumiseen liittyvillä säännöillä ja ohjelinjoilla tarjoten Basic LeSS -mallin 2-8 tiimille ja Huge LeSS -mallin yli 8 tiimille. SAFeen verrattuna LeSS säilyttää monet Scrumin käytännöt ja ideat, kuten sen että tiimit työskentelevät samassa sprintissä.

LeSS yleiskuva (less.works)

LeSS ydin (less.works)

Scrumiin verrattuna eroina on muun muassa Sprint planningit, joita on kaksi kappaletta. Yksi suunnittelutilaisuus kaikille tiimeille ja yksi jokaiselle tiimille erikseen. Retroja on myös jokaiselle tiimille erikseen ja yksi yhteinen. Skaalautuvuus näkyy Open Space -keskusteluissa, Town hall -tilaisuuksissa ja Scrum of Scrumeissa, joita pidetään useamman kerran viikossa informaation jakamiseksi ja koordinointia varten. Scrumiin tapaan tiimeillä on omat Sprint backlogit ja päivittäiset Scrum-tilaisuudet. Samoin tuotteen backlogin tarkennus tehdään tiimikohtaisesti asioille, joita tiimi todennäköisesti aikoo toteuttaa. Sprint Review pidetään kaikille tiimeille yhteisenä.

LeSSin periaatteet ovat käytännöllisiä kaikkeen tekemiseen sovelluskehityksessä.

LeSSin periaatteet (less.works)

LeSSissä myös ScrumMasterin ja tuoteomistajan roolit muuttuvat. ScrumMaster ei ole osa tiimiä, eikä tee työtä tiimissä, vaan keskittyy asiaan kokonaisuutena ja palvelee yhdestä kolmeen tiimiä. Tuotteella on yksi tuoteomistaja ja tuotebacklogi, jota useat tiimit tukevat. Tiimit työskentelevät suoraan asiakkaan ja sidosryhmien kanssa. Definition of Done on yhteinen koko tuotteelle ja sen pitäisi olla laaja ja käyttäjäkeskeinen. Tähän tarvitaan organisaatiorakenteen, roolien ja käytäntöjen muutoksia, joka ei välttämättä ole helppoa.

Scrumin tapaan kaikki tekeminen on tiimien sisällä, sisältäen muun muassa jatkuvan palvelun, laadunhallinnan, testauksen ja arkkitehtuurin, vaikka helposti nämä jäävät niin sanotun Undone-osaston vastuulle, joka tekee viimeiset silaukset tuotteelle. Tiimit ovat 7+-2 hengen moniosaaja-tiimejä, jotka tekevät käyttäjälähtöisen ominaisuuden kokonaisuudessa. Projektipäälliköiden on hyvä pysyä poissa tiimien läheltä.

LeSS vaikutti esityksen perusteella käytännönläisemmältä ja selkesti yksinkertaisemmalta lähestymiseltä skaalatuvaan ketterään kehitykseen.

Käytännön Kanban -kurssi oli käytännöllinen

Sovelluskehitystä voi toteuttaa monella eri tapaa ja jo jonkin aikaa ketterät menetelmät ovat olleet esillä parempaan lopputulokseen pääsemiseksi. Ketterät menetelmätkään eivät ole mitään hopeisia luoteja, vaan vaativat menetelmään perehtymistä, sopivien toimintatapojen kehittämistä ja organisaation kouluttamista uutta ajattelutapaa ajatellen. Osallistuin viime viikolla Reaktorin vetämälle ”Käytännön Kanban” -kurssille, jossa perehdyttiin yhteen menetelmään toteuttaa sovelluskehitystä ketterästi läpinäkyvämmin ja paremmin.

Kanban-menetelmä

Lyhyesti tiivistettynä Kanban-menetelmän ideana on toimintatavan ja työtehtävien visualisointi taulujen avulla ja rajoittaa käynnissä olevan päällekkäisen työn määrää ja pyrkiä saamaan työkokonaisuuksia valmiiksi nopealla tahdilla. Uutta työtä ei oteta sisään ennen kuin nykyiset on saatu valmiiksi. Tavoitetta kuvaa iskulause: ”Lopeta aloittaminen, aloita lopettaminen!” eli ”Stop Starting and Start Finishing!”. Prosessin ja organisaation nykytilan ymmärtämisen kautta tavoitellaan kysynnän ja kyvykkyyden tasapainon ylläpitämistä sekä asteittaista parantamista. Kanban-menetelmä liittyy Lean– ja Just-In-Time -ajatteluun ja sana ”kanban” tulee Japanista tarkoittaen visuaalista merkkiä.

”Kanban-menetelmällä tiimi pystyy hallinnoimaan, ennakoimaan ja rytmittämään tapahtumien kulkua tehokkaasti työssään. Menetelmä auttaa tiimiä ymmärtämään, kuinka työ toimii ja tekemään oikeita päätöksiä oikeaan aikaan. Kanban kertoo, milloin kannattaa aloittaa, hiljentää ja lopettaa aktiviteetit työn eri vaiheissa — nykytilanne ja ongelmat on helppo nähdä ja ymmärtää yhdellä silmäyksellä.” – Reaktorin Käytännön Kanban -kurssi

Käytännön Kanban -kurssi

Osallistuin viime viikolla Reaktorin Käytännön Kanban -kurssin, jonka aikana käsiteltiin menetelmän teoreettinen perusta, tärkeimmät periaatteet ja tutkittiin käytännönläheisesti Kanbanin soveltamista. Kerrankin koulutuksen painopiste oli sanalla käytäntö ja se toteutui mielestäni hyvin luentojen, tarinankerronnan, ryhmäkeskustelujen ja harjoitusten avulla. Koulutus painotti aktiivista oppimista ja kaksipäiväisen koulutuksen aikana opimme käytännön harjoitusten avulla muun muassa:

  • Kanban-menetelmän ottaminen käyttöön päivittäisessä työssä olemassa olevia toimintatapoja, rooleja ja vastuita kunnioittaen
  • Nykyisen toimintatavan visualisointi selkeästi ja ymmärrettävästi
  • Tiimityöskentelyn, tuottavuuden ja laadun kehittäminen järjestelmällisesti
  • Esteiden tunnistaminen ja poistaminen tiimien työssä
  • Työn kehittäminen kurssin aikana opittujen mittareiden avulla

Ensimmäinen päivä

Koulutuksen ensimmäisenä päivänä käytiin lyhyesti läpi menetelmän teoreettinen perusta ja tärkeimmät periaatteet, mutta asioiden läpikäynti painottui esimerkkeihin ja tarinoihin, eikä kalvoilta asian läpikäymiseen, mikä toimi mainiosti asian sisäistämisessä. Päivän aika aihetta läpikäydessä ei tullut niinkään tunnetta, että käsiteltäisiin juuri Kanbania, vaan miten töitä pitäisi tehdä parempaan lopputulokseen pääsemiseksi ja miten Kanban-menetelmä liittyy siihen.

Kanban ydinperiaatteet
Kanban ydinperiaatteet

Kurssin pitäjät, Sami Lilja ja Sami Honkonen, ovat käsitelleeet kurssin asioita blogikirjoituksissaan kuten Importance of pull, WIP limits and Kanban system ja How to fix 90% of problems at work, jotka liittyvät ja käsittelevät Kanbanin kolmea ensimmäistä periaatetta.

Teorian läpikäynnistä muistiin kannattaa pistää ainakin Littlen laki (läpimenoaika = keskeneräinen työ / nopeus), eli mikä on keskimääräinen aika tehtävän läpisaattamiseksi. Ei kannata ahnehtia liikaa töitä, sillä eivät ne yhtään nopeammin valmistu. Usein organisaatio yrittää kasvattaa nopeutta, mutta merkittävämpi tulos on pienentää keskeneräisen työn määrää. En tässä käy tarkemmin läpi muita esitettyjä asioita, mutta mainittakoon ”vaihteluväli, ei trendi” (regression to mean), ”kyvykkyys vs. kysyntä” ja ”työn kirjo”. Myös Scrum-bania sivuuttiin nopeasti.

Get Kanban -lautapeli oli oiva
Get Kanban -lautapeli oli oiva

Käytännön ensikosketuksen Kanban-menetelmään sai tehokkaasti GetKanban-pelillä, joka osoitti loistavasti mistä menetelmästä on kyse ja miten sovelluskehityksessä eri vaiheiden merkitys ja läpimenoaika näkyvät lopputuloksessa. Pelin avulla näki, miten Kanban teki työn eri vaiheista läpinäkyvää ja työn tekemisen esteet olivat helpommin ennakoitavissa ja poistettavissa. Tosin peli heitti eteen muutamia poikkiteloja kuten Carloksen ja Peten, joihin oma tiimini kompastui. Ohjelmistokehitystiimin työssä Kanban helpottaa havaitsemaan, onko työn eteneminen estynyt, mikä estää työn etenemisen, mitä on työn alla tällä hetkellä tai kuinka paljon töitä on odottamassa. Toisella pelikerralla tiimini onnistui pelissä paremmin, kun analysoimme hieman tikettien mahdollista läpimenoa, toteutimme automaattiset testit ja muutimme WIP-rajoja. Eli kuten käytännössäkin pitäisi tehdä :)

Päivän päätteeksi esiteltiin Case-esimerkki ”Oma Elisa”-palvelun kehittämisestä ja Ray.fi -sivuston kehityksestä ja millaisia Kanban-tauluja tiimeillä oli ollut käytössä. Muutamina poimintoina esimerkeissä luovuttiin sprinteistä, ei tehty planningia vaan työtä lisää kun tarve ja estimointi tehtiin T-paita koolla läpimenoajasta, ei työmäärästä. Scrumista säilytettiin demot ja retrot ja 2 viikon välein tuotantoon. Lisäksi väki organisoitui vapaammin, ei ollut kiinteitä tiimejä ja WIP-rajat pakottivat parikoodaukseen. Päivittäisissä tilannekatsauksissa käytiin läpi vain laput, jotka olivat olleet pitkään boardilla (täppä per päivä lappuun). Backlogia ei täytetty jatkuvasti, vaan lämmittelyboardilta tuotiin lisää tavaraa, kun noin 2 viikon työt jäljellä.

Esimerkeistä keskustelua herättivät muun muassa miten eri osa-alueet ja niiden hallinta menivät käytännössä ja miten ”päivittäinen agenda” ja ”miten löydän töitä” toimivat käytännössä. Yksinkertaisuudessaan ne voisivat olla seuraavat:

Päivittäinen agenda
Miten löydän töitä?

Toinen päivä

Koulutuksen jälkimmäisenä päivänä keskityttiin Kanbanin soveltamiseen ja osallistujien omien projektien tarkoitukseen ja Kanban-taulujen pohtimiseen. Päivän aikana toteutettiin viisi eri taulua, joka osoitti käytännössä, että Kanban-menetelmä on suhteellisen helppo ottaa käyttöön kaikenlaisissa tiimeissä, eikä liikkeelle pääseminen ei vaadi isoja muutoksia työtapoihin. Organisaation prosesseja lähdetään muokkaamaan asteittain ja askel kerrallaan, ja samalla seurataan jatkuvasti palautetta ja saatuja tuloksia.

Kanban-taulun kehittämisen pohjaksi on hyvä muistaa ja pohtia seuraavia asioita:

Kanban-taulun kehittämisen ohjenuorat
Kanban-taulu on kehittyvä, ei staattinen

Tässä pari esimerkkiä tuotoksista:

Kanban-taulun suunnittelussa kaikkia tehtäviä ei välttämättä kannata merkitä boardille. Esimerkiksi jos on paljon pieniä tehtäviä, eli kohinaa, hyväksytään se. Sitä ei kannata merkata boardille, mutta kannattaa jotenkin seurata sitä, esimerkiksi tukkimiehen kirjanpidolla. Eli nähdään paljon menee aikaa tiskin alta ja triviaaliin työhön.

Systeemiajattelu

Kanban-menetelmän ja mielestäni työelämään yleisestikin liittyvien asioiden lisäksi koulutuksessa käsiteltiin lyhyesti myös systeemiajattelua ja mistä kokonaisuus ja sen suorituskyky muodostuu. Asiaa avasi hyvin Russell Ackoffin ~8 minuutin puhe systeemiajattelusta (tai vitsien kera). ”Systeemi ei ole osiensa summa, vaan yhteistoiminnan tulos”. Asiaa selventää hyvin myös Honkosen ”You are part of a system” -kirjoitus.

Arvo- ja häiriökysyntä

Aiheeseen liittyen käsiteltiin myös arvo- ja häiriökysyntää (Value Demand ja Failure Demand). Asiaa pitää katsoa asiakkaan näkökulmasta, jolloin arvokysyntä on sitä, jota asiakas haluaa ja häiriö kaikkea muuta, kuten bugeja, muutospyyntöjä ja huonoa käyttöliittymää. Lisäksi yrityksen sisäistä häiriökysyntää ovat muun muassa raportointi, palaverit, infrahäiriöt ja odottaminen. Arvioilta 80 prosenttia työstä on häiriökysyntää ja vain 20 prosenttia arvokysyntää, eli sitä mitä pitäisi oikeasti tehdä. Kanban auttaa tekemään häiriökysynnän näkyväksi. Jotkut organisaatiot keskittyvät tekemään häiriökysyntää, kun pitäisi keksittyä tekemään arvokysyntää. Kannattaa olla täten tarkkana, ettei Kanbanilla hallita häiriökysyntää.

Muita läpikäytyä asioita olivat ”tarkoitus -> mittaus -> menetelmät”, ”oikeiden asioiden tekeminen oikein”, ”kysyntäanalyysi” ja ”kysyntä -> arvo -> virtaus”.

Yhteenveto

Reaktorin Käytännön Kanban -kurssin aikana käsiteltiin menetelmän teoreettinen perusta, tärkeimmät periaatteet ja tutkittiin käytännönläheisesti Kanban-menetelmän soveltamista. Kerrankin koulutuksen painopiste oli sanalla käytäntö ja se toteutui mielestäni hyvin luentojen, tarinankerronnan, ryhmäkeskustelujen ja harjoitusten avulla. Kurssilla käsiteltiin paljon asioita ja ongelmia, jotka ovat maalaisjärjellä ajateltuna selviä, mutta ikävän todellisia työpaikoilla. Keskustelu oli antoisaa ja herätti ajatuksia, miten asioita pitäisi kehittää.

Kurssin kuvaus lupaa paljon hyviä lopputuloksia ja ideana ja tavoitteena Kanban-menetelmä vaikuttaa lupaavalta kaaoksen hallintaan. En voi kuitenkaan sanoa, että kurssilla opituista asioista on ollut välittömästi hyötyä oman organisaationi työn kehittämisessä, mutta hitaasti eteenpäin kuitenkin. Tavoitteena on ottaa kurssilla opittuja asioita käyttöön, mutta uuden menetelmän ottaminen samantien osaksi päivittäistä työtä ei ole niin yksiselitteistä etenkään jäykässä organisaatiossa.

Kurssilta sai lisäksi mukaan David J. Andersonin Kanban -teoksen ja kätevän Kanban-lehdykkeen kiireisille johtajille. Lisäksi pitänee lukaista lisää kurssilla käsitellyistä aiheista muun muassa Henrik Knibergin Lean from the Trenches -kirjasta (PDF) ja pohtia Modig Åhlströmin Tätä on Lean -teoksen tai Daniel Kahnemanin Thinking, Fast and Slow -kirjan hankkimista.

Päivitys 28.11.2014: Osallistuin Käytännön Kanban -kurssille toistamiseen loppusyksystä ja tällä kertaa vain oman yksikköni väen kanssa, joka antoi paremman lähestymisen tiimin ongelmien ratkaisemiseen. Sami Lilja veti jälleen mainion kurssin ja sisältö oli suurin piirtein sama kuin keväällä. Nyt oman Kanban-taulun kehittämiseen oli hieman enemmän käytännön kokemusta, mutta osittain myös väen vaihtumisen takia ongelmat olivat samat. Mitä tehdä, kun henkilö on useassa eri asiakkaan projektissa ja ylläpidossa. Miten rajoittaa multitaskingia ja työn hajautumista. Tähän ei vielä löytynyt vastausta, mutta on tärkeää, että ei manageroida henkilöitä, vaan asiakkaalle tehtäviä tehtäviä.

Tietojärjestelmäarkkitehdin valmennusohjelma, osa 2

Kesälomat ovat jo kaukana takana ja paluu arkeen on todellisuutta sekä töiden että osaamisen kehittämisen osalta. Hieman lomien jälkeen jatkui myös Tieturin ”Tietojärjestelmäarkkitehdin valmennusohjelma” -kurssi, jonka ensimmäinen osa pidettiin alkukesästä. Keinoja ja ratkaisuja erinomaiseen arkkitehtuuriratkaisuun pääsemiseksi esittelevän kurssin ensimmäinen osio käsitteli tietojärjestelmäarkkitehdin työssä tarvittavia monipuolisia taitoja, laatuatribuutteja, arkkitehtuurikehyksiä ja 4+1 -mallia. Toinen osio jatkoi aihepiirin käsittelyä muun muassa suunnittelumalleilla, integraatioilla, SOA:lla, tietoturvalla ja arkkitehtuurin arvioinnilla ja dokumentoinnilla. Kuuden päivän kokonaisuus oli aikamoinen annos aiheeseen liittyviä otsikoita ja ajateltavaa ja tarjosikin lähinnä paljon lähtökohtia lisäopiskelulle, eikä niinkään käsitellyt miten asioita pitäisi tehdä. Eli hyvä yleiskatsaus aihepiiriin ja ajattelemisen aihetta tarjoava.

4+1 -mallin kaavioita tilanvarausjärjestelmästä

Tietojärjestelmäarkkitehdin valmennusohjelma, osa 2

Tietojärjestelmäarkkitehdin valmennusohjelman ensimmäisen osion jälkeen tunnelmat kurssista olivat aika teoriapainotteiset, mutta laajan aihepiirin käsittely konkreettisemmin olisi vaatinut vähintään pari päivää per aihepiiri, joten sinällään kurssin yleiskatsauksen omainen lähestyminen aiheeseen oli toimiva. Mutta silti odotukset kurssin jälkimmäiseltä osiolta olivat hieman enemmän. Lupasihan kurssikuvaus, että ”valmennusohjelman suoritettuaan osallistuja osaa tietojärjestelmäarkkitehdin työn kannalta systemaattiset toimintatavat ja merkittävät välineet.”.

Erinomaisen arkkitehtuuriratkaisun saavuttamiseksi keinoja ja ratkaisuja esittelevän kurssin toinen osio jatkoi aihepiirin käsittelyä muun muassa suunnittelumalleilla, integraatioilla, SOA:lla, tietoturvalla ja arkkitehtuurin arvioinnilla, valvonnalla ja dokumentoinnilla. Suurilta osin aihepiirit olivat tuttuja, mutta uusia keinoja parhaiden käytäntöjen metodeihin, arkkitehtuurin arviointiin ja sen testaukseen kyllä ilmeni.

Osa 2, päivä 1:

  • Parhaita käytäntöjä arkkitehtuurisuunnitteluun
    • Attribute Driven Development method (ADD), ketterän arkkitehtuurin suunnittelu, ketterän tiimin suunnittelukäytännöt

Kurssin neljäs päivä alkoi ryhmien saamien kotitehtävien läpikäynnillä, jonka harmillisesti oli tehnyt vain kaksi viidestä ryhmästä. Tehtävänä oli hyödyntää 4+1 -mallia jonkin järjestelmän, keksityn tai olemassa olevan, kuvaamiseen. Ryhmäni suunnitteli kuvitteellisen ”neuvottelutilojen tilanvarauksen ja käytönseurannan integraatio” -sovelluksen, jonka idea oli tehostaa neuvotteluhuoneiden käyttöä. Olimme kuvanneet konteksti-, prosessi-, komponentti- ja sijoittelukaaviot, joista keskustelimme lyhyesti. Olisi ollut kiva nähdä useampienkin ryhmien ratkaisuja, mutta muuten harjoitus oli mielenkiintoinen ideointihetki.

Loppuaika neljännestä päivästä käytiin läpi arkkitehtuurisuunnittelun parhaita käytäntöjä muun muassa toiminnallisten vaatimusten hyödyntämisessä, arkkitehtuurin oikeellisuuden ja suorituskyvyn aikaisessa testauksessa ja käsiteltiin anti-patterneja. Monta maalaisjärjellä perusteltavaa asiaa, mutta todellisuudessa kuitenkin yllättävän hankalia käytännössä viedä läpi, kuten arkkitehtuurin muuttaminen sen osoittautuessa huonoksi, prototyyppien tekeminen tai aloittaminen liian isosti. Harjoituksena käytiin läpi ADD:tä elokuvateatterin lipunvarausjärjestelmän laatuattribuuttien osalta, joista esille nostettiin monikanavaisuus, skaalautuvuus, tietoturva, laajennettavuus, avoimuus, saatavuus, muunneltavuus ja jäljitettävyys. Nykytrendien mukaisesti keskusteltiin myös ketterästä kehityksestä ja sen suhteesta arkkitehtuurisuunnittelun. Vaikka Scrum-projektissa arkkitehtuuri tehdään ”just in time”, on sprint 0 ja ennakkosuunnittelu tärkeää ja projektin alkuvaiheessa painottuu arkkitehtuurin osuus väheten loppua kohden.

Osa 2, päivä 2:

  • Arkkitehtuurin testaaminen
    • Testaamisen ajoittaminen, testaamisessa huomioitavia seikkoja, suorituskyvyn testaaminen
  • Järjestelmien yhteensovittaminen
    • Tietojärjestelmäintegraation haasteet, löyhä kytkeytyvyys, tyypilliset integraatioratkaisut, integraatioarkkitehtuuri, palveluväylät (ESB)
  • Palveluarkkitehtuurin luominen (SOA)
    • Mitä SOA tarkoittaa?, avoin arkkitehtuuri, SOA arkkitehtuurin luominen, arkkitehtuurin toteuttaminen ja haasteet

Viidennen koulutuspäivän aluksi keskustelimme teknisestä velasta, jota tulee sekä tietoisesti että suunnittelun myötä. Jos velkaa on paljon, on sovellusta myöhemmin hankala tai mahdoton refaktoroida kuntoon. Päivän pääteemat olivat kuitenkin arkkitehtuurin testaaminen, järjestelmien integrointi ja palveluarkkitehtuuri.

Sovelluskehitysprojekteissa testauksen rooli usein aliarvioidaan. Testauksenkin osalta pätee 80/20 sääntö, eli 80 prosenttia ongelmista korjataan testaamalla avainvaatimuksia säännöllisesti ja 20 prosenttia ongelmista on haastavia ja hankalia löytää. Ongelmana usein on myös laadukas testiaineisto ja sen määrä. Testaukseen liittyy myös suorituskyvyn arviointi ja nyrkkisääntönä voidaan pitää, että kannattaa varata 3,14 kertaa enemmän kapasiteettia kuin vaadittu. Toiminnallisen testauksen lisäksi pitää huolehtia suorituskyvyn testauksesta, jota käsiteltiin komponenttien ja koodin osalta. Tarjolla on useita avoimen lähdekoodin testausvälineitä, joista mainittiin muun muassa jMechanic ja JProfiler . Lisäksi lyhyesti esiteltiin kaupallista Compuwaren Application Monitoring -tuotetta (entinen dynaTrace). Testauksessa on hyvä muistaa Heisenbergin epämääräisyysperiaate, joka soveltaen on: ”Et voi suorittaa mittausta vaikuttamatta mitattavaan kohteeseen”.

Päivän muut aiheet olivat palvelusuuntautuneisuutta tukeva arkkitehtuurityyli eli SOA ja sovellusten integraatio. Tässä palvelu on looginen esitystapa toistuville liiketoiminnan aktiviteeteille, joilla on määritelty lopputulos, eli se on itsenäinen (itseriittoinen), voi koostua muista palveluista ja on musta laatikko kuluttajilleen. SOA:n rakentaminen pitäisi lähteä liiketoiminnan prosessien tietojärjestelmien tarpeista ja tuottaa aina liiketoiminta-arvoa. Ei kannata myöskään unohtaa, että SOA on kuin koiranpentu, joka vaatii jatkuvaa valvontaa, hoitoa, selkeitä rajoja ja vastuuhenkilöä, eli johtamista. Lisäksi sivuttiin REST-palvelun versiointia ja kuvaamista, kun käytössä ei ole WSDL:ää kuten SOAP-palveluissa. Sovellusten integraatioista käsiteltiin muun muassa erilaisia suunnittelumalleja kuten julkaise-tilaa (Twitter, RSS), sanomaväylät (SETI), vastaavuustunniste (laskun viitenumero), prosessimanageri, sanomakeskus (SMS) ja sääntöjen mukainen tietomalli.

Osa 2, päivä 3:

  • Teknologia-arkkitehtuuri
    • Teknologia-arkkitehtuuri mahdollistajana, liiketoimintalähtöinen teknologia-arkkitehtuuri, teknologioiden hallinta sekä valinta, teknologia-arkkitehtuurin suunnittelu
  • Lisensointimallit
    • Arkkitehtuuri ja lisenssit, Open Source -tuotteet sekä sovelluskehykset, näkökulmia lakiasioihin
  • Tietoturva-arkkitehtuuri
    • Tietoturvan näkökulmat ja tasot, vyöhykkeinen tietoturva, tietoturvan perustekniikat, tietoturvasuunnittelun peruspilarit
  • Arkkitehtuurin käytön valvonta
    • arkkitehtuurin käytön ohjeistus, arkkitehtuurin käytön katselmointi
  • Arkkitehtuurin arvioiminen
    • Arkkitehtuurin laatukriteerit, arkkitehtuurin arvioiminen, Architecture Tradeoff Analysis Method (ATAM) -metodi, Cost Benefit Analysis Method (CBAM)
  • Arkkitehtuurin dokumentoiminen
    • Arkkitehdin rooli dokumentoijana, arkkitehtuurin dokumentoiminen UML-kielellä, muita dokumentoinnin välineitä
  • Arkkitehtuurin hallinnointi
    • Arkkitehtuurin toteutus, arkkitehtuurin muutoshallinta, arkkitehtuuriorganisaatio, vaaditut prosessit

Kurssin viimeinen eli kuudes päivä sisälsi paljon eri aihepiirejä ja alkoi harjoituksella, jossa käytiin läpi sovellus- ja teknologia-arkkitehtuurin yhteyttä ja miten teknologia-arkkitehtuuri täyttää järjestelmän laatuvaatimukset. Teknologia-arkkitehtuurin rooli on mennä syvemmälle ja tarkemmalle tasolle, sekä se voi olla jo olemassa ja sanella asioita sovellusarkkitehtuurille. Tarkoituksena on taata järjestelmän rakennuspalikoiden yhteensopivuus ja dokumentoida valitut teknologiastandardit. Teknologia-arkkitehtuurin suunnittelusta käsiteltiin siihen liittyvät eri vaiheet: lähtötason kuvaaminen, näkökulmien ja työvälineiden valinta, tavoitearkkitehtuurin luominen, liiketoiminnan tarpeiden täyttymisen varmistaminen ja nyky- ja tavoitetilan kuilun analyysi. Teknologiasta olikin hyvä siirtyä lisensseihin ja avoimen lähdekoodin sovelluksiin, joista lähinnä mainittiin, että niitä on moneen lähtöön. Parempi olla tarkkana.

Tietoturva-arkkitehtuuria käsiteltiin sentään hieman laajemmin ja siitä on hyvä muistaa seuraavat kirjaimet: C = Confidentiality, I = Integrity, A = Availability. Arkkitehti valitsee miten tietoturvateknologioita ja työvälineitä käytetään tietoturvan toteuttamiseksi ja tietoturva-arkkitehtuurin rakennuspalikoita ovat: henkilöstön tietoturva tietoisuus ja koulutus, käyttäjähallinta, autorisointi ja autentikointi, toimien vahvistaminen, kriittisten osien eristäminen, tunkeutumisen havaitseminen ja estäminen, salaustekniikoiden käyttäminen ja virustorjunta. Lisäksi kerrottiin OWASP Top 10 -ongelmakohtien listauksesta (pdf) ja ettei kannata jäädä kymmeneen, sillä maailma muuttuu jatkuvasti. Aiheeseen liittyen tehtiin harjoitus elokuvateatterin lippujärjestelmän potentiaalisista tietoturvariskeistä ja niiden hallinnasta.

Tietojärjestelmän arkkitehtuurin voi suunnitella monella eri tavalla, eikä yhtä oikeaa ratkaisua ole, joten arkkitehtuuriratkaisun arviointi on tärkeää. Parasta se olisi suorittaa jo etukäteen, eikä vasta jälkeenpäin, vaikka se tällöin onkin helpompaa. Arvioida voi muun muassa ylläpidettävyyttä ja uusien ominaisuuksien ja bugien korjaamisen helppoutta ja nopeutta. Yksi keino tähän on käyttää ATAM:ia (Architecture Tradeoff Analysis Method) ja CBAM:ia (Cost Benefit Analysis Method), joita voidaan soveltaa arkkitehtuuria luodessa, kun projekti on ongelmissa ja jo olemassa olevaan arkkitehtuuriin.

Yhteenveto

Tietojärjestelmän arkkitehtuurin suunnitteluun on kehitetty erilaisia malleja, kursseja ja sertifiointeja, joiden avulla voidaan tähdätä parempaan lopputulokseen. Tieturin tietojärjestelmäarkkitehdin valmennusohjelma antaa hyvän yleiskuvan laajasta aihealueesta ja on kokonaisuutena aikamoinen annos aiheeseen liittyviä otsikoita ja ajateltavaa. Kurssi tarjosikin lähinnä paljon lähtökohtia lisäopiskelulle, eikä tarkemmin käsitellyt miten asioita pitäisi tehdä, joka olisikin ollut kurssin aikataulun ja aihepiirin laajuuden osalta mahdotonta.

Olisin itse kuitenkin kaivannut ehkä enemmän konkreettisempaa lähestymistä, jota kurssin neljäntenä ja viidentenä päivänä olikin hieman enemmän. Jos kurssista pitäisi mainita yksi mieleen jäänyt asia, on se 4+1 -malli, jonka käyttämistä arkkitehtuurin suunnittelussa käytiin läpi enemmän ja muita aihealueita sipaistaan siihen verrattuna suhteellisen pintapuolisesti.

Kurssi antaa pohjatiedot myös Open Groupin Certified Architect (Open CA) (aikaisemmin ITAC) sertifikaatin ykköstason suorittamiseen (edulliseen 1250 dollarin hintaan), jota pitää harkita.

Yksi sovellus, kolme Java EE -käyttöliittymäkehystä

Sovelluskehityksessä käyttöliittymän rakentaminen ja käyttäjille näkyvien toimintojen toteuttaminen on yksi tärkeimmistä osuuksista, sillä hyväkin sovellus voi kaatua heikkoon käyttöliittymään. Java EE -sovelluskehityksessä on tarjolla useita erilaisia käyttöliittymäkehyksiä, jotka tarjoavat työkalut toimivan käyttöliittymän rakentamiseen, mutta käyttötarkoitukseen sopivan välineen valinta ei ole aina yksiselitteistä. Oli siis aika päivittää hieman tietoja erilaisten Java EE -käyttöliittymäkehysten osalta ja tutustua Vaadin 7:aan, Java Server Faces (JSF) 2:een PrimeFacesin kanssa ja Apache Wicket 6:een toteuttamalla yksinkertainen imgur-kuvaselaussovellus. Aikaisemmin olen kehittänyt sovelluksia käyttäen muun muassa Strutsia, JSF 1.2:sta ja Wicket 1.5:sta.

Java EE 6 -sovelluksia voi toteutta monella eri tekniikoilla ja tällä kertaa toteutin käyttöliittymäkerroksen usealla eri tavalla (Vaadin 7, JSF2, Wicket 6) ja pitäen taustapalvelut vakiona. Imgurin REST-APIn käsittelyyn käytin jokaisessa sovelluksessa Apache CXF:ää rajapinnan lukemiseen ja GSONia JSON-sanoman muuntamiseen Java-olioiksi. Vaikka kaikki kolme kehystä tukevat Java EE 6:n JSR 299 CDI:tä, tein Java Beanien injektoinnin Spring 3:lla, joka toimi varmasti myös vanhemman WebLogic 11g -sovelluspalvelimen kanssa. Jettyllä tai TomEE:llä ajettaessa ei olisi ollut mitään ongelmaa.

Sovellusten koodit löytyvät GitHubista (https://github.com/walokra/fotorest.git), vaikkakaan ne eivät ole mitenkään viimeisteltyjä. Ehkä niistä kuitenkin on jollekin hyötyä.

Sovellus 1: Vaadin 7

Vaadin on avoimen lähdekoodin Java-sovelluskehys Web-sovellusten rakentamiseen ja muistuttaa enemmän työpöytäsovellusten tekemistä esimerkiksi Java Swing -kehyksellä kuin perinteistä Web-sovelluskehitystä HTML:n ja JavaScriptin kanssa. Vaadin rakentuu Google Web Toolkitin päälle ja käyttää GWT:tä sivujen renderöintiin. Vaadin on suomalaisen Turussa pääkonttoriaan pitävän Vaadin Oy:n kehittämä. Vaadin 7 julkaistiin pari kuukautta sitten.

Vaadin tarjoaa perinteiselle Java-kehittäjälle helpomman lähestymisen Web-sovellusten kehittämiseen, kun käyttöliittymän rakentaminen onnistuu ilman HTML:n ja JavaScriptin kanssa askartelua. Vastaavasti HTML:ää osaavalle kehittäjälle Swing-tyylinen käyttöliittymän rakentaminen voi olla tuskastuttavaa. Vaadin tarjoaa itsessään kattavan valikoiman erilaisia käyttöliittymäkomponentteja ja erilaiset demot antavat hyvän kuvan mitä Vaatimella saa aikaan.

Yksinkertaisen imgur-selaajan toteutus Vaadin 7:lla luonnistui nopeasti, kun olin ensin sisäistänyt Swing-tyylisen käyttöliittymän idean. Toimivan ulkoasun ja muutamat toiminnot sai rakennettua suhteellisen helposti ja lopputuloksesta tuli siisti. Koska Vaadin-sovellus on käytännössä kasa Javascriptiä, on sen debuggaaminen hieman hankalampaa, mutta kehys tarjoaa avuksi kohtalaiset työvälineet (?debug-parametri). Käytin Vaatimen oletusteemaa, koska muut teemat eivät vielä uusinta versiota tukeneet. Uuteen kehykseen tutustumisessa auttoi myös Vaatimen laadukas dokumentaatio ja keskustelufoorumi, vaikkakin moni keskustelu ja netistä löytyvä esimerkki käsitteli aikaisempaa 6 versiota.

Fotorest-sovellus toteutettuna Vaadin 7:lla:
Fotorest Vaadin 7

Sovellus 2: JavaServer Faces 2 + PrimeFaces

JSF 2 eli Java Server Faces on Javan spesifikaatio Web-sovellusten komponenttipohjaisten käyttöliittymien rakentamiseen ja osa Java Enterprise Editionia. Sovellus koostuu HTML:ää ja Facelet-tageja sisältävistä -XML-tiedostoista, jotka kehys prosessoi ja tarjoilee käyttäjälle. JSF:n 2 -versio julkaistiin 2009 ja tuorein 2.2. versio huhtikuussa 2013.

Sovelluksen ulkoasun rakentaminen ei juurikaan eroa normaalista Web-kehityksestä, joten HTML ja CSS -osaaminen ovat tarpeen siistin käyttöliittymän aikaansaamiseksi. JSF:n tarjoamia ominaisuuksia ja komponentteja voi laajentaa muun muassa PrimeFaces tai RichFaces -komponenttikirjastoilla, joilla käyttöliittymään saa enemmän kilkettä ja parempaa käytettävyyttä.

JSF 2:n oli sovelluskehitysalustana suhteellisen tuttu, sillä olin käyttänyt sitä pienen prototyypin tekemiseen pari vuotta sitten, eikä vuosien aikana mikään ollut juuri muuttunut. Täten uutena asiana oli enemmänkin PrimeFaces -käyttöliittymäkomponenttien käyttäminen. Yksinkertainen kuvaselaaja syntyi lähes yhtä helposti kuin Vaadinta käytettäessä, vaikka osa toiminnoista piti koodata sivupohjiin ja osa Javan puolelle ja käyttöliittymän dynaamisessa päivittämisessä oli alkuun pieniä ongelmia. PrimeFaces tarjosi kattavan listan erilaisia käyttöliittymäkomponentteja ja niiden ulkoasua oli helppo muokata jQuery UIn ThemeRollerin avulla.

Fotorest-sovellus toteutettuna JSF 2 + PrimeFacesilla:
Fotorest JSF 2 + PrimeFaces

Sovellus 3: Apache Wicket 6

Apache Wicket on avoimen lähdekoodin komponenttipohjainen Web-sovelluskehys Javalle. Lyhyesti kuvattuna Wicket on kuin yhdistelmä Vaadin ja JSF -kehyksiä, sillä käyttöliittymä rakentuu HTML-sivupohjista ja tapahtumiin reakoivista komponenteista. Sovelluksen ulkoasun voi täten rakentaa HTML:llä ja lisätä toiminnot Javan puolelta juurikaan koskematta sivupohjiin. Wicket 6 julkaistiin syksyllä 2009.

Wicket ei JSF:n tavoin tarjoa peruskomponentteja enempää, mutta käyttöliittymän toiminnallisuuksien laajentamiseen voi käyttää useita jQuery-pohjaisia komponenttikirjastoja kuten Wicket – jQuery UI, jqwicket ja wiquery. Vaikka komponenttikirjastoja on useita, ovat niiden heikkous ajantasaisuus (esim. jqwicket vain 1.5 versiolle), eivätkä ne eivät ole aivan yhtä kattavia kuin mitä Vaadin tai JSF:n kirjastot tarjoavat.

Ideana HTML-sivupohjat ja työpöytäsovellusmaisen tapahtumapohjaisuuden yhdistelmä on hyvä, mutta jotenkin kokonaisuus ei ole yhtä miellyttävä kuin JSF 2 tai Vaadin. Kehittäjän kannalta Wicketissä on monia hyviä puolia, kuten toimintojen liittäminen komponentteihin ja niiden uudelleenkäyttö on kätevämpää kuin JSF 2:ssa ja sovelluksen kehittäminen on kohtalaisen selkeää, kun toiminnot ovat yhdessä paikassa eikä sekä sivupohjassa että Java-luokassa kuten JSF 2:ssa. Itseäni eniten Wicketin osalta harmittaa kuitenkin kattavien komponenttikirjastojen puute, joka tekee käyttöliittymän toiminnallisuuksien rakentamisesta hieman työlästä, kun asiat joutuu toteuttamaan itse. Yksinkertaista kuvaselaajaakin varten piti tehdä muutamia lisäluokkia, eikä valmista loputtomasti skrollaavaa taulukkokomponenttia ollut saatavilla.

Fotorest-sovellus toteutettuna Wicket 6:lla:
Fotorest Wicket 6

Yhteenveto

Kolme Java EE -käyttöliittymäkehystä ja kolme erilaista tapaa lähestyä käyttöliittymän rakentamista. Vaadin 7 tarjosi nopeasti siistiä Swing-tyylisesti komponenttien kera, JSF 2 + PrimeFaces luotti perinteisempään komponenttipohjaiseen HTML:ään ja tageihin ja Wicket 6 oli joukosta hieman työläämpi komponenttipohjainen ratkaisu. Kokonaisuutena Vaadin on selkeästi yhtenäisin paketti ja sekä JSF:n että Wicketin kanssa on hieman enemmän askarreltavaa, joka toki myös tarjoaa vapauksia.

Jokaisella kehyksellä sai aikaan suhteellisen pienellä vaivalla yksinkertaisen imgur-kuvaselaajan haun kera. Jos pitäisi saada nopeasti valmista, niin kenties toteuttaisin sen Vaatimella, jolloin aikaa ei mene niin paljoa käyttöliittymän kanssa taisteluun. Valmiiden sivupohjien kanssa JSF 2:llakin syntyy koodia nopeasti. Kaikissa kolmessa on kyllä omat jekkunsa ja ”ongelmansa” muun muassa sessioiden koon ja selaimen kuormittavuuden osalta.

Seuraavaksi tutustumislistalla JVM:ssä toimivien kehysten osalta on ehkä Spring MVC, Play Framework, Grails ja puhdas GWT. Lisäksi Node.js:llä toteutettu kuvaselain on jo osittain tehty.

Tietojärjestelmäarkkitehdin valmennusohjelma, osa 1

Tietojärjestelmät eivät rakennu itsestään, vaan niiden kehitys vaatii monia askelia vaatimusmäärittelystä, suunnitteluun, toteutukseen, testaukseen ja toimittamiseen. Yksi tärkeä askel on järjestelmän arkkitehtuurin suunnittelu, joka luo perustan onnistuneelle ratkaisulle. Tietojärjestelmän arkkitehtuurin suunnitteluun on kehitetty erilaisia malleja, kursseja ja sertifiointeja, joiden avulla voidaan tähdätä parempaan lopputulokseen. Tieturi on useamman vuoden ajan järjestänyt 3+3 -päiväistä ”Tietojärjestelmäarkkitehdin valmennusohjelma” -kurssia, jossa käsitellään tietojärjestelmäarkkitehdin työssä tarvittavia monipuolisia taitoja ja keinoja erinomaiseen ratkaisuun pääsemiseksi. Osallistuin kurssin ensimmäiselle kolmipäiväiselle teoria- ja alustuspainotteiselle osiolle alkuviikosta ja tietämystä kertyi suurilta osin avainteemoista ja 4+1 -mallin hyödyntämisestä. Kurssin toinen osa on edessä syksyllä.

Jatka lukemista ”Tietojärjestelmäarkkitehdin valmennusohjelma, osa 1”

Ihmisen ja tietokoneen vuorovaikutus -kurssi: loppuosa

Stanfordin “ihmisen ja tietokoneen vuorovaikutus” -verkkokurssi Courserassa, eli englanniksi Human-Computer Interaction (HCI), päättyi muutama kuukausi sitten ja sen viimeiset pari viikkoa käsittelivät visuaalista suunnittelua, informaatiosuunnittelua, kokeiluiden suunnittelua ja suorittamista laboratoriossa ja webissä ja tulosten analysointia. Kurssin alkuosa oli prototypointipainotteinen. Kokonaisuuteena HCI-kurssin tarkoituksena on opettaa kehittämään käyttäjäkeskeisiä suunnittelutaitoja ja saamaan periaatteet ja keinot erinomaisten käyttöliittymien kehittämiseen millä tahansa teknologialla. Viiden viikon mittaisen kurssin luennot olivat hyviä ja vaikka suoritin kurssista vain ”luennot ja kyselyt” -osuuden, tarjosi se pohdittavaa ja uusia ideoita. Jos kurssista suorittaa myös harjoitustyöt sisältäen muun muassa prototypointia ja arviointia, on se erinomainen kurssi vähääkään käyttöliittymien kanssa tekemisissä olevalla suunnittelijalle tai sovelluskehittäjälle.

”Ihmisen ja tietokoneen vuorovaikutus”, osa 2

Stanfordin “ihmisen ja tietokoneen vuorovaikutus” -verkkokurssi kävi nopealla tahdilla läpi sovelluksen suunnitteluun liittyvät vaiheet idean saamisesta mallintamiseen ja asioiden prototypoimiseen, testaamiseen ja arviointiin. Tarkoituksena on, että kurssin jälkeen opiskelijalla on paremmat taidot käyttäjäkeskeisestä suunnittelusta ja tietää periaatteet ja keinot erinomaisten käyttöliittymien kehittämiseen käytettävästä teknologiasta riippumatta. Viisi viikkoisen kurssin aikana asiat käytiin läpi videoluentojen ja esimerkkien kautta, joiden tukena on vielä käytännön harjoitustyöt ja kokeet. Sekä harjoitustöiden että testien tekijät saivat kurssista “Studio” -todistuksen ja pelkkien pistokokeiden vastaajat “Apprentice” -todistuksen.

HCI-kurssin alkuosa käsitteli tarpeiden ja ideoiden löytämistä, prototypointia, mitä hyvät käyttöliittymät ovat, heuristiikkaa ja informaation esitysmuotoja. Kahden viimeisen viikon aikana käsiteltiin visuaalisen suunnittelun periaatteita tiedon jäsentämiseksi ja esittämiseksi käyttöliittymässä, havaintojen ja kognition periaatteita tehokkaan vuorovaikutuksen saamiseksi ja viimeisenä aiheena oli kontrolloitujen testien suorittaminen ja analysointi.

Viikko 4

Neljännen viikon luennot keskittyivät visuaaliseen ja informaatiosuunnitteluun.

Visuaalinen suunnittelu ja typografia

Visuaalisen suunnittelun osalta käsiteltiin tyhjän tilan merkitystä muun muassa ryhmittelyssä ja koon osoittamaa hierarkiaa. Eli käytä tyhjää tilaa ja lisää (tekstin) koon vaihtelua ja painoa.

Visuaalisen suunnittelun kolme tavoitetta ovat:

  • Ohjata: ilmaista rakennetta, suhteellista tärkeyttä, suhdetta
  • Tahdittaa: houkutella, ohjata suuntaa, tarjota kohtia syventymiseen
  • Viestittää: ilmaista tarkoitusta ja tyyliä, herättää sisältö elämään

Kolme perus välinettä tavoitteiden saavuttamiseksi ovat:

  • Typografia
  • Asettelu
  • Värit

Typografian osuus oli kohtalaisen tylsää, mutta osaltaan kuitenkin tärkeää. Luentoja seuraaville kerrottiin teoriana eri kirjasintyyppien ominaisuuksia ja käyttökohteita. Mitään yleisohjetta kirjasimen valintaan ei ole, sillä se riippuu ihan tarkoituksesta.

”Legibility, in practice, amount simply to what one is accustomed to” – Eric Gill, 1931

Informaatiosuunnittelu

Informaatiosuunnittelun osalta syvennyttiin ruudukoihin ja kohdistamiseen. Useat Web-sivut ovat ryhmitelty ruudukoihin, joka helpottaa tiedon organisointia. Tekstin osalta todettiin, että vasemmalle tasattu teksti on nopeampaa selata (jos luetaan vasemmalta oikealle). Tästä voidaan kuitenkin poiketa, jos se on tarkoituksellista. Esimerkkinä käsiteltiin Amazonin sivujen eri tekstintasaukset eri kohdissa sivustoa.

Värien merkitystä käsiteltiin lyhyesti, antaen esimerkkinä Amazonin sivut harmaasävyissä ja Javan ”ilme ja tuntuma” -ohjeen värimääritelmät. Javan (Swing-aikakauden) ohjeet määrittelivät kuusi väriä kahteen ryhmään: violetti = klikkaa, harmaa = ei klikattavissa. Näin se tarjosi puhtaan, yhdenmukaisen ilmeen, joka oli helppo silmille (lähinnä harmaa).

Lähinnä mitä värien käsittelystä voi lyhyesti sanoa, on kolme vinkkiä:

  • Kiinnitä huomiota väreihin
  • Suunnittele ensin harmaasävyissä
  • Säilytä luminanssi samana kuin harmaasävyissä, siirtyessäsi väreihin

Lukeminen ja navigointi

Viikon viimeinen luento keskittyi (Web-sivujen) lukemiseen ja navigointiin, miten helposti kävijät saavat ”hajun” sisällöstä (eng. Information Scent) ja löytävät sivuilta mitä haluavat ja tajuavatko he mitä vaihtoehtoja on tarjolla. Asian helpottamiseksi on muutamia keinoja. Ikonit auttavat, jos ne eivät ole liian yleisiä, avustavat toistuvaa tunnistamista ja jos käyttäjä tietää miltä asia näyttää, mutta ei sen nimeä. Toinen avustava tekijä on käyttää usean sanan linkkejä, joissa on tunnistettavia termejä ja avainsanoja.

Informaation löydettävyyden arvioimiseen voidaan käyttää silmäseurantaa, jolla saadan selvitettyä mihin käyttäjät sivuilla kiinnittävät huomion. Tutkimukset osoittavat, että sisältö pitäisi suunnitella silmäilyä ajatellen, jossa tärkein asia on vasemmassa yläkulmassa ja vähemmän tärkeät oikeassa alakulmassa.

On sanomattakin selvää, että sivujen tärkein alue on niin sanotun taitteen yläpuolelle (mikä mahtuu kerralla näkyviin selaimen ikkunaan), mutta käyttäjät kyllä selaavat alaspäin, jos he ajattelevat sen palkitsevan heitä. Myös tässä asiassa käyttäjät olettavat löytävänsä tärkeät asiat sieltä, jossa ne ovat muillakin sivuilla. On totuttu, että tietyt elementit ovat tietyissä kohdissa. Tämä pitäen mielessä, voi vain miettiä mikä on useiden sanomalehtien Web-sivujen tärkein sisältö, kun yli puolet sivusta on pelkkää mainosta.

Viikko 5

Viimeisellä viikolla keskityttiin kokeiden suunnitteluun, osallistujien olosuhteiden valintaan, kokeiden suorittamiseen ja niiden analysointiin ja vertaamiseen. Testaaminen on paljon muutakin, kuin ”pidätkö käyttöliittymästä” -tasoisten kysymysten kysymistä, ja on tärkeää tietää mitä vasten tuloksia arvioi ja mitä ne merkitsevät. Kokeiden osalta käytiin lyhyesti sanottuna läpi asioita, mitä luotettavilta, toistettavilta ja vertailukelpoisilta mittauksilta vaaditaan. Ei nyt ihan tieteellisellä tarkkuudella, mutta lähes. Tarkoituksena kokeilla on selvittää ”Onko käyttöliittymä X parempi kuin Y?” (ja mitä parempi tarkoittaa), ja usein vastaus on ”se riippuu”, joten kysymys onkin ”mistä?”.

Koejärjestelyt

Kokeiden yksi tärkeä osa-alue on osanottajien valinta eri koejärjestelyihin, miten he testaavat eri vaihtoehtoja vai kaikkia ja miten suoriutumista mitataan? Kokeen suorittamisen osalta pitää pohtia, testaavatko puolet käyttäjistä toista vaihtoehtoa ja loput toista, vai kummatkin ryhmät molempia ja missä järjestyksessä, että testattavat kohteet tai käyttäjien ominaisuudet eivät vaikuta lopputulokseen.

Koejärjestelyitä käsiteltiin teoriapainotteisesti ja niiden osalta päädyttiin kolmeen päästrategiaan:

  • Osallistujien sisällä: Kaikki kokeilevat kaikkia vaihtoehtoja. Toimiva vaihtoehto, jos eri versioiden testaus ei sotke toisten tuloksia.
  • Osallistujien välillä: Jokainen kokeilee yhtä. Vaatii enemmän henkilöitä ja tarkkaavaisuutta tasapuoliseen testien jakoon. Etuna on, että osallistujat eivät ole alttiita vaikutuksille toisesta testistä.
  • Tasoittamalla olosuhteita ja osallistujien järjestystä (esitestillä, raja-arvoilla), voidaan pienentää osallistujien välistä vaihtelua.

Koehenkilöiden kanssa tehtäviä kokeita käsiteltiin yhden luennon verran ja aiheessa keskityttiin muun muassa käytännön asioihin, sekä miten koe pitäisi suorittaa, tallentaa, käytiin läpi ”ajattele ääneen” -metodiin liittyviä asioita ja miten kokeen tuloksia pitäisi prosessoida, analysoida ja mitata. Hieman turhan pikkutarkkoja asioita tässä käytäväksi läpi. Erilaiset mitattavat asiat, kuten suoritusaika tai virheiden määrä ovat selkeitä tuloksia.

Kokeiden suorittaminen Internetissä

Pääpaino kokeiden suorittamisessa oli niiden tekemisessä Webin kautta, jota käsiteltiin kolmen luentokappaleen verran. Webissä suoritettavien kokeiden osalta käsiteltiin pääasiassa A/B -vaihtoehto -tyylisiä testejä, eli joissa osa kävijöistä saa erilaisen käyttöliittymän eteensä ja kokeilla selvitetään miten se vaikuttaa kävijän toimiin.

Esimerkkinä käsiteltiin Barack Obaman edellisen presidentinkampanjan Web-sivua, jossa oli neljä eri tekstivaihtoehtoa napissa (sign up, learn more, join us now, sign up now) ja kuusi erilaista visuaalista toteutusta (get involved, family, change, video obama greeting, video of campaign, sam’s video). Erot tekstivaihtoehtojen osalla olivat prosentuaalisesti pieniä ”learn more” -vaihtoehdon ollessa tehokkain, mutta kävijämäärään suhteutettuna suuria ja videovaihtoehdot toimivat kuvaa heikommin. Loppupäätelmänä esitettiin, että pienet muutokset aiheuttavat isoja eroja ja oletuksemme (mikä toimii parhaiten) ovat usein vääriä.

Toisena esimerkkinä esitettiin käyttäjien houkuttelemista seuraamaan henkilöä Twitterissä, muuttaen napin tekstiä. Kokeen lopputuloksena saatiin: ”I’m on Twitter” 4,7%; ”Follow me on twitter” 7,31%; ”You should follow me on Twitter” 10,09%; ”You should follow me on Twitter here” 12,81%. Eli mitä selkeämmäksi teet sen, mitä haluat käyttäjän tekevän, sitä useammin he tekevät sen.


Small distractions
like extra fields
can yield big changes

Periaatteina tehokkaiden online-kokeiden suorittamiseen esitettiin seuraavat asiat:

  • Kokeiden ajaminen 50/50%: vaikutuksen havaitsemiksi tarvitaan riittävä määrä osallistujia
  • Suorita nousevasti: rajaa koe alkuun 0.1% käyttäjistä ja varmistu, että se ei tuota ongelmia
  • Peruuta koe automaattisesti: määritä mittarit, joiden perusteella koe peruutetaan sen ollessa selkeästi heikompi esim. sivujen luontiajan suhteen
  • Aja koetta riittävän pitkään: ensimmäinen käyttö ei ole sama kuin mihin käyttäjät ovat tottuneet
  • Satunnaisen koejaon säännöt: johdonmukainen, eli sama käyttäjä saa saman kokeen, kestävä, riippumaton

Lopuksi luennolla esitettiin, että Internet-ajalla suunnittelussa on huomioitava, että ihmiset ovat usein liian varmoja itsestään, suunnittelijan rooli siirtyy olemisesta useiden vaihtoehtoisten ratkaisujen tekemiseen ja nopean kokeilemisen mahdollisuus tarkoittaa, että ensimmäinen versio (joskus) on vähemmän tärkeä.

Tulosten arviointi

Viimeisellä luennolla päästiin arvioimaan ja vertailemaan kokeiden tuloksia ja niiden dataa. Datan analysointiin esitettiin kolme kysymystä: 1. Miltä datani näyttää? 2. Mitkä ovat luvut kokonaisuudessaan? 3. Ovatko eroavaisuudet oikeita? Eli kannattaa tutkia dataa graafisesti eri yhteenvedoin ja menetelmin, sekä ryhmittää eli olosuhteiden tilastoja.

Erojen merkityksen arviointiin käytettiin eniten aikaa, esittelemällä Pearsonin Khii-toiseen -testi (Chi-squared), jolla vertailtiin odotettuja arvoja havaittuihin arvoihin esimerkiksi klikkausten määrän kehittymisessä. Tilastolliset menetelmät auttavat vahvistamaan, että ”olemme melkein varmoja” ja yleistämään tai olla yleistämästä pienestä testidatasta. Ja kannattaa huomioida, että data ei yleensä ole normaalia, vaan voi painottua eri tavoilla, joten testien ja niiden arvioinnin pitää ottaa se huomioon. Aika matemaattispainotteinen luento.

Yhteenveto

Viiden viikon mittainen Stanfordin “ihmisen ja tietokoneen vuorovaikutus” -kurssi oli aiheeltaan mielenkiintoinen ja tarjosi myös aihetta tuntevalla uusia ajatuksia ja ideoita. Kurssilla läpikäydyt aiheet olivat mielenkiintoisia ja tarjosivat sopivasti teoriaa ja esimerkkejä, vaikkakin muutamien ensimmäisten ja viimeisten luentojen aiheet olivat hieman tylsiä. Ainakin teoriassa osaan nyt selvittää ideoita ja tarpeita, suorittaa prototypointia eri tekniikoilla, arvioida eri vaihtoehtoja, ymmärrän miksi prototypointi ja vertaileva arviointi ovat oleellisia asioita erinomaisen vuorovaikutuksen suunnitteluun ja hahmotan miten tiedon eri esitysmuodot vaikuttavat käyttäjäkokemukseen.

Coursera-verkkokurssiympäristö toimi ihan asiallisesti, vaikka muutamia ongelmia sen kanssa kuulemma oli ainakin vertaisarviointiin liittyen, foorumien käytön mielekkyydestä voi olla montaa mieltä ja osallistumistodistusta sai odottaa pari kuukautta. Kuormittavuudeksi kurssisivuilla kerrotaan 8-10 tuntia/viikko, josta luentojen seuraamiseen ja pistokokeiden tekemiseen meni arviolta noin pari tuntia. Ei paha rasti, mutta kurssin parhainta antia olisi tehdä myös harjoitustehtävät, joiden avulla opittua asiaa saa harjoiteltua ideoinnista prototypointiin, testaamiseen ja arviointiin. Tämä jäi itseltäni harmillisesti väliin.

Useat Courserassa olevat kurssin pyörivät useamman kerran ja niin myös HCI, jonka seuraava toteutus alkaa syyskuun 24. päivä. Suosittelen kurssia kaikille, jotka vähääkään sivuavat käyttöliittymiä suunnittelun tai sovelluskehityksen ohessa, vähintään luentojen ja pistokokeiden osalta. Itse suunnittelin käyväni samaan aikaan käynnistyvän Scalalla toteutettavan funktionaalisen ohjelmoinnin -kurssin, joten HCI:n kattavampi suoritus jää myöhemmäksi.