mikä ihmeen ketterä ohjelmistokehitys

Mikä ihmeen ketterä ohjelmistokehitys?

Ohjelmistokehitystä voidaan tehdä monilla eri tavoilla. Perinteinen tapa tehdä ohjelmistokehitystä on projektin alussa tehtävä tarkka suunnitelma, jossa pyritään ottamaan huomioon kaikki mahdolliset näkökulmat. Tämän jälkeen koodarit hyppäävät projektin sisälle ja lopussa esitellään valmis ohjelmisto, sellaisena kuin se on aloittaessa ymmärretty. Tämä tapa sopii joihinkin projekteihin.

Meidän tapamme on kuitenkin toteuttaa ohjelmistoja ketterän ohjelmistokehityksen mallilla. Projektin alussa käydään samalla tavalla asiakkaan kanssa tarkka keskustelu ja määrittely, mitä valmiin ohjelmiston tulee tehdä ja ratkaista. Samalla määritellään kokonaisuuden työmäärällinen suuruus sekä kerätään kaikki mahdolliset toiminallisuudet ja ominaisuudet, joita ohjelmistoon halutaan.

Kokonaisuuden palasteleminen pienempiin osiin

Määrittelyn jälkeen kokonaisuus palastellaan pienempiin osiin, spritteihin. Yksi sprintti on yhden koodarin yhden viikon työmäärä (37,5h). Tyypillisesti ohjelmiston rakenteen ja perustan tekemiseen menee 1-5 sprinttiä, jonka jälkeen varsinaisia toiminnallisuuksia päästään toteuttamaan. Keräämme kaikki alussa esille nousseet toiminnallisuudet laajaksi listaksi (backlog), joista valitaan ja priorisoidaan ne toiminnallisuudet, mitkä ainakin halutaan saada valmiiksi projektin ensimmäisessä vaiheessa.

Miten hahmottaa lopputulosta?

Tyypillisesti aloitamme projektin tekemällä vaatimusmäärittelyn ja visuaalisen prototyypin. Varsinkin prototyypin avulla sekä asiakkaalla että tekijöillä on yhteinen käsitys millainen lopputulos olisi syntymässä. Usein tässä kohtaa vielä tarkennetaan tai muutetaan joitain toiminnallisuuksia tai ilmettä.

Koodaamisen aloittaminen

Nyt kun yhteinen näkemys lopputuloksesta on syntynyt, voidaan aloittaa itse koodaaminen. Ensin tosiaan toteutetaan ohjelmiston perusta. Tämä siis osa-alue, joka ei meidän normaalien ihmisten silmään näytä vielä miltään. Sitten päästäänkin toteuttamaan ohjelmiston toiminnallisuuksia, sprintti kerrallaan. Jokaisen sprintin aikana toteutetaan jokin sovituista toiminnallisuuksista ja käydään viikon päätteeksi se asiakkaan kanssa läpi. Näin asiakas näkee pitkin matkaa ohjelmiston valmistumisen ja pääsee vaikuttamaan lopputulokseen.

Mitä se ketteryys tässä tarkoittaa?

Varsin usein asiakkaan tarve ehtii muuttumaan tai tarkentumaan projektin aikana. Ketterä kehitysmalli mahdollistaa sen, että eri toiminnallisuuksien toteutusjärjestystä voidaan vaihtaa matkan varrella. Se mikä tuntui alussa vähäpätöiseltä voikin nousta aivan kriittiseksi ominaisuudeksi projektin edetessä. Tällaisessa tapauksessa kyseinen ominaisuus otetaankin työstöön heti seuraavalla viikolla eli seuraavassa sprintissä.

Mihin tällainen kehitystapa sopii?

Asiakkaiden tarpeet, muiden kehitettävään ohjelmistoon linkittyvät palvelut ja toisaalta käytönnön kokemukset muuttuvat hirveää vauhtia. Näinollen ketterällä ohjelmistokehityksellä toteutettavat palvelut ovat aivan loistava tapa saattaa melkein mikä tahansa nykypäivän ohjelmisto maaliin. Se antaa sekä asiakkaalle että tekijöille mahdollisuuden tuoda ideoita jatkuvasti esille ja tehdä muutoksia joustavasti projektin edetessä. Toisaalta se että tällä mallilla tähdätään aina jokaisen sprintin jälkeen toimivaan ohjelmistoon on suurimmalle osalle asiakkaista ensiarvoisen tärkeä asia hahmottamaan miten toiminta kanssamme etenee ja miten ohjelmisto valmistuu.

Valmis ohjelmisto

Projektin valmistuessa asiakkaalla on käytössään juuri ne toiminnallisuudet, jotka hän on itse kehityksen aikana valinnut. Toisaalta työlistalle (backlog) jää niitä kehitysideoita, joita voidaan toteuttaa esimerkiksi ohjelmiston seuraavaan versioon. Toivoisin kovasti, että jokainen joka lähtee hankkimaan ohjelmistoa, onpa kyseessä verkkosivut tai mobiili applikaatio tai jokin muu toteutus, osaisi jo alkuvaiheessa ajatella toteutusta jatkuvasti kehittyvänä. Ohjelmisto ei koskaan ole valmis. Aina löytyy kohtia, joita voidaan parantaa, ominaisuuksia joita voidaan lisätä ja toisaalta laitteet joilla ohjelmia käytetään kehittyvät, jolloin itse ohjelmaakin pitää muokata toimimaan näillä uusilla vaatimuksilla.

Loppuun vinkki tai pari

Älkää koittako saada kaikkea ympättyä ensimmäiseen julkaistavaan versioon. Ohjelmiston aikaisempi käyttöön ottaminen antaa myös mahdollisuuden kerätä palautetta käyttäjiltä ja muuttaa toiminnallisuuksien priorisointia. Toinen asia, jonka toivoisin jäävän mieleesi olisi se, että ohjelmistolle kannattaa budjetoida rahaa jatkokehitykselle tulevien vuosien aikana.  Muuten tulee aina yllätyksenä, että ohjelmistoa pitääkin muokata matkan varrella, kun tarpeet elävät. Turhan usein kuulee, että palvelu oli hyvä, muttei vastaa enää muuttunutta tarvetta. Näin ei tarvitsisi olla.