Kehityssykli ohjelmistokehityksessä

Kehityssykli ohjelmistokehityksessä TURUN YLIOPISTO Informaatioteknologian laitos TkK-tutkielma 21.10.2008 Jussi Timonen

TURUN YLIOPISTO Informaatioteknologian laitos TIMONEN, JUSSI: Kehityssykli ohjelmistokehityksessä TkK-tutkielma, 29 s. Ohjelmistotekniikka Lokakuu 2008 Ohjelmistokehitys on ala, johon kohdistuu jatkuvasti yhä enemmän paineita maailman tullessa entistä riippuvaisemmaksi erilaisesta tietotekniikasta. Ala on suhteellisen nuori mutta nopeasti kasvava. Ohjelmistojen suurentunut koko ja alati muuttuvat vaatimukset ovat johtaneet tilanteeseen, jossa on tarvetta kehittää uusia tapoja ja tekniikoita, jotka pystyvät vastaamaan nopeasti muuttuvaan tilanteeseen ja pitämään paisuvan ohjelmiston kehittäjiensä hallinnassa. Tämä tutkielma käsittelee pääasiassa ketterien kehitysmenetelmien toimintaa nykypäivän ohjelmistokehityksessä perinteisiä malleja unohtamatta. Tutkielmassa on mukana näkökulma työelämässä toteutetusta Scrum-menetelmän sovelluksesta. Lopussa tutkitaan myös metriikan ja testauksen osuutta kehitystyössä ja niiden eroja perinteisiin ja ketteriin menetelmiin. Asiasanat: ketterät menetelmät, Scrum, extreme Programming, ohjelmistokehitysmallit

Sisällys 1 Johdanto 2 2 Perinteiset mallit 3 2.1 Vesiputousmalli 3 2.2 Spiraalimalli 3 2.3 Inkrementaalinen 5 3 Ketterät kehitysmenetelmät 6 3.1 Ketterien kehitysmenetelmien historia 6 3.2 extreme Programming 7 3.3 Scrum 11 4 Testaus osana ketterää ohjelmistokehitystä 15 4.1 Testaus perinteisissä malleissa 15 4.2 Testaus ketterissä malleissa 15 5 Metriikka ohjelmistoprosessissa 17 5.1 Metriikka perinteisissä malleissa 17 5.2 Metriikka ketterissä malleissa 18 6 Suuren mittaluokan kehitysprojektit 19 6.1 Component Team 19 6.2 Feature Team 20 7 Kehitysmalli yrityksessä 23 7.1 Nykyinen malli 23 7.2 Mallin haasteet 25 7.3 Parannusmahdollisuuksia 26 Lähteet 28 Liitteet 29 Liite 1: Agile manifesto 29

2 1 Johdanto Ohjelmistoala on historiansa aikana kokenut monia mullistuksia. Ohjelmistojen kompleksisuus, koko ja vaatimukset ovat kasvaneet jatkuvasti. Kehitettäviltä sovelluksilta vaaditaan entistä parempaa laatua ja nopeampaa toimintaa. Näitä kasvavia vaatimuksia vastaamaan on kehitetty erilaisia ohjelmistokehitysmalleja, joilla pyritään selkeyttämään kehitystä, jakamaan työmäärää ja arvioimaan paremmin ohjelmiston valmistumisastetta. Työn tarkoitus on antaa lukijalle kuva perinteisten ohjelmistokehitysmallien ja ketterien menetelmien keskeisimmät eroista ja eduista. Perinteisistä malleista esitellään vesiputousmalli, spiraalimalli ja inkrementaalinen malli. Ketteristä menetelmistä tarkemmin tutkitaan extreme Programming- ja Scrum-malleja. Työhön on otettu mukaan näkökulma työelämästä ja todellisesta ohjelmistokehityksestä. Tässä osassa työ painottuu Scrum- menetelmien ja -työtapojen tuntemiseen, koska tutkimassani työympäristössä käytettiin juuri Scrum-menetelmää. Pelkän ohjelmistokehitysprosessin lisäksi työhön on sisällytetty osiot eri mallien testauksesta sekä luku metriikan merkityksestä ohjelmistoprosessissa.

3 2 Perinteiset mallit Ohjelmistokehitysmallit otettiin alun perin käyttöön selkeyttämään kaaoksen valtaamaa ohjelmistokehitysalaa. Mallit ovat tuoneet rakenteen ja suunnittelun ohjelmistokehityksen maailmaan, mutta ala on silti kaaoksen partaalla. (McGraw Hill 2005.) 2.1 Vesiputousmalli Vesiputousmalli (engl. Waterfall model) on yksi tunnetuimpia ja käytetyimipiä vaihejakomalleja. Se perustuu vesiputousmaiseen rakennelmaan, jossa jokaisessa vaiheessa suoritetaan tietty ohjelmistokehityksen osa. Edellisen osan tuloksen on tarkoitus toimia syötteenä seuraavalle osalle ja siten ohjata projektia eteenpäin. Mallin heikkoutena voidaan pitää sen tapaa kiinnittää vaiheet tiukasti. Tästä syystä tuotteen kehitys ei näy prosessin aikana asiakkaalle ja vaatimusten osuus suunnittelussa on erityisen korostunut. (Karttunen 2000, Sommerville 2004.) Alkuperäisen mallin kehittäjä Winston Royce sisällytti malliinsa myös palautekierroksen, jonka avulla kehityksen eri vaiheet saisivat palautetta toisiltaan(kuva 1). Enemmistö mallin käyttäjistä ei ole ottanut tätä kierrosta käyttöön, mistä syystä malli muuttuu lineaariseksi. (McGraw Hill 2005.) Malli jaetaan lähteestä riippuen hieman eri tavoin, mutta jokaisesta mallista voidaan löytää määrittely-, suunnittelu- ja toteutusvaiheet. (Karttunen 2000.) Kuva 1. Vesiputousmalli (Haikala& Merijärvi 2000). 2.1 Spiraalimalli Spiraalimalli eroaa vesiputousmallista siten, että siinä kehitystyö käydään läpi sykleissä, joissa jokaisessa kehitetään ohjelmistoa vastaamaan paremmin sille annettuja vaatimuksia. Spiraalin ideana on täydentää jokaisessa syklissä edellisen syklin vastaavia osia(kuva 2).

