Projektien kehitysmenetelmän valinnasta

Transkriptio

1 Projektien kehitysmenetelmän valinnasta LuK-tutkielma TURUN YLIOPISTO Informaatioteknologian laitos Tietojenkäsittelytiede Kalle Hjerppe 2011

2 <Tiivistelmätemplate> </Tiivistelmätemplate>

3 Sisällysluettelo 1 Johdanto Ketterä ohjelmistotuotanto Yleistä Scrum Plan-driven metodit Yleistä CMMI Menetelmien vertailu Yleispätevä menetelmä Kotikentät Tasapaino Riskin mukaan tasapainottaminen Scrum ja CMMI Yhteenveto Lähteet...22

4 1 Johdanto Ketteryys kuvailee ohjelmistotuotannon metodeja, jotka perustuvat iteratiiviseen ja inkrementaaliseen kehittämiseen. Ohjelmiston iteraatio on yksi kehityssyklin ajoittainen työjakso, jossa ohjelmistoon on tuotettu lisää arvoa. Plan-driven menetelmät ovat perinteisiä suunnitteluun ja dokumentointiin perustuvia kehitysmetodeja. Ketteryys ja kurinalaisuus vaikuttavat toistensa vastakohdilta, mutta ohjelmistontuotannossa ne tukevat toisiaan. Plandriven kehittäjien on nykyaikana oltava ketterä ja ketterien kehittäjien on oltava kurinalaisia. Tutkielman tavoitteena on selvittää molempia lähtökohtia hyödyntäviä tasapainoisia kehitysmetodeja. Tällaiset kehitysmetodit vaihtelevat projektista toiseen ja niiden on otettava huomioon vallitsevat olosuhteet ja mahdolliset riskit. Tutkielmassa tutkitaan ketterien ja plandriven ohjelmistotuotantomenetelmien ominaisuuksia tarkoituksena selvittää, millaisiin projekteihin nämä soveltuvat parhaiten. Menetelmien välimuodoista tutkitaan tasapainoon pyrkiviä menetelmiä, kuten riskistrategioihin perustuvaa kehitysmenetelmää. Käytännön esimerkkeinä tutkielmassa on ketterä menetelmä Scrum ja plan-driven menetelmä Capability Maturity Model Integration (CMMI). [8] Suuri osa tutkielman lähteistä perustuu Barry Boehmin ja Richard Turnerin julkaisuihin aiheesta, tärkeimpänä on kirja "Balancing Agility and Discipline A Guide for the Perplexed". Boehm on tutkinut ohjelmistotuotannon menetelmiä yli viisikymmentä vuotta. Hän on ohjelmistotuotannon professori ja Etelä-Californian yliopiston ohjelmistotuotannon keskuksen johtaja. Turner on tutkimusta tekevä professori suunnittelun johtamisen ja systeemisuunnittelun alalla George Washingtonin yliopistossa. Hänellä on laaja kokemus ohjelmistotuotannon alalta, sekä yksityiseltä sektorilta, että valtion virasta. [8, s. 268] Sekä ketteristä, että plan-driven menetelmistä on yleisiä väärinkäsityksiä. Sanotaan, ettei ketterissä metodeissa suunnitella. Tämä ei pidä paikkaansa, vaan ketterät metodit saavat nopeutensa kehitysryhmän välisen hiljaisen tiedon käyttämisestä hyväksi dokumentaation kustannuksella. Toisaalta dokumentoitujen suunnitelmien teko suuren ajan kustannuksella ei tarkoita sitä, että niitä noudatettaisiin oikein.[8, s. 54] On väärinkäsitys, että ketteriä ja plan-driven menetelmiä ei voida yhdistää. Onnistuneita ohjelmistoja on kehitetty tasapainoisilla menetelmillä. Yksittäistä kaikki projektit kattavaa kehitysmenetelmää on mahdotonta kehittää, koska projekteilla on liian erilaiset ominaisuudet. Kehitysmenetelmien tasapainottaminen on moniulotteinen prosessi, jossa on harkittava asiaa teknologian, johtamisen ja henkilöstön kannalta. [8, s. 97]

5 2 Ketterä ohjelmistotuotanto 2.1 Yleistä Ketterä ajattelu ohjelmistotuotannossa alkoi The Agile Alliancen manifestista, joka luotiin ketterien metodien asiantuntijoiden kokoontuessa Utahissa pienimuotoiseen konferenssiin. Jo aiempina vuosina oli noussut esiin kevyitä ohjelmistotuotantometodien malleja ja keskustelua niistä. Ne olivat kasvavassa suosiossa, suurimmaksi osaksi siksi, että tällaisilla menetelmillä oli työtä vapauttavia ominaisuuksia. The Agile Manifesto veti yhteen kokoontumiseen osallistuneiden asiantuntijoiden näkemykset ketterän kehityksen perusperiaatteista; Asiantuntijat loivat seuraavan julistuksen (liite 2.1), sekä kaksitoista ketteryyden periaatetta. [1] Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Liite 2.1 The Agile Manifesto [1] Liite 2.1. on Agile Alliancen julkaisema manifesti, jossa todetaan heidän päätyneen seuraaviin johtopäätöksiin ketteryyden arvoista. Ketterissä menetelmissä arvostetaan työntekijöitä yksilöinä ja heidän välistä interaktiotaan enemmän, kuin määrättyjä prosesseja, tai työkaluja. Yksilön tiedot ja taidot ovat tärkeitä pienryhmissä tapahtuvassa kehityksessä. Toimiva ohjelmisto on tärkeämpää, kuin työn tarkka dokumentaatio. Tällä tarkoitetaan sitä, että tarkasteltaessa työn tuloksia, suuri määrä valmista ohjelmaa on arvokkaampaa, kuin vähäinen määrä yksityiskohtaisesti dokumentoitua ohjelmaa. [1] Manifestin mukaan yhteistyötä asiakkaan kanssa arvostetaan enemmän, kuin sopimukesta neuvottelua. Tästä toivotaan seuraavan pitkä ja tuottoisa asiakassuhde. Valmius muutoksiin vaatimusmäärittelyssä on tärkeämpää, kuin suunnitelman seuraaminen. Muutosten tapahtuessa suunnitelma on vanhentunut. Manifestista voidaan myös todeta, tutkielman kannalta mielenkiintoisesta näkökulmasta, minkälaiseen projektiin ketterän kehityksen periaatteet sopivat. Agile -ajattelu syntyikin vastaiskuna vanhempia, tehottomia kehitysmalleja kohtaan. Manifesti kertoo jo paljon siitä, millaisia asioita kettterässä kehittämisessä pidetään tärkeinä tai vähemmän tärkeinä [2].

