Ketteryys vaatii ajattelun muutosta
Ohjelmistokehityksessä päivän sana on jo jonkin aikaa ollut ketteryys. Ketterä ohjelmistokehitys tarkoittaa käytännössä arvontuoton maksimointia ja riskien minimoimista jakamalla kehitys lyhyempiin toistuviin työvaiheisiin eli iteraatioihin tai sprintteihin. Ohjelmistosuunnittelu, koodaus ja testaus etenevät näissä iteraatioissa, joista jokainen tuottaa uuden, toimivan version, jota kutsutaan inkrementiksi. Näin tilaajalla on mahdollisuus päästä aina halutessaan testaamaan viimeisintä inkrementtiä ja antamaan palautetta kehitystiimille jatkokehitystä ajatellen. Näin prosessi pysyy hallittuna ja suunta oikeana.
Tavoitteena ohjelmistoprojektissa on tietysti toimiva ohjelmisto, hyvä viestintä ja nopea muutoksiin reagointi.
Ketteriä menetelmiä on useita, muun muassa Extreme Programming (XP), Scrum, DSDM, Crystal Methods, Agile modeling, Adaptive software development, Pragmatic Programming, Feature driven development ja Gilb-EVO. On siis mistä valita. Näistä erityisesti Scrum on jo muodostunut alan käytetyimmäksi viitekehykseksi.
Ketterä viitekehys ei kuitenkaan automaattisesti johda ketteryyteen, sillä yritys voi toimia ketterästi ilman tiettyjä menetelmiä, onhan ketteryys ennen muuta ajattelutapa. Toisaalta tiettyyn viitekehykseen tai tiettyihin menetelmiin siirtyminen ei automaattisesti merkitse sitä, että yritys tai yrityskulttuuri muuttuisi ketteräksi.
Usein ketterien menetelmien käyttöönotto merkitseekin organisaatiossa ajattelutavan muutosta, mikä ei tietysti tapahdu nappia painamalla vaan kyseessä on prosessi, joka johtaa uudenlaiseen organisaatiokulttuuriin. Samalla on siirrytty pehmeiden menetelmien puolelle – ajattelutavan ja ihmisten johtamisen muutokseen. Tällöin muutoksen pitää lähteä yrityksen tai organisaation johdosta.
Usein ongelmana on, että ohjelmistokehityksen tilaaja ei itsekään tiedä, mitä tilaa tai ei ymmärrä, mitä kaikkea projektiin kuuluu. Tällöin toimittajan pitää vanhaa prosessia tai järjestelmää tarkkailemalla ensin löytää prosessin tärkeimmät kipukohdat, jotka pitää ratkaista, ja näin tarjota tilaajalle oivalluksia kehitysprojektin tavoitteista, jotka voivat sisältää myös toiminnan kehittämistä.
Isoissa hankkeissa ketterät menetelmät voivat johtaa hajanaiseen kokonaisuuteen, kun kehitys tapahtuu osissa, jollei kukaan ei katso ratkaisun yhtenäisyyden ja saumattoman toimintalogiikan perään.
Yksi selkeä trendi ohjelmistokehityksessä on Full Stack -kehittäminen, mikä tarkoittaa sitä, että kehittäjätiimin tulee osata rakentaa kaikkiin arkkitehtuurin eri kerroksiin, ja siten saada aikaan toimiva järjestelmä, toimiva kokonaisuus. Full Stack Developer -tiimi osaa siis tehdä koko paletin. Tiimi osaa rakentaa koodia kaikkiin kerroksiin eli ohjelmoida serverillä pyörivät ratkaisut, suunnitella ja toteuttaa käyttöliittymän, rajapinnat, tietoliikenne jne, ja ymmärtää vieläpä yrityksen toimintaa ja bisneslogiikkaa. Ei siis riitä, että saadaan joku järjestelmän lisäosa toimimaan vaan kokonaisuuden pitää toimia saumattomasti yhteen.
Tuskin keneltäkään on jäänyt huomaamatta, että teknologinen kehitys on nykyään niin nopeaa, että kehityksessä on monesti vaikea pysyä mukana. Ohjelmistokehittäjien kannattaakin muistaa menetelmiä ja teknologioita valitessaan, että paras ja toimivin valinta riippuu aina tilanteesta sekä yrityksen tai organisaation tarpeesta. Ammattilaisen työkalupakissa pitää olla niin paljon tavaraa, että hän voi valita parhaat työkalut, ja opetella käyttämään niitä tarpeen mukaan.
Teknologiateollisuusalan yrityksille suunnatussa osaamispulssissa ohjelmistokehityksen osaamista piti tärkeänä 97 prosenttia tietotekniikan toimialan vastaajista, ja 77 prosenttia yrityksistä osaaminen on ensiarvoisen tärkeää tulevien vuosien liiketoiminnalle. Muilla toimialoilla ohjelmistokehitystä tarkasteltiin laajemman ohjelmisto-osaamisen otsikon alla.
Osaamispulssi antaa yrityksille hyvät suuntaviivat siihen, minkälaista osaamista tulevaisuudessa tarvitaan. Tämän pohjalta jatkuvan oppimisen tukeminen myös helpottuu.
Tutustu osaamispulssiin osoitteessa https://osaamispulssi.fi/.
Koulutusta ketteryyteen
- Ketterä määrittely
- Tiiminvetäjän ketterä johtajuus
- Fiksumpaa työskentelyä ketteryydellä
- Ketterä projekti – agile projektijohtaminen
- Scrum perusteet
- Product owner I (PO I)
- Scrum Master I (SM I)
- Kaikki ketteryyskoulutukset
Anssi Rusanen
Seniorikonsultti
Anssilla on pitkä kokemus ketteristä menetelmistä, transformaatioista niihin sekä tiimien ja liiketoiminnan kehittämisestä. Anssi toimii Tieturilla seniorikonsulttina. Hän on sertifioitu SAFe Program Consultant (SPC). Anssi on toiminut monenlaisissa rooleissa ketterissä sekä sellaisiksi siirtyvissä organisaatioissa, erityisesti haluten auttaa ihmisiä ja heidän toimintaansa kaaoksen keskellä.
