Prosessimalli ja ihminen

globaalin haaste
innovatiivisuudelle
ketterä tiimi?

prosessimalli
motivoi, mahdollistaa
ihmisen tarpeet
Laskeva aurinko sinkosi punertavat liekkinsä SYSOPENDIGIAn tornin yllä kaartuvalle taivaalle Sytyken MallinnusOSYn pienseminaarin ”Toiminnan tehostaminen prosessimallein” alussa.
Ohjelmistokehitysprosessin mallintaminen
Henrik Terävä SYSOPENDIGIAsta kertoi ohjelmistokehitysprosessin mallintamisesta ja käytöstä diplomityönsä ”Software processing modelling with EPF” pohjalta. Ohjelmistokehityksen yleisiä haasteita ovat tiedonjako tiimeille, prosessien integrointi, koulutusmateriaalien ajantasaisuus ja tehokkaat prosessit. Turhan usein prosessimalli eroaa käytännön mallista, vaikka ohjelmistokehityksen pitäisi perustua ihmisen toimintaan. Prosessin pitäisi motivoida kehittäjän tarpeiden mukaiseen oikeaan toimintaan – kuten häkistä toiseen siirrettävää oravaa motivoi toisessa häkissä avoimen oven takana odottava pähkinä.
Suomalainen, avoimen lähdekoodin tuote OpenMethod säästää aikaa ja mahdollistaa tietämyksen hallinnan. Se tarjoaa standardit rajapinnat räätälöintiin ja uudelleenkäyttöön. Haasteena ovat eri kielialueet ja muutosvastarinta.
Ensimmäisessä demossa Sytyken pienseminaarin työvaiheet ja kestot mallinnettiin ohjelmistokehityksen työkaluilla, toisessa tutkittiin kirjaston staattista ja dynaamista sisältöä, vaatimusmäärittelyn tehtäviä sekä raportteja ja ohjeita, kolmannessa projektista laadittiin julkaisu asiakkaalle.
Yleisöstä kysyttiin, käytetäänkö oikeassa projektissa tällaista tuotetta: menetelmiä on muutenkin niin paljon, ettei niihin tutustumiselta ehdi tehdä oikeita töitä. Onko taustalla kuvitelma ohjelmistokehitystyön jakamisesta yksinkertaisiin paloihin? Eiväthän palat loksahda kohdalleen ilman syväosaamista.
Rami Talme RP5 Softwaresta kertoi EPF Composerin ja Rational Method Composerin käyttökokemuksistaan. Miten asiakas saataisiin osallistumaan sovelluskehitykseen? Kuvaaminen on raakaa työtä ja sisällön tuottaminen vaikeaa; tätä tosiasiaa työkalu ei muuta. EPF:n sateenvarjosta voidaan poimia tarvittava, kerätä sisältöjä eri paikoista ja menetelmistä kuten Scrumista, XP:stä ja RUPista. Menetelmät periytyvät, omia menetelmäsisältöjä ja steppejä voidaan lisätä tai poistaa.
Yleinen väärinkäsitys lienee, ettei Scrumissa tarvitse dokumentoida eikä välittää arkkitehtuureista, koska ne kasvavat prosessin mukana. Hyvä tiimi osannee toimia ilman kuvausta, mutta uudet jäsenet tarvitsevat jotain kättä pidempää. Aiemmin menetelmäkehityksessä laadittiin sisältöjä kuvaamatta niiden järjestystä tai käyttötapauksia – mikä selittänee prosessikuvausten nykytilaa.
Miksi projektia säädellään? Eikö valmis ohje sovellu omaan tilanteeseen? Malliksi voidaan ottaa osaavan tiimin prosessi ja katsoa, sopiiko se omaan tilanteeseen vai pitäisikö iteratiivisesti edeten tuunata siitä omiin tarpeisiin soveltuva.
Ohjelmistoprosessit muuttuvassa maailmassa
Antero Järvi Turun yliopistosta puhui ohjelmistoprosesseista muuttuvassa maailmassa. Muutos syntyy liiketoiminnasta, ei menetelmistä tai teknologiasta. Globaalien markkinoiden hajautetuissa hankkeissa ja lyhyissä tuotesykleissä innovaatioverkostot ja asiakas nousevat keskeisiksi.
Ketterä kehitys yhdistettyjen kompetenssien tiimeineen vastaa muuttuvan maailman tehokkuus- ja reaktiivisuusvaatimuksiin. Ohjelmistokehityksen perusyksikkö voisikin olla ketterä tiimi, jossa jokainen vastaa tekemisistään.
Miten itsenäiset ja ketterät kehitystiimit toimivat tuotehankkeessa tarkoituksenmukaisesti? Kun hallitsemme toisaalta laajat, muokattavat prosessikehykset, toisaalta ketterien menetelmien skaalauksen, tarjoaisivatko monitiimiset sovellukset nykykehitykseen optimaalisen ratkaisun?
Laajoissa prosessikehyksissä kehittämisstrategia on mietitty, riskinhallinta korostunut ja vaiheet päättyvät tarkistuspisteisiin. Työkäytänteiden tarkka kuvaaminen aiheuttaa turhia riippuvuuksia. Ketterässä kehityksessä asiakas on kiinnostunut tuotteesta ja tiimi on tuotteen kehityskone. Ketteryyteen kuuluu epävarmuus: ymmärrys siitä, mitä ollaan tekemässä, kasvaa iteratiivisessa prosessissa.
Miten tiimit suojataan prosessirajapinnalla? Yhdestä käyttötapauksesta voi tulla vaatimuksia kahteen tuotekomponenttiin, joita eri tiimit tekevät yhtaikaisesti. Tällöin tarvitaan scrum-mastereiden yhteydenpitoa ja kustomointia sprinttien aikana. Voidaanko hanketta skaalata entistä isommaksi lisäämällä scrum-tiimejä, joiden välisiä riippuvuuksia scrum-masterit selvittävät scrum-tapaamisissaan?
Kehitysprojektit kytkeytyvät liiketoimintaprosesseihin, toiminnan kehittämiseen ja organisaation oppimiseen. Tuoteprojektit tarvitsevat valmiita ratkaisuja; aikaa on turha kuluttaa organisoitumistapojen miettimiseen. Menetelmästä riippumatta tarvitaan tiimijakoa, työnkulkuja, koordinointia ja vaatimusmääritystä. Tilannekuva auttaa mukauttamaan prosesseja projektin aikana ja viestimään – ja antaa tiimeille tilaa keskittyä kehitystyöhön.
Pienseminaarin esitysmateriaali löytyy Sytyken MallinnusOsyn sivulta.

