Ketterä ohjelmisto­ke­hi­tys ja sen menetelmät

Ketteriä (agile) menetelmiä on useita. Niitä yhdistää ajatus nopeista, projektin edetessä tarkentuvista kehityssykleistä, joita usein kutsutaan sprinteiksi. Luonteenomaista on myös läpinäkyvyys ja valmius tehdä tarvittaessa nopeita muutoksia. Tavoitteena on tehdä toimiva ratkaisu lyhyessä ajassa.

Keskeistä on myös ajatus siitä, että ohjelmistokehittäjien ja liiketoiminnan edustajien tulee tehdä yhteistyötä läpi koko hankkeen. Tavoitteena on vastata bisnestarpeisiin ja niiden muutoksiin sekä mahdollistaa tiheä päivityssykli, jos liiketoiminnan luonne ja loppuasiakkailta saatu palaute sitä edellyttävät.

Tärkeässä roolissa on kehittämisfilosofia, jonka mukaan uutta (ohjelmisto)ratkaisua luotaessa tavoitteena on sujuva ja tehokas järjestelmä. Tämä tarkoittaa yrityksen nykyisen järjestelmän ja nykyisten prosessien haastamista — miksi siirtää vanha kömpelö prosessi ohjelmistoksi, kun kenties koko vanhentunut työnkulku kannattaisi suunnitella uudestaan.

On hyvä huomata, että ei ole olemassa yhtä oikeaoppista tyyliä tehdä ketterää ohjelmistokehitystä. Siksi kehitysprojekteissa onkin tärkeää ymmärtää jo ennen starttia, mitä ohjelmistokehitystiimi ketteryydellä tarkoittaa ja miten se sitä käytännössä toteuttaa. Ketterän ohjelmistokehityksen menetelmät eivät kaikki ole keskenään helposti yhteensopivia, joten kehittäjätiimin ja asiakastiimin odotuksia ja toimintatapoja on hyvä käydä läpi ennen hankkeen alkua.

Mistä ketterässä ohjelmistoke­hi­tyk­ses­sä on kysymys?

Ketterät menetelmät ovat kurinalainen ja systemaattinen tapa suunnitella, luoda ja testata ohjelmistoja niin, että työ tehdään nopeiden iteraatiokierrosten kautta. Agile-maailman nimikkeisiin ei kannata hukkua, mutta monista termeistä on tullut lähes yleiskielisiä järjestelmäkehittäjien ja konsulttien käyttäminä.

Monille on tuttu 1-4 viikon mittaisten kehityssprinttien ketju. Jokaista sprinttiä ennen scrumtiimi päättää sprintin tavoitteet ja tehtävänjaon. Tiimi vastaa siitä, että tavoitteet toteutuvat, ja käyttää myös hyvin itsenäistä päätäntävaltaa työtavoistaan. Tiimi esittelee saavutuksensa sprinttikatselmuksissa, joissa tuoteomistaja (product owner) arvioi etenemistä ja onnistumista. Luonnollisesti tiimi myös arvioi omaa toimintaansa ja hienosäätää sitä tarpeen mukaan.

Scrumtiimi koostuu tuotteen omistajasta, kehitystiimistä ja scrum masterista. Perinteisestä projektijohdosta poiketen, scrum master ei toimi esimiehenä, vaan fasilitoi työtä, poistaa esteitä, viestii joka suuntaan ja ylläpitää ketterien menetelmien noudattamista. Käytännössä isommissa hankkeissa on tästä syystä myös aina erillinen asiakasvastaava tai projektipäällikkö, joka vastaa klassisessa mielessä ohjelmistokehitysyrityksen ja asiakasyrityksen välisestä asiakassuhteesta liiketoimintatasolla.

Muutosjoustavuudesta huolimatta ketterä ohjelmistohanke vaatii ratkaisun omistajalta selkeän vision toteutettavasta kokonaisuudesta. Tavoitteen on oltava kirkas.

Asiakas osallistuu ketteriä menetelmiä käytettäessä useammin ja enemmän projektin seurantaan ja projektinaikaisiin muutoksiin kuin perinteisemmässä niin kutsutussa vesiputousmallissa (waterfall), jossa on kenties vain muutama kommentointi- ja hyväksyntäkierros koko hankkeen aikana.

Asiakkaalla on ketterässä kehitysmallissa iso vastuu. Asiakkaan puolella täytyy olla kehitettävälle ratkaisulle yksi selkeä omistaja (product owner) ja hänen on osallistuttava projektiin aktiivisesti. Tämä rooli edellyttää ajankäyttöä ja päätöksentekokykyä. Asiakkaalla on iso merkitys määrittelytyössä ja backlogin, eli työtä ohjaavien tuotevaatimusten ja niihin liittyvien muutosten priorisoinnissa.

