CMMI-mallin apuna voidaan käyttää GQM (Goal-Question-Metric) –menetel-mää (Basili, 1992). Menetelmässä –menetel-määritetään ensin organisaation tavoitteet (goals), joista johdetaan sitten kysymykset (questions), joihin pyritään saamaan vastaukset sopivilla mittareilla (metrics). CMMI-mallia käyttävät organisaatiot voivat suorittaa arvioinnin joko itse tai käyttää SEI:n (Software Engineering Ins-titute) sertifioimaa arvioijaa. CMMI ei pyri sertifioimaan prosessien kypsyyttä
vaan se on ainoastaan niiden kehittämisen apuväline. Arvioinnit luokitellaan A-, B- tai C-arvioinneiksi, ja SCAMPI (Standard CMMI Appraisal Method for Pro-cess Improvement) A on laajin arviointi, jonka johtaa päteväksi todettu pääar-vioija (Kähkönen & Abrahamsson, 2004). Tällaisesta arvioinnista voidaan antaa julkinen tulos kypsyys- tai kyvykkyystasoina (SEI, 2006).
Myös CMMI-mallissa on joitakin heikkouksia. Patel ja Ramachandran (2009) arvostelevat CMMI-mallia sopimattomuudesta pieniin yrityksiin ja kette-rään kehittämiseen. Hämäläisen (2007) mukaan CMMI-malli ei sovellu aivan pienille organisaatioille.
3.4 CMM ja CMMI ketterän kehittämisen näkökulmasta
CMM- ja CMMI-kypsyysmalleja kehitettiin aikana, jolloin ohjelmistokehitystä tehtiin pelkästään perinteisillä menetelmillä. Tällaista ohjelmistokehitystä on totuttu kutsumaan suunnitelmavetoiseksi (plan-driven) kehittämiseksi, koska sille on tyypillistä laaja etukäteissuunnittelu ja runsas dokumentointi. Ketterää ohjelmistokehitystä on pidetty suunnitteluvetoisena (Turner & Jain, 2002). Näi-den kahNäi-den lähestymistavan yhdistämisen on sanottu olevan yhtä perustavan-laatuinen haaste kuin veden ja öljyn yhdistäminen (Turner & Jain 2002).
Tutkijat ovat kuitenkin eri mieltä siitä, kuinka yhteensopivia ketterät me-netelmät ja kurinalaiset (rigorous) meme-netelmät ovat (Heeager, 2013). Vaikka ketterät menetelmät näyttävät olevan konfliktissa kurinalaisten menetelmien kanssa, useat tutkijat ovat sitä mieltä, että on mahdollista käyttää (joitakin) ket-teriä käytänteitä ja periaatteita ja samaan aikaan täyttää laatuvaatimukset (Heeager, 2013). On arveltu, että on mahdollista saavuttaa CMMI tasojen 2 ja 3 prosessialueet käyttäen Scrumia ja XP–käytänteitä (Cohen, Lindvall & Costa, 2004; Paulk, 2002). Lisäksi muutamat ovat sitä mieltä, että useimmat XP projek-tit, jotka todella noudattavat XP-käytänteitä, voisivat saavuttaa CMMI tason 2 (Glazer, 2001; Kähkönen & Abrahamsson 2004; Paulk, 2001). Muutamissa tut-kimuksissa organisaatioissa käytetyt ketterät menetelmät täyttivät CMMI:n ta-sojen 2 ja 3 tavoitteet (Anderson, 2005; Baker, 2005; Bos & Vriens, 2005; Vriens, 2003; Kähkönen & Abrahamsson, 2004). Boehm ja Turner (2003) puolestaan to-teavat, että tason 5 konsepti jatkuvasta kehittymisestä suorituskyvyn paranta-miseksi on linjassa ketterien menetelmien kanssa, kuitenkin huomaten sen, että useimmat ketterät menetelmät eivät tue kaikkia alempien tasojen elementtejä (Pikkarainen & Mäntyniemi, 2006). Suurin osa Heeagerin (2013) käsittelemistä tutkimuksista oli sitä mieltä, että yrityksen, joka käyttää laajennettua ketterää menetelmää, on mahdollista mukautua kypsyysmalleihin kuten CMMI tasot 2 ja 3. Anderson (2005) jopa esittää, että olisi mahdollista saavuttaa CMMI-taso 5 käyttämällä ketteriä menetelmiä. On myös ehdotettu, että ketterät menetelmät olisivat tavallaan vertikaalinen siivu CMMI tasoista 2-5 (Cohen, Lindval & Cos-ta, 2004).
Usein on oletettu, että CMMI:n kanssa yhteensopivien prosessien täytyy olla raskaita, byrokraattisia ja hidas-liikkeisiä (Anderson, 2005). Ketterien
mene-telmien, kuten XP ja Scrum, on sanottu tarjoavan vähemmän byrokraattisen tavan laadukkaaseen ihmiskeskeiseen ohjelmistokehittämiseen (Bos & Vriens, 2004). Yleinen uskomus on kuitenkin ollut, että CMMI:tä seuratakseen tiimin täytyy dokumentoida vaatimukset, palaverit, suunnitelmat, riskit ja kehittämi-sen saavutukset, voidakseen kehittää korkealaatuisia ohjelmistoja. Toisaalta ketterissä menetelmissä tiimit voivat tuottaa korkealaatuisia ohjelmistoja käyt-tämällä epämuodollista ja kevyttä dokumentointia (Boehm & Turner, 2003).
Beck ja Boehm (2003) ovat sitä mieltä, että ketteryys ja kurinalaisuus eivät ole vastakohtia. Boehm (2002) myös esittää, että vaikka molempien suuntien edustajat pitäisivät niitä vastakohtina, niiden osien yhdistäminen projekteissa voi olla hyödyllistä. Glass (2001) huomauttaa, että ”yksi-koko-sopii-kaikille”
lähestymistapa ei toimi. Mahnic ja Zabkar (2007, 2008) toteavat, että on mahdol-lista luoda ohjelmistoprosessi, joka yhdistää ketteryyden ja kurinalaisuuden.
Glazer (2010) toteaa, että ketterät menetelmät ja CMMI täydentävät toisiaan ja voivat tuoda nopeita, edullisia, näkyviä ja pitkäaikaisia etuja.
Jotkut ovat esittäneet, että CMMI-kypsyysmallia ja ketteriä menetelmiä voisi käyttää yhdessä niin, että molemmista otettaisiin parhaat ominaisuudet (Boehm & Turner 2003; Paulk, 2001; Kähkönen & Abrahamsson, 2004). Asiasta on tehty kuitenkin vain muutamia tutkimuksia (Pikkarainen, 2008). Huo, Ver-ner, Zhu ja Babar (2004) huomasivat, että ketterät menetelmät sisältävät laa-dunvarmistus-käytäntöjä, ja niitä on jopa enemmän kuin vesiputousmallissa.
Yksi tapa käsitellä CMMI:n ja ketterien menetelmien yhteensovittamison-gelmaa, on vertailla CMMI:n ja ketterän kehittämisen periaatteita (Pikkarainen, 2008). Marcal ym. (2008) ovat tehneet selvityksen siitä, miltä osin Scrum-menetelmä vastaa CMMI:n määrityksiä. Heidän mukaansa noin kolmannes CMMI:n projektinhallinnan prosessialueiden käytännöistä tulee täytettyä Scrum-projektinhallintamallissa (Marcal ym., 2008). 16,4 % käytännöistä täyttyy osittain ja noin puolet eivät täyty ollenkaan. CMMI:n ja ketterän projektinhal-linnan välillä on eroja erityisesti riskienhallinnassa, organisaationlaajuisten pro-sessien hallinnassa sekä systemaattisessa historiatietojen käytössä. Osa näistä eroista liittyy dokumentaation puutteeseen, mikä puolestaan johtuu Agile-manifestin (Beck ym., 2001) arvosta “Arvostamme toimivaa sovellusta enem-män kuin kattavaa dokumentaatiota”. Työn ja kustannusten arviointiin käyte-tään Scrumissa tuotteen kehitysjonoa sekä sprintin kehitysjonoa. Näiden arviota ei ole kuitenkaan johdettu työn koosta tai kompleksisuudesta, mitä CMMI vaa-tii, eikä kustannusten arvioinnista mainita Scrumin yhteydessä mitään. Budjetti ja aikataulu johdetaan Scrumissa suoraan tuotteen kehitysjonosta määritellyistä työmääräarvioista, mutta tarkemmat ohjeet niiden laatimiseksi puuttuvat.
Scrumissa riskejä ei tunnisteta CMMI:n vaatimalla systemaattisella ja paramet-risoidulla tavalla. Ainoa projektin suunnittelun toiminto, jota Scrum ei toteuta millään tavalla, on työtulosten tai tehtävien ominaisuuksien, kuten koon tai kompleksisuuden, määrittäminen. (Marcal ym., 2008.).
Beckin ja Boehmin (2003) mukaan XP on kurinalainen menetelmä, sillä se tarjoaa selkeän mallin siitä, mitä käytänteitä tulisi käyttää. DeMarco ja Boehm
(2002) tukevat tätä toteamusta lisäten, että XP-menetelmä sisältää enemmän suunnittelua kuin mitä CMM-malli edellyttää.
Yhteenvetona voidaan todeta, että vaikka ketterän ohjelmistokehityksen ja perinteisten kypsyysmallien periaatteissa on lähtökohtaisia eroja, on ketteriä menetelmiä soveltamalla mahdollista saavuttaa alimpia CMMI-mallin tasoja.
Toisaalta CMMI-mallin soveltamista pidetään sen verran raskaana ja paljon re-sursseja vaativana, ettei sitä pidetä kovin soveliaana ketterän ohjelmistokehi-tyksen yhteydessä käytettäväksi.
3.5 Yhteenveto
Tässä luvussa kerrottiin kypsyysmalleista. Aluksi kerrottiin yleisesti kypsyys-malleista, niiden taustasta, rakenteesta ja periaatteista. Sen jälkeen kuvattiin kahta kypsyysmallia (CMM, CMMI) hieman tarkemmin. Lopuksi kerrottiin, miten perinteiset kypsyysmallit nähdään ketterän kehittämisen näkökulmasta.
Vaikka CMMI ja ketterät menetelmät on perinteisesti nähty lähes vastakkaisina menetelminä, ovat monet tutkijat nykyään sitä mieltä, että niitä voisi käyttää yhtä aikaa. Ongelmana on kuitenkin se, että CMM:n ja CMMI:n tapaisten mal-lien käyttö on raskasta, joten on toivottu vaihtoehtoista tapaa arvioida ketterän ohjelmistokehityksen kypsyyttä.
4 KETTERÄN OHJELMISTOKEHITYKSEN KYP-SYYSMALLEJA
Tässä luvussa esitellään kirjallisuudesta löytyneitä ketterän ohjelmisto-kehityksen kypsyysmalleja. Aluksi kerrotaan, miten malleja on etsitty ja valittu tähän esitykseen. Sen jälkeen kuvataan kutakin mallia erikseen tekijöiden mu-kaisessa aakkosjärjestyksessä. Tavoitteena on kuvata malleja siten, että niitä voidaan arvioida ja verrata kuvausten perusteella. Kustakin mallista esitetään, mitä tarkoitusta varten malli on kehitetty, minkälaisista tasoista se koostuu sekä onko mallia käytetty ja/tai validoitu.
4.1 Mallien etsintä ja valinta
Kuten edellisestä luvusta kävi ilmi, on ohjelmistokehitykseen kehitetty kyp-syysmalleja jo varsin varhaisessa vaiheessa. Nämä mallit perustuvat oletukseen siitä, että prosessit määritellään tarkasti ja niitä noudatetaan tunnollisesti joka tilanteessa. Nämä oletukset ovat varsin kaukana ketterän ohjelmistokehityksen arvioista ja periaatteista. Tästä syystä ei olekaan ihme, että ketterää ohjelmisto-kehitystä varten on pyritty kehittämään kypsyysmalleja, jotka sopivat parem-min ympäristöön, jossa edellytetään nopeaa reagointikykyä vaatimusten ja ym-päristön muutoksiin.
Ketterän ohjelmistokehityksen kypsyysmalleja koskevia tutkimuksia on etsitty tutkimuskannoista (esim. IEEExplore, ACM Digital Library) ja käyttä-mällä Google Scholaria. Joitakin malleja on julkaistu vain netissä kaupallisten toimijoiden ja konsulttien toimesta. Löydetyt tutkimukset on esitetty taulukossa 1.
Taulukon neljäntoista mallin tarkastelu tässä työssä olisi ollut liian työläs-tä. Tästä syystä mallijoukkoa jouduttiin rajaamaan. Gujralin ja Rayarajin (2008) malli rajoittuu käsittelemään vain sovelluskehitystiimejä. Humble ja Russel (2009) puolestaan keskittyivät mallissaan ohjelmistojen kasaamiseen ja julkai-semiseen. Nämä mallit eivät kuvaa tarpeeksi laajasti ja kattavasti ketterää ohjel-
TAULUKKO 1 Ketterän ohjelmistokehityksen kypsyysmalleja
Lähde Mallin nimi Käyttötarkoitus
Ambler (2010) The Agile Maturity Model
(AMM) Ketterän kehittämisen kypsyysmalli ohjelmisto-kehityksen tehokkuuden parantamiseen Benefield (2010) Seven Dimensions of
Ag-ile Maturity Ketterän kehittämisen käyttöönoton nopeuttami-nen
Gujral & Rayaraj
(2008) The Agile Maturity Model
(AMM) Sovelluskehitystiimien reagointikyvyn
Malik (2007) Simple Lifecycle Agility Maturity Model
(SLAMM)
Ohjelmistokehitysprosessin ketteryyden mittaa-minen
Nawrocki ym.
(2001) eXtreme Programming
Maturity Model (XPMM) Kypsyysmalli XP:n käyttöönotolle Packlick (2007) The Agile Maturity Map
(AMM) Ketterien menetelmien käytön kehittäminen orga-nisaatiossa
Patel &
Ramachandran (2009)
Agile Maturity Model
(AMM) Ketterän ohjelmistokehittämisen parantaminen ja tehostaminen
Pettit (2006) ”Agile Maturity Model” Ketterän kehittämisen arviointi ja kehittäminen organisaatiossa
Proulx (2010) Agile Maturity Model (AMM)
Organisaation ketteryyden tason ja ketterien me-netelmien noudattamisen arviointi
Sidky ym. (2007) The Agile Adoption Framework (AAF)
Ketterien käytäntöjen käyttöönoton systematisoi-minen
Yin ym. (2011) Scrum Maturity Model Ohjelmistokehitysorganisaation auttaminen ja ohjaaminen Scrum-menetelmän käytössä
mistokehitystä, kun ajatellaan koko organisaatiota ja sen toimintaa. Luin ja Chanin (2005) malli on tarkoitettu kehittymättömille tiimeille, ja vaikka malli ei täytä yllämainittua laajuuden ja kattavuuden vaatimusta, se valittiin kuitenkin, koska se on tarkoitettu käytettäväksi XP-menetelmän yhteydessä. Näin vertai-luun saatiin kaksi mallia (Lui & Chan, 2005; Nawrocki ym., 2001), jotka on tar-koitettu käytettäväksi XP-menetelmän yhteyteen. Malik (2007) on kehittänyt Excel-pohjaisen työkalun tuotekehitysprosessin kypsyyden arviointiin. Hän ei kuitenkaan selitä työkalun pohjalla olevaa mallia, joten sitä voidaan pitää
enemmän työkaluna kuin kypsyysmallina, ja näin ollen se ei tullut valituksi.
Muut taulukossa mainitut mallit valittiin kuvattaviksi ja vertailtaviksi
4.2 Amblerin malli
Ambler (2010) on esittänyt viisitasoisen ketterän kehittämisen kypsyysmallin, jolla pyritään parantamaan ketterän ohjelmistokehityksen tehokkuutta. Kyp-syysmallin tasot ovat retorinen (rhetorical), sertifioitu (certified), uskottava (plausible), kunnioitettava (respectable) ja mitattu (measured).
Ensimmäisen tason (retorinen) ketterien menetelmien käyttäjät uskovat, että ketterä kehittäminen on tehokkaampaa kuin perinteinen kehittäminen. He us-kovat vakaasti itseensä ja asiaansa, eivätkä kunnioita johtoa, tuoteomistajia tai edes ketterää yhteisöä. Retorisella tasolla päätökset tehdään itseohjautuvissa tiimeissä. Usein on kyse pilottiprojektimaisesta ketterän menetelmän kokeilusta.
Koska tällaisiin projekteihin valitaan usein taitavia osallistujia ja niillä on riittä-västi johdon tukea, projektit myös usein onnistuvat. Tämä lasketaan usein pel-kästään ketterien menetelmien ansioksi. On kuitenkin vaarana, että tiimi ajau-tuu ns. ”Scrum-but” tilanteeseen, jolloin Scrum-käytänteistä käytetään vain osaa, eikä kokonaisuuden tuomia hyötyjä saavutetakaan. Yleensä ottaen kette-rien menetelmien käytössä ollaan hyvällä alulla, mutta pitkä matka on vielä edessä.
Toisella tasolla (sertifioitu) suurin osa tiimin jäsenistä on suorittanut jonkin sertifioidun ketterän kehittämisen kurssin (esimerkiksi sertifioitu Scrum Mas-ter). Tällä tasolla sertifiointia on tärkeä tuoda esille myös ulospäin, niin omassa organisaatiossa kuin asiakkaiden suuntaankin. Tasolla pysyäkseen täytyy serti-fiointeja pitää voimassa. Yhä useampien suoritettua sertifiointikursseja, kette-rien menetelmien käyttö organisaatiossa laajenee. Sertifioinnista huolimatta ketteristä menetelmistä ja niiden soveltamisesta ei ole vielä kovin syvällistä tie-toa.
Kolmannella tasolla (uskottava) painopistettä aletaan siirtää ketterän kehit-tämisen strategioihin. Onnistuakseen tämä vaatii, että organisaatiossa on jo tar-peeksi laajalti ketterää tietämystä. Pienet ketterät tiimit toimivat jo hyvin, ja niissä aletaan huomata, mikä todella toimii kyseisessä organisaatiossa. Ongel-mia voivat aiheuttaa suuret tai hajautetut tiimit, joita ei vielä osata johtaa ja hal-lita ketterästi. Sertifiointi ei ole enää niin tärkeää, vaan nyt keskitytään taitojen kehittämiseen ja niiden strategioiden ymmärtämiseen, joita vaaditaan laaduk-kaiden lopputuotteiden toimittamiseen.
Neljännellä tasolla (kunnioitettava) ketterien menetelmien käyttö laajenee kattamaan koko toimitusketjun, aikaisemman pelkän ohjelmistokehityksen elinkaaren sijaan. Organisaatiossa siirrytään tuottamaan laadukkaita palvelui-ta/ratkaisuja sovellusten sijasta. Siellä ymmärretään paremmin kokonaisuutta, jossa toimitaan, ja liiketoimintaprosessien ja organisaatio-rakenteiden kehittä-minen hyödyttää kaikkia. Organisaatiossa arvostetaan ja käytetään useita kette-riä menetelmiä tilanteen mukaan. Myös perinteisiä menetelmiä osataan taas
arvostaa ja ymmärretään, että niillä on omat etunsa. Ketterät tiimit ovat tällä tasolla kurinalaisia ja itseohjautuvia ja niillä on riittävä tuki- ja ohjausverkosto.
Tiimit ymmärtävät myös organisaationsa asettamat rajoitukset omaan toimin-taansa.
Viidennellä tasolla (mitattu) prosessista kerätään tietoja erilaisilla mittaväli-neillä ja integroiduilla työkaluilla, joiden avulla saadaan tarkkaa reaaliaikaista tietoa. Mitatun tiedon perusteella prosessia voidaan ohjata ja parantaa. Tässä vaiheessa ymmärretään, että organisaation johto yrittää tehdä parhaita mahdol-lisia päätöksiä käytettävissä olevan, usein puutteellisen, tiedon perusteella. Kun prosessista on käytettävissä luotettavampaa tietoa, näihin tietoihin perustuvat päätökset ovat luotettavammalla pohjalla. Organisaatiossa käytetään useita eri-laisia menetelmiä, niin perinteisiä kuin ketteriäkin, aina sen mukaan, mikä kul-loisessakin tilanteessa on tehokkainta. Myös lähestymistapaa muokataan ja skaalataan tarpeiden mukaan.
Mallista ei ole käytännön kokemuksia eikä validointitietoja.
4.3 Benefieldin malli
Benefield (2010) on tehnyt tapaustutkimuksen British Telecomin (BT) IT-osaston kehittämästä mallista. IT-ala ja varsinkin televiestintä on viime vuosina ollut suurten muutosten kourissa. Alalle tulvii uusia teknologioita ja sovelluksia on kehitettävä entistä nopeammin ja asiakkaita enemmän huomioiden. Näihin haasteisiin vastatakseen myös BT siirtyi käyttämään ketteriä menetelmiä. Mene-telmät osin toimivat ja hyötyjäkin saavutettiin, mutta seurauksena oli usein on-gelmia jollain toisella alueella, jolloin hyödyt hävisivät tai pienenivät. Esimer-kiksi kehittämisen elinkaaren onnistunut lyhentäminen aiheutti ongelmia integ-roinnissa, joka taas puolestaan hidasti julkaisutahtia. Syiden selvittämisen yh-teydessä alettiin kehittää mallia, joka nopeuttaisi ketterien menetelmien käyt-töönottoa, ja samalla paljastaisi suurimmat riskialueet, jotta apu ja tuki voitai-siin kohdistaa nopeasti näille alueille.
Malliin valittiin seitsemän ulottuvuutta, joilla kypsyyttä arvioidaan, sekä niille viisi kypsyystasoa. Nämä seitsemän ulottuvuutta tai käytäntöä ovat au-tomatisoitu regressiotestaus, koodin laatumittarit, auau-tomatisoitu kehittäminen, automatisoidut koonnit ja versionhallinta, keskitetty toimitus ja integrointites-taus, testilähtöinen kehittäminen sekä suorituskyky- ja skaalautuvuustestaus.
Kypsyystasot on nimetty seuraavasti:
1. Uudet parhaat käytännöt (Emergent engineering best practices), 2. Jatkuvat käytänteet komponenttitasolla (Continuous practices at
component level),
3. Komponenttien välinen jatkuva integraatio (Cross component con-tinuous integration),
4. Projektitasoinen jatkuva integraatio (Cross journey continuous in-tegration),
5. Kysyntään juuri ajallaan vastaavat toimitukset (On demand just in time releases).
Tavoitteena ensimmäisellä kypsyystasolla on saavuttaa tiimien kesken yhtenäiset parhaat käytännöt ja luoda selkeä pohja, josta mallia lähdetään rakentamaan eteenpäin. Tasolle kuuluvia käytänteitä ovat yksikkötestit, koodikatselmoinnit, toistettavat koonnit, versionhallinta, koodin laatu, sekä testilähtöinen kehittä-minen. Tason saavuttamiseksi tiimien tulee ymmärtää näiden käytänteiden merkitys sekä käyttää/toteuttaa niitä vähintään alustavalla tasolla.
Toisen tason tavoitteena on luoda toistettavat käytännöt komponentti-tiimeille. Uudelleenkäytettävät automatisoidut koonnit, jakelut ja testitapaukset kuuluvat tämän tason saavuttamiseen.
Kolmannella tasolla näkökulma laajenee tiimeistä komponenttien väliseen integraatioon ja yhteistoimintaan. Tällä tasolla koontien ja regressiotestauksen tulee olla jo vahvasti automatisoitu. Tiimien tulee synkronisoida työnsä muiden tiimien kanssa ja suorittaa säännölliset koonti-/testikierrokset yli komponentti-rajojen.
Neljännellä tasolla näkökulma laajenee edelleen ja koskee nyt koko tuotan-toketjua. Useiden tuotteiden ja palveluiden tuottajien pitää pystyä toimimaan yhdessä ja tuottamaan asiakkaalle hänen haluamansa tuote. Tällä tasolla auto-matisointi on viety huippuunsa ja refaktoroinnista tulee rutiinia. Tuottavuus, suorituskyky sekä skaalautuvuus laajenee komponenttitasolta tuote- ja tuotan-toketjutasolle.
Viidennellä tasolla tiimit ovat erittäin tuottavia ja pystyvät nopeasti ymmär-tämään ja kommunikoimaan eri komponenttien ja tuotteiden väliset riippu-vuudet ja sidonnaisuudet. Koodin refaktorointi on rutiinia ja se myös näkyy koodin laadussa. Uudet tuotteet pystytään nopeasti kokoamaan ja kokeilemaan.
Parhaimmillaan tällä tasolla lopputuotteen testauksen, kehittämisen, operatiivi-sen toiminnan ja liiketoiminnan rajat hämärtyvät ja ideat voivat kehittyä va-paasti halki yrityksen ja niitä voidaan nopeasti kokeilla käytännössä.
Organisaation arviointia varten on käytettävissä taulukko, jonka riveinä ovat ulottuvuudet ja sarakkeina tasot (kuvio 5). Jokaisen ulottuvuuden taso ar-vioidaan omalla rivillään. Taulukkoon voidaan merkitä myös tavoitetaso. Tau-lukosta nähdään nopeasti vahvuudet ja heikoimmat alueet, joille seuraavaksi tulisi kohdistaa kehittämistoimia.
Benefield (2010) luonnehtii mallin käytön tuloksia organisaatiossa erittäin positiiviseksi. Mallin avulla on alustavien tulosten mukaan esimerkiksi virhei-den löytyminen vasta järjestelmätestauksen yhteydessä vähentynyt yli 60 % ja näistä virheistä tuskin yksikään on ollut erittäin vakava. Myös kun koonti-jakelu-/testaussyklit saatiin paremmin automatisoitua ja toistettavimmaksi, säästyi tuhansia henkilötunteja ja samalla paljastui uusia ongelma-alueita. Näi-den uusien ongelma-alueiNäi-den löytäminen aikaisessa vaiheessa mahdollistaa myös niiden ratkaisemisen aikaisemmin. Mallin käytön on sanottu laajenevan organisaatiossa edelleen.
Ulottuvuus Nykyinen
taso 1 2 3 4 5 Tavoite-taso
1 Automatisoitu regressiotestaus
2 Koodin laatumittarit
3 Automatisoitu kehittäminen
4 Automatisoidut koonnit ja versionhallinta 5 Keskitetty toimitus ja integrointitestaus
6 Testilähtöinen kehittäminen
7 Suorituskyky ja skaalautuvuus testaus KUVIO 5 Benefieldin (2010, 5) malli
4.4 Luin ja Chanin malli
Luin ja Chanin (2005) malli on tarkoitettu tukemaan XP-menetelmän käyttöön-ottoa sellaisissa tiimeissä, jotka eivät vielä ole niin kehittyneitä, että voisivat käyttää muita ketterän kehittämisen kypsyysmalleja. Luin ja Chanin (2005) mu-kaan kehittymättömät tiimit tarvitsevat yksinkertaiset ja vaiheittaiset ohjeet.
Beck (1999) havaitsi, että XP-käytänteiden välillä on vaikutussuhteita. Jotkut käytänteet vaikuttavat toisiinsa vahvistavasti ja osa XP-käytänteistä on keskei-sempiä kuin toiset. Näitä XP-käytänteiden suhteita havainnollistetaan kuviossa 6. Nuoli kahden käytänteen välillä tarkoittaa, että nämä käytänteet vahvistavat toisiaan. Suluissa käytänteen perässä on esitetty kunkin käytänteen suhteiden määrä.
XP:n vahvuus tulee juuri käytänteiden yhteisvaikutuksesta. Lui ja Chan (2005) halusivat löytää uuden esitystavan sille, kuinka nämä 12 käytännettä ovat vuorovaikutuksessa keskenään. Heidän mielestään olisi ollut väärin prio-risoida käytänteitä ainoastaan suhteiden määrän perusteella, sillä kaikki käy-tänteet ovat tärkeitä ja kuuluvat XP:n lähestymistapaan. Luin ja Chanin (2005) mielestä on kuitenkin selvää, että testaus, jolla on kahdeksan suhdetta, on hyvä lähtökohta, koska se tarjoaa suurimman määrän vaihtoehtoja seuraavaan aske-leeseen.
Lui ja Chan (2005) muokkasivat XP-käytänteiden suhdegraafia visuaalisen tiedon louhinnan (visual data mining, VDM) avulla toisenlaiseen muotoon (ku-vio 7) ja loivat sen perusteella oman mallinsa. Seuraavaksi kuvataan hieman heidän käyttämäänsä tekniikkaa.
KUVIO 6 XP käytänteiden suhteet (Beck, 1999)
KUVIO 7 Graafinen esitys vs. Matriisi (Lui & Chan, 2005, 478 )
Kuvio jossa on n solmua, voidaan esittää nxn–kokoisena matriisina, missä arvo (i, j) on 1 jos solmun i ja solmun j välillä on suhde, muuten arvo on 0. Esimer-kiksi kuviossa 7 Testauksen ja Metaforan välillä on suhde. Matriisissa Testauk-sen ja Metaforan risteyskohdissa niiden suhde on merkitty keltaiseksi.
Näin suhdekuvio voidaan esittää uudelleen matriisimuodossa. Matriisin ei kuitenkaan muodostu selkeää tai merkityksellistä kuviota (kuvio 8, vasem-manpuoleinen kuvio). Analyysin seuraavassa askeleessa vaihdetaan sarakkei-den ja rivien järjestystä matriisissa. Lui ja Chan (2005) määrittelivät funktion f(i,j)=(i+1,j)+(i-1,j)+(i,j+1)+(i,j-1), jossa (i,j)=1 jos matriisin ruutu rivillä i ja sa-rakkeessa j on merkitty, muuten (i,j)=0. f(i,j):n kokonaisarvo matriisissa on
Vaihtamalla kaksi riviä keskenään sekä niiden vastaavat sarakkeet, jotkut pis-teet siirtyvät kauemmas toisistaan, mikä vähentää f(i,j):n kokonaisarvoa. Samal-la tavoin pisteet voivat siirtyä lähemmäs toisiaan, mikä puolestaan lisää koko-naisarvoa. Tämän periaatteen mukaan matriisi voidaan järjestää uudelleen niin, että kokonaisarvo muodostuu mahdollisimman suureksi. Kuvion 8 oikeanpuo-leinen matriisi näyttää tuloksen järjestelyn jälkeen ja paljastaa kuviokeskitty-män.
KUVIO 8 VDM:n avulla löydetty kuviokeskittymä (Lui ym., 2005, 478)
Kuviosta päätellen ja klusterianalyysia hyväksikäyttäen Lui ja Chan (2005) ovat päätyneet neljään XP-käytänteiden käyttöönottovaiheeseen. Vaiheet ovat seu-raavat:
1. testaus, yksinkertainen suunnittelu, refaktorointi, koodaussäännöt 2. jatkuva integraatio
3. pariohjelmointi, yhteisomistajuus
4. metafora, 40-tuntinen viikko, pienet julkaisut, läsnäoleva asiakas, suunnittelupeli
Lui ja Chan (2005) sanovat saaneensa paljon positiivista palautetta ohjelmointi-tiimeiltä, jotka ovat kokeilleet mallia pyrkiessään ottamaan käyttöön XP:tä. Lui ja Chan (2005) pitävät menetelmän etuna sitä, että se opettaa samalla tiimejä
ymmärtämään, mitä tiimin pitäisi omaksua ja miksi. Mallin rajoituksena voi-daan pitää sitä, että se ei aikatauluta vaiheita mitenkään. Mallista ei ole vali-dointitietoja saatavilla.
4.5 Nawrockin, Walterin ja Wjochiechowskin malli
Nawrocki, Walter ja Wjochiechowski (2001) esittävät kypsyysmallin XP:n käyt-töönotolle. Mallin nimi on eXtreme Programming Maturity Model eli XPMM.
Mallista haluttiin tehdä mahdollisimman kevyt ja yksinkertainen, koska myös XP on ketteränä menetelmänä kevyt. Nawrocki ym. (2001) käyttävät osin CMM(I):tä (SEI, 2010) ja PSP:tä (Personal Software Process) (Humphrey, 2002) oman mallinsa pohjana. CMM(I):n he valitsivat sen laajan käytön ja tunnettuu-den vuoksi.
CMM(I):ssä on viisi tasoa, kun taas XPMM:ssä on neljä tasoa. Molemmissa tasoille on määritelty käytänteitä, joita täytyy noudattaa tasolle pääsemiseksi.
Sekä CMMI:n että XPMM:n ensimmäisellä tasolla ovat organisaatiot/projektit, jotka eivät toteuta mitään mallin määriteltyjä käytänteitä. CMMI:n ja XPMM:n tasoilla 2 yhdistävänä tekijä on suuntautuminen projektitiimeihin.
Nawrocki ym. (2001) jakavat XP-käytänteet viiteen osa-alueeseen, yleis-suunnitteluun (planning, P), yksityiskohtaisempaan yleis-suunnitteluun (designing, D), koodaukseen (coding, C), testaukseen (testing, T) sekä ympäristöön (facili-ties, F). Jokainen näistä osa-alueista sisältää useita siihen liittyviä XP-käytänteitä, paitsi ympäristö, jossa on vain yksi XP-käytänne. Osa-alueeseen ”testaus”
Nawrocki ym. (2001) jakavat XP-käytänteet viiteen osa-alueeseen, yleis-suunnitteluun (planning, P), yksityiskohtaisempaan yleis-suunnitteluun (designing, D), koodaukseen (coding, C), testaukseen (testing, T) sekä ympäristöön (facili-ties, F). Jokainen näistä osa-alueista sisältää useita siihen liittyviä XP-käytänteitä, paitsi ympäristö, jossa on vain yksi XP-käytänne. Osa-alueeseen ”testaus”