6 The Agile Manifeston kaksitoista periaatetta kiteyttävät ketteryyden pääominaisuudet: 1) Tärkein tehtävä on asiakkaan palveleminen tuottamalla arvokasta ohjelmaa aikaisin ja jatkuvasti. 2) Projektissa vastaanotetaan vaatimusmäärtittelyä koskevia muutoksia, jopa myöhäisessä vaiheessa. 3) Ohjelman iteraatioita toimitetaan usein, muutaman viikon kuukauden välein. 4) Liiketoiminnan henkilöiden ja ohjelmistokehittäjien tulee olla yhteistyössä päivittäin. 5) Projektit rakennetaan motivoitujen yksilöiden ympärille; heitä tuetaan tarvittavilla tavoilla ja osoittamalla luottamusta. 6) Henkilökohtainen keskustelu on tehokkain tiedonvälitysmedia kehittäjille ja heidän välillään. 7) Toimivan ohjelman määrä on projektin edistymisen tärkein mittari. 8) Ketterät menetelmät ovat jatkuvaa työntekoa kestäviä. Kehittäjien tulisi pystyä jatkamaan tasaista työvauhtia jatkuvasti. 9) Ketteryyttä lisää jatkuva huomio tekniseen erinomaisuuteen ja hyvään suunnitteluun. 10) Oleellista on turhan työn määrän minimointi. 11) Itseäänjohtavat ryhmät luovat parhaat arkkitehtuurit, vaatimusmäärittelyt ja suunnitelmat. 12) Ryhmä arvioi tasaisin väliajoin omaa toimintaansa ja pyrkii parantamaan sitä. [1] Ketterässä kehitystavassa painotetaan suhteita ja kommunikaatiota ohjelmistonkehittäjien keskuudessa. Esimerkiksi, sopimuksissa ihminen on tärkeämpi kuin valittava prosessi, tai kehitystyökalu. Olemassa olevissa käytännöissä tämä ilmenee tiiviinä ryhminä, läheisinä työympäristön ratkaisuina ja muina ryhmähenkeä luovina tapoina.[3] Kehittäjäryhmän tärkein tehtävä on tuottaa jatkuvasti toimivaa ja testattua ohjelmistoa. Uusia versioita julkaistaan tasaisin väliajoin, päivittäisistä julkaisuista kerran kuussa tuleviin: nopeus on metodologiakohtaista. Päämääränä on rakentaa ohjelmaa valmiimmaksi iteraatio kerrallaan. Pystyäkseen pitämään jatkuvan kehityksen nopeuden, kehittäjien tulee pitää ohjelmakoodi yksinkertaisena ja helppona, jolloin dokumentaation määrä ja tärkeys vähenee.[3] Ketterässä ajattelussa asiakkaan ja kehittäjän väliselle yhteistyölle ja suhteelle annetaan suurempi painoarvo kuin tiukoille sopimuksille. Asiakasta kunnioitetaan myös tulevaisuuden kumppanina, jolloin on edullista vaalia hyvää suhdetta. Sopimusneuvottelut on keino luoda ja ylläpitää tätä asiakas kehittäjä -suhdetta, eikä niitä kohdella voitontavoitteluna. Riskiä siitä, ettei sopimus täyttyisi vähentää se, että ketterässä kehityksessä toimitetaan arvoa iteraatioittain heti projektin alusta lähtien. Hyvin muotoillun sopimuksen tärkeys kuitenkin kasvaa sitä enemmän, mitä suurempi projekti on kyseessä.[3] On olemassa lukuisia erilaisia kehitysmetodeja, joita kuvaillaan ketteriksi. Osia useasta voidaan jopa käyttää yhtäaikaisesti samassa projektissa. Kehitysmetodeja voidaankin pitää työkaluina, joista valitaan projektiin parhaiten sopivat. On myös käytännössä yleistä, että projekteissa on käytössä kehitysryhmän itsensä räätälöimä tapa, joka koostuu monen metodin yksittäisistä tavoista. Ketteryys tarkoittaa periaatteita toiminnan perustana, ketterät metodit ovat näitä

7 periaatteita soveltavia toimintatapoja. Toimintatavat eivä vastaa täysin projektien tarpeita, ja siksi niitä on muokattava sopiviksi. [8, s.26-30] 2.2 Scrum Scrum on ketterä, iteraatioittain ohjelmistoa tuottava metodi ohjelmistonkehitykseen. Se kehystää tuotannon työjaksoihin, jotka on nimetty Sprinteiksi. Yhden iteraation pituus on enintään kuukausi, ja ne seuraavat toisiaan ilman välissä olevia taukoja. Sprinttien aikataulutuksesta käytetään termiä timeboxed, joka tarkoittaa sitä, että Sprintin aikataulu on kiinnitetty sovitun mittaiseksi. Sprintti loppuu tiettynä päivänä, oli työ valmis tai ei. Sprintin kestoa ei voi pidentää sen ollessa kesken. Tämän rajoituksen tarkoituksena on taata vakaa kehitysympäristö Sprintin ajaksi, mikä sallii kehittäjien keskittyä tietyn ajan tiettyihin ohjelmiston osiin. [4] Scrum-kehityksessä on määritetty kolme pakollista dokumentaatioartikkelia. Ensimmäinen on asiakkaan vaatimuksista pidettävä priorisoitu lista, backlog. Projektilla on yksi backlog, johon valitaan toteutettavat ominaisuudet tärkeysjärjestyksessä. Projektin backlog voi muuttua koska tahansa, mutta jo toteutettuja ominaisuuksia ei luonnollisesti poisteta. Jokaisen Sprintin alussa kehitysryhmä valitsee projektin backlogista toteutettavat ominaisuudet ja sitoutuu tekemään parhaansa niiden toteuttamiseksi Sprintin aikana. Kehitysyhmän itse arvioidessa, paljonko he kykenevät Sprintissä toteuttamaan, ja sitoutuessaan siihen, saavutetaan suurempi tuotantomäärä ja työmoraali, kuin määrättäessä tehtävä työ ryhmälle. Kokenut ryhmä kykenee luonnolliesti arvioimaan paremmin yhdessä Sprintissä toteutettavan työmäärän, eli optimaalisen tuotantonopeuden saavuttamiseen on tehtävä useita Sprinttejä kokemuksen saamiseksi. [4] Valitut ominaisuudet kirjataan toiseen pakolliseen dokumenttiin, Sprintin backlogiin, joita luodaan uusi jokaista Sprinttiä kohden. Sprintin ollessa kesken kehitysryhmä toteuttaa Sprintin backlogia tärkeysjärjestyksessä ja vaikka projektin backlog muuttuisi, Sprintin backlogia ei vaihdeta. Tämä on taas toimenpide siihen, että kehittäjät voisivat tehdä työtään häiriöittä, ilman, että heidän tarvitsisi keskittyä muuttuviin vaatimuksiin. Tilanteessa, jossa kesken olevan Sprintin jatkaminen olisi liian kallista, eli Sprintin backlog ei vastaa projektin tarpeita lainkaan, on mahdollista keskeyttää koko Sprint, aloittaa uusi ja tehdä uusi Sprintin backlog. [4] Kolmas Scrumin määrittämä dokumentaation muoto on Sprintin burndown chart. Luodessaan Sprintin backlogia kehitysryhmä arvioi kuhunkin tehtävään kuluvan ajan määrän. Tämä arvio auttaa seuraavien Sprinttien työtä valitessa, koska kehitysryhmä voi tarkemmin valita työmäärän, johon sitoutua. Burndown chart on kaavio, johon joka päivä merkitään aiemman arvioinnin perusteella, paljonko työtä Sprintissä on jäljellä. Tästä syntyy, projektin edetessä, vähenevä kuvaaja, josta kehitysryhmä näkee työn etenemisen. Tärkeää on, että kehitysryhmä näkee Sprintissä jäljellä olevan työn määrän ja voi siten säädellä toimintaansa ajan kuluessa. [4] Scrum määrittää myös kolme kehitykseen kuuluvaa roolia: Product owner, ScrumMaster ja Team. Product owner on kakkien projektiin kuuluvien osakkaiden edustaja. Hän vastaa siitä, millainen ohjelmistosta tulee ja projekti etenee hänen näkemyksensä mukaan. Product owner priorisoi ohjelmistoon tulevat ominaisuudet, ja hyväksyy tai hylkää lopulliset tuotokset. Product

