Ketterät metodologiat ohjelmisto start-upin näkökulmasta

Transkriptio

1 T Ohjelmistotuotannon seminaari Kevät 2002: Agile Software Development Ketterät metodologiat ohjelmisto start-upin näkökulmasta Samppa Turunen, 49121H

2 EXECUTIVE SUMMARY Ongelma: Ovatko ketterät metodologiat sopivia start-upille? Start-upin kuvaus 1) kypsymättömyys 2) rajalliset resurssit 3) tasaisen tulovirran puute 4) sijoittajien aiheuttama ulkoinen paine 5) epävakaa ympäristö. Työskentely on määrittelemätöntä ad hoc tyyppistä soveltamista. Mahdollisesti myös asiakas puuttuu, mikä vaikeuttaa vaatimusten määrittelyä. Start-up voi myös kasvaa nopeasti ja ihmisten roolit ja toimenkuvat muuttuvat nopeasti. Kaiken tämän lisäksi start-upilla saattaa olla vain yksi mahdollisuus, joten epäonnistumiselle tai kokeilulle ei ole varaa. Start-up asettaa näin omalaatuisuudellaan monia kriteerejä metodologialle. Yleisesti ketterien metodologioiden luonne ja lähestymistapa on hyvinkin sopiva startupille. Crystal Clear Ihmislähtöinen lähestymistapa. Ryhmä määrittelee toimintatapansa ja kehittää metodologiaa sitä kautta. Hyvä skaalautuvuus ja helppo omaksuttavuus. Scrum Minimi kaaoksen hallinta. Sopii esimerkiksi tuotekehitysprojekteihin, joissa tulevaisuus saattaa olla hyvinkin epäselvä. Erittäin kevyt ja helposti omaksuttavissa, joten erittäin hyvä vaihtoehto etenkin pienelle start-upille. FDD Toiminto kerrallaan kokonaisuuden mallin ohjaamana. Sopii esimerkiksi räätälöityjen sovellusten kehitysprojekteihin, joissa asiakas on mukana. Se on joustava ja tarjoaa sopivasti suunnitelmallisuutta sekä muutoksen hallintaa. DSDM on maksullinen ja sen maastouttamisessa voi olla hankaluuksia ilman koulutusta. Näin ollen se on melko kaukana start-upin tarpeista. XP Aggressiivinen, kurinalainen ja asiakasta korostava. Kokonaisuudessaan XP on useiden start-up yritysten resurssien ja tavoitteiden ulkopuolella. Mikään metodologia ei toimi sellaisenaan, vaan aina ne täytyy muokata tilanteen mukaan sopiviksi. Eri metodologioiden ajatusten ja käytäntöjen yhdisteleminen tuo tarvittavat ja sopivat osat yhteen. Metodologian valintaan vaikuttaa myös yrityksen arvot ja ihmisten asenteet, tuotteen sovellusalue ja monet muut seikat, jotka tulee ottaa huomioon. Ketterissä metodologioissa on selvää potentiaalia. 2

3 SISÄLLYSLUETTELO 1 JOHDANTO TAUSTA ONGELMA TAVOITTEET RAJAUS TOTEUTUS RAPORTIN RAKENNE START-UP YRITYS KUVAUS JA KARAKTERISOINTI KRITEERIT METODOLOGIALLE VALINTAAN VAIKUTTAVAT TEKIJÄT METODOLOGIOIDEN LUPAUKSET JA MAHDOLLISUUDET PÄRJÄÄKÖ ILMAN PROSESSIA? KETTERÄT METODOLOGIAT KETTERIEN METODOLOGIOIDEN LYHYET ESITTELYT Extreme Programming (XP) Crystal Clear Scrum Feature Driven Developement (FDD) Dynamic Systems Developement Method (DSDM) LUOKITTELU JA LAJITTELU FRONT-LOADED, BALANCED JA BACK-LOADED SUUNNITTELUN LÄHTÖKOHDAT SKAALAUTUVUUS KURI JA SUVAITSEVAISUUS START-UPIN KRITEERIT ERI METODOLOGIOITTAIN YHTÄLÄISYYDET JA EROT START-UPIN VALINNAT YHDISTELMÄT MISTÄ LÄHTEÄ LIIKKEELLE? XP:n ensimmäiset käytännöt YHTEENVETO JA PÄÄTELMÄT LÄHDELUETTELO

4 1 JOHDANTO 1.1 TAUSTA TKK:n Seminaarikurssin aiheena oli keväällä 2002 ketterät prosessit. Valitsin aiheen henkilökohtaisen kiinnostuksen ja kokemuksen takia. Olen työskennellyt kahdessa hyvin erilaisessa start-upissa, joissa sovellettiin ad hoc, eli sen tarkemmin määrittelemätöntä prosessia. Havainnot ja päätelmät perustuvat siis osittain myös omiin kokemuksiin. Toivon tästä olevan ainakin jotain hyötyä uusille ohjelmistotuotannon yrityksille. 1.2 ONGELMA Millainen on start-up yritys, mitkä ovat sen tarpeet ja tyypillisimmät ominaisuudet? Millaisia vaatimuksia start-up yrityksen erityispiirteet asettavat prosessille? Ovatko ketterät metodologiat sopivia start-upille? Mitä start-upin tulisi huomioida ketterää metodologiaa valitessa? Näihin kysymyksiin vastaaminen auttaisi ehkä parantamaan tehokkuutta ja ennakoimaan tulevaisuuden ongelmatilanteita. Prosessien kehittämisen lähtökohtana on yleensä jokin ongelma tai vaikeus, jota metodologian tekniikoilla yritetään korjata. Esimerkiksi kommunikaatio eri sidosryhmien kesken. Näitä ongelmia ei välttämättä start-up yrityksessä pääse syntymään, mutta silti joistain metodologioista saattaisi olla hyötyä niin motivaation kuin tehokkuudenkin kannalta. Ketterät prosessit ovat kaikkein lähimpänä pienten start-up yritysten tarpeita joustavuutensa ansiosta, tai niin ainakin saattaisi luulla. Usein jo sana prosessi saa työntekijät takajaloilleen peläten työmäärän ja sääntöjen lisääntyvän ja avoimen ilmapiirin katoavan. Ketterät prosessit ovat kuitenkin kaikkea muuta kuin paperisotaa 4

5 ja niiden mahdollisuudet start-up yrityksissä jää usein huomaamatta. Onko niistä kuitenkaan mitään käytännön hyötyä, kun maastouttaminenkin saattaa olla hankalaa ja resurssit ovat rajalliset? Yleensä pienet start-up yritykset eivät määrittele prosessejaan kovinkaan tarkasti ja osa syynä tähän lienee eri metodologioiden vaikea vertailtavuus ja resurssien sekä motivaation puute. Yksi metodologia ei välttämättä sellaisenaan myöskään ole paras, vaan kaikki prosessit tulisi mukauttaa yrityksen tilanteeseen ja tarpeisiin. Start-up yritykset eivät kuitenkaan aina voi ennakolta tietää tarpeitaan ja siten kokeileminen voi olla turhauttavaa ja valinnan tekeminen vaikeaa. 1.3 TAVOITTEET Tavoitteena on selkiyttää metodologioiden taustoja, ominaisuuksia ja eroja sekä kartoittaa niiden soveltuvuutta start-up yritysten ominaisuuksista johdettuihin kriteereihin. Toisaalta ketterät prosessit lupaavat paljon ja tavoitteena onkin selvittää miten hyvin ne ovat toimineet käytännössä ja mitä start-upin tilanne tarkastelun lähtökohtana vaikuttaa metodologioiden soveltuvuuteen. Pyrkimyksenä olisi tuottaa heuristiikkaa start-up yrityksille prosessin valinnan ja muokkaamisen avuksi. Metodologiat ovat kokonaisuuksia, jotka koostuvat toisiaan tukevista toiminnoista ja tavoitteena on etsiä valintaan vaikuttavat piirteet ja esitellä prosessit objektiivisesti pienen start-up yrityksen perspektiivistä. 1.4 RAJAUS Näkökulman asettava pieni start-up yritys on kooltaan noin 4-20 henkilöä. Olen rajannut tutkimuksen ulkopuolelle asiat, jotka kyllä vaikuttavat metodologian sopivuuteen, mutta eivät ole juuri start-upille ominaisia. Esitän kuitenkin joitain yleisiä 5