4 Spiraalimalli jakautuu neljään pääosaan: 1. Tavoiteanalyysi Määritetään tarkat tavoitteet seuraavalle syklille. Luodaan suunnitelma syklin toteuttamiseksi ja tunnistetaan riskit. 2. Riskianalyysi Analysoidaan jokainen tunnettu riski ja pyritään minimoimaan riskin vaikutus. 3. Toteutus ja testaus Kun riskit on todettu, valitaan toteutustapa. Tämä voi olla esimerkiksi vesiputous- tai evolutionäärinen malli. Tässä yhteydessä suoritetaan myös testaus. 4. Suunnittelu Tehdään päätös jatkamisesta seuraavaan kierrokseen. Tästä edetään taas vaiheeseen 1. (Sommerwille 2004.) Kuva 2. Spiraalimalli (Sommerwille 2004).

5 2.3 Inkrementaalinen malli Monissa ohjelmistonkehitysprosesseissa vaatimukset ovat tarkasti tiedossa, mutta prosessi tuottaa kuitenkin lineaarisen kehityssyklin. Tälläiselle prosessille voi tulla tarve tuottaa osia toiminnallisuudesta toisia nopeammin. Tätä toiminnallisuutta, joka tuotetaan prosessin osana, kutsutaan inkrementiksi. (Pressman 2005.) Inkrementaalisen kehityksen voi ajatella koostuvan lyhyistä vesiputousmallin sykleistä, joita iteroidaan toinen toisensa jälkeen. Jokainen iteraatio tuottaa inkrementin ja edistää siten ohjelmiston kehitystä. Tällä tavoin voidaan luoda eritasoisia ominaisuuksia, ja jo luotuja ominaisuuksia voidaan myös tarkentaa antamalla lisää toiminnallisuutta seuraavassa iteraatiossa. (Pressman 2005.) Usein ensimmäisen iteraation tuote on ydintuote. Se toteuttaa perusvaatimukset, mutta suurin osa toiminnallisuudesta on vielä toteuttamatta. Ydintuote toimitetaan usein asiakkaalle perusteellista arviointia varten. Näin saavutetaan se, että asiakas ja toteuttaja ymmärtävät toisiaan. Arvioinnin tuloksilla muokataan seuraavia iteraatiotita vastaamaan lopullisen tuotteen vaatimuksia. Täten tuote kehittyy koko sen elinkaaren ajan.

6 3 Ketterät kehitysmenetelmät 3.1 Ketterien kehitysmenetelmien historia Ketterien kehitysmenetelmien virallisena syntymäpaikkana voidaan pitää mökkiä Snowbirdin hiihtokeskuksessa Utahissa. Tähän mökkin kerääntyi helmikuun puolessa välissä vuonna 2001 seitsemäntoista ohjelmistoalan ammattilaista pohtimaan alan tulevaisuutta ja rentoutumaan. Kolmipäiväisen tapaamisen tuloksena syntyi Agile software development manifesto, joka esitetään kokonaisuudessaan liitteessä 1. (Agile manifesto 2001; Liite 1.) Manifestin sisältö on seuraava (Martin 20003): Yksilöitä ja interaktioita enemmän kuin prosesseja ja työkaluja Toimivaa sovellusta enemmän kuin kokonaisvaltaista dokumentaatiota Asiakasyhteistyötä enemmän kuin sopimusneuvotteluita Muutokseen reagoimista enemmän kuin suunnitelman noudattamista. Manifestin yhteydessä luotiin vielä 12 periaatetta, jotka erottavat ketterät menetelmät raskaista prosesseista (Martin 2003): 1. Korkein prioriteetti on täyttää asiakkaan vaatimukset aikaisilla ja jatkuvilla toimituksilla sekä arvokkaalla ohjelmistolla. 2. Hyväksytään muuttuvat vaatimukset myös myöhäisessä kehitysvaiheessa. Muutetaan muutokset asiakkaan kilpailukyvyksi. 3. Toimitetaan toimivia ohjelmistoja säännöllisesti, muutaman viikon tai kuukauden välein. Mieluummin usein kuin harvoin. 4. Liiketoiminnan ammattilaisten ja kehittäjien tulee tehdä töitä yhdessä päivittäin koko projektin ajan. 5. Projektin luovat siitä motivoituneet henkilöt. 6. Tehokkain tapa tiedon kuljettamiseksi tiimissä on kasvokkain tapahtuva kommunikaatio. 7. Toimiva ohjelmisto on tärkein edistyksen mittari. 8. Ketterät kehitysmenetelmät edistävät kestävää kehitystä. Rahoittajien, kehittäjien ja käyttäjien pitäisi pystyä säilyttämään tasainen tahti jatkuvasti. 9. Jatkuva huomio tekniseen erinomaisuuteen ja hyvään suunnitteluun lisää ketteryyttä. 10. Yksinkertaisuus tekemättömän työn maksimointi on olennaista.