8 owner omistaa projektin backlogin ja hallinnoi sitä. ScrumMaster on yksi kehitysryhmän jäsenistä, jonka tehtävänä on johtaa Scrumin toimintatapojen toteutumista ja toimia linkkinä kehitysryhmän ja ulkopuolisten välillä. Ryhmä siis on siis vakaassa kehitysympäristössä, jota ScrumMaster suojelee. Team on Scrumin termi kehitysryhmälle. Erityisvaatimuksia ryhmän kokoonpanosta ei ole, mutta se koostuu tyypillisesti viidestä yhdeksään jäsenestä, jotka johtavat toisiaan. Ryhmän sisällä tulee olla lähes kaikki projektissa tarvittava taito ja tieto. Koko kehitysryhmä on vastuussa työn tuloksesta. [4] Projektin työntekoon Scrum määrittää pidettäväksi neljä seremoniaa: päivittäisen Scrumkokouksen, sekä Sprint planning, review ja retrospective -kokoukset. Päivittäinen Scrum-kokous on lyhyt tapaaminen, jossa kehitysryhmä kokoontuu yhden kerran nopeasti käymään läpi seuraavat asiat: 1) Mitä tehtiin eilen? 2) Mitä tehdään tänään? 3) Mitä esteitä työn tekemiselle oli tai on? Päivittäiseen tapaamiseen ei kuulu tuoda muita asioita, ja jos on suurempia ongelmia, niitä koskien sovitaan toinen jatkokokous. [4] Sprint planning -kokous on kaksiosainen, yhteensä noin päivän kestoinen tapahtuma. Ensimmäisessä osassa Product owner ja kehitysryhmä keskustelevat siitä, mitä Sprintissä pitää tehdä ja millainen heidän näkemyksensä siitä on. Toisessa osassa kehitysryhmä suunnittelee keskenään, miten sovitut asiat toteutetaan. Ryhmä arvioi, kauanko kussakin tehtävässä kuluu aikaa, ja sitoutuu tämän perusteella toteuttamaan tietyn työmäärän. Sprintin backlog luodaan. [4] Sprintin jälkeen pidetään Sprint review -kokous, joka on epämuodollinen, noin kahden tunnin pituinen tapahtuma, jossa kehitysryhmä esittelee Sprintin aikana saavuttamansa tulokset. Kokous voi olla esimerkiksi demonstraatio uusista ohjelmiston ominaisuuksista, tai arkkitehtuurin tarkastelua. Sääntönä on, että kokousta ei saa valmistella kahta tuntia enempää, eikä diaesityksiä saa näyttää. Tämän perustelu on tapahtuman pitäminen epämuodollisena. Koko kehitysryhmän on osallistuttava reviewiin ja paikalle kannustetaan saapumaan kaikki projektiin osalliset henkilöt. [4] Scrumin tärkeä teema on jatkuva oman toiminnan tarkastelu ja kehittäminen. Jokaisen Sprintin lopussa järjestetään retrospective-tapaaminen, jossa käydään läpi Sprintissä hyvin, tai huonosti menneitä asioita ja sitä, miten toimintaa parannettaisiin. Retrospective on tyypillisesti nopea kokous, alle tunnin pituinen ja siihen osallistuu vähintään koko kehitysryhmä ja Product owner. Tapa toteuttaa itsearviointi voi olla jokaisen osallistujan vuorollaan kertoen seuraavaan Sprinttiin yhden asian, mitä he haluavat aloittaa, yhden asian minkä lopettaa ja yhden mitä jatkaa tehdä.[4]

9 Kuva 2.2 Scrumin malli [4] Kuva 2.2 on kaavio Scrum-projektin etenemisestä. Product Owner kuuntelee käyttäjiä, asiakkaita, kehitysryhmää ja muita projektin osakkaita. Saadun tiedon perusteella hän luo projektin backlogin. Ennen Sprinttiä projektin backlogista valitaan toteutettavat tehtävät Sprint backlogiin Spring planning -kokouksessa. Sprintin ajan kokoonnutaan päivittäin ja päivitetään burndown chart. Sprintin ja sen loppuseremonioiden jälkeen lopputuloksena pitäisi olla valmis inkrementti ohjelmistoon. "Potentially shippable" tarkoittaa sitä, että Sprintin jälkeen tehty työ ei saisi olla kesken, vaan se on valmis toimitettavaksi vaikka heti. [4] Scrumin perimmäinen ajatus on se, että ohjelmistontuotannossa on useita teknisiä ja ympäristöstä riippuvia muuttujia, kuten ohjelman vaatimukset, projektin aikataulu, käytettävissä olevat resurssit, ja teknologia. Näiden muuttujien odotetaan muuttuvan prosessin aikana, mikä tekee prosessista vaikeasti ennustettavan ja monimutkaisen. Tämän vuoksi Scrum lähestyy aihetta joustavasta näkökulmasta ja on valmiina reagoimaan muutoksiin. Tavoitteena on se, että tuotettu järjestelmä on hyödyllinen kun se toimitetaan eikä vastaa vanhoja, jo muuttuneita vaatimuksia. [3] Scrumia käyttämällä kehitysryhmä saa rauhallisen työympäristön ja voi saavuttaa nopeimman ryhmän taitoa vastaavan kestävän tuotantonopeuden. Kehitysryhmä tarkastelee omaa toimintaansa kriittisesti ja pyrkii parantamaan sitä joka Sprintissä.

10 3 Plan-driven metodit 3.1 Yleistä Perinteinen tapa tuottaa ohjemistoja on vaiheittain etenevä, vesiputousmallia seuraava kehitys. Vesiputousmalli on menetelmä, jossa kehitys jaetaan vaiheisiin, kuten vaatimusmäärittelyyn, suunnitteluun ja ohjelmointiin. Vaiheet seuraavat toisiaan tietyssä järjestyksessä edellisen valmistuessa. Nämä vaiheet on tyypilliset vaiheet ovat: 1) Vaatimusmäärittely, 2) Suunnittelu, 3) Toteuttaminen, 4) Testaus ja 5) Ylläpito.[9] Plan-driven metodeista on monia muunnelmia, kuten V-malli, mutta kaikki noudattavat samankaltaista elinkaarimallia jotenkin muokattuna. V-malli on kaksisuuntainen vesiputousmalli, joka tuo erityisesti esille jokaista kehityksen vaihetta vastaavan testausvaiheen. [10] Esimerkiksi alijärjestelmien arkkitehtuurin suunnitteluvaihetta vastaa niiden testaus ja moduulien toteutusta vastaa yksikkötestaus. V-mallissa vesiputous etenee ylhäältä alas ensin laajojen asioiden suunnittelusta yksityiskohtiin ja niiden toteutukseen. Sitten toiminta etenee alhaalta ylös testaten ja verifioiden jokaisen tason yksityiskohdista aloittaen. Prosessi voidaan vielä jakaa kolmeen näkökulmaan: käyttäjän, suunnittelijan ja toteuttajan näkökulmiin. Käyttäjää koskee ylin taso ja toteuttajaa yksityiskohdat. Suunnittelija on näiden välillä.[10] V-mallissa projekti on testivetoista, kun jokaista elinkaaren askelta vastaa testausvaihe. Tästä seuraa myös se, että testijärjestelyjä harkitaan jo aikaiseisessa projektin vaiheessa, mikä lisää projektin varmuutta ja vähentää epävarmuutta tilanteessa, jossa riskejä ei voida ottaa. [11] Tyypillisesti plan-driven prosessi alkaa yksityiskohtaisesta suunnitteluvaiheesta, jossa koko tuote käydään läpi, suunnitellaan ja dokumentoidaan tarkasti. Suunnitteluvaiheeseen vaadittu työmäärä on tiedossa ja voidaan aikatauluttaa ja organisoida helposti. Yksityiskohtaisen designdokumentin perusteella koko työ voidaan jakaa osiin, arvoida jokaisen kustantama aika- ja työmäärä ja aikatauluttaa tarkasti. Tämän jälkeen projekti voidaan kokonaisuudessaan vielä esittää hyväksyttäväksi tarkkoine kustannusarvoineen, vielä ennen kuin paljoa työtä ollaan tehty. [4] Vasta edellisten vaiheiden jälkeen itse kehitysryhmä ryhtyy työhön projektin parissa. Osa ryhmästä voi toki olla myös suunnitteluryhmässä, mutta elinkaarimallissa tämä ei suinkaan ole pakollista. Kehitysryhmässä jokaisella on omat, määrätyt roolinsa, ja työ etenee askel askeleelta esimerkiksi eri osastojen välillä. Työn valmistuttua se siirtyy testausvaiheeseen, jossa ohjelman laatu ja toimivuus tarkastetaan ennen sen toimitettamista asiakkaalle. [4] Plan-driven menetelmä on looginen ja sen kulkua on helppo seurava valmiiden milestonemerkkipaalujen valmistumisen myötä. Milestone on ennalta sovittu ohjelmiston osa tai kehitysprosessin vaihe, joiden valmistumisen myötä projektin etenemistä voidaan seurata. Milestoneilla voi olla määrätty päivämäärä, jolloin niiden tulee olla valmiina, mikä auttaa projektin aikataulussa pysymisessä ja sen seuraamisessa. Projekti pysyy hallinnassa ja luultavimmin tarkasti suunnitelmassa, koska elinkaarimallissa dokumentointi on suuressa osassa ja kaikesta on kirjoitettu oikea toimintatapa. Projektin kulku on suunniteltua ja muistuttaa muita perinteisiä tekniikan alan työprojekteja: Ensin työ ajatellaan läpi, kirjoitetaan suunnitelma. Toiseksi seurataan suunnitelmaa toteutuksessa ja yritetään pitää kaikki järjestyksessä.