6 huomioita metodologian valintaan vaikuttavista tekijöistä kokonaisuuden hahmottamiseksi, mutta en keskity niihin tarkasti. Laajuuden vaikutusta olisi tutkittava tarkemmin ja koska se ei ole juuri start-upin kannalta kriittistä, vaikkakin merkityksellistä, olen sivuuttanut sen tästä tutkimuksesta. Tutkimuksen kohteena ovat seuraavat ketterät metodologiat: Extreme Programming (XP), Scrum, Dynamic Systems Developement Method (DSDM), Crystal Clear (Crystal Methodologies) ja Feature Driven Developement (FDD). Ne ovat määriteltyjä ja dokumentoituja sekä niistä on olemassa tarkasteluun sopivia kokemuksia. Martin Fowlerin mukaan (Fowler, 2001) Jim Highsmith on ilmoittanut, että Adaptive Software Developement (ASD) yhdistetään Crystal Methodologies -perheeseen, eikä sitä siten tarkastella tässä erillisenä metodologiana. RUP on Fowlerin mukaan (Fowler, 2001) raskaamman sarjan metodologia, vaikkakin kevennettävissä, eikä siten ole otettu mukaan tähän tutkimukseen. Mukana olevat metodologiat edustavat ketteriä prosesseja melko laajasti, joskaan kaikista ei ole yhtä kattavaa kokemusten dokumentointia ja vertailua saatavilla. Tarkoituksena ei ole kattaa kaikkia mahdollisia ketteriä metodologioita vaan esitellä tyypillisimmät ja niiden avulla havainnollistaa ketterien metodologioiden soveltuvuutta start-upille. 1.5 TOTEUTUS Olen kerännyt kokemusraportteja sekä vertailevia artikkeleita ja tehnyt niiden pohjalta kirjallisuustutkimuksen. Eri prosessien kokemusraportit ovat yleensä sovitettu aluksi yhden projektin mittaisiksi tai yhdelle tiimille, jolloin ne myös soveltuvat tutkimuksen aineistoksi. Pienten yritysten ja etenkin start-upien koko toiminta saattaa olla vain yksi projekti tai yksi tiimi. Tällöin on kuitenkin arvioitava kokemuksia vain soveltuvin 6

7 osin ja huomioitava esimerkiksi projektin ulkopuolisten resurssien rajallisuus ja muut pienen yrityksen ja start-upin väliset erot. Osa käsiteltävistä asioista on hyvin spekulatiivista ja olen käyttänyt omaa kokemusta ja intuitiota osaksi ratkaisujeni taustalla etenkin start-up yrityksen luonnetta analysoitaessa. Pyrkimys on kuitenkin olla mahdollisimman objektiivinen. 7

8 2 RAPORTIN RAKENNE 3 START-UP YRITYS Sart-upin kuvaus ja karakterisointi, sekä niistä johdettavat vaatimukset metodologialle. 4 METODOLOGIOIDEN LUPAUKSET JA MAHDOLLISUUDET Metodologioiden käytön motivointi, ketterien prosessien vertailu Startupin näkökulmasta. 5 LUOKITTELU JA LAJITTELU Metodologioiden lajittelu eri tyyppeihin ja erojen sekä yhtäläisyyksien kuvaus. 6 START-UPIN VALINNAT Pohdiskelu metodologioiden luokituksen ja start-upin karakterisoinnin perusteella. 7 YHTEENVETO JA PÄÄTELMÄT 8

9 3 START-UP YRITYS 3.1 KUVAUS JA KARAKTERISOINTI Stanley M. Suttonin mukaan Start-up yrityksillä ei saata olla tuotetta, asiakaskuntaa eikä tasaista tulovirtaa, mitkä korostavat innovatiivisen, nopeatempoisen ja reaktiivisen ohjelmistotuotannon piirteitä. Omalla tavallaan nuoruus ja kypsymättömyys, rajalliset resurssit sekä useat ulkopuoliset vaikuttajat erottavat start-up yrityksen pienistä tai vakiintuneista yrityksistä. (Sutton, 2000) Ohjelmistotuotannolle tyypillinen piirre on ajan riittämättömyys ja tuotteet pyritään valmistamaan mahdollisimman nopeasti. Ulkoisista vaikuttajista rahoittajat tuovat suurimman paineen tehdä tulosta nopeasti ja pienen yrityksen rajallisilla resursseilla toimiva start-up on kovassa puristuksessa. Ensimmäisten projektien onnistuminen saattaa myös olla kriittistä jatkon kannalta, joten kokeiluun ei välttämättä ole varaa. Ohjelmistotuotanto on jatkuvasti kehittyvän tekniikan juoksupyörässä ja tuotannon suunnittelu tulevaisuutta silmällä pitäen on tärkeää. Kuitenkin alan jatkuva muuttuminen estää tarkkojen suunnitelmien tekemisen ja moni yritys onkin tilanteessa, jossa välttämättä ei tiedetä mitä edes ensi vuonna tehdään. Tätä voidaan kai pitää myös positiivisena reagointinopeutena, mikä on haastavaa myös tuotantoprosessille ja metodologialle. Suttonin mukaan (Sutton, 2000) start-up yritysten nuori ikä, vähäinen karttunut kokemus, sekä historian puute näkyy sekä yrityksen prosessikyvykkyydessä että itse organisaatiossa. Kokemusaineisto tai vertailu, jossa metodologiaa on sovellettu kohtalaisen pieneen yritykseen, suhteellisen pieneen projektiin tai tiimiin voidaan arvioida myös start-upin 9

10 näkökulmasta. Tällöin on kuitenkin huomioitava edellä mainitut start-upin erot verrattuna pitkään alalla toimineeseen. Wardin mukaan prosessin kehittäminen isoissa yrityksissä pyrkii parantamaan tehokkuutta ja luotettavuutta vähentäen samalla kustannuksia. Pienille organisaatioille tällä ei kuitenkaan Wardin mukaan ole merkitystä. (Ward et al., 2001) Taulukko 1, Start-up yrityksen ominaisuudet Yleiset ominaisuudet: Kypsymättömyys Rajalliset resurssit Ei tasaista tulovirtaa Kiire ja ulkoinen paine Pieni dynaaminen tiimi Mahdollisesti myös: Ei asiakasta Muuttuvat roolit Nopeasti kasvava Ei varaa epäonnistua tai kokeilla Prosessia ei määritelty 3.2 KRITEERIT METODOLOGIALLE Kehitettävän ohjelmistotuotteen ominaisuudet, käyttökohteen kriittisyys ja vaadittava laatu vaikuttavat myös metodologian vaatimuksiin. Yrityksessä työskentelevien henkilökohtaiset tottumukset vaikuttavat pienen yrityksen tuotantoprosessiin voimakkaasti ja työntekijöiden tavat ja rutiinit muokkaavat osaltaan yrityksen mahdollisesti vielä määrittelemättömän prosessin. Wardin mukaan ohjelmistoyritys elää jatkuvassa muutoksessa ja prosessi, jolla ohjelmistoa tuotetaan muuttuu jatkuvasti tilanteen mukaan. Metodologiat painottavat eri asioita, joista jotkin soveltuvat start-upille paremmin ja toisten toteuttamisessa saattaa taas olla selviä vaikeuksia resurssien rajallisuuden ja esimerkiksi asiakkaan puutteen takia tai metodologian vaatiman kouluttajan 10