Tosiasiassa ketterien menetelmien esittäminen täysin vastakkaisena vaihtoehtona vesiputousmallille ei tee oikeutta kummallekaan toimintatavalle. Ensinnäkin, agile ei ole aina vaihtoehto. On tilanteita, joissa klassinen waterfall-malli on toimivin tai esimerkiksi tilaajalle tutuin ja helpoin toimintatapa. Toiseksi, vesiputousmallikin pitää sisällään paljon erilaisia nyansseja ja on kehittynyt vuosien varrella. Kokeneet toimijat voivat myös yhdistää ketteriä menetelmiä ja klassista vesiputousmallia erityisesti laajemmissa hankekokonaisuuksissa.

Näin Fellowmind Finlandilla tehdään ohjelmistokehi­tysp­ro­jek­te­ja ja sovelletaan lean-ajat­te­lua

eCraft (nyk. Fellowmind Finland) on alunperin perustettu ohjelmistokehitysyhtiöksi. Meillä on kahdenkymmenen vuoden kokemus ohjelmistoratkaisujen kehitystyöstä ja paljon käytännössä testattuja ketteriä toimintamalleja.

Ketterät menetelmät nousivat uudistamaan ohjelmistokehitystä aivan 2000-luvun alussa, juuri samoihin aikoihin, kun eCraft oli vakiinnuttamassa omaa toimintaansa. Siksi ketterä toimintatapa on leimannut työtämme alusta asti. Olemme hioneet sen vuosien varrella toimivaksi ja sadoissa asiakasprojekteissa testatuksi työskentelymalliksi.

Ketteryys yhdistyy Fellowmind Finlandilla lean-ajatteluun ja haluumme tehdä asiakkaidemme kanssa jatkuvaa kehitystyötä, ei vain yksittäisiä projekteja.

Näin me näemme ketteryyden:

• Mieti loppuasiakasta: Pohdi, mikä toiminta luo loppuasiakkaalle aidosti arvoa, ja kuinka tuota arvoa voisi lisätä samalla, kun turhaa työtä poistetaan.

• Osallista ratkaisun omistajat ja käyttäjät: Nopea palaute on tärkein ohjausmekanismi. Testaa asiat käytännössä, ei laboratoriossa.

• Haasta asiakas päästämään irti vanhasta: Eliminoi vanhentuneisiin prosesseihin ja työkaluihin liittyvä hukkatyö, poista tarpeettomat vaiheet ja luo uusi, virtaava työnkulku.

• Tutustu työn arkeen: Vanhaa prosessia ja/tai järjestelmää tarkkailemalla löydämme nopeasti tärkeimmät kipukohdat, jotka pitää ratkaista. Tarkkailu yhdistetään asiakkaan antamaan briiffiin ja usein jo tässä vaiheessa meillä on tarjota tärkeitä oivalluksia kehitysprojektin tavoitteista.

• Luo arvoa, älä käytä projektin aikaa hukkatoimintoihin: Teemme työtä suoraviivaisesti ja vähällä hierarkialla.

Ketterät ohjelmistokehi­tys­me­ne­tel­mät vaativat kokemusta

Ketterät menetelmät vaativat kokemusta. Osaava ohjelmistokehityksen tiimi osaa välttää niitä tyypillisiä haasteita, joita ensi kertaa ketteriä menetelmiä soveltavat tiimit kohtaavat:

• Pilkkoutumisansa: Isoissa hankkeissa ketterät menetelmät johtavat joskus hajanaiseen kokonaisuuteen, kun kehitys tapahtuu osissa ja välttämättä kukaan ei katso ratkaisun yhtenäisyyden ja saumattoman toimintalogiikan perään. Kokenut tiimi osaa välttää tämän ansan.

• Muutosansa: Ketteriin menetelmiin sisäänrakennettu filosofia nopeista muutoksista ja reagointikyvystä voi johtaa väärissä käsissä siihen, että tavoitteita ja vaatimusmäärittelyä muutetaan projektin sisällä jatkuvasti. Syntyy paljon toimintaa ja vähän valmista. Tässä auttaa selkeä tavoitemäärittely.

• Resurssiansa: Ketterät menetelmät eivät ole taikatemppu, jolla pystyttäisiin ratkomaan vaikeita ongelmia minimaalisilla resursseilla. Ketteryys ei ole oikopolku. Isot ongelmat voidaan pilkkoa pieniksi paloiksi, mutta resursseja ne silti edellyttävät. Vaativat työt edellyttävät riittävästi aikaa ja asiantuntijoita menetelmästä riippumatta. Osaava konsultti on realistinen työmääräarvioissaan.