7 11. Parhaat arkkitehtuurit, vaatimukset ja suunnitelmat ilmestyvät itseorganisoituneista tiimeistä. 12. Tiimi arvioi tasaisin väliajoin, miten se voisi tulla tehokkaammaksi ja kehittää siten toimintaansa tehokkaammaksi. 3.1 Extreme programming XP on tunnettu ketterä kehitysmenetelmä, jonka luoja on Kent Beck. XP on kevyt menetelmä, joka sopii pienistä keskikokoisille ohjelmistonkehitystiimeille. Muodollisuutensa puolesta XP asettuu informaaliin ryhmittymään. Sen käytössä ei normaalisti juurikaan suoriteta dokumentointia. Toiminnan runko hahmotellaan tarinakorteille (engl. Story Card). Kuten muutkin ketterät kehitysmenetelmät XP keskittyy asiakkaaseen, muuttuviin vaatimuksiin ja laatuun. (Larman 2004). Sana extreme tulee Beckin uskomuksesta, että ohjelmistokehityksessä ei voi olla liikaa hyviä asioita. Tällä Beck tarkoittaa hyviksi todettujen tapojen viemistä jokapäiväiseen ohjelmointiin äärimmäisellä tasolla (engl. extreme, suom. äärimmäinen). Tämä tarkoittaa esimerkiksi seuraavaa (Larman 2004): Testaus on hyvää, joten kirjoitetaan yksikkötestit (mahdollisuuksien mukaan) koko koodille ja hyväksymistestit koko toiminnallisuudelle. Koodinkatselmointi on hyvää, joten tehdään sitä koko ajan ja käytetään myös pariohjelmointia. XP:n arvot ja käytännöt on esitetty kuvassa 3. Kuva 3. Extreme programmingin käytännöt ja arvot (Larman 2004).

8 XP:n erikoisuus ilmenee siinä, että se ei vaadi muuta valmista tuotosta kuin itse koodin ja testit. Vaikka XP:tä käytettäessä pyritään tekemään vain koodi ja testit, voidaan menetelmässä tarvittaessa ottaa käyttöön XP:tä raskaammissa menetelmissä noudatettuja käytäntöjä. Vaikka kaikki evolutionaariset kehitysmenetelmät välttävät spesifikaatioiden kirjaamista, suurin osa kuitenkin rohkaisee kirjoittamaan ylös yksityiskohtia seuraavasta iteraatiosta. XP:n lähestymistapa on korostaa suullista kanssakäymistä vaatimusten ja suunnitelmien määrittämisessä. Ainoa kirjoitettu dokumentti ovat tarinakortit, joille on kirjattu hyvin suurpiirteisiä asioita. Järjestelmä muodostuu tehokkaaksi, kun asiakas on samassa tilassa ja tarinakorttien avulla keskustellaan tuotettavasta koodista. XP:n lähestymistapaa kehitykseen voidaan kuvata Craig Larmanin esittämällä kysymyksellä (Larman 2004): Is there a sane and disciplined way to quickly succeed on typical small projects by focusing on code and tests, while avoiding most other documentation? (Onko olemassa järkevää ja kurinalaista tapaa onnistua nopeasti tyypillisissä pienissä projekteissa keskittymällä koodiin ja testeihin ja samalla minimoimalla muu dokumentaatio? Suom. Jussi Timonen.) XP:n lähtökohta ei ole hakkerimainen koodaa-ja-korjaa-ohjelmointi, vaan se tähtää uuteen rakenteelliseen ja kestävään tapaan onnistua huomioiden samalla ketterien kehitysmenetelmien periaatteet. XP on hyvin kurinalainen ja samalla ketterä ohjelmistonkehitysmenetelmä (Larman 2004). Kuva 4. XP-projektin vaiheet (Ambler 2002).

9 XP-projektin vaiheet ovat seuraavat (Amber 2002, kuva 4): Tutkimusvaiheen tärkeänä tuloksena ovat tarinakortit. Tätä vaihetta voidaan pitää valmiina, kun asiakas on sitä mieltä, että tarinakorteilla on enemmän kuin tarpeeksi materiaalia ensimmäistä versiota varten, ja ohjelmoijat ovat sitä mieltä, että järjestelmää ei voi arvioida paremmin kuin implementoimalla se. Tässä vaiheessa ohjelmoijat käyttävät kaikkia eri tekniikoita, joita he aikovat käyttää varsinaisessa ohjelmassa. Parin viikon jälkeen valmistuu kolmesta neljään eri versiota mahdollisesta arkkitehtuurista ja tekniikoista, joita ohjelmoijat voivat arvioida keskenään löytääkseen parhaan mahdollisen vaihtoehdon. Vaiheeseen kannattaa myös sisällyttää simulointi, jossa testataan valmiin järjestelmän rajoja ratkaisumallit huomioon ottaen. Samaan aikaan kun ohjelmoijat suunnittelevat toteutusta, asiakas harjoittelee kirjoittamaan tarinoita eli kuvauksia ohjelman toiminnasta. Tämä on yleensä ensin vaikeaa, koska asiakas ei kirjoita sitä, mitä ohjelmoijat tarvitsevat. Alussa on tärkeää antaa nopeaa palautetta, jotta asiakas löytää oikean näkökulman kirjoittaessaan. Suunnitteluvaiheen tarkoituksena on löytää yhteisymmärrys ensimmäisen ja tärkeimmän ohjelmistoversion valmistumisajankohdalle asiakkaan ja ohjelmoijien kesken. Yleensä ensimmäiseen versioon menee aikaa kahdesta kuuteen kuukautta. Iteraatiot ensimmäiseen versioon tapahtuvat jakamalla aikataulu yhdestä neljän viikon pituisiin iteraatioihin. Jokainen iteraatio tuottaa toimivat testisetit jokaiselle tarinalle, joka on kyseisessä iteraatiossa. Ensimmäinen iteraatio luo arkkitehtuurin ohjelmistolle, ja seuraavassa tulisi valita tarinat, jotka pakottavat luomaan koko järjestelmän. Seuraavissa iteraatioissa oikeat tarinat löydetään tutkimalla kysymystä: Mikä on arvokkain asia tässä iteraatiossa? Jokaisen iteraation aikana etsitään ongelmia tutkimalla aikataulua ja suunnitelmia. Kun havaitaan ongelma, siihen tulee puuttua heti joko muuttamalla tai lisäämällä tarinakortteja. Kuva 5. Iteraation elinkaari (Ambler, 2002).