11 puuttuminen. Prosessin pitäisi näin ollen mukautua erilaisiin tarpeisiin ja ihmisiin, sillä varaa ihmistyyppien valintaan tai ihmisten vaihtamiseen ei useinkaan ole, ja asenteiden sekä tottumusten muuttaminen saattaa olla hankalaa. Koulutus voi olla monelle start-upille kaukainen haave taloudellisesti tärkeämpien asioiden mennessä edelle. Metodologian tulisi siksi olla helposti omaksuttavissa ja otettavissa käyttöön ilman suuria investointeja koulutukseen tai opetteluun. Hyväksi havaittu lähestymistapa lienee kehittää prosessia vähän kerrassaan ja motivoida ihmiset muutoksen vastaanottamiseen. Start-upissa nämä asiat voivat olla kuitenkin melko helppoja ratkaista, koska henkilöstö on omistautuneisempaa ja sitä on mahdollisesti vähemmänkin. Joten start-upissa metodologian käyttöön ottaminen kokonaisuudessaan ja kerta heitolla saattaa onnistua helpostikin, jolloin metodologian toisiaan tukevat toiminnot toimivat paremmin. Toisaalta henkilökunnan roolit ja vastuualueet vaihtelevat nopeasti ja uuden metodologian maastouttaminen saattaa vain entisestään vaikeuttaa tilannetta. Jos kokonaisvaltaiseen muutokseen ei ole varaa, kannattanee purkaa eri vaihtoehdot osiin ja valita niistä sopivimmat tekniikat ja ajatukset käyttöönotettaviksi. Cockburn esittää (Cockburn, 2000a, s.143) mm. seuraavia kysymyksiä metodologian arvioinnille: 1) Kuinka nopeasti metodologia sallii ihmisten vaihtumisen ja koulutuksen? 2) Kuinka suuri vaikutus sillä on myynti prosessiin? 3) Kuinka paljon se antaa ihmisille vaputta? 4) Kuinka nopeasti se sallii reagoinnin muuttuviin tilanteisiin? 11

12 Taulukko 2, Kriteerit metodologialle Ominaisuus: Kypsymättömyys Rajalliset resurssit Ei tasaista tulovirtaa Kiire ja ulkoinen paine Kriteeri: Luo uskottavuutta Edut nähtävissä heti, joustava, kevyt Edullinen, ei vaadi koulutusta Nopea ja varma tulos, laadunvarmistus Ei asiakasta Muuttuvat roolit Nopeasti kasvava Ei varaa epäonnistua tai kokeilla Prosessia ei määritelty Ei liian riippuvainen asiakkaasta Mukautumiskykyinen, ihmisläheinen Skaalautuu kasvun mukana Suunnitelmallisuutta, laadunvarmistus Helppo omaksua ja maastouttaa 3.3 VALINTAAN VAIKUTTAVAT TEKIJÄT Kokonaiskuvan muodostamiseksi esittelen joukon muita valintaan vaikuttavia tekijöitä. Nämä eivät kuitenkaan ole juuri start-upille ominaisia, joten en ole ottanut niitä kriteereiksi metodologioita vertailtaessa. Nämä on kuitenkin hyvä ottaa huomioon lopullista arviointia tehtäessä. Kuten kaikkeen ihmisten tekemään työhön, persoonallisuudet, ihmisten välinen dynamiikka ja henkilökohtaiset tarpeet, tavoitteet ja halut vaikuttavat metodologian soveltuvuuteen (Cockburn, 2001) ja väärä valinta saattaa aiheuttaa ylimääräistä kitkaa ja resurssien menetyksiä. Ohjelmistoja on myös monenlaisia projektin luonne vaihtelee: www, lääketiede, 12

13 wireless, pelit, embedded, ym. Osassa merkittävä kriteeri on ehdoton laatu ja virheettömyys, kuten lääketieteen sovellukset. Toisissa etusijalla on käyttäjäystävällisyys, kuten esimerkiksi peliteollisuus ja www-sovelluskehitys. Uusien tekniikoiden sovellukset kilpailevat kuluttajien mielenkiinnosta ja käytön helppous sekä toiminnan vakuuttaminen ovat onnistumisen kannalta tärkeitä. Granville Millerin (Miller, 2001) mielestä käytettävä ohjelmointikieli vaikuttaa metodologian valintaan. Esimerkiksi ohjelmointikielenä C++ tarvitsee tarkempaa suunnittelua etukäteen etenkin suuremmissa järjestelmissä. Metodologian valintaan vaikuttavat myös seurattavat standardit, vaadittava laatu, sekä valitut työkalut, joihin on sijoitettu rahaa. Jos tuotanto on hyvin suoraviivaista standardin toteuttamista, ei luovaa ja idearikasta metodologiaa välttämättä tarvita. Start-upin tilanne on kuitenkin usein toinen ja idearikas ja avoin ympäristö saattaa olla eduksi. 4 METODOLOGIOIDEN LUPAUKSET JA MAHDOLLISUUDET Alistair Cockburn määrittelee (Cockburn, 2000a, s. 101) metodologian olevan kaikki se mitä yritys tekee saadakseen ohjelmistotuotteen markkinoille. Kaikilla organisaatioilla on metodologia, mutta vain harvat vaivautuvat kirjoittamaan sen ylös. Tämä lienee tavallista juuri start-up yrityksissä, joissa muita toimintoja pidetään helposti tärkeämpinä. Kommunikointia pidetään jopa itsestään selvyytenä, ja järjestetyt tapaamiset ja kokoukset saattavat vaikuttaa turhilta. Vaatimusmäärittely on hankalaa, sillä asiakasta ei välttämättä edes vielä ole ja sen tarpeiden arvailu saattaa olla vaikeaa. Erillisen testausorganisaation puuttuessa testauksesta tulee välttämätön paha ja yleensä se jää ohjelmoijan itsensä harteille, jolloin testausta ei välttämättä edes 13

14 tehdä kunnolla saati suunnitella. Tähän ongelmaan, monien muiden asioiden lomassa, metodologiat lupaavat parannusta mm. jatkuvan testauksen ja seurannan avulla. 4.1 PÄRJÄÄKÖ ILMAN PROSESSIA? Ilman prosessia ei voi toimia, mutta monet yritykset toimivat hyvinkin ilman prosessin virallista määrittelyä. Cockburn perustelee (Cockburn, 2000a, s ) metodologian tarpeen ja edut seuraavasti: 1) Se kertoo miten teemme täällä töitä, jolloin se toimii apuna uusia työntekijöitä tutustuttaessa prosessiin 2) Se toimii apuna ihmisten vaihtuessa ja esimerkiksi alihankinta suhteissa tehokkaana toimintatapojen selvittäjänä. Start-upissa ihmisten vaihtuvuus saattaa olla nopeaa ja toimintatapojen selkeys säästää vähäisiä resursseja. 3) Se selventää toimenkuvia ja vastuita. Tämä voi olla hyvinkin merkittävää tuoreessa organisaatiossa, jossa muutoksia organisaation rakenteessa tapahtuu usein ja tehtävät saattavat olla epäselviä. 4) Se vakuuttaa sponsorit. Tämä perustelu on Cockburnin mukaan syypää paksujen prosessimäärittelykansioiden rakentamiseen. Yrityksen ulkopuolisella taholla, esimerkiksi asiakkaalla, on luonnollinen refleksi pitää painavampaa prosessia turvallisempana. Uskottavuus olikin yksi start-upin asettamista kriteereistä metodologialle. 5) Se osoittaa näkyvää edistymistä. Metodologian tuottaman raportointi aineiston avulla projektin eteneminen on helppo osoittaa esimerkiksi asiakkaalle tai johdolle. Start-upin on hyvä tietää miten projekti etenee, jotta nopea reagointi olisi mahdollista 14