Pyrähtelevä ohjelmistokehitys

vaatimus jäätyy
putoukseen, pyrähtää
sulaen scrumiin

rup ruoppaa pienen
palan valmiiksi, muuttaa
lennossa suuntaa
Nykyaikaiset ohjelmistokehityksen mallit olivat aiheena Sytyken MallinnusOsyn jäsentilaisuudessa 17.9.07 SYSOPENDIGIAlla.
Paula Salmi Osuuspankkikeskuksesta (OPK), nykyisestä OP-Pohjolasta esitteli heidän kehittämänsä V5-mallin, Allan Halme Accenturalta pureutui RUPin teoriaan ja Lasse Koskela Reaktor Innovationsista pohdiskeli Scrumin taustaa ja todellisuutta tänään.
Yleisössä istuneet kokeneet systeemityöläiset toisaalta kritisoivat Allan Halmen turhan teoreettista esitystä RUPista, toisaalta täydensivät Lasse Koskelan esitystä omilla kokemuksillaan scrumista.
V5-malli kehittää
OP-Pohjolan organisaatiouudistus pyrki eroon eri palvelualueilla toimineiden järjestelmäkehittäjien erillisten ratkaisujen koordinointiongelmista. Ict-palvelut ostetaan keskitetystä ict-organisaatiosta, vaikka liiketoiminnan tavoitteet määritetään edelleen palvelualueilla ja liiketoiminnan edustajat päättävät hankkeiden priorisoinnista ja etenemisestä.
Kehitysprosessin vaiheet noudattelevat perinteistä systeemityömallia idean kiteyttämisestä pilotointiin, jalkauttamiseen ja hyötyjen mittaukseen. Malli on ryhdistänyt ja selkeyttänyt prosessia ja vastuunjakoa, mutta haasteet eivät ole kadonneet: tehtävät ja dokumentit ovat vielä osin päällekkäisiä ja riittävän informaation takaaminen kapulanvaihtotilanteissa eri yksiköissä toimivien määrittelijöiden ja testaajien välillä vaatii ponnisteluja.
Paula Salmi kevensi esitystään kuvalla näppikseen nojaavasta pääkallosta, jota näytöltä tuijotti teksti ”Waiting for reply”. Hän kertoi ketterän kehittämisen käynnistyneen OP-Pohjolassa sertifioitujen projektipäälliköiden ja OWASP-tietoturvaan erikoistuneiden testaajien myötä.
RUP palastelee
Allan Halme vertasi RUPia vesiputousmalliin. RUPissa vaatimuksia ei jäädytetä, mutta koodaus kannattaa aloittaa vasta kun neljä viidesosaa järjestelmästä on määritelty. Kiinteähintainen tilaus edellyttää mahdollisimman hyvää vaatimusmääritystä.
Systeemityötä voi verrata Firenzen katedraalin kupolin rakentamiseen 1400-luvulla: järjestelmästä saa todellisen kuvan vasta, kun toteutus on jonkin matkaa edennyt ja nähdään, pysyykö toteutus sovituissa raameissa ja onko järjestelmän suorituskyky riittävä.
Kun tilaajalta tulee uusia tarpeita kesken projektin, RUPissa osa järjestelmästä on valmiina ja suuntaa voidaan muuttaa kohti uusia tavoitteita. Vesiputousmallissa taas kaikki olisi levällään eikä suunnan muuttamiseen löytyisi kiintopistettä.
Yleisö oli aktiivinen: Vastaava palasteleva suunnittelu-toteutus-idea kehitettiin jo 1990-luvun alussa Sytyken STST-työryhmässä, nykyisen Rela-yhteisön edeltäjässä. OP-Pohjolan V-malli ei tietenkään noudata vaihejakoa vesiputousmaisesti, kuten Allan Halme tulkitsi, vaan sisältää luonnollista iteraatiota, kun käyttäjät, ongelma, teknologia tai markkinat saattavat muuttua projektin aikana. Esitetyt RUPin työmääriä kuvaavat käyrät eivät toimi versioivassa tuotekehityksessä, jossa vaatimusmäärityksen työmäärä ei vähene työn edetessä.
Scrum pyrähtää
Lasse Koskela esitti Scrumin tausta-ideat kuvaamalla Toytan toisen maailmansodan jälkeisestä innovoivaa tuotekehityksestä, jossa pienin askelin tehokkaasti tehtiin jotain konkreettista, mikä tuotti lyhimmän kehitysajan ideasta valmiiseen tuotteeseen. Tältä pohjalta kehitettiin Scrum 1990-luvun alussa.
Asiakkaan priorisoimat tärkeät kehittämistoimenpiteet kootaan Product Backlogiin, josta kahdesta neljään viikkoon kestävän pyrähdyksen työmäärä poimitaan Sprint Backlogiin. Pyrähdyksen jälkeen tuotos on valmis eikä vaadi hiomista.
Ict-ammattilaisten velvollisuus on selvittää asiakkaalle priorisointiin ja toteutusjärjestykseen vaikuttavat tekniset asiat. Yleisön joukosta todettiin, että Scrumissa käytetään jatkuvasti aikaa Backlogin kampaamiseen, ettei se happane.
Scrumia opitaan tekemällä, ei kurssilla. Prosessi on yksinkertainen, mutta vaikea soveltaa. Scrumin toimijoita ovat tuotteen omistaja, moniosaava ja itseohjautuvat tiimi, johon kuuluu 5-9 henkilöä sekä Scrum-master. Scrum-master on kuin voi leivän välissä, poistaa esteitä ja ylimääräisiä välikäsiä sekä huolehtii prosessin järkevästä soveltamisesta.
Asiakkaiden kanssa keskustellaan heidän ymmärtämällään kielellä. Siihen ei kuulu pariohjelmointi eikä Scrum-master.

