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.
Vastaa