15 ja kohtalokas epäonnistuminen voidaan välttää. 6) Kun metodologiat ja tekniikat nimetään, niiden ympärille perustaa kursseja ja opettaa niitä tietoja ja taitoja, joita niissä tarvitaan. Näin metodologian määritteleminen toimii pohjana myös koulutukselle ja jatkokehitykselle. Näistä syistä mielestäni voidaan pitää metodologian olemassa oloa hyödyllisenä etenkin start-upille. Toisaalta, jos metodologia vie liikaa kriittisiä resursseja ja jos määritteleminen tehdään huolimattomasti, saattaa siitä olla vain haittaa. 4.2 KETTERÄT METODOLOGIAT Martin Fowler näkee ketterissä metodologioissa kaksi avain ajatusta: Ne ovat enemmän mukautuvia kuin ennustavia ja ne keskittyvät enemmän ihmisiin kuin prosesseihin. (Fowler, 2001) Highsmithin mielestä (Highsmith et al., 2001) ketterät metodologiat painottavat kahta ideaa: 1) Toimiva koodi kertoo totuuden mitä asiakas lopulta saa. 2) Hyväntahtoinen ryhmätyö on erittäin tehokasta. Ketteryys on siis tiivistä ryhmätyöskentelyä iteratiivisessa ja mukautuvassa prosessissa. Myös välittömän kommunikaation korostaminen ja etenkin nopea palaute on monelle ketterälle metodologialle ominaista. Asiakas on tärkeässä asemassa määrittelemässä vaatimuksia ja lopulta antamassa tavoitteet laadulle ja hyväksynnän lopputuotteelle. Ketterät metodologiat luottavat paljolti ihmisten taitoihin suunnittelijoina, ohjelmoijina ja osaajina. Suunnittelijoita ei erotella tekijöistä vaan korkeamman tason suunnittelijat laskeutuvat ohjelmoijan rinnalle ja ohjelmoija osallistuu suunnittelemiseen. Koulutus ja muut seikat ovat jätetty miltei kokonaan huomioimatta ja luotetaan osaavien ihmisten kouluttavan toisiaan. Ihmiset on siis otettu etusijalle ja turhaa 15

16 dokumentaatiota vältetään. Suunnittelu ja toteutus ovat iteratiivisia, eli kokonaisuutta kasvatetaan toiminnallisuus kerrallaan. Tehtäviä ei suunnitella tarkasti vaan huomio kiinnitetään toiminnallisuuksien toteuttamiseen (Highsmith & Cockburn, 2001). Iteraatiot ovat yleensä nopeita, 2-6 viikkoa ja toteutettavat toiminnallisuudet priorisoidaan dynaamisesti. Asiakas on tiiviissä kontaktissa suunnitteluvaiheessa ja toteutettavien toiminnallisuuksien valitsemisessa aina iteraatioiden välillä. Näin laadunvarmistus toimii aktiivisesti läpi koko tuotekehityksen. Start-upilta, joka ei tee räätälöityjä sovelluksia puuttuu yleensä tämä olennainen toteutettavien toimintojen ja vaatimuksien määrittelijä, eli asiakas. Tämä saattaa olla suuri ongelma metodologioissa, joissa korostetaan asiakkaan asemaa, ellei sitä voida korvata sisäisesti ns. sponsorilla. Tällaisia projekteja ovat mm. tuotekehitys ja ns. paketti-ohjelmistojen tuotanto, jolloin asiakkaan tarpeet on selvitettävä markkinatutkimuksella. Toinen hankaluus voi tulla osaavan henkilökunnan puutteesta. Monet tekniikat ja metodit vaativat valmentajan tai tutorin, ainakin aluksi, joka valvoo oikeaa suoritusta ja opastaa ongelmatilanteissa. Tähän pienillä yrityksillä ei välttämättä ole varaa. Siksi metodologian tulisi olla helposti omaksuttavissa ja tulosten nopeasti nähtävissä. 16

17 Taulukko 3, Ketterien metodologioiden ominaisuudet Vastattava kriteeri: Ketterien metodologioiden ominaisuuksien vastaavuus: Luo uskottavuutta Resurssitarve Edut nähtävissä heti, joustava, kevyt Edullinen Ei vaadi koulutusta Nopea ja varma tulos Ei liian riippuvainen asiakkaasta Mukautumiskykyinen, ihmisläheinen Skaalautuu kasvun mukana Suunnitelmallisuus Laadunvarmistus Helppo omaksua ja maastouttaa Subjektiivista, kaikki kyllä verrattuna ad hoc. Vaihtelee metodologioittain Hyvä vastaavuus Vaihtelee metodologioittain Vaihtelee metodologioittain Hyvä vastaavuus Vaihtelee metodologioittain Hyvä vastaavuus Vaihtelee metodologioittain Vaihtelee metodologioittain Hyvä vastaavuus Vaihtelee metodologioittain Start-up yrityksen tilanne ja tarpeet näyttäisivät kutakuinkin sopivan ketteriin prosesseihin. Ne soveltuvat pieniin tiimeihin ja keskittyvät start-upin kannalta olennaiseen, eli tuotteen nopeaan kehitykseen ja toimitukseen. Ketterien metodologioiden muokkautumiskyky nopeisiin tilanteisiin ja muuttuviin tarpeisiin auttaa start-upia epävakaassa ympäristössään. Taulukosta käy kuitenkin ilmi monia kriteereitä, joiden välillä ketterät metodologiat 17

18 eroavat toisistaan. 4.3 KETTERIEN METODOLOGIOIDEN LYHYET ESITTELYT Esittelen ketterät metodologiat lyhyesti, ja etenkin miten ne eroavat toisistaan. Tämän jälkeen vertailen edellisessä kappaleessa esille tulleita eroavaisuuksia kriteerien suhteen EXTREME P ROGRAMMING (XP) XP koostuu 12 käytännöstä, joista monet tekniikat ovat viety äärimmäisyyksiin. Suunnittelu, testaus ja toteutus tehdään miltei yhtä aikaa ja pareittain. XP käyttää metaforia järjestelmän suunnittelussa, ja painottaa yksinkertaisuutta. Järjestelmää ei tarkasti suunnitella kokonaisuutena vaan muokataan nopeasti kulloinkin kohdattujen ongelmien myötä. Kaikkeen sovelletaan yksinkertaisinta mahdollista ratkaisua. Toiminnallisuuksien suunnittelu tapahtuu pienissä pikemminkin minuuttien ja tuntien, kuin päivien mittaisissa pyrähdyksissä, jonka jälkeen tehdään testit ennen varsinaista koodia. Järjestelmää muokataan uudelleen (Refactor) aina kun tarvetta siihen ilmenee tai joku tekijöistä havaitsee yksinkertaisemman tavan toteuttaa kyseinen asia. Toteutuksessa merkittävässä roolissa on pariohjelmointi, jolla pyritään virheettömään koodiin ja jatkuvaan oppimiseen, sekä säilyttämään tieto ohjelmiston kehityksestä yrityksessä, jos joku henkilö vaihtuu tai sairastuu. Iteraation kiertoaika on melko kiinteästi määritelty 2-3 viikkoon. Iteraatioiden välissä toteutettavat toiminnallisuudet priorisoidaan asiakkaan toimesta binäärisesti: toiminto toteutetaan joko tässä syklissä tai sitten ei. XP kuvaa enemmän miten asiat tulee tehdä kun muut metodologiat, jotka keskittyvät 18

19 toimintaympäristön ja puitteiden luomiseen. Alan Radding kuvaa (Radding 2002) XP:tä preskriptiiviseksi ja jopa dogmaattiseksi CRYSTAL CLEAR Crystal metodologiaperhe on erittäin joustava ja muokkautuu tilanteen mukaan. Se antaa työryhmälle valtuudet määritellä prosessi mieleisekseen ja parantaa sitä sitten jatkuvasti. Crystal Clear on Crystal Methodologies -perheen pienin ja kevein ja tarkoitettu 4-6 henkilön ryhmille. Crystal Clear sisältää 20 artefaktia, joista vain muutama on formaaleja ja loput epävirallisia, kuten jutustelu liitutaululla, keskustelut ja sähköpostit. Cockburn esittelee (Cockburn, 2000a) Crystal Clearin pienen ryhmän metodologiaksi. Neljään rooliin tarvitaan eri ihmiset: sponsori, vanhempi ohjelmoija/suunnittelija, ohjelmoija/suunnittelija ja käyttäjä (vähintään osa-aikainen). Muita rooleja, jotka voivat mennä edellisten kanssa lomittain, ovat projektikoordinaattori (Project Coordinator), liiketoiminta-asiantuntija (Business Expert) ja yksi tai useampi vaatimustenkerääjä (Requirements Gatherer). Kahden tai kolmen kuukauden välein ohjelmistosta toimitetaan uusi versio iteratiivisesti. Prosessin etenemistä seurataan virstanpylväillä (Milestone), jotka koostuvat ennemminkin toimituksista tai tärkeistä päätöksistä kuin paperidokumenteista SCRUM Scrumin nimi tulee Rugbyn (englantilainen jalkapallo) termistöstä, jossa se tarkoittaa pikaista palaveria ennen koitosta. Siinä jaetaan ohjeet ja sovitaan mitä tullaan 19