Sytyken MallinnusOSY

abstrakti malli
kehittää ketterästi
verkkopalvelut
Historian siivet havisivat, kun Sytyken OlioOSYn tuhkasta nousevan MallinnusOSYn ensimmäisessä miniseminaarissa 18.4.07 SysOpenilla kaksi puhujaa ja kaksi osallistujaa muistelivat yhdessä Sytyken Oliotyöryhmää, jossa viisitoista vuotta sitten työstivät yhdessä raporttia Oliot systeemityössä.
Jukka Tamminen aloitti historiakatsauksella 1980-luvun lopulla Finnairilla tehtyihin SRM-tutkimuksiin, jotka paljastivat yksitoista asiakastietojärjestelmää; joka sovelluksella oli omansa ja jokaisessa niistä tiedot eri tiloissa. Kokonaismallintaminen selkeytti tilannetta, mutta toi raskaat vuosia kestäneet projektit, jotka vastasivat huonosti nopeasti muuttuvan liiketoiminnan tarpeisiin.
Tänään tietojärjestelmiä kehitetään ketterästi. Muutamassa päivässä laadittava abstrakti oliomalli auttaa hallitsemaan useat samanaikaiset ketterät projektit. Malliin kootaan kaikki keskeiset käsitteet, joista liiketoiminta tarvitsee tietoa. (Otus, jota Jukka Tamminen nimitti oliomalliksi, on mielestäni UML:n mukainen luokkamalli.)
Malli tuottaa todellisuudesta toisen todellisuuden, lennoista varausjärjestelmän. Tarvitsemme älykkään ihmisen, joka huomaa vastaavuudet näiden todellisuuksien välillä – ja tämän älykkään ihmisen soisi olevan mukana jo järjestelmän rakennusvaiheessa.
Jukka sanoi, että jos liiketoiminnan abstrakti malli tietää jotain käyttöliittymistä, se on saastunut. (Saman tapaista ajatusta olen itse vuosikausia yrittänyt tolkuttaa opiskelijoilleni.)
Sakari Lehtonen heitti, että olioiden aika oli vuosina 1991-2006, mutta nyt on siirrytty SOAan. 1980-luvulla meillä oli moduulit, 1990-luvulla käyttötapaukset ja 2000-luvulla palvelut. Modulaarisuus tarkoittaa metsän näkemistä puilta. B2B tarkoittaa verkostoliiketoimintaa. Domain Modelista eli liiketoimintamallista saadaan XML-malli – niin, yksinkertaisesti väkäsillä.
Tilakaavion käyttö ja merkitys on herännyt uudestaan henkiin, kun mallinnetaan liiketoimintatapahtuman tilaa. Nykyisin puhutaan rekisterien sijaan komponenteista, mutta transaktiot ovat samoja kuin ne ovat olleet neljännesvuosisadan ajan. Uutta on integraatiokerros ja sen BPEL-kieli. BPM-prosesseissa orkesteroidaan liiketoimintaprosessit karkealla tasolla kun taas UML:n käyttötapaukset kertovat käsittelysäännöt tarkemmalla tasolla.
Sakarin mielestä luokkamallia ei pidä esittää liiketoiminnan edustajille vaan heidän kanssaan keskustellaan käyttöliittymien avulla. Oma kokemukseni on erilainen: käyttäjät, asiakkaat tai tilaajat, vaikka heillä ei olisi it-alan koulutusta, osaavat lukea luokkamallia ja ottaa kantaa luokkiin ja niiden välisiin yhteyksiin, kunhan heille annetaan selkokielellä mallin lukuohjeet. Käyttäjät ovat toimintansa asiantuntijoita; juuri he pystyvät kertomaan, voiko tilauksella olla yksi vai monta tilaajaa – tai asuntolainalla monta lainanottajaa, esimerkiksi mies ja vaimo.
Joku yleisön joukosta tiesi kertoa Ivar Jakobsonin sanoneen viime vuoden lopulla Suomen-vierailullaan, että UML on kuollut. Mielenkiintoista! Kun viisitoista vuotta sitten työstimme Sytyken Oliotyöryhmässä Oliot systeemityössä -raporttia, ei UML ollut vielä syntynyt eikä käyttötapauksia keksitty.
Sakari ja Jukka väittelivät kiivaasti käyttötapauksista ja kollaboraatiokaavioista. Sakari kannatti edellisiä ja piti jälkimmäisiä tarpeettomina kun taas Jukka oli täysin toista mieltä.
Illan viimeinen esiintyjä, nuori teoreetikko Tomi Reinikainen kertoi intressiperusteisesta lähestymistavasta. Intressejä on eri tahoilla ja niitä päivitetään järjestelmän elinkaaren ajan, myös ylläpitovaiheessa.