• Legacyansa: Yrityksen olemassa olevaa prosessia ei aina kannata suoraan siirtää uudeksi tietojärjestelmäksi. Ensin on viisasta pohtia, voisiko prosessia sujuvoittaa suunnittelemalla se uudestaan. Moni ohjelmistoratkaisu kytkeytyy liiketoiminnan kehittämiseen ja silloin oikea lähtökohta on miettiä ensin arvovirtoja ja yrityksen toimintojen läpileikkaavia prosesseja - vasta sitten koodata ratkaisu ketteriä menetelmiä käyttäen.

• Itseohjautuvuusansa: Ketterän ajattelun omaksuneet ohjelmistokehitystiimit ja asiakasyrityksen tiimit ovat kyllä itseohjautuvia työssään. Ne tarvitsevat silti kirkkaan, ylimmän johdon tukeman tavoitteen. Itseohjautuvuus ei ole sitä, että tiimi keksii itse tavoitteensa.

Muita ratkaisuja ohjelmistoke­hi­tyk­sen tehostamiseen

Ketterät menetelmät eivät ole itseisarvo. Joissain tilanteissa perinteisellä menetelmällä toteutettu projekti, joka hyödyntää esimerkiksi Microsoft Power Apps -työkalua liiketoimintasovellusten nopeaan luomiseen, on paras ratkaisu kehitystyön tehostamiseen. Toki Power Apps -sovellusratkaisuja voi käyttää myös ketterän työprosessin sisällä lisävauhdittajana.

Markkinoille onkin syntynyt joukko niin kutsuttuja low-code -työkaluja, jotka eivät korvaa perinteistä sovelluskehitystyötä, mutta voivat tarjota nopean ratkaisun yksinkertaisten uusien sovellusten rakentamiseen. Power Apps on yksi tällainen työkalu ja sopii esimerkiksi tilanteisiin, joissa halutaan tuoda ja viedä tietoa sekä käsitellä sitä automatisoidusti eri järjestelmien välillä.

Siinä, missä ketterät menetelmät vauhdittavat työn tekemisen prosessia, voi low-code -ratkaisuilla nopeuttaa itse koodin tekemistä.

Vastaavalla tavalla kaikki merkittävät pilvipalveluiden tarjoajat ovat kehittäneet valmiit työkalut pilvi-infran konfigurointiin, hallitsemiseen ja tietoturvaan. DevOps-toimintamallin myötä ohjelmistokehittäjän ei enää tarvitse rakentaa ja testata omia ratkaisuja infran hallintaan. DevOps toimii ohjelmistokehityksen (development) ja IT-operaatioiden/palvelutarjonnan (operations) eli tuotantoonviennin, operoinnin ja monitoroinnin automatisoinnin välineenä: kehityksen, testaamisen ja ylläpidon toiminnot tehdään valmiin sapluunan mukaan. Tuloksena on koordinoidumpi ja ketterämpi työtapa kehityksen ja palveluoperoinnin välillä. DevOpsin filosofiaan sisältyy jatkuvan oppimisen ja kehittämisen kulttuuri.

Ketteriä menetelmiä ei kannata myöskään väärinkäyttää työhön, jota ei kenties pitäisi tehdä ohjelmistokehitystyönä lainkaan. Esimerkiksi perusjärjestelmiin, kuten toiminnanohjausjärjestelmään (ERP) tai asiakkuudenhallintajärjestelmään (CRM), on saatavilla valmiita lisäarvopalveluita ja toimialakohtaisia paketteja, joilla voidaan nykyään toteuttaa paljon toiveita, jotka ennen olisivat vaatineet koodausta.

Erityisesti Microsoft-ekosysteemi tarjoaa paljon valmiita ratkaisuja. Kokenut toimittajakumppani osaa hyödyntää valmiiden pakettien ja kehitystyökalujen mahdollisuudet perinteisen ohjelmistokehitystyön rinnalla.

Tietyissä tilanteissa toimivinta on edetä hybridimallilla. Olemme Fellowmind Finlandilla toteuttaneet esimerkiksi useita olemassa olevan CRM-järjestelmän päälle rakennettuja käytettävyyttä ja käyttöliittymää parantavia ratkaisuja. Nämä ratkaisut toteutetaan ketterän ohjelmistokehityksen periaattein. Laajemmissa CRM- ja ERP-hankkeissa voidaan puolestaan toteuttaa järjestelmän käyttöönottoa perinteisemmällä kaavalla ja sen rinnalla tehdä ketterin menetelmin kokonaisuutta täydentäviä kehitystöitä.

Jos haluat kuulla aiheesta lisää, olethan yhteydessä!