11 Kolmanneksi toteutettu työ testataan ja toimitetaan asiakkaalle. [4] 3.2 CMMI 1980-luvun loppupuolella Yhdysvaltojen puolustusministeriö tilasi ehdotuksia ratkaisemaan vallitsevien ohjelmistotuotantotapojen ongelmia, kuten tehottomuutta, kalliutta ja epäonnistumisalttiutta. Ehdotuksista valittiin ja rahoitettiin Software Engineering Institute (SEI), joka teki tutkimusta luoden lopulta mallin, josta tuli Capability Maturity Model (CMM). CMM luotiin armeijan projektien prioriteettien mukaan: jos ohjelma epäonnistuisi, ihmisiä kuolisi. Myös se, että projekteja toteutettiin valtion rahoituksella vaati tietyn vastuullisuuden tason kaikilta mukana olevilta tahoilta. Projekteissa arvostettiin riskien pienuutta, standardeja ja sopimuspohjaisia ratkaisuja kehittäjän ja asiakkaan välillä. Muutaman vuoden jälkeen CMM laajennettiin moneksi samankaltaiseski metodologiaksi ja siitä tuli suosittu kansainvälisesti. Suosiossaan monista versioista alkoi olla haittaa, joten Capability Maturiy Model Integration (CMMI) luotiin, joka kokosi monien versioiden puolet yhteen menetelmään. CMMI on plandriven kehitysmalli, joka antaa ohjeet siitä, mitä kehitysorganisaation tulee tehdä ohjelmistontuotantoprosessissaan. [2] CMMI-kehittäminen on kokoelma best practice -tapoja, eli tapoja joiden on todettu olevan paras ratkaisu tietyssä tilanteessa, ja muita kehittämisen toimintoja. CMMI on koko ohjelmiston elinkaaren mukana suunnittelusta toimittamiseen. Metodologia sisältää 22 prosessialuetta, joissa toimintaa on tarkoitus parantaa ja keskittyy siihen. Ajattelumalli on, että kehitysprosessi on se, mikä pitää organisaation hallinnassa ja määrittää sen, miten liiketoimintaa tehdään. Jokaiselle prosessialueelle on määritelty tarkoitus, sekä geneeriset ja spesifiset tavoitteet. [12, s. 12] Spesifiset tavoitteet ovat prosessialuetta koskevia kriteerejä, joiden on täytyttävä, ennen kuin alue on valmis. Esimerkiksi versionhallinnan yksi spesifisistä tavoitteista on: "Baseline-versioilla on oltava hyvä ja ylläpidetty integriteetti." (Baseline-versio on toimiva ohjelmiston versio, johon tulevien käännösten muutoksia voidaan verrata). Spesifisten tavoitteiden saavuttamiseksi CMMI kuvailee toimintatapoja, joilla ne voidaan saavuttaa ja olettaa niitä käytettävän. [12, s. 13] Geneeriset tavoitteet ovat tavoitteita, jotka ovat samoja monen prosessialueen kesken. Ne kuvaavat prosessialueen ominaisuuksia, joiden on täytyttävä, että prosessit käyvät metodologiaan. Geneeriset tavoitteet ovat pakollisia täyttää, jotta prosessialuetta kohdeltaisiin valmiina. Esimerkki geneerisestä tavoitteesta on: "Prosessi on vakiinnutettu määriteltynä prosessina." Geneeristen tavoitteiden saavuttamiseksi CMMI määrittelee geneerisiä toimintatapoja. Sama toimintatapa voi olla käytössä useassa prosessialueessa ja ne ovat luonteeltaan yleisiä. Määritellyt toimintatavat ovat sellaisia, joita pidetään tärkeinä geneeristen tavoitteiden täyttymiseksi. Organisaatio vertaa omia prosessejaan CMMIn prosessialueisiin varmistaakseen menetelmän toiminnan.[12, s. 13] Yllä mainitut CMMIn komponentit muodostavat tasoja. Tasot ovat evolutiivinen tapa kehittää organisaation kehitysprosesseja ja palveluita. Organisaation prosessien ollessa tietyllä tasolla se käy todisteesta siitä, että organisaatio on järjestäytynyt ja voi auttaa esimerkiksi liikekumppanuuksien luomisessa. Tietyn tason saavuttamiseksi organisaation on täytettävä kaikki

12 sitä tasoa vastaavat tavoitteet kehitettävällä prosessialueella. Kypsyystasoja on viisi ja niiden saavuttamisen kriteerit tiukkenevat ja muuttuvat käytännön ongelmien ratkaisusta aktiiviseen kehittymiseen. [12, s.23-26] Ensimmäinen taso kuvaa organisoimatonta toimintaa. Kehitys on kaaottista ja epävakaata. Toinen kypsyystaso on johdettua kehitystä: jotain kehitysprosessia noudatetaan ja työ on hallinnassa. Kolmas taso on hyvin määritellyt prosessit. Organisaatio käyttää tiettyjä prosesseja ja työkaluja tasaisesti kaikkien projektien kesken. Yksittäisen projektin prosessit on räätälöity organisaation omista menetelmistä sopiviksi. Neljäs kypsyystaso tarkoittaa sitä, että organisaatiolla on lukumääräisiä mittareita laadun ja prosessien mittaamiseen. Viidennen tason organisaatio kehittää prosessejaan jatkuvasti tavoitteidensa mittarien mukaisesti. Neljännen ja viidennen tason suurin ero on keskittyminen johtamiseen ja organisaation ylätasojen optimointiin. [12, s ] 4 Menetelmien vertailu Ketterät menetelmät lupaavat asiakastyytyväisyyttä, vähemmän virheitä, nopeampaa tuotantoa ja mahdollistuutta usein muuttuviin vaatimuksiin. Plan-driven menetelmät lupaavat ennustettavuutta ja vakautta. Molemmilla on hyvät puolensa, mutta myös huonot puolensa, jotka voivat johtaa projektien epäonnistumiseen huomioimatta jäädessään. Tämä heijastuu siihen, millaiseeen projektiin kumpikin lähestymistapa sopii. Haasteellisinta on tasapainotella tilanteessa, jossa projektin ominaisuudet eivät ole äärimmäisiä. Silloin paras ratkaisu olisi käyttää molempien lähestymistapojen sopivia osia. Projekti voi käyttää sekä ketteriä, että plandriven menetelmiä suhteessa sen tarpeisiin. [5] Boehm ja Turner esittävät kuusi toteamusta ketterien ja perinteisten menetelmien tasapainottamisesta: 1) Kummastakaan lähtökohdasta ei voida saada kaikenkattavaa ratkaisua. 2) Molemmilla menetelmillä on oma kotikenttänsä, jossa se on selvästi toista vahvempi tapa. 3) Tulevaisuuden ohjelmistonkehitysarviot ennustavat sellaisten sovelluksien, joiden kehittämisessä tarvitaan sekä ketteriä, että perinteisiä toimintatapoja, nousua. 4) Joitain tasapainoisia kehitysmenetelmiä on kehitteillä. 5) On toimivampaa rakentaa kehitysmenetelmänsä alhaalta ylös, kuin karsia kaikenkattavasta metodologiasta itselleen sopivaa. 6) Kehitysmenetelmät ovat tärkeitä, mutta todelliset ratkaisut voivat olla ihmissuhteissa, kommunikaatiossa ja odotusten hallinnasssa. [5]