10 Elinkaaren vaiheet ovat seuraavat (Beck 2002; kuva 5): Tuotteistamisvaiheessa iteraation pituus muuttuu kolmesta viikosta noin viikkoon. Tällöin pidetään päivittäisiä tapaamisia ryhmän kesken, jotta kaikki tietävät ohjelmiston tilanteen. Tässä vaiheessa suoritetaan sertifiointia ja rinnakkaista testausta. Tarkoituksena on varmistaa, että kehitettävä järjestelmä on valmis tuote. Koska projekti on jo pitkällä, ryhmällä on varsin paljon tietoa ohjelmiston rakenteesta ja toiminnasta. Tässä vaiheessa suoritetaan järjestelmän optimointi. Nyt myös hidastetaan tahtia, koska riskien arviointi tulee tärkeämmäksi valittaessa tarinoita iteraatioihin. Ylläpitoa voi sanoa XP-projektin normaaliksi tilaksi. Siinä tuotetaan samaan aikaan uutta toiminnallisuutta ja pidetään olemassa oleva systeemi toiminnassa. Muutoksissa ollaan nyt paljon varovaisempia kuin aikaisemmin, koska tuote on jo julkaistu. Ryhmän toiminta saattaa vaatia muutoksia, koska ulkopuolelta tulee tukipyyntöjä. Kun ryhmään liittyy uusi jäsen, hänen tulisi toimia ensimmäisten iteraatioiden ajan pariohjelmoinnissa ja lukea paljon testejä sekä koodia. Kun uusi jäsen tuntee olevansa valmis, hän voi aloittaa varsinaisen ohjelmiston tekemisen mutta kevyemmällä työmäärällä. Kuolema on luonnollinen vaihe ohjelmistokehityksessä siinä kuin ihmiselämässäkin. Kun asiakas ei keksi enää lisää uusia tarinoita, on aika viedä ohjelmisto varastoon. Tässä vaiheessa kirjoitetaan dokumentti, josta käy ilmi ohjelmiston rakenne ja käyttö. Kuolemaan johtavia syitä voi olla kaksi: asiakas on tyytyväinen ohjelmistoon, tai ohjelmisto ei vain toimi kuten haluttaisiin. Roolit ovat tarpeellisia niin normaalissa elämässä kuin työympäristössäkin. XP jakaa eri tekijöille omat roolit ja kehottaa myös tarkastelemaan roolien sopivuutta eri henkilöille. Roolit ovat Beckin (2000) mukaan seuraavat: Ohjelmoija on XP-projektin sydän. Ohjelmoijan toimenkuvaan kuuluvat itse ohjelmointi, testien tekeminen, refraktorointi eli jatkuva ohjelmiston rakenteen parantaminen, tehtävien arviointi ja tärkeänä osana myös kommunikointi. Tarkoituksena on kehittää mahdollisimman arvokasta ohjelmistoa ja samalla jättää turha työ pois. XP-ohjelmoijan työ on jokseenkin erilaista kuin normaali ohjelmistotyö. XP-ohjelmoija tarvitsee hyvät kommunikointi- ja yhteisökyvyt. Asiakas ja ohjelmoija hoitavat testaamisen, ja ohjelmoijan vastuulla on opastaa asiakasta tekemään järkeviä testejä ja ajaa niitä. Asiakas muodostaa ohjelmoijan kanssa XP:n ytimen. Ohjelmoija tietää, miten ohjelmoida, asiakas tietää, mitä ohjelmoida. Asiakkaan rooli XP-projektissa ei ole helppo. Asiakkaan vastuulla on suuri osa projektin menestyksestä. Asiakkaan tulee olla yhtä innokas oppimaan uutta kuin ohjelmoijan.

11 Tärkein tehtävä on kirjoittaa hyviä tarinoita ja tehdä päätöksiä, kun niitä tarvitaan, sekä suorittaa testausta. Seuraaja valvoo projektin etenemistä ja tekee arvioita työn onnistumisesta ja aikaisempien arvioiden paikkansapitävyydestä. Seuraaja valvoo uusien työtehtävien arviointia vertaamalla niitä aikaisempiin tuloksiin ja pyrkii siten saattamaan tiimin toiminnan mahdollisimman ajantasaiseksi. Seuraaja pitää yllä tilastoa tiimin toiminnasta ja seuraa kokonaisuutta. Valmentaja on vastuussa prosessista kokonaisuutena. Valmentaja huomaa, jos joku poikkeaa normaalista prosessista ja pyrkii hoitamaan asian kuntoon sekä toimii tarvittaessa tukena ja ohjaajana. Konsultti toimii projektissa ulkopuolisena tahona, joka tarjoaa erikoistietämystään, kun projekti sitä tarvitsee. Konsultin tehtävä ei ole varsinaisesti osallistua työntekoon vaan pikemminkin opettaa tarvittavia taitoja ryhmälle. Johtajan rooli on ryhmälle tärkeä. Johtajan tulee tarjota suunta ryhmälle ja myös huolehtia, että tavoitteista pidetään kiinni. Tärkeä tekijä johtajan roolin onnistumisessa on avoin kommunikaatio ja valmius paneutua ryhmän ongelmiin. Ryhmä luottaa siihen, että johtaja palauttaa sen tarvittaessa oikeaan suuntaan. 3.2 Scrum Scrum on ohjelmistonkehitysmenetelmä, joka korostaa itsenäistä vastuunjakoa ja ryhmän toimintaa ongelmanratkaisussa. Se keskittyy arvoihin ja tapoihin projektinhallinnassa eikä vaatimuksiin ja itse koodauksen käytäntöihin tai testaukseen. Tästä syystä Scrum on helposti yhdistettävissä muihin kehitysmetodeihin. (Larman 2004). Nimensä Scrum on saanut rugbyssä käytettävän aloitusryhmityksen mukaan (Wikipedia). Scrum-projektissa on vain kolme roolia. Nämä ovat tuotteen omistaja (engl. Product Owner), Scrum-ryhmä ja Scrum-mestari (engl. Scrum Master). Kaikki vastuu projektissa on jaettu näiden osapuolien kesken. Tuotteen omistaja on vastuussa siitä, että ulkopuoliset vaatimukset (aikataulut, raha, vaatimukset) välittyvät ryhmän tietoon. Hän myös priorisoi työtehtävät. Ryhmä on itseorganisoitunut itsenäinen yksikkö, joka huolehtii kaikista kehitysiteraatioon kuuluvista vastuista. Ryhmän tavoite on muuttaa iteraatioon valitut tehtävät toimivaksi inkrementiksi aikarajojen sisällä.

