Ohjelmistokehityksessä osaamisen kehittäminen on tärkeää ja siihen löytyy Internetistä paljon hyviä materiaaleja ja ilmaisia kursseja, sekä avoimen yliopiston tai ammattikorkeakoulujen kursseja, joista voi kerätä opintopisteitä. Yksi tällainen kokonaisuus on Microsoft Skills for Jobs, joka tarjoaa opintopolkuja kaikille osaamisensa kehittämisestä kiinnostuneille. Kävin ”Practical AI” -kurssin, joka opettaa mitä jokaisen tulisi tietää tekoälystä.
Practical AI -kurssi: perusteet tuottavasta tekoälystä
Practical AI -kurssi perehtyy (tuottavaan) tekoälyyn yleistasolla ja käytännönläheisesti. Kurssi käy läpi tärkeimmät käsitteet, tutustuu tuottavaan tekoälyyn ja opettaa käyttämään kieli- ja kuvamalleja. Kurssi on tarkoitettu kaikille aiheesta kiinnostuneille, eikä sen suorittaminen edellytä teknistä osaamista, tutkintoa tai sanakirjaa.
Kurssin laajuus on kaksi opintopistettä (2 op / ECTS) ja arviointi perustuu hyväksytty/hylätty-asteikkoon. Edetä voi omaan tahtiin. Itsellä kurssin läpikäymiseen taisi mennä pari iltaa, eli aika paljon vähemmän kuin tuo opintoviikkojen 2 * 27 tuntia.
Kurssin on kehittänyt Microsoft Skills for Jobs, Kajaanin ammattikorkeakoulu ja yrityskumppanit. Oppimisalustana toimii Edukamu, joka on Kajaanin ammattikorkeakoulun käsialaa.
Materiaali on jaettu kuuteen osa-alueesen:
Tekoälyn tausta ja määritelmä
Johdatus tuottavaan tekoälyyn
Tekoäly arjen apurina
Kieltä tuottava tekoäly
Kuvia tuottava tekoäly
Eettiset kysymykset
Osa-alueet kattavat pääpiirteittäin sen, mitä asiasta tarvitsee ylätasolla tietää ja helpon lähestymisen tekoälyn konkreettiseen käyttöön kielimallien kautta.
Kurssin kehittäjän panos näkyi materiaalissa, sillä tuottavissa tehtävissä ja esimerkeissä käytettiin ”Copilot with Bing” -hakukonetta (OpenAI ChatGPT 4) ja ”Copilot Designer” -kuvanluontia (OpenAI DALL-E 3). Palveluiden nimet olivat ehtineet muuttumaan siitä, kun kurssimateriaali oli julkaistu 2023 keväällä, joka kuvastaa hyvin aihealueen ja palveluiden kehitystahtia. Palveluiden käyttöön ei tarvinnut Edge-selainta, vaikka materiaalissa niin kerrottiin. Positiivisena puolena muitakin tunnettuja tuottavia tekoälypalveluita esiteltiin. Microsoftin palveluiden etuna on, että ne ovat ilmaisia käyttää ja tarjoavat uusinta kielimallia.
Kokonaisuutena Practial AI -kurssi antaa yleiskäsityksen tekoälystä ja sen eri tyypeistä, menemättä kuitenkaan liikaa niiden yksityiskohtiin. Toisaalta asiaa olisi voinut käydä tarkemminkin läpi tekoälyn kehityksen osalta ja etenkin eettisten kysymysten puolesta. Tehtävät jokaisen osion lopussa olivat helppoja, joten kurssin läpikäyminen ei vaadi suurta panostusta. Lopuksi saa kivan sertifikaatin ja 2 opintopistettä Opintopolkuun.
Artikkelin kuvaa varten käytin Copilot Designeria sekä suomeksi että englanniksi, ja lopputulosta joutui hieman hakemaan. Kielimallien käyttö on oma taiteenlajinsa, että saa mitä ajattelee haluavansa. Tai sitten saa jotain parempaa, ainakin ideoita jatkokehittää.
Practical AI tekoälyn kuvittamana (kuvat: Copilot Designer)
Kun työpaikkailmoitukset vilisevät trendisanoja työpaikan organisaation ketteryydestä, matalasta hierarkiasta, itseohjautuvuudesta, osallistuvuudesta ja arvopohjaisesta kulttuurista, ollaan lähellä sitä kulttuuria, jossa itse olet parhaimmillasi ja onnistut yhdessä tiimisi kanssa. Mutta mitä tämä tarkoittaa käytännössä? Kävin ottamassa asiasta syvempää oppia Neuroleadershipin kurssilla ”FLOW – Brain-based coaching for agile teams” ja oppimassa lisää kollegoiden mentoroinnista, johon olen työpaikallani käytettävissä. Goforella kehitetään henkilöstölle tarjottavaa mentorointia ja coachausta tiimin ja henkilön kehittymisen tueksi, jota tehdään toisten goforelaisten toimesta.
”Kohti kulttuuria, jossa toisiaan arvostavat asiantuntijat tekevät yhdessä töitä asiakasarvon luomiseksi? – FLOW: Brain-based coaching for agile teams”
FLOW-ohjelman fokus on yhdessä onnistuminen vaativassa asiantuntijatyössä paineen alla. Nelipäiväisen ohjelman aikana kehitettiin valmiuksia yhä itseohjautuvampaan ja ketterämpään toimintaan ja opittiin käytännön keinoja olla itse parhaimmillaan ja onnistua yhdessä tiimin kanssa.
Ohjelma alkoi tunnin virtuaalisella orientaatiosessiolla ja jatkui kahdella kahden päivän lähijaksolla Huone-kokoushotellissa Kampissa ja Jätkäsaaressa. Osallistujia oli noin viisitoista, kolmesta eri organisaatiosta ja jakautuen sekä tuotepohjaiseen että palvelubisnekseen tietotekniikan alalla.
organisaatioymmärrys: mitä jokaisen on hyvä tietää johtamisen isosta kuvasta, jotta ymmärtää paremmin toimintatapojen eroja niin oman organisaatio sisällä kuin asiakkaiden ja yhteistyökumppanien kanssa toimittaessa.
Paljon tiukkaa asiaa tiiviissä paketissa, kun ohjelma vielä perustuu osallistuvaan keskusteluun ja käytännön harjoituksiin. Mutta se juuri tekee FLOW-ohjelmasta toimivan ja oman lisänsä aiheen käsittelyyn tuo eri organisaatioiden käytäntöjen ja tapojen kertominen ja omaan toimintaan vertaaminen.
FLOW-ohjelmassa käsitellyt aihepiirit voi jakaa pääteemojen ”aivot ja yhdessä onnistuminen”, ”onnistu yhdessä tiimisi kanssa” ja ”avaimia oivaltavaan ja aivoystävälliseen keskusteluun” alle. Tässä lyhyt yhteenveto ohjelmassa käsitellyistä aiheista täydennettynä asiaan liittyvällä lisämateriaalilla. Kuvat ovat FLOW-ohjelman materiaalista (Virpi Oinonen/Businessillustrator.com) ja muistiinpanot niihin kirjoittajan. Suosittelen osallistumaan FLOW-ohjelmaan, sillä se tarjoaa ajattelemisen aihetta ja herättää kysymyksiä ketterämmässäkin organisaatiossa.
Aivot ja yhdessä onnistuminen
Aivot ovat tärkeässä osassa päivittäistä tekemistämme, etenkin tietotyössä, ja sen huomioiminen auttaa sekä ymmärtämään omaa toimintaamme että onnistumaan yhdessä. FLOW-ohjelmassa asiaa käsiteltiin muun muassa norsu – kuski, U-käyrä ja SCARF-mallin kautta, sekä johtamisen ison kuvan ja Cynefin-mallin avulla.
Norsu – kuski
Voidaan kuvitella, että korviemme välissä asustaa erottamaton parivaljakko, norsu ja kuski. Kuski edustaa tietoista, harkitsevaa mieltä: suunnitelmallisuutta, empaattisuutta ja joustavuutta sekä kykyä havainnoida itseään. Norsu on tiedostamaton puoli, jossa tapahtuu automaattisesti huikea määrä asioita. Muutosta saadaan aikaan, kun sekä norsu että kuski kulkevat samaan suuntaan. Tarvitaan norsun energiaa ja tarmoa, sekä kuskin ohjastamista.
– Kun rutiinit saavat kyytiä ja tunnemme olomme uhatuksi, nakkaa norsu kuskin pöpelikköön ja lähtee rymistelemään karkuun äärimmäisen energisesti. Ilman kuskia norsu voi toimia tehokkaasti, suoraviivaisesti ja refleksiivisesti, aiemmin opitun varassa ja energiaa säästäen. Järkipuhetta on turha yrittää, koska logiikka on kuskin kanssa puskassa, Arto Miekkavaara sanoo.
Norsun ja kuskin suhde näkyy myös impulsikontrollissa. Kuski asustaa aivojen etuotsalohkon kuorikerroksella ja vastaa impulssikontrollista – siinä määrin kuin kykenee, jaksaa tai viitsii. Norsu on perusolemukseltaan impulsiivinen ja kuskin impulssikontrollin alla, sikäli kun kuski on tehtäviensä tasalla: 0,5 sekuntin reakointiajasta norsu käyttää 0,3 sekunttia ja kuskille jää 0,2 sekunttia tehdä päätöksiä. Ettei norsu mene mihin mieleen juolahtaa, pitää homman hallussa toivoaksemme levollisen valpas kuski. Kolhut päähän vielä heikentävät impulssikontrollia ja norsu pääsee rymistelemään herkemmin. Eli kriittisessä tilanteessa etuotsalohkosta sammuu valot. Impulssikontrollia voi harjoitella käyttämällä ”jos…, niin…” testiä (implementation intention -strategia). Esimerkiksi ”jos Repe soittaa bisselle ja koitan pääsemään eroon röökistä, niin en lähde.”
Impulssikontrolli: kuskilla 0,2 sekunttia aikaa ohjastaa norsua
Norsu – kuski -jaoittelu kuvaa hyvin myös parivaljakon energiankulutusta: tietoisen mielen käyttäminen ja rutiinien ravistelu on energiaa kuluttavaa ja kuski vie yli puolet parivaljakon energiasta. Voidaan sanoa kuskin olevan käytössä noin 1,5 tuntia vuorokaudessa ja jokainen tietoinen päätös kuluttaa energiaa. Kannattaa siis organisoida arki niin, ettei tarvitse käyttää tahdonvoimaa. Opitut rutiinit ja tavat menevät norsun voimilla. Norsun kulkeminen autopilotilla näkyy hyvin esimerkiksi silloin, jos muutat uuteen asuntoon ja ajatkin kotimatkalla vanhaan osoitteeseen.
Norsu ja kuski, FLOW-materiaali ja muistiinpanot
Uusia tapoja ja rutiineita kannattaa opetella, mutta se vie aikaa: 2-3 kuukautta vähintään. Tapojen vahvistaminen vaatii neljää asiaa:
Aika
Huomio
Toisto
Positiivinen palaute
Yksi hyvä keino on hyödyntää 20 sekunnin sääntöä. Jos haluat eroon esimerkiksi Facebookin käytöstä, poista appi puhelimesta, jolloin sovelluksen avaaminen selaimessa kestää liian kauan ja kiusausta on helpompi vastustaa. Tai jos haluat aloittaa aamulenkit, laita illalla juoksuvarusteet valmiiksi. Uusien tapojen oppimisen työläyteen liittyen on hyvä esimerkki hieman viritetty polkupyörä, jonka ajamisen hankaluutta video hauskasti kuvaa.
U-käyrä
Käänteisen U-käyrän laki (Yerkes-Dodson laki, 1908) näyttää stressin tai luovan jännitteen riippuvuuden suorituskykyyn. Kiire ja stressi laskevat vireystilaa, jolloin kuski karkaa unille ja norsun rutiinit ja tavat ottavat vallan. Fokus hajaantuu, työt ei etene ja koneelliset ja rutiininomaiset työt onnistuvat. Flow-tila löytyy käyrän keskivaiheilta, jolloin stressi ja luovan jännite ovat balansissa. Kun on riittävästi aikaa miettiä, mutta pieni jännite, syntyy myös oivalluksia.
Töissä ja arjessa on hyödyllistä kiinnittää huomio omaan U-käyrään ja harjoitella taitoa pysähtyä ja ajatella niissä tilanteissa, joissa huomaat luisuvasi alas U-käyrän oikeaa puolta. Eli havaita kun ”norsu hermostuu”.
U-käyrä, FLOW-materiaali
SCARF-malli
David Rockin neurotieteellisistä tutkimuksista yhteen kokoama SCARF-malli kuvaa toimintaamme ohjaavia tunne- tai kokemusreaktioita. Se perustuu tutkimustuloksiin, joissa on huomattu yksilön asemaa muuttavat muutokset keskeisiksi reagoinnin syiksi. Yksilö kokee nämä muutokset joko uhkina tai palkintoina. Uhkia paetaan ja palkintoja kohti pyritään. SCARF-malli pyrkii tekemään näkyväksi sellaiset sosiaaliset ilmiöt, joita koemme joka päivä työpaikalla ja vapaa-ajalla ja se on väline, jolla voi paremmin ymmärtää omia ja muiden reaktioita.
SCARF-mallin sosiaaliset ulottuvuudet ovat: status, ennustettavuus, autonomia, yhteenkuuluvuus ja oikeudenmukaisuus. ”Managing with the Brain in Mind”-artikkeli avaa hyvin mallin merkitystä käytännössä.
SCARF-malli, FLOW-materiaali
Johtamisen iso kuva
Johtamisen iso kuva oli yksi iso teema FLOW-ohjelmassa. Frederick Laloux kuvaa kirjassaan ”Reinventing Organizations”, miten maailmankuvamme on kehittynyt. Vanhan maailmankuvan mukainen ajattelutapa ei ole enää toiminut, mikä on johtanut kehittyneempien ajattelumallien syntyyn ja jokaisella uudella tasolla olemme kehittäneet uuden, radikaalisti toimivamman tavan organisoitua.
Organisaatioissa syntyy yleensä kitkaa, kun esimerkiksi ”oranssi” organisaatio pyrkii ottamaan käyttöön ”vihreitä” menettelyjä pelkästään pintatasolla, tai kun joku menettely tuottaa ”telttoja jalkapallokentälle”. Yhtenä välitehtävänä oli havainnoida ympäröivää maailmaa ”värien” ja ”jalkapallokenttien” kannalta ja olemaan tuomitsematta itseäsi ja muita. Organisaatioiden eri värit ovat kyllä helposti havaittavissa työelämässä, kun työskentelee asiakasprojektissa monitoimittajaympäristössä.
Useimmat ketterät sovelluskehitysfirmat toimivat vihreällä tasolla, joissa avainsanoina ovat perhe, arvopohjainen kulttuuri, työntekijöiden voimauttaminen ja sidosryhmien huomioiminen. Siitä pitäisi nousta seuraavalle tasolle, tealiin, jossa sanat ovat organismi, itseorganisoituminen, kokonaisvaltaisuus ja evolutiivinen tarkoitus.
Kehittyneimmälle ajattelumallille, tealille, on Suomessa myös oma itseohjautuvasti toimiva yhteisö, jonka tarkoituksena on auttaa Suomea ja suomalaisia siirtymään kohti merkityksellistä työtä sekä kokonaisvaltaista ihmisyyttä.
Yksi johtajan tärkeä ominaisuus on ymmärtää kompleksisuutta ja osaltaan hallita sitä. Aihepiiriä käsiteltiin Dave Snowdenin Cynefin-mallin mukaan (Simple-Complicated-Complex-Chaos). Tiivistettynä kompleksisuusteoriasta voi katsoa 3 minuutin videosta, miten järjestää lastenjuhlat.
FLOW-kurssin vetäjä Arto Miekkavaara tarjosi oivaltavan kurssin lisäksi myös viitteitä lisäopiskeluun aiheeseen liittyen. Tässä muutamia aihepiirejä, joita Miekkavaara lähetti kurssin jälkeen luettavaksi.
Teresa Amabile puhe Progress principlestä on hieman kryptinen, mutta hyödyllinen 18 minuutin video, jos ”ihmisasiat” kiinnostavat. Tärkein asia, joka edistää aikaanaamista ja motivaatiota on ”progress in meaningful work”, eli edistymisen kokemus merkityksellisessä työssä.
Toinen iso aihealue on ”kohti-tila”, jonka voisi myös kääntää muotoon ”myönteisyys”. Alan jättiläinen on Barbara Fredrickson, jonka julkaisuja löytyy hänen Pohjois-Carolinan yliopiston sivuiltaan. ”Fredricksonin popularisoitu ”Broaden and build” -teoria on ollut kritiikin kohteena pääasiassa koska hänen ja työparinsa Marcial Losadan tilastollisessa analyysissä on jotain sanomista. Mutta: paljon löytyy häneltä muutakin ja tieteen tarkoitus yleensä on korjata itseään (se on se _re_ sanassa research).”
Altaan syvästä päästä: Peter Senge Otaniemessä Systeemiälyn laboratorion 30v-juhlassa pitämä tunnin puhe: ”Systems Thinking for a Better World”. Senge on maailmanluokan ajattelija, jonka 1990 julkaistu ”Fifth Discipline” pitää edelleen pintansa. Youtubesta löytyy myös kaikenlaista em. hakusanoilla.
Edelliseen liittyen, jos aihe puhuttelee, niin sitä voi käydä läpi pitkän kaavan mukaan u.labin kurssilla ”Leading From the Emerging Future”, joka johdattelee Theory U -metodiin. ”Tämän pitemmälle ei oikein tällä hetkellä taida päästä.”, kirjoittaa Miekkavaara.
Aivokemiasta keskusteluun
Kirjoitus käsitteli lyhyesti aivokemian oivaltamista, sen vaikutuksista ihmisten käyttäytymiseen ja apuvälineistä erilaisten toimintaympäristöjen ymmärtämiseen. Seuraavassa osassa aihepiiri jatkuu ”Onnistu yhdessä tiimisi kanssa” -otsikon alla ja käyn läpi aihepiirit: kuuntele potentiaalia, aivot ja oivallus, valitse fokuksesi, kysy ratkaisusta, tiimin tilanne, ”me” vai ”ne”? Lisäksi ”Avaimia oivaltavaan ja aivoystävälliseen keskusteluun” osiossa käyn läpi kurssilla esitetyt keskustelurungot: ”Next Step – oivaltava ongelmaratkaisukeskustelu” ja ”Check-in – aivoystävällinen seurantakeskustelu”.
Ketterä kehitys ja lean-ajattelu ovat yleistyneet viime aikoina myös isommissa organisaatioissa ja sovelluskehitystä on opittu tekemään järkevämmällä tavalla. Mutta miten hallita isoja hankkeita, joissa on satoja kehittäjiä ja useita kokonaisuuksia? Tähän kysymykseen yrittää Scaled Agile Framework, eli lyhyemmin SAFe, tuoda vastauksen määrittelemällä miten voidaan ketterä kehitys skaalata enterprise-kontekstissa. Kävin muutama viikko sitten tutustumassa aiheeseen Leading SAFe -kurssilla ja samalla suoritin SAFe Agilist -sertifikaatin.
Leading SAFe
Leading SAFe on kaksipäiväinen kurssi, jossa perehdytään Scaled Agile Frameworkin saloihin ja kurssi antaa valmiudet johtaa SAFe -mallin kehitystä ja suorittaa SAFe Agilist -sertifikaatti. Kehyksenä SAFe on jaettu kolmeen osa-alueeseen, joiden avulla bisneksen strategiset teemat muokkautuvat ratkaisuja tuottaviksi arvovirroiksi, ketteriksi julkaisujuniksi ja useiksi Scrum-tiimeiksi. SAFen pääpirteittäinen idea selviää hyvin Scaled Agile Frameworkin -sivuilla olevasta kuvasta, josta voi klikata eri osa-alueita, jotka kehyksen koostavat: tiimi, hanke ja portfolio.
SAFe 3.0
Kurssin ensimmäinen päivä sisältää ketterään kehitykseen liittyen Lean-ajattelua ja ketterän kehityksen skaalaamista. Lisäksi aloitetaan Agile Release Trainin, eli junan, läpikäyntiä, josta jatketaan seuraavana päivänä. Viimeisenä päivänä käydään läpi myös portfolio-taso ja johtamisen skaalaamista. Läpikäytävän asian määrä on ihan kohtuullinen, vaikka etenkin viimeisenä päivänä loppuosan materiaali juostaan hieman läpi. Kokonaisuuteena kurssi antoi hyvän yleiskuvan SAFesta ja sisäisen kurssin kouluttajina toimineet CGI:n Anna Ferguson ja Juha Rossi vetivät asiat hyvin läpi.
Kurssin sisältö ei ole kovinkaan yllättävää, sillä käytännössä se kertaa sen kaiken hyvän käytännön, jota ketterä kehitys ja lean-ajattelu sisältävät ja paketoi sen isompaan kokonaisuuteen lisäten siihen omat vaiheensa. Tämän jälkeen tosin voi ajatella, että onko tekeminen enää kovin ketterää, kun ympärille on leivottu vaikka mitä, mutta aina se vesiputousmallin voittaa. Sovelluskehityksen ennustettavuuteen ja koodin laatuun, sekä johtamiseen liittyviä asioita kannattaa soveltaa pienemmässäkin skaalassa.
Mielipidettä SAFen toimivuudesta en osaa sanoa, sillä sen näkee vasta käytännössä, kun/jos sitä itse pääsee toteuttamaan ja muodostamaan oman näkemyksensä eri osa-alueiden toimivuudesta. Kehyksessä on kuitenkin paljon jo muissa yhteyksissä hyväksi havaittuja asioita, joiden käyttäminen varmasti edesauttaa parempaan lopputulokseen pääsemisessä.
SAFe Agilist -sertifikaatti
SAFe Agilist -sertifikaattitesti on avoin testi, jossa saa käyttää haluamiaan materiaaleja ja se suoritetaan kotona. Kysymykset koostuvat Leading SAFe -kurssimateriaalista ja Scaled Agile Framework -sivuston materiaalista ja kysymykset ovat yhdistelmä enemmän tai vähemmän hankalia ja visaisia, joihin vastauksien löytäminen on myös oppimiskokemus.
Leading SAFe -kurssi antoi kohtalaiset valmiudet sertifikaatin suorittamiseen, mutta testiä tehdessä tuli googleteltua, luettua SAFen sivustoa ja kurssimateriaalia sen verran paljon, että 50 kysymyksen vastaamisessa kesti noin kolme tuntia. Kurssi ja sen materiaali ei vastaa selkeästi asioihin, vaan toimii lähinnä viitteenä mistä aihepiiristä vastausta voi etsiä. Kaikkiin kysymyksiin en löytänyt oikein hyvää vastausta, joka näkyi tuloksissakin, mutta testi meni kuitenkin läpi pistein 172 / 218 (40/50 kysymystä) rajan ollessa 130 pistettä, joten kai sitä voi olla vastauksiin tyytyväinen.
Yhteenveto
Kurssina ja aiheena Leading SAFe oli mielenkiintoinen, vaikkakin asiat olivat Scrumin ja Kanban -kurssien jälkeen osittain toistoa. Harjoitukset tukivat tekemistä, mutta enemmän kurssista saa irti, jos suunnitteilla on, tai on osallistunut isoihin sovelluskehityshankkeisiin.
Scaled Agile Framework tuo suuriin hankkeisiin, ainakin toivottavasti, ketteryyttä ja sen sisältämät menetelmät ja ideat toimivat pienemmässäkin skaalassa. Hyvä koodi, parempi mieli.
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.
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.
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.