13 4.1 Yleispätevä menetelmä Frederik Brooks on tutkinut kaikenkattavaa yksittäistä ratkaisua ohjelmistontuotantoon. Hän on päätynyt lopputulokseen, ettei yleispätevää menetelmää voida kehittää, koska ohjelmistojen ominainen vaikeus tekee kehittämisestä aina monimutkaista. Ohjelmiston sisimmäinen olemus on rakennelma limittäisiä abstrakteja käsitteitä, kuten tietorakenteita, alkioiden välisiä suhteita tai algoritmeja. Vaikea osa ohjelmistokehittämisessä on tehdä tämän abstraktin konseptin mukaan vaatimukset, suunnitelu ja testaaminen. Vaikeaa ei ole olemusta vastaavan esityksen tekeminen ja sen toimivuuden testaaminen; kaikki tekevät syntaksivirheitä, mutta ne eivät ole merkittäviä verrattuna käsitteellisiin ohjelmien ongelmiin. Tämän pitäessä paikkansa, ohjelmistotuotanto tulee aina olemaan vaikeaa, eikä yleispätevää tuotantomenetelmää ole. Ohjelmistoilla on neljä luontaista vaikeaa ominaisuutta: kompleksisuus, mukautuminen, muttuvuus ja näkymättömyys. [6] Ohjelmistot ovat monimutkasimpien ihmisen luomien rakennelmien joukossa, sillä yksikään osa ei ole samanlainen kuin toinen, ainakaan lausetasoa ylempänä. Jos ne ovat, ne yhdistetään samaksi rutiiniksi. Tässä suhteessä ohjelmat ovat varsin erilaisia verrattuna tietokoneisiin, rakennuksiin tai ajoneuvoihin, joissa kaikissa on paljon toistuvia elementtejä. Tietokoneet ovat sinällään todella kompleksisia, koska niillä on todella monta erilaista tilaa. Tästä johtuen niiden luominen, kuvaileminen ja testaaminen on vaikeaa. Ohjelmistoilla on vielä monta kertaa enemmän erilaisia tiloja kuin tietokoneilla. [6] Toinen monimutkaisuutta lisäävä seikka on se, että ohjelmiston on mukauduttava kaikkiin sitä ympäröiviin rajapintoihin. Ei voida löytää luonnonlakeja ohjelmistoille, joiden mukaan asiat toimivat: suuri osa kompleksisuudesta on väkinäistä mukautumista ympäristöön. Usein ohjelmiston on mukauduttava, koska se luotiin viimeksi. Toisin siksi, että sen on helpointa mukautua muihin. Kuitenkaan erilaisiin rajapintoihin mukautumisesta syntyvään vaikeuteen ei voi vaikuttaa ohjelmistotuotannon menetelmillä, vaan se on luontaista. [6] Ohjelmistoilla on jatkuvasti paine muuttua. Muutoksia tulee toimittamisen jälkeenkin. Osittain tämä muutosherkkyys johtuu siitä, että ohjelmistoa voi muutta helposti; se on vain informaatiota, eikä materiaa. Onnistuneelle ohjelmistolle löydetään uusia käyttötarpeita myöhemmässä vaiheessa sen elinkaarta, ja näihin vastataan muutoksilla. Ohjelmistot myös kestävät kauemmin kuin niiden käyttöalustat. Uusien tietokoneiden, tallennusmuotojen tai muiden laitteiden vaihtuessa käyttöön ohjelmiston on muututtava ottamaan ne mukaan. [6] Viimeinen ohjelmistontuotannon luontainen vaikeus on ohjelmiston näkymättömyys. Ohjelma on näkymätön, eikä sitä voi visualisoida. Arkkitehti voi piirtää talon piirrustukset, joka havainnollistaa vahavasti sitä, millainen talosta tulee. Ohjelmiston suunnitelmadokumenteista ei näy ohjelmiston toimintaa silmäyksellä. Tämä haittaa ei vain ohjelmiston suunnittelua, vaan myös kommunikaatiota ihmisten välillä ohjelmiston toimintaa koskien. [6] Tässä luvussa tarkasteltiin, miten vaikeaa ohjelmistoa on kehittää. Vaikka ei ole olemassa yksittäistä ratkaisua, joka vastaisi kaikista edellisistä vaikeuksista koostuvaan onglemaan, eri ohjelmistontuotantomenetelmissä on ratkaisuja yksittäisiin vaikeuksiin. Ketterissä menetelmissä pyritään vähentämään muuttuvuuden ja näkymättömyyden tuomia esteitä luomalla yhteisen näkemyksen kehitysryhmän sisällä siitä, millainen ohjelmiston tulee olla. Monesti ketterät