12 Scrum-mestari on vastuussa prosessista ja sen ylläpitämisestä sekä opettamisesta. Hänen tulee myös varmistaa, että käytetty Scrum sopii organisaatioon. Mestari ei ole erityisasemassa ryhmään nähden. Hänellä on tärkeä tehtävä toimia esteiden poistajana samalla, kun hän toimii ryhmän jäsenenä. Yksilöt, jotka toimivat näissä rooleissa, ovat asiasta kiinnostuneita ja sille omistautuneita. Monet ovat projekteista kiinnostuneita mutta eivät valmiita omistautumaan. Scrum tekee selvän eron näiden kahden ryhmän välille. (Schwaber 2003). Scrum-projektissa arvot ovat seuraavat (Schwaber 2003): Sitoutuminen Koko Scrum-ryhmä sitoutuu määriteltyyn tavoitteeseen iteraation ajaksi ja hoitaa sen kokonaan itsenäisesti. Johtoporras ja Scrum-mestari sitoutuvat olemaan sekaantumatta ryhmän asioihin iteraation aikana sekä tukemaan ja poistamaan esteitä ryhmän tieltä. Tuotteen omistaja sitoutuu määrittelemään ja priorisoimaan Product Backlogin eli eräänlaisen tehtävälistauksen ja ohjaamaan seuraavaan iteraatioon otettavia komponentteja. Keskittyminen Scrum-ryhmän tulee voida keskittyä iteraation eli sprintin tavoitteisiin ilman häiriöitä. Siksi johtoportaan tulee tarjota resursseja, poistaa esteitä ja välttää keskeyttämästä työtä ylimääräisillä pyynnöillä. Avoimuus Avoin Product Backlog tekee tiimin työn ja priorisoinnin näkyväksi. Päivittäisessä Scrum-tapaamisessa jaetaan oma työtilanne ja kerrataan yleinen tilanne. Työn sujuminen ja nopeus esitetään graafilla, joka on kaikille näkyvä. Rohkeus Johtoportaalla on oltava rohkeutta suunnitella ja ohjata ryhmää ja luottaa yksilöihin sekaantumatta iteraation sisäiseen toteutukseen. Ryhmällä on oltava rohkeutta ottaa vastuuta ja ohjata iteraation kulkua.

13 Kuva 6. Sprintin kulku (Schwaber2004). Scrum-projektin elinkaari koostuu neljästä vaiheesta: suunnittelu, järjestäminen, kehitys ja julkaisu (kuva 6). Scrum-tapaaminen on palaveri, joka pidetään päivittäin sprintin aikana. Tapaamisen tarkoitus on saattaa koko Scrum-ryhmä ajan tasalle. Tapaaminen pidetään joka kerta samassa paikassa ja samaan aikaan. Ryhmän jäsenet kootaan yhteen ympyrään ja jokaiselle esitetään seuraavat kysymykset: Mitä olet tehnyt viime tapaamisen jälkeen? Mitä aiot tehdä ensi tapaamiseen mennessä? Mitä esteitä on vaikeuttamassa tavoitteisiin pääsyä? Tapaaminen on yleensä lyhyt, noin 15 20 minuuttia, ja se antaa selvän kuvan projektin vaiheesta. Scrum-ryhmän ulkopuolisilla ei ole tapaamisessa oikeutta puhua, ja he seisovat ympyrän ulkopuolella. Päivittäinen Scrum-tapaaminen pidetään ryhmälle, muut ovat vapaaehtoisesti vain kuuntelemassa. Jos jostain aiheesta jää paljon puhuttavaa, pidetään uusi tapaaminen Scrumtapaamisen jälkeen. (Larman 2004.) Product Backlog on lista, johon on kirjattu kaikenlainen tekemätön työ. Sen ylläpitovastuu on tuotteen omistajalla, joka päivittää ja priorisoi listaa. Lista ei ole koskaan valmis, ja se elää projektin mukana mukautuen ja muuttuen uusien vaatimusten mukaan. Tämän listan pohjalta ryhmä valitsee tehtävät osat seuraavaan sprintiin. (Schwaber 2003.)