20 tekemään. Tämä kuvaa hyvin Scrumin jokapäiväisiä lyhyitä palavereja (scrum), joissa neuvotellaan tavoitteet päivälle ja puretaan esille tulleet ongelmat ja seurataan projektin edistymistä. Scrum on kuin spiraalimalli nopeutettuna ja päivittäisillä tapaamisilla terästettynä (Rising et al., 2000). Scrum luottaa pieniin, alle 10 henkilön ryhmiin, joilla on valtuudet tehdä päätöksiä ja etukäteen suunnittelu, tehtävien määrittely ja johdolle raportointi on vähäistä. Scrum ei ota samalla tavalla kantaa ohjelmoinnin käytäntöihin kuin XP, vaan keskittyy pikemminkin iteratiivisen suunnitteluun ja edistymisen seurantaan. Jeff Sutherlandin mukaan (Sutherland, 2001) Scrum toimii kaikissa ympäristöissä ja skaalautuu hyvin ylöspäin. Projektit jaetaan 30 päivän iteraatioihin, joita kutsutaan sprinteiksi. Ennen sprintin alkua määritellään siihen kuuluvan toiminnallisuuden vaatimukset, jonka jälkeen ryhmän annetaan toteuttaa se. Ideana on siis vakauttaa vaatimukset toteutuksen, eli sprintin ajaksi. Projektin johtoa ei kuitenkaan irroteta tehtävistään sprintin ajaksi, vaan joka päivä pidetään em. scrum. (Beedle et al., 1999) FEATURE D RIVEN D EVELOPEMENT (FDD) FDD (Coad, 1999) esittää tavan tuottaa ohjelmiston pienissä toiminnallisissa palasissa, joista jokaisesta on hyötyä asiakkaalle. Aluksi luodun toteutettavan järjestelmän malli ohjaa ikrementaalista tuotantoa. FDD sisältää neljä perus prosessia: kokonaisuuden kuvaaminen, yksityiskohtainen toiminnallisuuslistan luominen, suunnittelu toiminnallisuus kerrallaan ja rakentaminen toiminnallisuus kerrallaan. Tuotannon etenemistä seurataan tarkasti ja seurannasta saadaan automaattisesti raportteja esimiehille ja johdolle sekä asiakkaalle. Prosessit viedään läpi neljän pää roolin avulla. Johtava Arkkitehti (Chief Architect) 20

21 suunnittelee asiakkaan kanssa kokonaisuuden. Johtava Ohjelmoija (Chief Programmer) valitsee toiminnallisuus ryhmien jäsenet ja organisoi toteutuksen. Luokan Omistaja (Class Owner) suorittaa toiminnallisuuden toteutuksen, testauksen ja pitää katselmuksen. Luokan omistaja voi olla mukana useassa ryhmässä ja Johtava ohjelmoija voi toimia useamman toiminnallisuus ryhmän vetäjänä. Asiakas on mukana kokonaismallin suunnittelussa ja toiminnallisuuksien määrittelyssä, joita tarkennetaan, ryhmitellään ja lopuksi priorisoidaan. Tämän jälkeen määritellään minimaalinen järjestelmä, jolla kuitenkin on vielä taloudellista arvoa. Toiminnallisuudet ryhmitellään ja toteutetaan 1-2 viikon jaksoissa. Kun johtava ohjelmoija on tyytyväinen kunkin iteraation tulokseen integroidaan muutokset ohjelmistoon. Artefakteja on vain neljä: toiminnallisuuslista, luokkakaavio, sekvenssikaavio ja koodi DYNAMIC S YSTEMS D EVELOPEMENT M ETHOD (DSDM) DSDM sai alkunsa Englantilaisten yritysten yhteenliittymästä (DSDM Consortium), mistä se on vallannut maailmaa. Yhteenliittymän kehittämänä se poikkeaa muista metodologioista kattavalla ja täysipäiväisellä yritystuella ja organisaatiota tukevalla koulutuksella ja opastuksella. DSDM Consortium järjestää kursseja ja koulutusta ja painaa ohjekirjoja ynnä muuta. Se on myös maksullinen, joten pienen yrityksen näkökulmasta se saattaa olla poissa vaihtoehdoista, jos raha on kynnyskysymys. Toisaalta ulkoistettu koulutus, tuki ja ohjaus säästäisivät henkilöresursseja, jos investointi koetaan kannattavaksi. Highsmithin mielestä (Highsmith, 2001) DSDM on kattavin ohjelmiston koko elinkaaren hallinnassa ja dokumentoinnissa osittain DSDM Consortiumin takia. Prosessi alkaa toteutettavuustutkimuksella (Feasibility study), jossa arvioidaan onko 21

22 DSDM sopiva kyseiseen projektiin. Liiketoimintatutkimus (Business study) koostuu lyhyistä ryhmätöistä, joissa pyritään ymmärtämään liiketoimintaympäristö. Näistä alkuvaiheista saadaan projektisuunnitelma ja järjestelmän arkkitehtuurin hahmotelma. (DSDM Consortium, 2002b) Loppuosa prosessista muodostuu kolmesta yhtyeenliitetystä syklistä: Toiminnallisuusmallin sykli tuottaa analyysejä, dokumentaatiota ja prototyyppejä. Suunnittelu ja toteutus sykli kehittää ohjelmiston iteratiivisesti ja implementointi sykli käsittelee operatiiviseen käyttöönottoon sijoitusta. Toteutettavien toiminnallisuuksien priorisointi tapahtuu neljässä portaassa (MoSCoW): 1) täytyy olla (Must have), 2) pitäisi olla (Should have), 3) voisi olla (Could have) ja 4) haluttaisiin joskus (Want to have sometime). (DSDM Consortium, 2002c) 5 LUOKITTELU JA LAJITTELU Wardin mielestä (Ward, 2001) ketterien metodologioiden vertailu rinta rinnan on pohjimmiltaan merkityksetöntä. Ja keskustelua, joissa formaaleja prosesseja verrataan rinta rinnan ilman tietyn ryhmän ja tietyn tilanteen kontekstia, tulisi välttää. Tässä tutkimuksessa kontekstia on pyritty luomaan karakterisoimalla start-upin luonne ja tilanne, jolloin vertailu on mielestäni perusteltua. Vertailu helpottaa havaitsemaan erilaisuudet ja valaisemaan metodologioiden eri ominaisuuksia, jolloin niihin on nopeampi tutustua ilman syvällistä tuntemusta. 5.1 FRONT-LOADED, BALANCED JA BACK-LOADED Miller (Miller, 2001) jakaa metodologiat kolmeen luokkaan: 1) Front-loaded, 2) Balanced ja 3) Back-loaded. Front-loaded prosesseissa paino on suunnittelulla ja Back-loaded prosessit tuottavat pikaisesti minimivaatimukset täyttävän tuotteen ja 22