14 menetelmät kariutuvat monimutkaisuuteen ja mukautuvuuteen: ne eivät toimi yhtä hyvin suurissa projekteissa monimutkaisuuden kasvaessa, eivätkä ole yhtä järjestäytyneitä kuin standardeja noudattavat prosessit. [6] Plan-driven menetelmissä ratkaisuna mukautuvuuteen ja näkymättömyyteen on panostaminen yksityiskohtaiseen dokumentointiin. Toisaalta tämä johtaa menetelmien heikkouteen muuttuvuutta vastaan. Dokumentointi, systems of systems -ratkaisut ja organisaation integrointi prosessiin lisäävät menetelmien monimutkaisuutta. Systems of systems on kokoelma tehtäväkohtaisia tai muuten omistautuneita menetelmiä, joita yhdessä käyttämällä pyritään hallitsemaan kokonaistilannetta, luoden yhden todella monimutkaisen, metodien summan.[5] 4.2 Kotikentät Molemmilla kehitysmenetelmillä on oma kotikenttänsä, vaikka harvan projektin ominaisuudet sopivat täysin kumpaankaan. Menetelmän kotikenttä kuvaa sellista projektia, jonka ominaisuudet sopivat täysin kyseisen metodin käyttöön. Kehitysmenetelmän sopivuudella projektin ominaisuuksiin kotikenttien välillä on vaikutus projektin onnistumismahdollisuuksiin. Mitä enemmän projektin tilanne eroaa käytetyn menetelmän kotikentästä, sitä suurempi on projektin epäonnistumisen riski. [7, s.58] Projekteista voidaan ottaa esille useita ominaisuuksia, mutta pääteemat ovat ohjelmiston vaatimukset, projektinhallinta, tekniset ominaisuudet ja projektin henkilöstö [5]. Kehitettävän ohjelmiston vaatimukset ovat tärkeimmässä osassa valittaessa käytettävää kehitysmenetelmää. Ketterässä metodissa ohjelmiston tavoitteena on saada arvoa nopeasti ja olla avoimina muutoksille. Plan-driven metodissa tavoitteena on ennustettavuus ja vakaus. Laajan ohjelmiston, jonka kehittäminen vaatii montaakymmentä ihmistä, kehittämiseen soveltuu parhaiten plan-driven metodit. Pieniin projekteihin taas kuuluvat ketterät metodit. Se, millaiseen ympäristöön ohjelmistoa kehitetään vaikuttaa metodien toimivuuteen. Rauhattomille ja nopeasti muuttuville markkinoille tuotettava ohjelmisto, joka keskittyy yksittäiseen projektiin, on ketterille metodeille edullinen. [5] Projektinhallinnan ominaisuudet vaikuttavat projektin sijaintiin ketterä plan-driven -skaalassa. Kehittäjän suhde asiakkaaseen on yksi näistä ominaisuuksista. Ketteryys vaatii paljon sitoutumista asiakkaalta: omistautuneet, kehityspaikalla olevat asiakkaat ovat ketterään metodiin sopivia. Plan-driven metodissa asiakkaan välistä kanssakäymistä ei tarvita yhtä paljon kuin ketterässä. Asiakas on keskittynyt sopimusehtoihin, kun taas ketterässä asiakas arvostaa priorisointinsa mukaan tapahtuvaa inkrementaalista arvonlisäystä.[5] Projektin teknisistä ominaisuuksista voidaan määrittää alueita, joilla menetelmät ovat toistaan parempia. Projektin vaatimusten ollessa prioritisoidussa järjestyksessä olevia ei-formaaleja tarinoita ja testitapauksia, tai niiden muuttuessa ennakoimattomasti, ketterät metodit ovat parhaiten onnistuvia. Plan-driven metodin parhaan tilanteen näkökulmasta vaatimusten evoluutio on ennustettavissa ja ne ovat virallisesti määriteltyjä. Itse ohjelmiston kehitys on ketterässä kotikentässä yksinkertaista suunnittelua, jota toteutetaan lyhyillä inkrementaatioilla. Refaktoroinnin oletetaan olevat halpaa. Plan-driven metodeissa suunnittelu on laajamittaista ja inkrementit ovat pidempikestoisia. Refaktorointi oletetaan kalliiksi, ja viimeiseen ratkaisuun

15 pyritään ensimmäisellä kerralla. Ohjelmistoa testataan plan-driven metodissa dokumentoitujen testisuunnitelmien ja proseduurien mukaan. Ketterässä metodissa toteutetaan testitapauksia, jotka siten määräävät testauksen kulun.[5] Kotikenttien näkökulmasta on myös tarkasteltava projektin käytössä olevien työntekijöiden ja muiden siihen osallistuvien ihmisten, kuten asiakkaan, ominaisuuksia. Kehitysryhmän kokoonpano voi muuttua projektin aikana. Plan-driven metodi vaatii projektin alussa, sen tärkeimmässä vaiheessa, erittäin osaavan kehitysryhmän joka hallitsee käytettävän prosessin. Myöhemmin prosessin edetessä kehityksessä voidaan toisaalta käyttää vähemmän taitavia henkilöitä, jotka vain tekevät mekaanista työtä. Toisaalta kettärässä kehitysryhmässä kaikkien jäsenten oletetaan olevan cross-functional osaajia, jotka taitavat käytettävän kehitysmetodin. Osaamisen tarve säilyy koko projektin ajan, ja käytettävää menetelmää tuntematonta henkilöä on haasteellista käyttää. [5] 4.3 Tasapaino Kaikki projektit eivät sovi puhtaasti kumpaankaan ohjelmistonkehitysmenetelmään, ketterään tai plan-driveniin. On mahdollista käyttää yhdistelmää ketteristä ja plan-driven menetelmistä saaden paremmat mahdollisuudet projektin onnistumiseen, kuin käyttämällä huonosti projektiin sopivaa menetelmää. Ketterät kehittäjät voivat skaalata projektiaan suuremmaksi ottamalla käyttöön plan-driven menetelmiä tukemaan aiempia tapoja. Plan-driven menetelmiin tottuneet kehittäjät voivat tehdä raskaammista osista kehitystään kevyempiä ketterillä menetelmillä. [8, s.83] On todettava, että ketterien ja plan-driven menetelmien tasapainottaminen ei ole yksinkertainen työ. Joka projektilla on omat ominaisuutensa, johon on räätälöitävä oikeanlainen ratkaisu. Kehitysmenetelmien sekoittaminen ja niiden rajojen ulkopuolella toimiva käyttö vaatii myös kokeneen henkilön, jollaon syvällistä tietoa kaikista projektissa käytettävistä menetelmistä. Epäonnistuminen menetelmien sekoittamisessa voi johtaa koko projektin sekaisin menemiseen ja lopulta kaatumiseen, tai vähintään tehottomaan toiminttaan. [8, s. 97] Ketterän metodin laajemmaksi skaalaamisessa ilman plan-driven menetelmiä kohdataan kolme ongelmaa. Ketterissä kehitysryhmissä iso osa tiedosta on hiljaista ryhmän yksilöiden tietämystä ja sitä ei ole suoranaisesti dokumentoitu. Ohjelmistoa kehitettäessa dokumentointi pysyy kevyenä, eikä tieto ole kaikkien saatavilla. Skaalattaessa ketterää kehitystä laajaan projektiin, tämän tiedon määrä kasvaa liian suureksi muistettavaksi ilman dokumentointia. Ongelma korostuu moninkertaiseksi, jos kehitysryhmän henkilöstö vaihtuu kesken projektin. [8, s ] Toinen ongelma ketterien menetelmien käytössä laajoissa projekteissa on laajuuden luoma tarve saada entistä kokeneempia kehitysryhmän jäseniä. Henkilön on hallittava käytettävä ketterä metodi hyvin, jotta hän osaa poiketa sen rutiineista oikein. Poikkeuksia on tehtävä kohdissa, joissa projektin laajuus estää normaalin ketterän tavan toiminnan, tai tekee siitä vähemmän tehokasta. [8, s ] Kolmas ongelma ilmenee projektin ollessa laaja ja sellainen, jonka muutokset ovat ennustettavissa. Ketteät menetelmät suosivat ohjelmakoodin ja arkkitehtuurin pitämistä mahdollisimman yksinkertaisena; ylimääräisiä asioita ei ohjelmoida varmuuden vuoksi. Joissakin tilanteissa on selvää, että tietynlaisia objekteja tullaan tarvitsemaan monenlaisia, mutta