14 Scrumin kehitysiteraation tavoitteena on luoda mahdollisimman valmis tuote. Scrum-iteraatio syntyy valitsemalla aluksi Product backlogista ne osat, joihin ryhmä pystyy sitoutumaan. Tämä lista on Sprint Backlog. Sprint Backlogin tehtävät pilkotaan vielä pienemmiksi tehtäviksi, eli taskeiksi. Tuotteen omistaja määrittelee jokaiselle sprintille tavoitteen. Tämän jälkeen ryhmälle annetaan aikaa 1 4 viikkoa toteuttaa valitut taskit. Joka-aamuisessa tapaamisessa käydään läpi tilanne ja kirjataan se graafiin. Tässä vaiheessa voidaan pohtia, ollaanko tavoiteajassa vai ei. Sprintin aikana on mahdollista muokata tehtäviä ja tavoitteita edistymisen mukaan, mutta tämä tapahtuu vain ryhmän sisällä. Kun aika on loppu, ryhmä esittelee työnsä tulokset ja tuotteen omistaja vertaa niitä asetettuun tavoitteeseen. Menetelmän tehokkuus liittyy pitkälti ryhmän kykyyn arvioida osaamistaan ja työmääriä sekä omistautumiseen valittujen tavoitteiden toteuttamisesta. (Larman 2004, Schwaber 2003.) Kuva 7. Sprint backlog (Schwaber 2001). Sprintin etenemistä seurataab graafilla(kuva 7). X-akselilla on päivät, ja Y-akselilla näkyy, paljonko työtä on jäljellä. Työn yksikkö muodostuu erilaisista kertoimista ja arvioista työtehtävän vaativuudesta. Scrum-kehityksessä on kolme tärkeää palaveria. Sprintin sunnittelutapaaminen, sprintin tarkastustapaaminen ja retrospektive-palaveri eli kehityspalaveri. Suunnittelupalaverissa hajotetaan product backlogista valitut tehtävät pienemmiksi taskeiksi, joita kehittäjät alkavat tehdä. Tarkastuspalaverissä ryhmä esittelee luomansa tuotteen ja tuotteen omistaja tarkastaa sen sopivuuden Sprintin tavoitteseen nähden. Retrospektive-palaverin tarkoitus on oppia itse prosessista ja työtavoista. Scrum pyrkii olemaan oppiva järjestelmä ryhmän sisällä ja myös prosessissa.

15 4 Testaus osana ketterää ohjelmistokehitystä Testaus on tärkeä komponentti jokaisen ohjelmiston kehityksessä. Testauksella pyritään varmistamaan, että ohjelmisto vastaa sille annettua määrittelyä ja myös toimii tarpeeksi hyvin. Testauksella ei koskaan kyetä osoittamaan ohjelmiston virheettömyyttä tai suoraan parantamaan sen laatua vaan mittaamaan sen vallitsevaa tilaa. 4.1 Testaus perinteisissä malleissa Perinteisissä ohjelmistonkehitysmalleissa testaus on toteutettu yhtenä kokonaisena ja muista erillisenä vaiheena. Tällaisessa muodossa käydään läpi kaikki kehitysvaiheet, ja testausvaihe tuottaa uusia vaatimuksia ja virheitä. Löydetyt ongelmat otetaan huomioon seuraavassa syklissä ja pyritään korjaamaan. Virheiden löytäminen johtaa sitä kalliimpiin muutoksiin, mitä myöhemmin ne löydetään. (Kaner 1999.) 4.2 Testaus ketterissä malleissa Ketterien kehitysmenetelmien mukana on kehittynyt erilaisia tapoja luoda ohjelmistoja. Eräs näistä on Test Driven Development, jossa kirjoitetaan yksikkötestit kaikille luotaville metodeille ennen niiden varsinaista ohjelmointia. Näitä testejä ajamalla voidaan varmistaa ohjelman toimivuus, vaikka ohjelman sisälle tehtäisiinkin muutoksia. Testien tulee olla erillisiä ja automaattisia. On tärkeää, että testit ovat toisistaan riippumattomia. Tällöin ei jouduta tilanteeseen, jossa yhden testin epäonnistuminen johtaa satojen muiden testien epäonnistumiseen. On mahdotonta testata kaikkea, joten kannattaa keskittyä sellaisten komponenttien testaamiseen hyvin, jotka ovat herkkiä hajoamaan. Yksikkötestejä kirjoittavat ohjelmoijat. Kaikkien yksikkötestien tulisi mennä läpi, koska ne ovat sidottu suoraan ohjelmistoon. (Beck 2000.) Yleensä XP-ryhmässä tulisi olla ainakin yksi testaukseen erikoistunut jäsen. Hänen tehtävänään on auttaa asiakasta hyväksymistestien kirjoittamisessa ja tarinoiden luonnissa. Asiakkaan luomat hyväksymistestit eivät välttämättä mene läpi, koska ne eivät ole suoraan sidoksissa ohjelmiston sisäiseen rakenteeseen. (Beck 2000.) Automaatio on tärkeässä osassa XP:n kaltaisessa tekniikassa, jossa testejä on paljon ja niitä ajetaan koko kehityksen ajan, useita kertoja päivässä. Mitä lyhyempi iteraatio on, sitä tärkeämmäksi täysin automatisoitu testaus tulee. (Cockburn 2007.) Scrumissa testaus on pitkälle sisällytetty Sprintiin. Kehittäjät testaavat luomansa ominaisuudet samalla, kun kirjoittavat sen. Tätä toimintamallia tukee Scrumin pyrkimys mahdollisimman

16 yksinkertaiseen koodiin. Kun sprint on ohi, uudet ominaisuudet yhdistetään ja toiminnallisuus tarkastetaan. (Schwaber 2001.) Scrum ei ota suoraan kantaa testaukseen. On tavallista, että Scrum ja XP yhdistetään, jolloin Scrum tuo toimintamallit ja XP testauksen.