23 reagoivat nopeasti muutoksiin. Balanced prosessi pyrkii mukautumaan erilaisiin tarpeisiin ja tarjoaa kompromissin edellisten väliltä. Tämän mukaan Crystal metodologiat, ja FDD sijoittuvat Balanced kategoriaan ja DSDM, Scrum sekä erityisesi XP Back-loaded. Front-loaded kategoriaan kuuluisi esimerkiksi Rational Unified Process (RUP). RUP on Martin Fowlerin mukaan (Fowler, 2001) raskaamman sarjan metodologia, vaikkakin kevennettävissä, eikä siten ole otettu mukaan tähän tutkimukseen. Metodologian valintaan start-upissa vaikuttaa miten selvä tehtävän ohjelmiston tulevaisuus on. Etukäteen suunnittelulla voidaan välttyä turhilta kokeiluilta ja siksi se on koettu tehokkaaksi prosessin nopeuttajaksi ja selkiinnyttäjäksi. Kuitenkin tilanteet saattavat usein muuttua niin voimakkaasti, että suunnittelu on joko erittäin vaikeaa tai jopa mahdotonta. 5.2 SUUNNITTELUN LÄHTÖKOHDAT Metodologiat ovat suunniteltu jotain ratkaisua tai ongelmaa silmälläpitäen tai kehittyneet jossain ympäristössä, jonka jälkeen ideat on yleistetty ja muokattu sopivaksi kokonaisuudeksi. Näin suunnittelun lähtökohdat ovat monesti erilaiset ja metodologiat painottavat eri asioita. Ottamalla huomioon metodologian taustat voidaan paremmin käsittää mihin sillä pyritään. XP:n on nimensä mukaankin aggressiivisin ketteristä metodologioista. Robert L. Glass kertoo (Glass, 2001) XP:n kehittäjän Kent Beckin vastanneen seuraavasti, kun häneltä kysyttiin miten XP:n osat on valittu: he took all the best practicies he knew and turned the knob up to 10 to see what happened. Cockburn määrittelee Crystal metodologiaperheen perustuvan seuraavaan ajatukseen ohjelmiston kehittämisestä: Software developement is a cooperative 23

24 game, in wich the participants help each other in reaching the end of the game the delivery of software. Crystal metodologiat on kehittynyt keräämällä onnistuneiden projektien onnistumisien syitä. Kaksi esille tullutta menestystekijää: pienet ryhmät tuottavat parempia tuloksia kevyemmällä metodologialla ja yksinkertaisintakin prosessin rajoitetta on liian vaikeaa noudattaa. (Cockburn, 2000c) DSDM on suunniteltu keskittyen iteratiiviseen kehitykseen ja Rapid Application Developement:iin. (RAD) Se on maksullinen ja sille tarjotaan koulutus- ja ohjauspalveluita, joten se on selvästikin suunnattu vakavaraisemmille ja kypsemmille organisaatioille. FDD ratkoo liike-elämän vaatimuksen yhä nopeammista toimituksista ja sykleistä. Tämä on erityisesti räätälöityjen sovellusten kehittäjälle toimiva lähtökohta, jolloin asiakkaan kanssa ollaan tiiviissä yhteistyössä parhaan lopputuloksen saavuttamiseksi. Scrumin lähtökohtana on kaaoksen hallinta vain sen verran kuin organisaatio sitä vaatii. Scrum on siis hyvä tilanteissa, joissa vaatimukset muuttuvat tai niitä ei edes heti tiedetä tai muuten kaoottisessa ympäristössä. 5.3 SKAALAUTUVUUS Jos start-up yritys kasvaa nopeasti voi skaalautuvuus olla merkittävä tekijä metodologian valinnassa. Toinen vaikuttava tekijä on ryhmäkoko, joka tulisi olla mahdollisimman pieni, mutta silti toimiva. Eli joustavuus henkilömäärissä ja tehtävissä on tärkeää. XP:tä on kritisoitu (Glass, 2001) huonosta skaalautuvuudestaan suurempiin ohjelmistoihin. 24

25 FDD on hyvin skaalautuva isoonkin projektiin, mutta suurten ohjelmistojen pilkkominen toteutettaviin toiminnallisuuksiin saattaa olla hankalaa. Rajoittava projektin kasvun tekijä on Palmerin mukaan (Palmer, 2000) vain johtavien ohjelmoijien lukumäärä yrityksessä. Crystal Clear on suunniteltu 4-6 hengen projekteille, mutta samasta metodologiaperheestä löytyy lisää ohjeistusta ja painoa (Crystal Yellow ja Crystal Orange), jos projektin koko kasvaa, jolloin sen avulla voi hallita suuriakin ohjelmistoprojekteja ja organisaatioita. DSDM skaalautuu hyvin ja koulutusta on tarjolla suurillekin ryhmille. Scrum rajoittaa ryhmäkoon mielellään 10 henkilöön. Jeff Sutherlandin mukaan (Sutherland, 2001) Scrum kuitenkin skaalautuu hyvin. 5.4 KURI JA SUVAITSEVAISUUS Cockburn jakaa metodologiat (Cockburn, 2000a, s. 51) sen mukaan millä tavoin ne käsittelevät ihmisten yleisiä heikkouksia: kurilla (discilpine) tai suvaitsevaisuudella (tolerance). Organisaation kulttuuri vaikuttaa metodologian sopivuuteen ja kurin tai suvaitsevaisuuden ilmapiiriin. Ketterät metodologiat ovat ihmislähtöisiä, eikä kuri tässä tilanteessa tarkoita lisääntynyttä byrokratiaa. XP vaatii kuria, asennetta ja sitoutumista ja on siten discipline-tyyppinen metodologia. Crystal Clear edustaa taas hyvin suvaitsevaista metodologiaa. Ryhmä määrittelee prosessinsa itse ja kehittää sitä eteenpäin. Toisaalta Crystal Clear vaatii myös tiettyjä perusdokumentteja, jotka täytyy tehdä. FDD ja DSDM sisältävät toimintatapoja ja prosesseja, jotka täytyy tehdä, mutta ei niin 25

26 määräävästi, tarkasti tai ankarasti kuin XP. Scrum mukautuu hyvin monenlaisiin tilanteisiin ja on erittäin kevyt, joten asettaisin sen suvaitsevaiseksi metodologiaksi. 5.5 START-UPIN KRITEERIT ERI METODOLOGIOITTAIN Taulukko 4, Ketterien metodologioiden erot kriteerien suhteen Edullinen Helppo Koulutus ja Skaalautuva Kokonaisuuden Asiakas omaksua resurssitarve suunnittelu mukana Crystal Clear DSDM FDD XP Scrum Taulukkoon on kerätty pisteitä edellisen kappaleen pohdinnan perusteella sen mukaan miten metodologia vastaa tiettyyn start-upin kriteeriin. Positiivinen luku tarkoittaa hyvää vastaavuutta start-upin tarpeisiin ja negatiivinen heikkoa. Nollat ovat selvyyden vuoksi jätetty pois kohdista, joista on vaikea nähdä eroja metodologioiden välillä. 5.6 YHTÄLÄISYYDET JA EROT Ketterät prosessit ovat kaikki iteratiivisia, tuloksiin suuntautuneita ja keskittyvät ihmisiin ennemminkin kuin dokumentteihin. Edellisissä kappaleessa esitettyjen erojen 26

27 lisäksi esimerkiksi eri metodologioiden laajuus, eli kattavuus vaihtelee melko paljon. Laajuuden vaikutusta olisi tutkittava tarkemmin ja koska se ei ole juuri start-upin kannalta kriittistä, vaikkakin merkityksellistä, olen sivuuttanut sen tästä tutkimuksesta. XP kuvaa metodologioista eniten käytännön tekniikoita ja sääntöjä, joten sitä voi soveltaa muiden metodologioiden kanssa rinnan. Highsmithin mielestä DSDM ja Scrum voivat samanlaatuisina kilpailla keskenään, ja toisaalta FDD ja Crystal Methodologies (Highsmith, 2001). DSDM ja Scrum ovat samanlaatuisia prosessia ohjaavana ja määrittelevänä metodologiana, ja FDD ja Crystal Clear luovat perustukset prosessille, jonka yksityiskohdat voi organisaatio tai ryhmä itse muotoilla ja päättää. Palmer, esittää FDD myönteisessä artikkelissaan (Palmer, 2000) XP:n ja FDD eroiksi: 1) Ryhmäkoon, joka FDD:ssä skaalautuu paremmin ylöspäin. 2) Erona XP:hen FDD määrittelee järjestelmän kokonaismallin (Domain Object Model), mikä vähentää koodin uudelleen muokkaamistarvetta (Refactoring) 3) XP:ssä koodi omistetaan yhteisönä, mistä on monia etuja, mutta FDD:ssä on pyritty säilyttämään samat edut kuitenkin säilyttämällä yksilöllinen omistajuus. Tällöin tietämys projektin lähdekoodista on Palmerin mielestä pikemminkin ryppäissä (clustered) kuin hajaantunut kaikkialle, mikä voi olla merkittävää etenkin suurissa projekteissa. 4) XP:ssä koodin katselmointia ei ole erikseen, kuten FDD:ssä vaan pariohjelmointi ajaa tämän tehtävän. Katselmointi tuo lisää töitä, mutta toisaalta sillä on myös etunsakin pariohjelmointiin nähden, kuten johtavan ohjelmoijan näkemys koodin ratkaisuihin. 5) FDD ei määrittele yksikkötestausta niin tarkasti kuin XP vaan jättää päätäntävallan johtavalla ohjelmoijalle. 6) XP:ssä projektin johto seuraa sen edistymistä, ja FDD:ssä toiminnallisuuskohtainen seuranta (Tracking by Feature) antaa helposti aineistoa 27

