Vihreä koodi, vastuullisuus, Green ICT ja kestävä kehitys ovat nyt alkuvuoden aikana nousseet esille yhä useammin ja useammassa kontekstissa ohjelmistokehitykseen liittyen. Viime vuoden keväällä kirjoitin Vihreää koodia -webinaarista ja sen esittämistä hyvistä ohjelmistokäytännöistä kohti vihreämpää koodia ja nyt on vuorossa kohti vihreämpää tulevaisuutta sovelluskehityksessä on Linux Foundationin Green Software for Practioners LFC131 -sertifikaatti.
Green Software for Practioners LFC131 -kurssi ja sertifikaatti
Linux Foundationin ilmainen Green Software for Practioners LFC131 -kurssi kertoo miten määritellään, rakennetaan ja ajetaan vihreitä sovellusohjelmistoja. Kurssi kertoo suuntaviivat, jotka auttavat luomaan ymmärrystä mitä tarkoittaa vihreiden sovellusten harjoittaja riippumatta sovellusalueesta, organisaation koosta, ajoympäristöstä tai ohjelmistokielestä ja -kehyksestä. Eli tarjoaa korkean tason käsitteet ja ajatusmallit vihreämpään sovelluskehitykseen.
Vihreä ohjelmisto tarkoittaa kurssin määrityksen mukaan hiilitehokasta ohjelmistoa, joka tuottaa mahdollisimman vähän hiiltä. Vain kolme toimea vähentää ohjelmiston hiilipäästöjä: energiatehokkuus, hiilitietoisuus ja laitteistotehokkuus.
Kurssi on jaettu kuuteen osaan:
Hiilitehokkuus: Tuota mahdollisimman vähän hiilipäästöjä.
Energiatehokkuus: Käytä mahdollisimman vähän energiaa.
Hiilitietoisuus: Tee enemmän kun sähkö on puhtaampaa, tee vähemmän kun sähkö on likaisempaa.
Laitteistotehokkuus: Käytä mahdollisimman vähän (laitteistoon) sitoutunutta hiiltä.
Jokaisen osion päätteeksi on lyhyt monivalintakysely, jota ei pisteytetä. Kurssin päätteeksi on lopputentti, josta pitää saada 85% oikein. Testin voi suorittaa niin monta kertaa kuin tarvitsee. Tentin läpäistyä saa sertifikaatin todisteeksi.
Yksi mielenkiintoinen asia sovelluskehittäjälle on esitelty Software Carbon Intensity (SCI), joka sisältää toiminnalliset päästöt (hiilipäästöt sovellusta ajettaessa) ja laitteistopäästöt (hiilipäästöt fyysisistä resursseista, joita tarvitaan sovelluksen ajoon). Kun teet sovelluksestasi energiatehokkaamman, laitteistotehokkaamman tai hiilitietoisen, SCI tuloksesi pienenee. SCI jäi hieman korkealle tasolle, kun esimerkkejä, lukuja tai konkreatiaa ei sinänsä esitelty.
Toinen hyvä osio oli hiilitietoisuus, jossa esitettiin muutamia konkreettisia menetelmiä vihreämpään sovellukseen muun muassa siirtämällä laskentaa sellaiseen ajankohtaan tai toiselle mantereelle, jossa on vihreää sähköä (hiili-intensiivisyys alhaisempi) saatavilla.
Green Software for Practioners LFC131 -kurssi tarjoaa korkean tason käsityksen vihreydestä energian kulutuksen ja tuotannon osalta ja miten sitä voi pohtia sovelluskehityksen näkökulmasta. Kurssi lupaa opettaa miten soveltaa vihreän ohjelmistokehityksen periaatteita softan suunnittelussa ja kehittämisessä. Korkealla tasolla tavoite täyttyy ja sekä aihepiiristä että vihreästä ohjelmistokehityksestä saa käsityksen pääpiirteittäin. Konkretiaa ei tarjota, eikä kovin uusia ajatuksia, jos vihreät asiat ovat jo tuttuja. Osa asioista oli myös kurssin aihepiirin (sovelluskehitus) näkökulmasta epäolennaisia, keskittyen yleiseen ilmastosopimuksiin ynnä muihin. Teknologistanäkökulmaa olisi toivonut olla enemmän, sekä menemistä sovellustasolle (esimerkiksi vihreä koodi).
Kurssi on lyhyt, kuvaus taisi kertoa parin tunnin kestosta ja itsellä taisi mennä varmaan tunnin luokkaa. Kurssin pystyi käymään hyvin läpi kännykällä lukemalla, joka helpotti kurssin läpikäymistä pienissä paloissa.
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ä.
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
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
Viimeisen vuoden aikana etätyöt ovat tulleet tutuiksi yhä enemmän yritysten työntekijöille, sekä koululaisille, ja yritykset ovat viimeistään nyt opetelleet työn tekemisen uutta normaalia. Etätöistä on puhuttu tietotyössä jo pitkään ja siihen on ollut jossain määrin myös mahdollisuus muutamana päivänä viikossa, mutta pakon edessä suurin osa yrityksistä on ymmärtänyt, että töitä voi tehdä aivan samalla tavalla kotona, kuin että istuisi omalla tai asiakkaan konttorilla.
Itse hyppäsin etätöihin täydellä sydämellä toissa vuonna, kun muutin maalle ja konttori ja kollegat jäivät pääkaupunkiseudulle. Millaista etätöiden tekeminen on sitten ollut ja mitä työvälineitä tietotyössä siihen itselläni liittyy? Tässä muutamia ajatuksia asiasta työskennellessäni konsulttitalossa sovelluskehityksen parissa.
IT-alan kehityksen kärki, parhaat työpaikat ja verkostot ovat pääkaupunkiseudulla
Yksi asia, jota pohdin muuttaessani pääkaupunkiseudulta, oli IT-alan tapahtumat, verkostot ja oman osaamisen kehittäminen meetuppien kautta, josta pakostikin jäisin paitsi maakunnassa. Helsingissä on, tai on ainakin ollut, aktiivinen meetup-kulttuuri, jossa yritysten sponsoroimissa iltamissa kehittäjät esittävät teknologia-aiheisia asioita ja toiset kehittäjät kuuntelevat ruuan ja juoman merkeissä. Samalla voi verkostoitua ja vaihtaa ajatuksia toisten kehittäjien kanssa. AWS, React, React Native, Kubernetes, iOS, JavaScript, DevOps, tietoturva ja muista aihepiireistä sai kuulla hyviä tarinoita, miten toiset ovat asioita ratkaisseet.
Oman osaamisen kehittäminen ja oman ammattialan kehittymisen seuraaminen on yksi tärkeä osa itseohjautuvuutta, joka korostuu täysipainoisessa etätyössä. Uutislähteiden, blogien, podcastien, tapahtumien nauhoitusten ja virtuaalisten tapahtumien seuraaminen on hyvä omaksua tavaksi, jota olen vuosien aikana tehnyt muun muassa omaan blogiini kirjoittamisen kautta. Eli sinällään meetuppien poisjäänti pitää täyttää omalla tekemisellä, jossa Internetin lähteiden seuraaminen ja virtuaaliset verkostot ovat pääroolissa.
Maakunnissa asuessa vaihtoehdot työpaikkojen suhteen ovat rajatumpia myös tietotekniikan alalla ainakin vielä tällä hetkellä, kun edelleen haetaan työntekijöitä yrityksen konttorien kaupungeista. Muutos päivittäisestä konttorilla istumisesta etätöiden tekemiseen ja muutamana päivänä kuukaudesta konttorille matkustamisen suuntaan on hiljakseen muuttumassa suopeammaksi ja jopa täysin etätöihin sallivaan suuntaan. Kulunut vuosi toi lisävauhtia ajatusmaailman muutokseen valtioneuvoston etätyösuositusten myötä, vaikka jäykimmät organisaatiot eivät niidenkään myötä ole vielä ymmärtäneet etätöiden mahdollisuutta. Tulevaisuudessa odotan, että työntekijän sijainnilla tietotyössä on yhä vähemmän merkitystä ja työyhteisö kehittyy työtapojen suhteen ottamaan etätyöskentelyn paremmin huomioon.
Hevoskontakteja 🦄
Työssäviihtymiseen tarvitaan ihmiskontakteja
Toinen mietinnässä ollut asia oli kollegoiden kanssa spontaani ajatustenvaihdon vähentyminen ja ylipäätänsä kontaktien väheminen, kun ei tulisi käytyä konttorilla tai tavattua pääkaupunkiseudulla olevia kaveri- ja harrastusporukoita.
100% etätyönteko on kieltämättä jossain määrin yksinäistä puurtamista, mutta niin se on vaikka istuisit konttorilla oman projektisi parissa. Kommunikaatiovälineet auttavat ajatusten vaihdossa ja sovelluskehityksessä säännölliset dailyt ja suunnittelupalaverit Meetin välityksellä ovat arkipäivää. Kasuaalinen ajatustenvaihto ja pallottelu on hieman hankalampaa, mutta siihenkin voi käyttää yrityksen sisäistä Slackia tai turvautua laajempaan koodaajien yhteistöön, Koodiklinikan Slackkiin. Ennen oli IRC, nyt on Slack ja Discord. Mutta virtuaalinen kommunikaatio on yksi isoin miinuspuoli etätöiden tekemisessä. Töissä kasuaalista kommunikaatiota on viritelty virtuaalisten kahvituntien parissa ja se on ihan mukava tapa.
Sovelluskehityksessä yksi osa tekemistä on kommunikointi ja asioiden käyminen yhdessä läpi esimerkiksi koodikatselmoinnin tai parikoodauksen yhteydessä. Kaikkeen on työvälineet olemassa, ja yksi koodauksen jakamisen mahdollistava työväline on Visual Studio Live Share.
🚲
🚲
Työmatkat eivät ole mukavia
Kotona työskentelyssä suurin plussa on se, että nyt työmatkaan ei mene lähes tuntia per suunta junassa, metrossa tai muussa julkisessa kulkivälineessa istuessa, vaan se aika jää käytettäväksi vaikka koiran kanssa lenkkeilyyn tai oman osaamisen kehittämiseen. Heräät, käyt koiran kanssa lenkillä, syöt aamiaisen ja kävelet tohveleissa työhuoneeseen aloittamaan työpäivän.
Kotikonttori tuo viihtyvyyttä
Sähköpöytä, satulatuoli, iso monitori, oma työhuone. Siinä neljä etätöiden tekemisen viihtyvyyteen vaikuttavaa asiaa. Satulatuolin ja normaalin työtuolin yhdistelmä tuo ergonomiaan sopivaa vaihtelua ja sähköpöytä mahdollistaa seisaaltaan työskentelyn. Etäpalaveita varten on hyvä olla kunnon Web-kamera ja mikrofoni tai pöytämikrofoni, vaikka usein käytän kuulokkeita. Monitorin suuri ruutualue ja iso resoluutio varmistavat työtehokkuuden, kun ikkunoita voi levitellä sopivasti näytölle. Ja kun tilaa on nyt sen verran enemmän kuin aikaisemmin, voi työt ja työkoneet jättää työpäivän jälkeen työhuoneeseen.
Kotikonttori 🧑💻
Etätyö korostaa kommunikaation merkitystä
Kommunikaation merkitys kaikessa tekemisessä on usein aliarvioitu ja etenkin sovelluskehityksessä sen merkitys korostuu. Riittävä dokumentaatio, asynkroninen kommunikaatioväline, etäpalaverit ja tekemisen jäsentäminen ovat hyviä lähtökohtia onnistumiselle. Etenkin dokumentaatio jää helposti puutteelliseksi ja se hajaantuu kommunikaatiovälineiden historiaan tai tekijöiden omiin muistiinpanoihin.
Toinen merkityksellinen asia ovat palaverit ja niiden tehokkuus. Nykyisessä työssäni olen saanut keskittyä sovelluskehitykseen ja palaverit ovat jääneet vähemmälle, mutta niiden osalta on hyvä tiedostaa muutamia asioita, jotka tekevät niistä parempia. Agenda ja johdonmukainen läpikäynti ovat tuttuja asioita, ja Martin Fowler kertoo miten tehdä tehokkaita etäpalavereita: hyvä audio, käytä galleria-näkymää, mykistä jos et puhu, kiinnitä huomiota valaistukseen. Hieman pidemmälle mennessä voi poimia vinkkejä täältä: älä käytä langattomia kuulokkeita, hanki parempi mikrofoni, älä mykistä ja kuuntele itseäsi.
Etätyö tuo posiviitista virettä, muttaa vaatii myös uusia keinoja
”Lisääntynyt etätyö näyttää vaikuttaneen työssä jaksamiseen pääsääntöisesti myönteisesti ja tuoneen työhön positiivista virettä. Työhyvinvointi jopa parani koronakevään aikana: etätöihin siirtyneillä työn imu lisääntyi ja krooninen väsymys väheni. Haasteita ovat etenkin tylsistyminen, työkavereiden kanssa käytävän epävirallisen vuorovaikutuksen väheneminen ja huono ergonomia. Työnteosta voi kadota kipinä, kun virikkeet ja työkaverit puuttuvat. Jaksamiseen on keksittävä uusia keinoja.”
Etätyö on erilaista tekemistä ja se korostuu, jos sitä tekee päivästä toiseen. Harva yritys on ajatellut etätyöskentelyä ja sen vaatimia erityisvaatimuksia työn tekemiselle ja kommunikaatiolle. Elon artikkelissa ehdotetaan hyviä asioita:
Panosta ergonomiaan ja rytmitä työpäivää: Etätyö vaatii itsekuria. Jaksamista kannattaa ammentaa työn rytmittämisestä, lounas- ja kahvitauoista, ulkoilusta ja liikunnasta. Jos mahdollista, rytmitä päivä niin, että ehdit ulkoilemaan valoisan aikaan.
Vaali yhteisöllisyyttä: Yhteydenpito työkavereihin on merkittävä osa työhyvinvointia myös etätyömaailmassa. Virallisten etäpalavereiden ohella vapaamuotoiset virtuaalikahvittelut ja etäjumppahetket ovat tärkeitä, jotta päiviin tulee myös epävirallista vuorovaikutusta.
Vähennä videopalavereita: Liian usea videopalaveri päivässä lisää väsymystä
Haastetta peliin: On tärkeää huolehtia siitä, että työ tarjoaa myös etäilyn aikana riittävästi mielekkäitä haasteita.
Meillä töissä on otettu ”uuden normaalin” tueksi apua Auntielta, joka tarjoaa ratkaisuja arkeen, jos se tökkii. Ja vaikkei tökkisikään. Heillä on myös hyviä vinkkejä etätyön tekemiseen.
Töitä laiturin nokasta?
Onko etätyö uusi normaali?
Yritykset luopuvat keskustassa olevista isoista konttoreista ja säästävät toimitilakuluissa? Työtä voi tehdä paikattomasti ja rekrytä osaavia tekijöitä sijannista riippumatta? Sovelluskehitystiimit panostavat dokumentaatioon tiedon jakamisessa? Työtavat, -kulttuuri ja -käytännöt kehittyvät tukemaan etätöitä?
Tulevaisuuden ennustaminen on vaikeaa, mutta maailma kehittyy ja toimintatavat, sekä ajatusmaailmat muuttuvat. Etätyön hyödyt ovat todistettu ja nyt viimeistään monessa paikassa todettu käytännössä. Täysiaikainen etätyö vaatii paljon työyhteisöltä, sekä työntekijältä, eikä se sovi kaikille, mutta ajatusmaailman uskoisi sen osalta muuttuvan suopeammaksi. En usko, että kotona tekeminen tulee laajemmalti jäämään uudeksi normaaliksi, sillä ihmiset kaipaavat kontakteja ja parempia työtiloja, mutta flexi-työ ja etätöiden lisääntyminen tulevat kyllä yleistymään.
Sosiaalinen kanssakäyminen on useimmille työntekijöille yksi pääaktiviteeteista. ”Miten viikonloppusi meni?”, ”Katsoitko eilen illan ottelun?” jne. on kirjaimellisesti se, mistä he löytävät sosiaalisen poistoventtiilinsä ja henkilökohtaiset yhteydensä.
Esimiehet tykkäävät seurata alaistensa tekemistä, sillä se tekee heidät tuntemaan olevansa enemmän vallassa kuin itse asiassa ovat.
Työmatkarutiini, vaikkakin se on painajaismaista, tarjoaa tunteen normaaliudesta, johon useimmat ovat tottuneet ja oudolla tavalla luottavat arjen perustan luomisessa.
Työ on pakopaikka kodin arjesta.
On erilaisia työtapoja ja arjen pyörittämistä, ja jokaisen pitää löytää se juttu, joka toimii itselle. Mutta vanhoihin kaavoihin ei ole järkevää kangistua.
Maaseudun rauhallisuus ja luonto tuovat arkeen positiivisuutta
Yhteenvetona todettakoon, että muutto maakuntaan Saimaan rannoille on ollut selkeä elämänlaatua parantava asia sekä asunnon että elämisen rauhallisuuden takia. Toki omakotitalossa ja pihassa riittää tekemistä, mutta se tuo hyvää vastapainoa päätteen ääressä istumiselle ja kotipihasta lähtevillä poluilla liikkumiselle. Myös töiden tarjoamat projektit ovat olleet mielenkiintoisia ja omaa osaamista kehittäviä, eikä etätöissä niiden osalta ole ollut eroa, istuisiko konttorilla vai kotona. Tietenkin viime aikoina tilanne on ollut sama kaikilla. Omaa osaamista on saanut hyvin kehitettyä virtuaalisten konferenssien ja Internetin lähteiden kautta, sekä hetkellisen tauon jälkeen myös omat harrasteprojektit ovat edistyneet.
Arki täällä maaseudulla on erilaista ja se näkyy etenkin (fyysisten) sosiaalisten kontaktien määrässä ja osittain varmaan myös tarjolla olevien projektien valinnassa (nyt meneillään olevien rajoitusten jälkeen), mutta vastapainona se tarjoaa monia positiivisia asioita, joita ei pääkaupunkiseudulla olisi voinut saavuttaa. Voisi siis todeta, että tämä uusi normaali näyttää meille toimivan.
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.
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.
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.
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
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 agendaMiten 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 ohjenuoratKanban-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.
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ä.
Kävin vajaa kuukausi sitten opiskelemassa TOGAF 9 -kokonaisarkkitehtuuriviitekehyksen perusosion Tieturin kurssilla ja nyt edessä oli Open Groupin TOGAF 9 sertifioinnin jälkimmäinen Certified osuus. Vaikka työtehtäväni eivät suoranaisesti liity yritysarkkitehtuurin kehittämiseen, tarjoaa TOGAF keinoja ja ideoita myös omaan työhöni ja teknisen arkkitehdin roolissa on hyvä tietää perusteet maailman yleisimmin käytetystä yritysarkkitehtuuriviitekehyksestä, johon myös julkisen hallinnon JHS-179 -suositus pohjaa. Kuten ensimmäisenkin osion, myös toisen osion opiskelumateriaali löytyy verkosta, mutta osallistuin Tieturin järjestämälle TOGAF 9 Certified -kurssille, joka tarjoaa (level 2) -sertifikaatin suorittamiseen tarvittavat tiedot ja valmiudet.
TOGAF 9 lyhyesti
”Arkkitehtuuri on tarpeettoman luovuuden rajoittamista” – antiikin kreikka
Open Groupin TOGAF, eli The Open Group Architecture Framework, on maailman yleisimmin käytetty kokonaisarkkitehtuuriviitekehystä ja sekä ilmainen että vapaasti saatavilla oleva viitekehys yrityksen sisäiseen kehittämiseen. Viitekehyksen ideana on pienentää kokonaisarkkitehtuurin suunnittelemisen riskejä, kustannuksia sekä lyhentää sen suunnitteluun kuluvaa aikaa ja se tarjoaa sen saavuttamiseksi kehittämismetodin (ADM) ja työkaluja. TOGAF on myös perustana Suomen julkishallinnon käyttämässä kokonaisarkkitehtuurin suunnittelumenetelmässä (JHS-179). En ala tässä käymään tarkemmin viitekehystä läpi, vaan kiinnostuneet voivat lukea siitä TOGAF-dokumentaatiosta.
Suomessa TOGAFia kouluttavat ainakin Tieturi ja Wakaru.
Tieturin TOGAF 9 Certified -kurssi
TOGAF 9 Certified -kurssi on TOGAF 9 Foundationin jatkokurssi, jonka kolmipäiväinen kokonaisuus tarjoaa osallistujalle TOGAF 9 Certified (level 2) -sertifikaatin suorittamiseen tarvittavat tiedot ja valmiudet. Kun Foundation kurssi tarjosi lähinnä yleisnäkemyksen kokonaisarkkitehtuuriviitekehykseen ja sen vaiheisiin, opettaa Certified -kurssi syvällisesti yritysarkkitehtuurin suunnittelun avainkohdat, kuinka suunnittelu tehdään TOGAF -viitekehyksen avulla, miten soveltaa TOGAFia ja ymmärtää sen tarjoamat näkökulmat.
Tieturi TOGAF 9 Certified -kurssin ensimmäisen päivän piirustuksia
Tieturin kurssi käy aihepiirin läpi 524 kalvon ja 12 testisertifiointikysymyksen avulla, joka toimi Jari Kasslinin vetämänä hyvin, antaen TOGAFin eri vaiheisiin liittyvistä tekniikoista ja asioista hieman syvällisemmän kuvan ja valmistaen sertifiointitestiin. Jatkokurssilla asia käytiin läpi hieman enemmän luennonomaisesti kuin vajaa kuukausi sitten käymälläni peruskurssilla, vaikka muutama arkkitehtuurin suunnitteluun liittyvä ryhmäharjoitus tehtiin. Kahteen ja puoleen päivään oli ahdettu lyhyt kertaus TOGAFin peruskurssista, ADM:n vaiheisiin liittyvien tekniikoiden läpikäynti, TOGAFin osa-alueiden tarkempi käsittely, testiharjoituskysymysten pohdinta ja muutama ryhmäharjoitus.
Kävin Certified-kurssin suhteellisen nopeasti Foundationin jälkeen, joten perusasiat olivat vielä hyvin muistissa, mutta kurssin aikana ei juurikaan peruskurssin aiheita sivuttu, vaan syvennyttiin juuri niihin aiheisiin, jotka jäivät avoimiksi ja herättivät ”miten se tapahtuu käytännössä” (siis millä tekniikoilla) -kysymyksiä. Jatkokurssilla sai paremman käsityksen miten TOGAFia voisi hyödyntää myös omassa työssä ja miten viitekehyksen tekniikoita voisi soveltaa. Käytännön esimerkkejä ei Certified-kurssikaan tarjoa, vaan asiat ovat enemmän strategisella ja loogisella tasolla. Sertifiointitestiä ajatellen etenkin testiharjoituskysymysten läpikäynti ja vastausten pisteyttäminen testiä ajatellen 5, 3, 1 ja 0 -jaottelulla toimi hyvin asian sisäistämiseksi.
Tieturin TOGAF 9 Certified -kurssi toimi mielestäni hyvin aiheeseen syventymiseen ja tarjosi selkeämmän kuvan kokonaisuudesta ja sertifiointitestissä vaadittavista asioista, kuin mitä pelkkää TOGAF 9 dokumentaatiota tavaamalla saa. Kolmipäiväinen kokonaisuus maksoi 1750e + alv, joten edullinen kurssi ei ole. Halvempi vaihtoehto myös jatkokurssilla on käyttää Open Group myymää opiskeluopasta (29,95 dollaria) ja harjoitustestiä (0,99 dollaria), mutta en osaa sanoa miten hyvin ne yksistään toimisivat sertifiointitestiä ajatellen. Sertifiointitesti kustansi 278e + alv.
”Kokonaisarkkitehtuuri on teknologiatietoista, mutta niin paljon kuin mahdollista, teknologiariippumatonta”
Kurssin jälkeen pidetty TOGAF 9 Certified -sertifiointitesti sisälsi kahdeksan skenaariopohjaista kysymystä (monivalinta, pisteytys: 5, 3, 1,0), joista piti saada vähintään 24 pistettä. Aikaa vastaamiseen oli hieman yli pari tuntia, josta käytin noin puolet. Nyt kysymyksissä ei enää leikitelty sanavalinnoilla tai nippelitiedolla, vaan arvioitiin TOGAFin soveltamista ”oikeaan” arkkitehtuuritapaukseen. Muutamiin kysymyksiin paras vastaus löytyi helposti, mutta vaikka 90% (36/40 pistettä) tuloksen perusteella voisi olettaa testin olleen suhteellisen helppo, jäi muutamien kysymysten kohdalla arpomaan parasta vaihtoehtoa. Mutta mikä tärkeintä, nyt on myös TOGAF 9 Certified -sertifikaatti suoritettu.
Kolme päivää teoriaa esitteli paljon uusia asioita, joten pohdiskeltavaa ja kerrattavaa riittää myös kurssin jälkeen.
Sovelluskehitys on pohjimmiltaan määrittelyjä, suunnitelmia, koodia ja testausta, mutta sen täytyy usein toimia jonkin ennalta annetun arkkitehtuurin mukaisesti ja on usein yksi rakennuspalikka isommassa kokonaisuudessa, kokonaisarkkitehtuurissa. Vaikka työtehtäväni eivät suoranaisesti liity yritysarkkitehtuurin kehittämiseen, on myös teknisen arkkitehdin roolissa hyvä tietää perusteet maailman yleisimmin käytetystä yritysarkkitehtuuriviitekehyksestä, eli Open Groupin TOGAFista, johon myös Julkisen hallinnon JHS-179 -suositus pohjaa. TOGAF materiaali löytyy ilmaiseksi verkosta, mutta osallistuin kuitenkin Tieturin järjestämälle TOGAF 9 Foundation -kurssille, joka tarjoaa (level 1) -sertifikaatin suorittamiseen tarvittavat tiedot ja valmiudet.
TOGAF 9
”Arkkitehtuuri on tarpeettoman luovuuden rajoittamista” – antiikin kreikka
Open Groupin TOGAF, eli The Open Group Architecture Framework, on maailman yleisimmin käytetty kokonaisarkkitehtuuriviitekehystä ja sekä ilmainen että vapaasti saatavilla oleva viitekehys yrityksen sisäiseen kehittämiseen. Viitekehyksen ideana on pienentää kokonaisarkkitehtuurin suunnittelemisen riskejä, kustannuksia sekä lyhentää sen suunnitteluun kuluvaa aikaa ja se tarjoaa sen saavuttamiseksi kehittämismetodin (ADM) ja työkaluja. TOGAF on myös perustana Suomen julkishallinnon käyttämässä kokonaisarkkitehtuurin suunnittelumenetelmässä (JHS-179). En ala tässä käymään tarkemmin viitekehystä läpi, vaan kiinnostuneet voivat lukea siitä TOGAF-dokumentaatiosta.
Suomessa TOGAFia kouluttavat ainakin Tieturi ja Wakaru.
Tieturin TOGAF 9 Foundation -kurssi
Tieturin TOGAF 9 Foundation -kurssi on kolmipäiväinen kokonaisuus, jossa on kahden ja puolen päivän tiukka annos teoriaa yritysarkkitehtuuriviitekehyksestä ja sertifiointikokeeseen valmistautumisesta. Kurssi tarjoaa TOGAF 9 Foundation (level 1) -sertifikaatin suorittamiseen tarvittavat tiedot ja valmiudet. Täten kurssilla on kaksi päätavoitetta: TOGAFiin perehdyttäminen ja sertifiointitestiin valmentaminen.
Kokonaisuutena Jari Kasslinin vetämä kurssi toimi oivallisesti TOGAF 9 -viitekehyksen sisällön läpikäymiseen ja asioiden hahmottamisessa, vaikka Foundation-osuus on teoriapainotteista ja sisältää paljon omaksuttavaa. Asioita käsiteltiin sertifiointitestiä ajatellen ja Kasslin esitti muun muassa TOGAFin osat, Enterprise Continuumin ja Architecture repositoryn paremmin visuaalisesti kuvattuna, kuin mitä Open Groupin materiaalissa. Lisäksi muutamat harjoitukset toimivat hyvin asian käsittelyn tukena. Ensimmäisenä päivänä sai kohtalaisen kokonaiskuvan viitekehyksen eri osa-alueista ja rooleista ja toisena päivänä käytiin tarkemmin läpi muun muassa eri vaiheiden tekniikoita ja tuotoksia. Kolmannen päivän aamupäivällä käytiin läpi muutama osio tarkemmin ja kerrattiin sertifiointitestiä varten. Kurssimateriaali tarjoaa kaksi testiin valmentavaa koetta, joista toinen tehtiin kurssin aikana ja toinen toisen päivän iltana kotona.
1. päivän tuotoksia2. päivän ADM:n tuotokset -piirros
Tieturin kurssimateriaali ja aiheen läpikäynti tähtäsi mielestäni hyvin testiä varten, sillä vaikka TOGAFin Foundation osa sisältää paljon uutta asiaa sisäistettäväksi, kerrattiin aiheita sopivasti, jolloin se jäi paremmin mieleen. Tietenkään ei kurssi ilmainen ollut (1650e+alv), mutta en sitä itse maksanutkaan. Toki saman tiedon voi poimia lukemalla TOGAF 9:n dokumentaation, jonka pureskelu itsenäisesti lukemalla on työlästä, ja käyttämällä Open Group tarjoamaa opiskeluopasta (29,95 dollaria) ja harjoitustestiä (0,99 dollaria).
Omalta osaltani kurssi onnistui hyvin, pääsin tavoitteeseeni, eli nyt taskusta löytyy TOGAF 9 Foundation -sertifikaatti ja perustietämys TOGAF 9:n sisällöstä ja vaiheista. Sertifiointitestistä mainittakoon, että se onnistui jekuttamaan 30 prosentissa kysymyksissä. Testin läpipääsyraja on suhteellisen matala, 55 prosenttia, joten kysymyksistä on tehty hankalia ja jossain määrin termeillä ja sanamuodoilla leikkimistä. Hieman jäi sellainen fiilis, että niitä asioita, joita kertasin toisen päivän iltana ja kahdessa esimerkkitestissä, ei juurikaan kysytty siinä muodossa varsinaisessa testissä. Selkeästi aktiivinen seuraaminen ja kuunteleminen kurssilla oli tuottanut tulosta ja tieto oli sisäistetty :)
Seuraavaksi edessä on kolmen viikon päästä Foundation-vaiheessa opitun teorian yhdistäminen käytäntöön ja aihepiiriin syventyminen TOGAF 9 Certified -kurssilla ja Certified-sertifiointitesti.