16 ketterissä metodeissa näitä ei ohjelmoida kuin tarpeen mukaan, vaikka yleisemmän ratkaisun tekeminen olisi helpompaa tulevaisuuden kannalta. Tämä johtaa koodin jatkuvaan refaktorointiin, eli uudelleen kirjoittamiseen, aina uutta sen tyyppistä objektia tarvittaessa. [8, s.88] Ratkaisu näihin ongelmiin on ottaa kehitykseen mukaan joitain plan-driven metodeja helpottamaan keihtyksen laajemmaksi skaalaamista. Hiljaisen tietämyksen taakan jakamiseen voidaan ottaa käyttöön korkean tason arkkitehtuureja, jotka antavat kehittäjille kokonaiskuvan kehitettävästä ohjelmistosta helposti. Toista ongelmaa vastaan voidaan määritellä milestoneja tarkemmin, jotta ohjelmiston osia ei pidetä valmiina niiden ollessa kesken. Kolmatta ongelmaa, yksinkertaisten kehitystapojen haittoja, voidaan helpottaa käyttämällä valmiita suunnittelumalleja ja arkkitehtuurisia ratkaisuja. Tämä onnistuu luonnollisesti ainoastaan ohjelmiston kohdissa, joissa muutokset ovat ennustettavissa. [8, s.89-90] Plan-driven menetelmien virtaviivaistaminen ketterillä tavoilla on ketterien arvojen tuomista hitaan, suunnitellun toiminnan mukaan. Ensimmäinen seikka on ottaa ketteryyden inhimilliset arvot, "Individuals and Interactions over Processes and Tools ", huomioon projektia suunnitellessa. Tyypillisessä plan-driven menetelmässä ihmiset mukautuvat käytettävien prosessien vaatimiin rajoituksiin ja tapoihin. Tämä arvosuhde voidaan vaihtaa toisin päin ja mukauttaa käytettävissä olevat työkalut ja prosessit projektin henkilöstön tarpeisiin. Esimerkiksi tietyt standardit voidaan huomioida, mutta niiden mutta niiden milestonet voidaan mukauttaa käytännöllisiksi. [8, s. 92] Kuva Metodinvalinnan ulottuvuudet [5] Boehm ja Turner ovat määrittäneet viisi akselia, joiden muuttujia tarkastelemalla voidaan tehdä valinta kehitysmenetelmästä. Nämä ovat graafisessa muodossa kuvassa Akselit ovat projektin kriittisyys, koko, työkulttuuri, muutokset ja henkilöstö. Tähdenmuotoinen graafi auttaa hahmottamaan erilaisten projektien suuntauksia nopealla tarkastelulla. Arvioimalla projektia jokaisen akselin suhteen voidaan visuaalisesti kuvata sen suhdetta äärimmäisiin

17 kehitysmenetelmiin. Pieni tähti, jossa projektia vastaavat kunkin akselin arvot ovat sisemmässä osassa graafia, tarkoittaa sitä, että projekti sopii ketterille kehitysmenetelmille täysin. Akselien ulkoreunoilla olevat arvot ovat taas täysin plan-driven menetelmiä vastaavia. Useimmiten käytännön projekteissa nämä arvot eivät vastaa kumpaakaan ääripäätä ja tällöin tarvitaan tasapainoisia menetelmiä. [5] Kriittisyysakseli kuvaa projektin epäonnistumisen seurauksia. Mitä kriittisempi projekti on, sitä vähemmän siinä voidaan tehdä riskejä. Akselin ääripäät ovat epäonnistumisesta seuraava mielipaha ja ihmishenkien menetys. Projektin koko on akseli kolmesta kolmeen sataan ja kuvaa kehitysryhmän henkilömäärää. Ketterät menetelmät suosivat pieniä kehitysryhmiä ja pienen riskin projekteja. Plan-driven menetelmissä epäonnistumisen riski pienenee ja henkilöstön määrällä ei ole vaikutusta. [5] Organisaation työkulttuuri -akseli on abstrakti arvio siitä, kuinka järjestäytynyttä kehitysympäristön kulttuuri on. Plan-driven menetelmät toimivat huonommin ilman kurinalaista organisaatiorakennetta kun taas ketterät kehitysryhmät ovat itseorganisoivia. Projektin muutoksia kuvaava akseli on arvio siitä, kuinka todennäköisesti projektin vaatimukset vaihtuvat kuukauden aikana. On mainittava, että ketterille menetelmille sopii sekä paljon, että vähän muuttuvat vaatimukset, kun taas plan-driven menetelmillä on vaikeuksia reagoida muutoksiin. Projektin henkilöstön akseli kuvaa käytettävät menetelmät taitavien henkilöiden osuutta kehitysryhmässä. Plan-driven menetelmille sopii se, että suuri osa ryhmästä ei ole erityisen kokeneita, se riittää, että mukana on muutama taitava henkilö. Ketterät menetelmät vaativat enemmän metodin tuntevia henkilöitä ja on sitä parempi, mitä vähemmän kokemattomia tekijöitä on. [5] Tilanteessa, jossa projektin ominaisuudet eivät ole yhtenäisesti akselien ääripäiden lähettyvillä, vaan tukevat yhdessä ketterää ja toisessa plan-driven menetelmää, tarvitaan tasapainoisia kehitysmenetelmiä. Ketteriä metodeja voidaan käyttää hyödyksi muuten plan-driven menetelmissä aiemmin mainitulla tavalla, ja plan-driven metodeja ketterissä projekteissa. Seuraavassa luvussa tutkitaan tapaa tehdä projektille räätälöity hybridimenetelmä, joka käyttää molempien lähtökohtien parhaita puolia Riskin mukaan tasapainottaminen Riskin mukaan tasapainottaminen on Boehmin ja Turnerin esittämä käytännön metodi, jossa riskien analyysillä ja yhtenäisellä projektin viitekehyksellä voidaan valita sopivin ohjelmistonkehitysstrategia. Metodissa määritetään ja otetaan huomioon erityisesti ketterään ja plan-driven kehittämiseen yleisesti liittyviä riskejä käyttäen riskianalyysiä. Tämän prosessin tarkoituksena on auttaa organisaatioita ja projekteja käyttämään hyväksi sekä ketterien, että plandriven menetelmien parhaita puolia ja minimoimaan niiden huonommin sopivia ominaisuuksia. Metodi koostuu viidestä vaiheesta: 1) Riskianalyysi, 2) Riskien vertailu, 3) Arkkitehtuurin analyysi, 4) Projektin mukauttaminen, 5) Toteutus ja valvonta. [7] Ensimmäiseksi tehdään riskianalyysi menetelmien tiedettyihin riskialueisiin. Sen tarvitsee myös vastata kysymyksiin siitä, miten tasapainotellaan sen välillä, että tekee tarpeeksi jotain verrattuna liian paljon tekemiseen. Esimerkiksi kysymyksiin, kuten "Paljonko testausta on tarpeeksi?" tai "Kuinka paljon suunnittelua ja arkkitehtuuria on tarpeeksi?" on vaikea vastata, mutta se on

18 tehtävä menetelmän valitsemiseksi. [8, s.100] Riskianalyysissä arvioidaan projektin ympäristöä, ketteryyttä ja plan-driven memetelmiä koskevat riskit. Mikäli näistä ei päästä varmuuteen, voidaan lisää informaatiota ostaa tekemällä prototyyppejä, keräämällä käyttäjädataa ja -analyysillä. Vaikka riskianalyysi ei ole helppo tehtävä, se luo perustan päätöksenteolle kehityksen strategiasta myöhemmin prosessissa. Mainituista kolmesta riskikategoriasta tarkastellaan etukäteen valittuja kandidaattiriskejä. Riskianalyysiä tehdessä on huomioitava, että kandidaattiriskit ovat vain yleisiä riskejä huomioitavaksi. Aina ne eivät sovi projektin tilanteeseen, ja aina ne eivät ole riittäviä tarkasteltavaksi. Riskianalyysi riippuukin paljon kyseessä olevasta projektista, eikä siihen voida antaa täysin valmista vastausta. [8, s.103] Seuraavassa luettelossa on kunkin kategorian kandidaattiriskit: Projektin ympäristöä koskevat riskit: Teknologiassa on epävarmuuksia. Projektilla on monta erilaista osakasta, joita on koordinoitava. Projekti koskee monimutkaisia systems of systems -ohjelmistoja Ketteryyteen liittyvät riskit: Projekti on kriittinen, eikä siinä saa olla virheitä. Projekti on erittäin laajamittainen. Ketterän kehityksen yksinkertaisesta suunnittelusta seuraavat ongelmat, kuten tarve tehdä ohjelmiston osien suunnittelua etukäteen Ketterä kehitys on riippuvainen kehitysryhmän sisäisestä tiedosta, eli jos projektin henkilöstö on erittäin vaihtuvaa, tämä voi olla ongelma. Kehitysryhmässä ei ole tarpeeksi ihmisiä, jotka ovat taitavia ketterissä menetelmissä. Plan-driven menetelmien riskit: Projektin vaatimukset ovat jatkuvasti muutoksen alaisina. Projektilla on tarve saada aikaan nopeita tuloksia. Ohjelmistosta voi nousta uusia vaatimuksia, kun käyttäjät pääsevät tutustumaan sen käyttöön. Kehitysryhmässä ei ole tarpeeksi ihmisiä, jotka ovat taitavia plan-driven menetelmissä. [8, s ] Riskien kartoittamisen jälkeen on analysoitava niiden tulokset. Prosessin vaihe kaksi on kolmisuuntainen valintatilanne, josta päätetään, tehdäänkö projekti ketterien, plan-driven, vai tasapainoisen menetelmän mukaan. Mikäli kaikki projektin riskit viittaavat siihen, että projekti sopii täysin ketterällä tai plan-driven metodilla tehtäväksi, on strategiaksi helppo valita kyseinen menetelmä. Mikäli projekti on tämänlainen, prosessin kolmas vaihe jätetään välistä ja jatketaan suoraan neljänteen vaiheeseen. Tilanteessa, jossa projektissa todetaan riskejä molemmissa menetelmissä, on parasta käyttää tasapainoitettua strategiaa. [8, s.103]

