Diplomityö aiheeni on mallipohjaisen testauksen soveltaminen ketterään ohjelmistokehitykseen, joten käynpä hieman läpi mitä tarkoittaa ketterä ohjelmistokehitys?
Heti ohjelmistotuotannon alku metreiltä lähtien huomattiin asioiden menevän mönkään. Projektit oli myöhässä, niihin meni liikaa rahaa ja laatu oli huonoa. Sitten huomattiin että kun tehdään kaiken kattava toimintamalli niin asiat saadaan kuntoon. Ohjelmoija tietää missä järjestyksessä edetä ja mitä dokumentteja tuottaa. Kaiken kattava toimintamallista tuli kuitenkin niin työläs että aikaa meni enemmän sen noudattamiseen kuin itse työntekoon. Joskus pari insinööriä tuskastui turhan työn tekemiseen ja sai idean kehittää toimintaa ohjaavan kehyksen jossa kaikki turha on jätetty pois, ja näin syntyi ketterät ohjelmistokehitys mallit.
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 iteraatio kerrallaan. Iteraatioon valitaan riittävästi taskeja, joita tehdään iteraation aikana niin paljon kuin keretään. Jos ei keretä niin ne siirtyy seuraavaan kertaan. Taskien vaatima työmäärä arvioidaan ja sitä myöten opitaan arvioimaan kuinka kauan koko projektin työ vielä kestää.
Vastuu jakautuu ketterissä projekteissa koko ryhmälle. Eli jos homma ei toimi niin se ei ole projektin johtajan vika vaan koko ryhmän.
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ä.
Ryhmän sisäiset roolit ovat Mobile-D:ssä vähän samantapaisia kuin perinteisessä ohjelmistokehityksessä sillä erotuksella että tässä ne ovat vain vastuita. Toisin sanoen projektin vetäjän vastuulla on että projekti tulee ohjattua, mutta sen ei tarvitse itse tehdä kaikkea siihen liittyvää. Testaaja varmistaa että tarvittavat testit tulee tehtyä, mutta hänen ei ole välttämätöntä itse testata. Osaltaan tämän idea on laaja-alaistaa ihmisten osaamista, ja saada sitä kautta kaikki pelaamaan paremmin. Jos työmies tietää miten seuraava homma tehdään, niin hän osaa tehdä oman työnsä niin että se helpottaa seuraavaa työvaihetta.
Tässä on erittän hyvä paperi ketteristä ohjelmistokehitysmalleista.
