ketterät metodologiat ohjelmisto start-upin näkökulmasta
TRANSCRIPT
T-76.650 Ohjelmistotuotannon seminaari
Kevät 2002: Agile Software Development
Ketterät metodologiat
ohjelmisto start-upin näkökulmasta
Samppa Turunen, 49121H
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 start-
upille.
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
SISÄLLYSLUETTELO
1 JOHDANTO .............................................................................................4 1.1 TAUSTA .......................................................................................................................4
1.2 ONGELMA....................................................................................................................4
1.3 TAVOITTEET ................................................................................................................5
1.4 RAJAUS........................................................................................................................5
1.5 TOTEUTUS ...................................................................................................................6
2 RAPORTIN RAKENNE................................................................................8
3 START-UP YRITYS ...................................................................................9 3.1 KUVAUS JA KARAKTERISOINTI.....................................................................................9
3.2 KRITEERIT METODOLOGIALLE ...................................................................................10
3.3 VALINTAAN VAIKUTTAVAT TEKIJÄT..........................................................................12
4 METODOLOGIOIDEN LUPAUKSET JA MAHDOLLISUUDET .........................13 4.1 PÄRJÄÄKÖ ILMAN PROSESSIA?...................................................................................14
4.2 KETTERÄT METODOLOGIAT .......................................................................................15
4.3 KETTERIEN METODOLOGIOIDEN LYHYET ESITTELYT .................................................18 4.3.1 Extreme Programming (XP) ............................................................................................ 18 4.3.2 Crystal Clear .................................................................................................................... 19 4.3.3 Scrum .............................................................................................................................. 19 4.3.4 Feature Driven Developement (FDD).............................................................................. 20 4.3.5 Dynamic Systems Developement Method (DSDM) ........................................................ 21
5 LUOKITTELU JA LAJITTELU .....................................................................22 5.1 FRONT-LOADED, BALANCED JA BACK-LOADED ........................................................22
5.2 SUUNNITTELUN LÄHTÖKOHDAT.................................................................................23
5.3 SKAALAUTUVUUS......................................................................................................24
5.4 KURI JA SUVAITSEVAISUUS .......................................................................................25
5.5 START-UPIN KRITEERIT ERI METODOLOGIOITTAIN .....................................................26
5.6 YHTÄLÄISYYDET JA EROT..........................................................................................26
6 START-UPIN VALINNAT.........................................................................28 6.1 YHDISTELMÄT ...........................................................................................................30
6.2 MISTÄ LÄHTEÄ LIIKKEELLE? .....................................................................................31 6.2.1 XP:n ensimmäiset käytännöt ........................................................................................... 31
7 YHTEENVETO JA PÄÄTELMÄT.................................................................32
8 LÄHDELUETTELO...................................................................................34
3
11 JJOOHHDDAANNTTOO
11..11 TTAAUUSSTTAA
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.
11..22 OONNGGEELLMMAA
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
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.
11..33 TTAAVVOOIITTTTEEEETT
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ä.
11..44 RRAA JJAAUUSS
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
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.
11..55 TTOOTTEEUUTTUUSS
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
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
22 RRAAPPOORRTTIINN RRAAKKEENNNNEE
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 Start-
upin 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
33 SSTTAARRTT--UUPP YYRRIITTYYSS
33..11 KKUUVVAAUUSS JJ AA KKAARRAAKKTTEERR II SSOO IINNTT II
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
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: Mahdollisesti myös:
Kypsymättömyys Ei asiakasta
Rajalliset resurssit Muuttuvat roolit
Ei tasaista tulovirtaa Nopeasti kasvava
Kiire ja ulkoinen paine Ei varaa epäonnistua tai kokeilla
Pieni dynaaminen tiimi Prosessia ei määritelty
33..22 KKRR II TTEEEERR II TT MMEETTOODDOOLLOOGGIIAALLLL EE
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
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
Taulukko 2, Kriteerit metodologialle
Ominaisuus: Kriteeri:
Kypsymättömyys Luo uskottavuutta
Rajalliset resurssit Edut nähtävissä heti, joustava, kevyt
Ei tasaista tulovirtaa Edullinen, ei vaadi koulutusta
Kiire ja ulkoinen paine Nopea ja varma tulos,
laadunvarmistus
Ei asiakasta Ei liian riippuvainen asiakkaasta
Muuttuvat roolit Mukautumiskykyinen, ihmisläheinen
Nopeasti kasvava Skaalautuu kasvun mukana
Ei varaa epäonnistua tai kokeilla Suunnitelmallisuutta, laadunvarmistus
Prosessia ei määritelty Helppo omaksua ja maastouttaa
33..33 VVAALL IINNTTAAAANN VVAA IIKKUU TTTTAAVVAATT TTEEKK II JJÄÄTT
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
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.
44 MMEETTOODDOOLLOOGGIIOOIIDDEENN LLUUPPAAUUKKSSEETT JJAA MMAAHHDDOOLLLL IISSUUUUDDEETT
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
tehdä kunnolla saati suunnitella. Tähän ongelmaan, monien muiden asioiden
lomassa, metodologiat lupaavat parannusta mm. jatkuvan testauksen ja seurannan
avulla.
44..11 PPÄÄRR JJÄÄÄÄKKÖÖ II LLMMAANN PPRROOSSEESSSS IIAA??
Ilman prosessia ei voi toimia, mutta monet yritykset toimivat hyvinkin ilman prosessin
virallista määrittelyä.
Cockburn perustelee (Cockburn, 2000a, s. 142-143) 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
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.
44..22 KKEETTTTEERRÄÄTT MMEETTOODDOOLLOOGGIIAATT
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
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
Taulukko 3, Ketterien metodologioiden ominaisuudet
Vastattava kriteeri: Ketterien metodologioiden ominaisuuksien
vastaavuus:
Luo uskottavuutta Subjektiivista, kaikki kyllä verrattuna ad hoc.
Resurssitarve Vaihtelee metodologioittain
Edut nähtävissä heti, joustava, kevyt Hyvä vastaavuus
Edullinen Vaihtelee metodologioittain
Ei vaadi koulutusta Vaihtelee metodologioittain
Nopea ja varma tulos Hyvä vastaavuus
Ei liian riippuvainen asiakkaasta Vaihtelee metodologioittain
Mukautumiskykyinen, ihmisläheinen Hyvä vastaavuus
Skaalautuu kasvun mukana Vaihtelee metodologioittain
Suunnitelmallisuus Vaihtelee metodologioittain
Laadunvarmistus Hyvä vastaavuus
Helppo omaksua ja maastouttaa 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
eroavat toisistaan.
44..33 KKEETTTTEERR II EENN MMEETTOODDOOLLOOGGIIOO IIDD EENN LLYYHHYYEETT EESS II TTTTEELLYYTT
Esittelen ketterät metodologiat lyhyesti, ja etenkin miten ne eroavat toisistaan.
Tämän jälkeen vertailen edellisessä kappaleessa esille tulleita eroavaisuuksia
kriteerien suhteen.
4.3.1 EXTREME PROGRAMMING (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
toimintaympäristön ja puitteiden luomiseen. Alan Radding kuvaa (Radding 2002)
XP:tä preskriptiiviseksi ja jopa dogmaattiseksi.
4.3.2 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.
4.3.3 SCRUM
Scrumin nimi tulee Rugbyn (englantilainen jalkapallo) termistöstä, jossa se tarkoittaa
pikaista palaveria ennen koitosta. Siinä jaetaan ohjeet ja sovitaan mitä tullaan
19
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)
4.3.4 FEATURE DRIVEN DEVELOPEMENT (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
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.
4.3.5 DYNAMIC SYSTEMS DEVELOPEMENT METHOD (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
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)
55 LLUUOOKKIITTTTEELLUU JJAA LLAAJJ IITTTTEELLUU
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.
55..11 FFRROONNTT--LLOOAADDEEDD ,, BBAALLAANNCCEEDD JJAA BBAACCKK--LLOOAADDEEDD
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
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.
55..22 SSUUUUNNNNIITT TTEELLUUNN LLÄÄ HHTTÖÖKKOOHHDDAATT
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
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ä.
55..33 SSKKAAAALLAAUUTTUUVVUUUUSS
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
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.
55..44 KKUURR II JJ AA SSUUVVAA IITTSSEEVVAA II SSUUUUSS
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
määräävästi, tarkasti tai ankarasti kuin XP.
Scrum mukautuu hyvin monenlaisiin tilanteisiin ja on erittäin kevyt, joten asettaisin
sen suvaitsevaiseksi metodologiaksi.
55..55 SSTTAARRTT--UUPP IINN KKRR II TTEE EERR II TT EERR II MMEETTOODDOOLLOOGGIIOO IITTTTAA IINN
Taulukko 4, Ketterien metodologioiden erot kriteerien suhteen
Edullinen Helppo
omaksua
Koulutus ja
resurssitarve
Skaalautuva Kokonaisuuden
suunnittelu
Asiakas
mukana
Crystal
Clear
+1 +1 +1
DSDM -1 -1 +1 +1
FDD +1 +1 -1
XP -1 -1 -1 -1 -2
Scrum +2 +1 +1
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ä.
55..66 YYHHTTÄÄLLÄÄ II SSYYYYDDEETT JJAA EERROOTT
Ketterät prosessit ovat kaikki iteratiivisia, tuloksiin suuntautuneita ja keskittyvät
ihmisiin ennemminkin kuin dokumentteihin. Edellisissä kappaleessa esitettyjen erojen
26
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
mittaamisprosessiin.
Palmer on myötävaikuttanut FDD:tä, joten edelliset vertailut eivät ole aivan
puolueettomia.
66 SSTTAARRTT--UUPPIINN VVAALLIINNNNAATT
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
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
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.
66..11 YYHHDDII SSTTEELLMMÄÄTT
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 Crystal-
metodologiat 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
66..22 MMII SSTTÄÄ LLÄÄHHTTEEÄÄ LL II II KK KKEEEELLLLEE ??
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.
6.2.1 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
tullut ongelma ja ratkaista se XP:n tyylillä.
77 YYHHTTEEEENNVVEETTOO JJAA PPÄÄÄÄTTEELLMMÄÄTT
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
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
88 LLÄÄHHDDEELLUUEETTTTEELLOO
1. Beck, Kent. 1999. Embracing Change with Extreme Programming. Computer,
October 1999. IEEE 1999, 0018-9162/99.
2. Beedle, M., M. Devos et al. 1999 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. 1999. Java Modeling in Color with ULM. Chapter 6. Prentice
Hall 1999. Saatavissa:
<http://www.togethersoft.com/files/services/jmcu/chapter6.pdf>
4. Cockburn, Alistair & Jim Highsmith. 2001. Agile Software Development: The
People Factor. Computer, November 2001, pp. 131-133.
5. Cockburn, Alistair. 2000a. Agile Software Development.
6. Cockburn, Alistair. 2000b. Crystal Clear: A Human-Powered Methodology for
Small Teams. Addison-Wesley 2000. Esiversio saatavissa:
<http://members.aol.com/humansandt/crystal/clear/>
7. Cockburn, Alistair. 2000c. Selecting a Project’s Methodology. IEEE Software,
July/August 2000.
8. DSDM Consortium. 2002a. DSDM and Extreme Programming (XP).
9. DSDM Consortium. 2002b. The DSDM Lifecycle [online]. [viitattu 24.
helmikuuta 2002] Saatavissa:
<http://www.dsdm.org/about/lifecycle.asp>
10. DSDM Consortium. 2002c. The Underlying Principles [online]. [viitattu 24.
helmikuuta 2002] Saatavissa:
34
<http://www.dsdm.org/about/principles.asp>
11. Fowler, Martin. 2001. The New Methodology [online]. Lokakuu 2001 [viitattu
15. maaliskuuta 2002] Saatavissa:
<http://martinfowler.com/articles/newMethodology.html>.
12. Glass, Robert L. 2001. Extreme Programming: The Good, the Bad, and the
Bottom Line. IEEE Software November/December 2001. IEEE 2001, 0740-
7459/01. ss. 111-112.
13. Highsmith Jim. 2001. DSDM and the Agile Software Developement
Movement, The DSDM Magazine, 11/9/01, s. 2.
14. Highsmith, Jim & Alistair Cockburn. 2001. Agile Software Developement: The
Business of Innovation. Computer, September 2001, s. 120-122.
15. Kivi, Jeremy et al. 2000. Extreme Programming: A University Team Design
Experience. IEEE 2000, 0-7803-5957-7/00
16. Miller, Granville. 2001. Sizing Up Today’s Lightweight Software Processes. IT
Pro, May/June 2001.
17. Nawrocki, Jerzy et al. 2001. Toward Maturity Model for eXtreme Programming.
Ponzan University of Technology. IEEE 2001, 1089-6503/01.
18. Palmer, Steve. 2000. Feature Driven Development and Extreme
Programming. Coad Letter, July 2000, Issue 70. Saatavissa:
<http://www.togethercommunity.com/coad-letter/Coad-Letter-0070.html>
19. Paulk, Mark C. 2001. Extreme Programming from a CMM Perspective. IEEE
Software, November/December 2001. IEEE 2001, 0740-7459/01.
20. Radding, Alan. 2002. Extremely agile programming. Computerworld, 4
February 2002, vol 36.
35
21. Rising, Linda et al. 2000. The Scrum Software Developement Process for
Small Teams. IEEE Software, July/August 2000. IEEE 2000, 0740-7459/00.
22. Sutherland, Jeff. 2001. Inventing and Reinventing SCRUM in Five Companies.
21 September 2001.
23. Sutton, Stanley M. Jr. 2000. The Role of Process in a Software Start-Up. IEEE
Software, July/August 2000.
36