28 mittaamisprosessiin. Palmer on myötävaikuttanut FDD:tä, joten edelliset vertailut eivät ole aivan puolueettomia. 6 START-UPIN VALINNAT Balanced tyyppinen metodologia sopii start-up yritykselle ehkä parhaiten, sillä suunnitelmallisuus ja kokonaiskuvan luominen helpottavat yrityksen strategista johtamista. Suunnitelmia tarvitaan myös sijoittajien vakuuttamiseksi. Täsmällisen tarkkoja suunnitelmia on kuitenkin mahdoton ja tehdä, koska tilanne muuttuu koko ajan, joten iteratiivinen kehitys on miltei pakollista. Tällöin käytetään ns. vyöryvän aallon periaatetta (Rolling Wave Principle), jolloin suunnitelmia tarkennetaan sitä mukaa kuin projekti etenee. Back-loaded prosessi olla hyvä vaihtoehto, jos tilanne on herkkä muutoksille, eikä kokonaiskuvan suunnitelmaa voida tehdä. Tällaisia voivat olla mm. tutkimusprojektit. Crystal-metodologiat perustelevat prosessin tarpeen ja motivoi ihmislähtöisesti muokkaamaan prosessin tilanteeseen ja ympäristöön sopivaksi. Se antaa muista poiketen jatkuvan prosessin kehittämisen haasteen ryhmälle. Tämä lähestymistapa soveltuu mielestäni hyvin prosessiaan kehittävän start-upin tarpeisiin. Crystaliin voi liittää tekniikoita muista prosessista ja se määrittelee vain tarvittavat elementit, jolla tuotanto saadaan toimimaan hyvin. Scrum sopii mielestäni erittäin nopeasti muuttuviin tilanteisiin ja lähes kaoottiseen ympäristöön, jossa seuraavan toteutettavan iteraation onnistumista ei tiedetä. Tällaisia voisivat olla esimerkiksi uusien teknologioiden kaupallistamis- ja tutkimusprojektit, joiden toteutettavuutta ei voida ennakoida. Scrum voi olla jo lähellä nykyistä määrittelemätöntä prosessia, joten sen maastouttaminen voi olla varsin 28

29 helppoa, jos pätevä scrum-osaaja (Scrum Master) on käytettävissä. Helpon maastouttamisen tärkeys korostuu etenkin pienille start-upeille. FDD tarvitsee asiakasta valitsemaan toteutettavat toiminnallisuudet ja sopii siksi start-upeille, jotka toimittavat esimerkiksi räätälöityjä sovelluksia. Asiakkaan puuttumisen voi korvata sisäisellä asiakkaalla, mutta todellisten tarpeiden määrittäminen saattaa tällöin olla hankalaa. Asiakkaan sitouttaminen siirtää riskejä asiakkaan puolelle ja ohjaa tuotekehitystä oikeaan suuntaan. Rajoittava tekijä FDD:n kasvamisessa suurempiin projekteihin on johtavien ohjelmoijien määrä. Jos osaavaa henkilökuntaa on riittävästi, on FDD mielestäni kevyt ja toimiva ratkaisu, jolla saavutetaan tuloksia nopeasti ja hallitusti. FDD:n ongelmakentän kokonaismallin rakentaminen voi olla ratkaisevassa asemassa uutta tuotetta kehitettäessä ja sen ymmärtämisessä, jolloin suurilta yllätyksiltä vältytään ja strateginen tavoite on kokoajan näkyvissä. DSDM on mielestäni pienen ohjelmistoalan start-upin resursseille raskas, koska usein aikaa koulutukseen tai kouluttautumiseen ei ole, tai muut taloudellisesti merkittävämmät päätökset menevät edelle. Kokemusaineiston puute on jättänyt DSDM:n vähemmälle huomiolle tässä tutkimuksessa, joten vertailu ei näiltä osin ole kovin luotettava. Tämä saattaa olla myös viite siitä, että DSDM ei ole start-upin kannalta helposti lähestyttävissä. XP ei mielestäni välttämättä sovi yritykselle, joka haluavat uskottavuutta ja välttää turhaa urheilua ja kokeilemista. Mark C. Paulkin mukaan (Paulk, 2001) XP:tä ei ehkä tulisi käyttää korkeaa luotettavuutta tai todella kriittisiä sovelluksia toteutettaessa. Toisaalta XP:n aggressiivisuus saattaa olla juuri se tarvittava imagon pönkittäjä, mikä erottaa pienen start-upin muista ja nostaa sen nopeasti suurille markkinoille. Tämä vaatii kuitenkin kaikilta mukana olevilta kuria, asennetta ja sitoutumista, joka ei 29

30 välttämättä ole saavutettavissa. XP luottaa mielestäni myös liikaa ihmisten, ja etenkin ohjelmoijien, kyvykkyyteen suunnittelijoina ja ohjelmointikielten asiantuntijoina. Jos sellaisia ei organisaatiossa ole, niin XP voi koitua erittäin vaikeaksi. Kuitenkin, jos potentiaalia on, niin XP:n eri tekniikat, kuten pariohjelmointi nopeuttavat tietojen ja taitojen välittymistä ja ihmiset kehittyvät nopeasti yhtä hyviksi. Tässä kuitenkin rajana on se yrityksen paras ohjelmoija, ja tulokset riippuvat pitkälti hänestä. Palmer myös huomautti (Palmer, 2000), että huonojen ohjelmointitapojen ja -ratkaisujen välittyminen onnistuu pariohjelmoinnissa yhtä helposti kuin hyvienkin. Onnistuakseen XP:n periaatteet ja tekniikat vaativat valmentajan, joka ohjaa ja opastaa niiden suorittamisessa. Tähän ei pienellä yrityksellä välttämättä ole varaa ja vaarana on että XP yritetään väkisin maastouttaa ja käsitykset vääristyvät. XP vaatii myös asiakkaalta paljon, ja sen korvaaminen sisäisesti yrityksessä saattaa olla hankalaa. Ja jos asiakas on olemassa, niin XP haluaisi periaatteessa olla viiveettömässä kontaktissa häneen. Käytännössä tämän toteuttaminen saattaa olla hyvin vaikeaa. 6.1 YHDISTELMÄT Tilanteen mukaan eri metodologioita kannattaa myös yhdistellä ja poimia niistä parhaat puolet, kuten jos XP:n pariohjelmointi tuntuu kokeilun arvoiselta, voi sitä soveltaa muissakin metodologioissa. DSDM ja Scrum kuvaavat metodeja samalla tasolla ja ovat siten toisensa poissulkevia kokonaisuudessaan. FDD ja Crystalmetodologiat ovat myös samanlaatuisia, mutta mielestäni Crystalin periaatteet ja ajatukset soveltuvat hyvin mihin tahansa ihmislähtöiseen lähestymistapaan. Metodologiat ovat kuitenkin suunniteltu kokonaisuuksiksi, jossa osat tukevat toisiaan, jolloin kannattaa perehtyä metodien sidoksiin ja valita toisiinsa sopivat tekniikat. 30