17 5 Metriikka ohjelmistoprosessissa On helppoa luoda tilastoja kuvaamaan ohjelman rakennetta ja sisältöä ja kutsua tulosta metriikaksi sekä kohdella näitä tuloksia aivan, kuin niillä olisi teoreettinen perusta tai ennustavaa arvoa. Tällaisella ohjelmiston tutkinnalla on yleensä hyvin vähän todellista arvoa kehitysprosessissa. (Kaner 1999.) Ennen metriikan vakavaa käyttöönottoa tulee pohtia seuraavia kysymyksiä (Kaner 1999): Mitä tämä mitta väittää mittaavansa? Mikä on teoreettinen suhde ominaisuuksien ja mittausten välillä? Onko mittarit valittu sen mukaan, onko niillä perustavanlaatuinen yhteys ominaisuuteen, jota mitataan, vai ovatko ne vain helposti saatavilla? Kun ohjelmoijaa ohjeistetaan pienentämään mittarin tulosta, esim. ohjelman kompleksisuuslukua, onko tuloksena syntynyt tuote luotettavampi vai ei, helpommin ylläpidettävä, helpommin testattava jne.? Onko testattavan ominaisuuden ja mittarin empiirinen suhde kunnossa? Voidaanko mittarin tulosta verrata eri ohjelmistojen kesken? 5.1 Metriikka perinteisissä malleissa Metriikan käyttö on vesiputousmallisessa kehitysmallissa hankalaa. Aluksi vaikuttaa siltä, että oikeat mittarit on helppo löytää. Projektin pitkittyessä asia ei kuitenkaan ole näin, vaan kehitys on vain näennäisesti suoraviivaista. Projektin alussa on eteneminen valmiusastemetriikan mukaan nopeata. Tässä vaiheessa luodaan vaatimuksia ja suunnitellaan ohjelmistoa. Ongelmia syntyy, kun varsinainen ohjelmointityö alkaa ja projektin eteen tulee uusia haasteita. Integrointivaiheessa kehitys hidastuu nopeasti, koska tässä vaiheessa kohdataan helposti odottamattomia ongelmia (kuva 8). Näiden ongelmien kanssa painivalle kehitysryhmälle kohdistuu kuluneen ajan myötä entistä suurempi paine saada järjestelmä toimimaan. Tämä johtaa helposti tilanteeseen, jossa ei ehditä suunnittelemaan kunnollisia korjauksia ohjelmistoon ja sorrutaan tekemään helpoin mahdollinen korjaus. Tuloksena syntyy pahimmillaan hauras ja heikosti ylläpidettävä tuote, joka toimitetaan myöhässä. (Royce 2001.)

18 Kuva 8. Metriikan kehitys vesiputousmallissa (Royce2001). 5.2 Metriikka ketterissä malleissa Scrum-ryhmässä valmiusaste muodostuu pitkälti sprintin aikana päivittyvästä Sprint Backlogin graafista. Siihen merkitään joka aamu tehdyt taskit ja seurataan projektin etenemistä. Avainasemassa on ryhmän ja tuotteen omistajan tekemät arviot eri tehtävien vaikeustasosta ja tekemiseen kuluvasta ajasta. Scrum-ryhmä tulee sitä tarkemmaksi arvioissaan, mitä enemmän aikaa kuluu ja tuntemus omiin kykyihin kasvaa. Tuotteen omistaja pitää kirjaa koko projektin arvioiduista tehtävistä Product Backlogissa. Molempien Backlogien näkyvyysalue on laaja, joten projektin seurattavuus on hyvä. Seurattavuuden ongelmana voidaan pitää sitä, että Product Backlog päivittyy jatkuvasti. (Larman 2003.) Scrum-kehityksessä toimiva mittari on Velocity. Se mittaa sprinteissä aikaansaatujen työnyksikköjen keskiarvoa. Velocity auttaa arvioimaan koko Product Backlogin valmistumiseen kuluva aikaa. Jos esimerkiksi on edetty kaksi Sprintiä, joissa on saatu aikaan 50 ja 100 työn yksikköä, on keskiarvo 75. Tämä suure luonnollisesti tarkentuu, mitä kauemmin ryhmä on työskennellyt. Usein mitataan myös asiakkaalle luvattua toiminnallisuutta suhteessa toimitettuun toiminnallisuuteen. XP-projektissa metriikka on keskeisessä asemassa. Suunnittelupeliä arvioidaan vertaamalla arvioitua kehitysaikaa toteutuneeseen. Tällä suureella ryhmä voi päätellä sopivan nopeuden työhönsä. XP-käytäntöihin kuuluu pitää esillä näkyvää karttaa, johon päivitetään ryhmän edistyminen vähintään viikoittain. Metriikalla on tapana menettää tarkoituksensa ajan myötä, joten suureita ja mittaustappoja tulee olla valmius päivittää. Metriikalla on suuntaa antava rooli XP-projektissa. Sen tarkoitus ei ole suoraan ohjata projektia vaan antaa lisätietoa ryhmän tilanteesta. (Beck 2000.)