19 Vaihe kolme on siis projektille, jota ei voi luokitella kumpaankaan menetelmään täysin, tai sillä on vakavia riskejä eri alueilta. Mikäli on mahdollista, kehitetään ohjelmiston arkkitehtuuri, jota voidaan kehittää ketterien menetelmien avulla niillä osa-alueilla, joilla niiden vahvuuksia voidaan hyödyntää, mutta samalla minimoiden niihin liittyvät riskit. Plan-driven menetelmiä käytetään jäljelle jäävään työhön ja niitä kohdellaan oletusmenetelminä alueilla, joille ei voida luoda sopivaa arkkitehtuuria. Mikäli tässä vaiheessa nousee esiin uusi riski, jota ei riskianalyysissä huomioitu, prosessissa voidaan palata askeleita taaksepäin tarpeen mukaan. [8, s.104] Ennen arkkitehtuurin luomista, koska suunnitteleminen maksaa, on vastattava kysymykseen: "Kuinka paljon suunnittelua on tarpeeksi?" Käytännössä on arvioitava kahta riskiä vastakkain. Tarkastellaan onko liian vähäisen suunnittelun seuraus pahempi menetys, kuin suunnitteluun käytetyn ajan ja rahan tuoma markkinaikkunan pieneneminen. Liian vähästä suunnittelusta seuraa jo valmiin työn uudelleen tekemistä. Projekteissa, joissa aikataulu on tiukka, ei ole varaa tehdä työtä moneen kertaan. Kriittisessä projektissa, jossa epäonnistumisella on vaaralliset seuraukset, arkkitehtuurin virheillä on seurauksia. Yleisesti ketterät riskit tukevat enemmän suunnittelua ja plan-driven riskit päinvastoin. Toisaalta suunnitteluun käytetystä ajasta johtuva riski nousee siitä, jos arkkitehtuurin pitää olla todella ykstyiskohtaisia, koska muutosten sisällyttäminen siihen on vaikeaa. [8, s ] Vaihe neljä on projektin mukauttaminen todettuihin riskeihin ja valittuun menetelmään. Tasapainoisessa strategiassa projektin runko voi noudattaa jotain plan-driven metodologiaa, jos sen heikkouksiin vastataan ketterillä menetelmillä. Tärkeintä on tehdä riskienhallintastrategia, joka ottaa huomioon prosessin alussa todetut riskit. Jokainen riski on huomioitava, mutta niille tehtävän hallintastrategian ei välttämättä ole pakko olla monimutkainen. Tämän vaiheen yksityiskohdat ovat pääosin riippuvaisia kehitysorganisaation resursseista ja johtajien kokemuksesta. Esimerkiksi projekti, jonka vaatimukset muuttuvat paljon, voi rakentaa plandriven ohjelmistorungon arkkitehtuurin muutoksia sietäväksi ja tuottaa siihen sisälletyt moduulit ketterillä ryhmillä. Riskienhallintastrategiat voivat myös olla ihmisten välisiä pehmeitä ratkaisuja. Riskiä siitä, että projektin tärkeimpiä ihmisiä lähtee pois kesken työn ja jättää projektin pulaan, voidaan vähentää esimerkiksi tarjoamalla bonuksia projektin valmistumisesta. [8, s ] Viimeinen vaihe prosessissa on käytännön toteutus ja sen valvonta. Prosessi soveltaa ketterää tapaa tarkastella kriittisesti omaa toimintaa ja pyrkiä parantamaan sitä mahdollisimman usein. Koska yksikään arviointi tai päätös ei ole hyvä joka tilanteessa, projektista vastaavien tarvitsee koko elinkaaren ajan valvoa ja arvioida edellä tehtyjen ratkaisujen toimivuutta. Mikäli ongelmia havaitaan, voi olla pakko palata taaksepäin ja suunnitella uudelleen niitä aiheuttava kohta. Tärkeää on se, että muutokset, jos niitä on tehtävä, toteutetaan mahdollisimman nopeasti, jolloin niistä seuraava haittakin on pienempi. [8, s ] Toiminnan tarkastelusta voi myös seurata positiivisia asioita. Valvomalla ohjelmiston kehittymistä saattaa huomata uusia mahdollisuuksia tuottaa enemmän arvoa asiakkaalle, tehdä toiminnasta tehokkaampaa ja nopeampaa, tai muita tapoja parantaa organisaation toimintaa. [8, s ]

20 4.3.2 Scrum ja CMMI Scrum ja CMMI ovat todella erilaisia menetelmiä, mutta ne voivat silti sopia samaan projektiin yhdessä ja olla synergisiä. Projektissa, jossa plan-driven menetelmään sopivaa runkoa halutaan virtaviivaistaa ketterillä metodeilla, Scrum ja CMMI voivat toimia. On fakta, että CMMI määrittää prosessialueet todella yksityiskohtaisesti ilman paljoa tulkinnanvaraa. [2] Paras tapa käyttää CMMItä on kohdella sitä prosessien mallina, eikä suoranaisena kehitysmenetelmänä. CMMI ei määrittele miten prosessin toiminta tehdään, vaan se kertoo, mitä organisaation on tehtävä projektin toimimiseksi. Projekti voisi hyvinkin käyttää Scrumia lähes kokonaisuudessaan CMMIn ohella. Scrum määrittelee muutaman toimintatavan ja henkilöstön roolit, sekä tiettyjen dokumenttien käytön. Näitä ei estetä CMMIn määrityksissä lainkaan. [2] CMMI voidaankin nähdä kokoelmana mallitoimintatapoina, enemmän teoreettisena mallina, joka on tehty tutkimuksen perusteella. Näin CMMI on konsepti, josta opitaan ja jota sovelletaan oikeisiin käytännön tilanteisiin. Tämä ajatus näkyy myös tavassa, jolla CMMIn prosessit ovat kirjoitettu. Ne ovat abstraktimmalla tasolla, kuin tavallinen toimintatavan kuvaus. Toisaalta ketteristä menetelmistä, kuten myös Scrumista, puuttuu korkean tason määrittelyjä. [2] Käytännössä siis Scrumin ja CMMIn yhdistelmämenetelmä on ketterää Scrum kehitystä, jossa käytetään jonkin verran aikaa ja resursseja CMMIn vaatimusten toteuttamiseen. Mikäli tavoitteena on saada korkeampia kypsyystasoja, on käytettävä paljonkin huomiota organisaation toiminnan kehittämiseen. Plan-driven vaikutteista saadaan ryhtiä ja paremmin ketteriä riskejä kestävää toimintaa. Myös monet CMMItä käyttävät organisaatiot ovat nykyään ottaneet ketteriä kehitysryhmiä tekemään käytännön työtä. [2]