Ketterä ohjelmistokehitys

Diplomityö aiheeni on mallipohjaisen testauksen soveltaminen ketterään ohjelmistokehitykseen, joten käynpä hieman läpi mitä tarkoittaa ketterä ohjelmistokehitys?

Perinteisessä ohjelmiston kehityksessä pyritään ensin määrittelemään mahdollisimman tarkasti mitä tullaan tekemään. Sitten pilkkua viilaten tehdään ohjelma, ja jokainen muutos alkuperäiseen maksaa tilaajalle hunajaa ja on tekijälle kettumainen toteuttaa. Perinteinen malli toimii hyvin joissain tapauksissa, esim tukiasemat joissa on selvät vaatimukset olemassa. Käytäntö on kuitenkin osoittanut että muutoksia tulee aina. Yleensä asiakas ei kuitenkaan ole täysin varma millainen lopputulos pitäisi olla ja hänen näkemyksensä kypsyy sitä mukaa kun hieman näkee mitä on tulossa. Hyvin monessa tapauksessa on järkevää käyttää muutoksiin paremmin taipuvaa ketterää mallia. Ketteränohjelmistokehityksen manifestin tiivistetyt periaatteet ovat:

Yksilöitä ja vuorovaikutusta enemmän kuin prosesseja ja työkaluja

Toimivaa sovellusta enemmän kuin kokonaisvaltaista dokumentaatiota

Yhteistyötä asiakkaan kanssa enemmän kuin sopimusneuvotteluita

Muutokseen reagoimista enemmän kuin suunnitelman noudattamista

“Vaikka oikeanpuoleisillakin kohdilla on arvoa, me arvostamme
vasemmanpuoleisia enemmän.” lähde

Ketterän kehityksen myötä ei heitetä roskiin kaikkia dokumentteja ja suunnitelmia, vaan ketterässä mietitään aina että mikä on todella tarpeen. Jos asiakas haluaa tarkan suunnitelman, niin se tehdään mutta muutoin tehdään niin hyvä kuin kehittäjille on tarpeen. Ketterä kehitys on iteratiivista eli ei tehdä kaikkea valmiiksi kertarykäisyllä vaan yksi ominaisuus kerrallaan. Ominaisuus jaetaan vielä pienempiin osatehtäviin joiden suunittelu helpottaa tekijöiden työtä selvillä suuntaviivoilla ja työmäärän arviointia, koska pienemmät palaset on helpompi arvioida. Tässä pääpiirteittäin Mobile-D menetelmä, joka on kehitelty VTT:llä Oulussa:

1. Suunittelupäivä: (kesto 1-2 päivää) Jaetaan ohjelma ominaisuuksiin, ja ominaisuudet taskeihin. Suunnitellaan riittävällä tasolla mitä kukin tekee miten ja mitkä ovat rajapinnat, jos järjestelmä hajautetaan. Jos tätä edeltää jo iteraatioita niin analysoidaan että miten ne meni, ja mitä pitäisi kehittää niin prosessissa kuin ohjelmassakin. Eli prosessia voidaan muuttaa eri iteraation vaiheissa esim jättää joitain kokouksia pois tai lisätä.

2. Tekopäivä: (kesto pari viikkoa) Tällöin tehdään itse ohjelmaa, eli koodataan. Tässä on tärkeää huomata, että tekemisen aikana ominaisuudet on jäädytetty ja niitä ei lisäillä tai poistella jos se muuttaa ohjelmaa liikaa. Eli pilkun paikkoja voi muuttaa, mutta jos ohjelmointikieli tai muu iso asia muuttuu niin iteraatio kannattaa puhaltaa poikki.

3. Esittelypäivä: (kesto pari päivää) Tämän päivän ajankohta sovitaan etukäteen eikä sitä siirretä mistään syystä. jos jotain ei saada valmiiksi niin sitten se siirtyy seuraavalla kierokselle. Tässä käydään ensin kehitystiimin sisällä läpi mitä on tehty, ja onhan kaikki tehty suunnitelman mukaan. Sitten kun tarkistukset on tehty niin demo esitellään asiakkaalle. On myös mahdollista tehdä ns. sisäisiä iteraatioita jolloin asiakas ei saavu paikalle. Lopuksi todetaan että onko kaikki ominaisuudet tehty, ja jos ei niin siirrytään seuraavaan iteraatioon ja aloitetaan taas päivästä 1. suunittelupäivä.

Tässä on erittän hyvä paperi ketteristä ohjelmistokehitysmalleista. Tähän voisi kirjoitella vielä hieman lisää, joten taidan jossain välissä tehdä tänne blogiin oman sivun ketteristä ohjelmistojen kehitysmalleista.