19 6 Suuren mittaluokan kehitysprojektit Ketterät menetelmät tarjoavat toimivan ratkaisun pienistä keskisuuriin ohjelmistoprojekteihin. Ongelmia alkaa tulla, kun järjestelmän koko kasvaa niin suureksi, ettei 7 15 henkilön kehitysryhmällä riitä aika tai asiantuntemus. Ohjelmistoalalla on tarvetta tuoda ketterien menetelmien etuja myös suuriin projekteihin. Seuraavassa esitellään Scrum-menetelmän tapa kehittää suurempaa, kerroksittaista ohjelmistoa. 6.1 Component Team Komponenttiryhmä (engl. Component Team) on vanha lähestymistapa suurien ohjelmistokokonaisuuksien luonnissa. Siinä kehittäjistä muodostetaan ryhmät arkkitehtuuristen kokonaisuuksien ympärille. Esimerkiksi käyttöliittymää ja tietokantaa varten voi olla omat ryhmänsä(kuva 10). Mel Conway on todennut, että tuotettavan ohjelmiston ja sitä tuottavan organisaation välillä on yhteys. Tätä Convayn lakinakin tunnettua tilannetta ovat komponenttitiimien puolestapuhujat siteeranneet, mutta Convay itse ei huomiollaan rohkaise komponenttitiimien käyttöön. Hän pikemminkin vain huomioi asian. Brad Silverberg on muotoillut asian seuraavasti (Larman& Vodde 2008): The software tends to mirror the structure of the organization that built it. If you have a big, slow organization, you tend to build big, slow software. (Ohjelmisto heijastaa rakentajaorganisaationsa rakennetta. Jos organisaatio on suuri ja hidas, on tavallista, että myös ohjelmisto on suuri ja hidas. Suom. Jussi Timonen.) Komponenttiryhmiin järjestäytymiseen ohjasi kaksi perustavaa oletusta: Työntekijät eivät voi tai heidän ei kannata oppia uusia taitoja. Koodia ei voi tehokkaasti jakaa ja integroida ihmisten välillä. Komponenttiryhmä vaikutti loogiselta rakenteelta 1960- ja 1970-luvuilla. Silloin ohjelmistokehityksessä erikoistuttiin kapeaan alaan eikä ollut toisia ryhmiä, jotka olisivat voineet hajottaa ohjelmiston rakenteen. Myös versionhallinta ja testaus olivat tiensä alussa. Asiakkaan tarpeet eivät juuri koskaan rajoitu yhteen osaan ohjelmistoa, vaan uudet vaatimukset koskettavat suurta alaa. Tällöin tulee vastaan ongelma työn jakamisesta ja hallinnoinnista. Yleensä tarvitaan erillinen analyysiä varten erikoistunut ryhmä, ja myös testauksen vastuu on epäselvä, koska millään ryhmistä ei ole välttämättä kokonaiskuvaa ohjelmistosta.

20 Tämä kehitys johtaa väistämättä vesiputousmaiseen sykliin, jossa kierrokset ovat lyhempiä kuin varsinaisessa vesiputousmallissa(kuva 9). Kun ohjelmistoon lisätään uutta, kompleksista osaa, sitä ei saada valmiiksi ketterien periaatteiden mukaan yhdessä iteraatiossa, vaan se vie ainakin 5 6 kierrosta. Kuva 9. Vesiputousmainen sykli, Kuva 10. Komponenttiajattelu johon komponenttiajattelu johtaa ohjelmistokehityksessä (Larman& Vodde 2008). (Larman& Vodde 2008). 6.2 Feature Team Feature Team pyrkii toimimaan kuten oikein toimiva Scrum-ryhmä. Se pystyy tekemään kaiken työn saadakseen tehtyä Product Backlogista kokonaisen taskin. Tavoitteena on toimia kaikkien järjestelmän moduulien alueella ja tuottaa sellaisenaan käyttökelpoista toiminnallisuutta (kuva 11). Feature Team antaa mahdollisuuden jättää vaatimukset, suunnittelun, ohjelmoinnin sekä testaamisen ryhmän vastuulle toisin kuin Component Teamissa. Tällä saavutetaan parempi näkyvyys asiakkaalle ja huomattavasti yksinkertaistunut prosessi. Tällainen rakenne myös kannustaa Scrumin kannalta tärkeään uuden oppimiseen. Projekteissa toimii samanaikaisesti monia Feature Teameja, jotka käyttävät samoja komponentteja. Siksi on tärkeää, että koodi on hyvälaatuista ja että sitä refraktoroidaan ja integroidaan jatkuvasti. Yksikkötestit ovat tehokas tapa varmistaa järjestelmän toimivuus.

21 Kuva 11. Feature Teamin toiminta (Larman & Vodde 2008). Feature Team sisältää myös monia haasteita ratkaistavaksi. Näitä ovat seuraavat (Larman & Vodde 2008): Laajenneet taidot ja tuotetietämys Feature Teamilla on työalueenaan koko ohjelmisto ja sen komponentit. Tämä vaatii suuren määrän tietämystä ja halua oppia. Luonnollisesti jokaisen ei tarvitse tuntea koko järjestelmää, vaan tuotteen omistaja etsii sopivimman ryhmän luomaan uuden ominaisuuden. Jos aikaa on käytettävissä paljon, on myös mahdollista antaa ominaisuus sellaiselle ryhmälle, jolla ei ole asiasta tietämystä mutta jolla on kiinnostusta ja pohjatietoa. On normaalia, että ryhmillä on oma erikoistumisalueensa. Samanaikainen pääsy ohjelmakoodiin Koska ohjelmistoa kehittäviä ryhmiä on monia ja kaikilla on pääsy koko järjestelmän alueelle, eteen tulee tilanne, jossa yhtä komponenttia muokkaa moni eri taho. Tähän haasteeseen apua tuovat monet uudet työkalut. Tärkeä osa ratkaisua on jatkuva integraatio, jolla varmistetaan, että ohjelmisto pysyy toimivana. Jaettu vastuu suunnittelusta Komponenttiajattelussa on olemassa ryhmä, joka vastaa omasta alueestaan ja samalla sen suunnittelusta. Feature Teameilla taas muokataan jatkuvasti eri komponentteja. Jatkuva integraatio toimii tässäkin. Ohjelmisto kannattaa kääntää automatisoidusti useaan kertaan päivässä. Näin päästään hajottamaan suuret kokonaisuudet pieniin osiin ja seurattavuus paranee.