31 6.2 MISTÄ LÄHTEÄ LIIKKEELLE? Sutton esittelee (Sutton, 2000) seitsemän askelta miten lähestyä prosessia: 1) Määrittele prosessi, 2) Pysy joustavana, 3) Käytä oikeita määrittelyn muotoja 4) Yleistä määrittelyt (Generalize), 5) Opi ja käytä uudelleen (Learn and Reuse), 6) Hanki oikeita ihmisiä ja 7) Kehitä prosessia (Process Improvement). Oikeiden ihmisten hankkiminen lienee vaikeinta start-up yrityksessä, koska rekrytointiresurssit ovat rajalliset. Suttonin mukaan hyvä ohjelmistokehittäjä on joustava ja pystyy mukautumaan erilaisiin tehtäviin. Näin ollen start-upissa on kiinnitettävä erityistä huomiota henkilöiden valintaan ja painotettava osaamisen lisäksi myös soveltuvuutta olemassa olevaan ympäristöön ja ilmapiiriin XP:N ENSIMMÄISET KÄYTÄNNÖT Jotta XP toimisi kokonaisuutena Nawrocki et al. ovat määritelleet (Nawrocki et al., 2001) Capability Maturity Model:n (CMM) kaltaisen mallin XP:lle XP Maturity Model (XPMM). Mallin toisella tasolla, Initial, on ensimmäiset käytännöt ja periaatteet, jotka tulisi ottaa prosessiin mukaan. Käytännöt ovat jaettu kahteen ryhmään: 1) asiakassuhteen hallinta (Customer Relationship Management, CRM) ja 2) tuotteen laadun varmistus (Product Quality Assurance, PQA). CRM osa sisältää yhteensä 11 metodia, joista joitain on hieman kevennetty. PQA osassa niitä on seitsemän. Nämä metodit muodostavat joukon käytäntöjä, jotka tulisi maastouttaa, jotta XP toimisi kokonaisuutena. Lista on pitkä ja kaikkien toteuttamiseen nopealla aikataululla ja vaivattomasti saattaa olla liian raskasta start-up yritykselle. Toisaalta, kuten jo totesin start-up yritys voi olla XP:n maastouttamisen kannalta helppo tapaus, jos koko henkilöstö pitää ideasta ja omistautuu käytäntöjen opettelemiseen ja toteuttamiseen. XP:tä voi myös lähestyä, kuten Kent Beck ehdottaa (Beck, 1999), ottamalla esille 31

32 tullut ongelma ja ratkaista se XP:n tyylillä. 7 YHTEENVETO JA PÄÄTELMÄT Start-upin luonteesta ja ympäristöstä johdetut kriteerit sopivat ensi silmäykseltä erittäin hyvin ketterien metodologioiden kuvauksiin. Syvemmin tarkasteltaessa kuitenkin huomataan miten eri metodologiat eroavat toisistaan ja summittainen valinta voi olla kohtalokasta. Nopeisiin muuttuviin tilanteisiin soveltuva Scrum ei välttämättä sovi hyvin määriteltyihin ja suoraviivaisiin toteutusprojekteihin. XP ei taas skaalaudu laajojen ja monimutkaisten järjestelmien kehitykseen, jossa tarvitaan tarkkaa suunnitelmallisuutta. Metodologia on siis valittava aina tilanteen mukaan ja niistä voi yhdistellä itselleen sopivan kokonaisuuden. Mikään metodologia ei heti suoraan toimi sellaisenaan, vaan mukauttaminen yrityksen arvoihin, tottumuksiin, asenteisiin ja ihmisiin on tärkeää. Start-upin ensiaskeleet alkaisivat peiliin katsomisella ja tilanteen hahmottamisella, eli nykyisen prosessin määrittelemisellä. Merkittävimmät eroavaisuudet löytyivät näissä kriteereissä: 1) kokonaisuuden suunnittelu, 2) helppo omaksuttavuus, 3) koulutus ja resurssitarve, 4) asiakkaan mukanaolo, 5) skaalautuvuus ja 6) edullisuus. Näiden perusteella päädyin seuraaviin suosituksiin: Crystal Clear on hyvä jos ongelmia halutaan ratkoa ihmislähtöisesti: Ryhmä määrittelee toimintatapansa ja kehittää metodologiaa sitä kautta. Crystal Methodologies perheessä on myös paljon kasvun varaa ja tarvittavia lisäelementtejä, esimerkiksi projektinhallintaan, voidaan ottaa käyttöön aina tarpeen mukaan. Scrum sopii esimerkiksi tuotekehitysprojekteihin, joissa tulevaisuus saattaa olla 32

33 hyvinkin epäselvä. Scrum on myös erittäin kevyt ja helposti omaksuttavissa, joten erittäin hyvä vaihtoehto etenkin pienelle start-upille. FDD sopii esimerkiksi räätälöityjen sovellusten kehitysprojekteihin, joissa asiakas on mukana. Se on joustava ja tarjoaa sopivasti suunnitelmallisuutta sekä muutoksen hallintaa. Se ei kuitenkaan määrittele toimintatapoja niin tarkasti kuin esimerkiksi XP. Eri metodologioiden yhdisteleminen tuo tarvittavat ja sopivat osat yhteen. XP voi olla sopiva, jos halutaan sen aggressiivisuutta ja asiakas on siihen valmis. Kokonaisuudessaan XP on kuitenkin useiden start-up yritysten resurssien ja tavoitteiden ulkopuolella. XP:tä voi sen kehittäjän Kent Beckin mukaan (Beck, 1999) helposti kokeilla käyttämällä sitä vastaan tulevan ongelman ratkaisemiseen, ja siten nähdä sopiiko se yrityksen kulttuuriin. Metodologian maastouttaminen voi olla vaikeaa start-up yrityksessä johtuen henkilöstön roolien vaihtumisesta ja rajallisista resursseista. Toisaalta, kaikki kerralla -lähestymistapa saattaa myös toimia, riippuen henkilökunnan valmiuksista. Yleensä metodologian maastouttaminen kannattaa suunnitella ja poimia vain välttämättömimmät ja eniten hyötyä tuovat elementit. Prosessin taakka tulisi olla mahdollisimman pieni. Prosessin määrittelemisen ja kehittämisen lisäksi rekrytointi ja sopivien ihmisten löytäminen on tärkeää metodologian ja koko start-upin onnistumiselle. Cockburn esittää (Cockburn, 2000a, s.143) mm. seuraavia kysymyksiä metodologian arvioinnille: 1) Kuinka nopeasti metodologia sallii ihmisten vaihtumisen ja koulutuksen? 2) Kuinka suuri vaikutus sillä on myynti prosessiin? 3) Kuinka paljon se antaa ihmisille vaputta? 4) Kuinka nopeasti se sallii reagoinnin muuttuviin tilanteisiin? 33

34 8 LÄHDELUETTELO 1. Beck, Kent Embracing Change with Extreme Programming. Computer, October IEEE 1999, / Beedle, M., M. Devos et al SCRUM: An extension pattern language for hyperproductive software developement. Pattern Languages of Program Design 4, N. Harrison, B. Foote, and H. Rohnert. Addison-Wesley. 3. Coad, De Luca Java Modeling in Color with ULM. Chapter 6. Prentice Hall Saatavissa: < 4. Cockburn, Alistair & Jim Highsmith Agile Software Development: The People Factor. Computer, November 2001, pp Cockburn, Alistair. 2000a. Agile Software Development. 6. Cockburn, Alistair. 2000b. Crystal Clear: A Human-Powered Methodology for Small Teams. Addison-Wesley Esiversio saatavissa: < 7. Cockburn, Alistair. 2000c. Selecting a Project s Methodology. IEEE Software, July/August DSDM Consortium. 2002a. DSDM and Extreme Programming (XP). 9. DSDM Consortium. 2002b. The DSDM Lifecycle [online]. [viitattu 24. helmikuuta 2002] Saatavissa: < 10. DSDM Consortium. 2002c. The Underlying Principles [online]. [viitattu 24. helmikuuta 2002] Saatavissa: 34