VAASAN YLIOPISTO 

TEKNILLINEN TIEDEKUNTA 

TIETOTEKNIIKKA 

 

 

 

 

 

 

 

 

   

 

 

 

 

Henri Nyholm 

TAPAUSTUTKIMUS: MITEN IT-ORGANISAATIO  

HYÖDYNTÄÄ KETTERÄN KEHITYKSEN ARVOJA JA  

PERIAATTEITA OHJELMISTOPROJEKTEISSA? 

 
 

 

 

 

 

 

 

 

 

 

 

Tietotekniikan 

pro gradu -tutkielma 

 

 

 

VAASA 2016 



 1 

SISÄLLYSLUETTELO sivu 

1 JOHDANTO 6 

1.1 Tutkimuksen tavoite ja rajaus 7 

1.2 Tutkimusaineisto –ja menetelmät 8 

1.3 Tutkielman rakenne 9 

2 OHJELMISTOPROJEKTI 10 

2.1 Elinkaari 10 

2.1.1 Elinkaarimalli ja elinkaaren vaiheet 11 

2.1.2 Vesiputousmalli 13 
2.1.3 Iteratiivinen malli 14 

2.2 Prosessit 14 

3 KETTERÄ OHJELMISTOKEHITYS 19 

3.1 Ketteryyden määrittely ja ideologia 19 

3.2 The Agile Alliance ja Agile Manifesto 21 

3.3 Ketterän ja perinteisen ohjelmistokehityksen eroavaisuudet 23 

3.4 Ketteryys ja projektihallinta 29 

4 KETTERIÄ MENETELMIÄ 33 

4.1 Extreme Programming (XP) 33 

4.1.1 Arvot ja käytännöt 34 

4.1.2 Säännöt 36 
4.1.3 Roolit ja tiimit 37 
4.1.4 Elinkaari 39 

4.2 Scrum 41 

4.2.1 Empiirinen prosessienhallinta 41 
4.2.2 Scrum-roolit 42 

4.2.3 Scrum-viitekehys 43 

4.3 Kanban 46 

4.3.1 Viitekehys 47 

4.3.2 Kanban-taulu 48 

5 TUTKIMUSASETELMA 50 

5.1 Aineistonkeruumenetelmät 50 

5.1.1 Kysely 50 
5.1.2 Teemahaastattelut 51 

5.2 Tutkimusaineiston analysointi  52 

  



 2 

6 TUTKIMUSAINEISTO JA -TULOKSET 54 

6.1 Projektien perustiedot 54 

6.2 Esikyselyn tulokset 56 

6.3 Teemahaastattelun tulokset 58 

6.3.1 Yksilöt ja kanssakäyminen 58 
6.3.2 Toimiva ohjelmisto 60 
6.3.3 Asiakasyhteistyö 62 
6.3.4 Muutokseen vastaaminen 66 

6.4 Yhteenveto tutkimustuloksista 69 

7 JOHTOPÄÄTÖKSET 74 

LÄHDELUETTELO 75 

LIITTEET 79 

LIITE 1. Esikysely 79 

LIITE 2. Teemahaastattelukysymykset 80 

 



 3 

KUVALUETTELO                         sivu

      

 Vesiputousmallin vaiheet (Royce 1970) 13 

 Prosessilajit (IEEE Std 15288 2008: 12). 15 

 Organisaation prosessit (ISO/IEC 15288 2005:60.) 16 

 Extreme Programming -projektin sisältö kuvattuna yleisellä tasolla (Schuh 

2005: 21) 34 

 Extreme Programming -elinkaaren vaiheet mukailtuna (Abrahamsson ym. 

2002:19) 39 

 Scrum -viitekehys (Rubin 2013:17) 44 

 Esimerkki Kanban -taulusta (VersionOne 2015). 48 

 

 

TAULUKKOLUETTELO                       sivu 

 

Taulukko 1. Ohjelmiston elinkaaren vaiheet (ISO/IEC 15288 2005:57.) 12 

Taulukko 2. Ketterän ja perinteisen lähestymistavan merkittävimmät eroavaisuudet 

osa-alueittain. (Awad 2005.) 25 

Taulukko 3. Ketterän ja perinteisen lähestymistavan eroavaisuudet periaatteittain. 

(Aitken & Ilango 2013.) 27 

Taulukko 4. Tärkeimmät menestystekijät ketterässä ohjelmistokehitysprojektissa 

ominaisuuksineen (Chow & Cao 2007). 32 

Taulukko 5. Esikyselyn teemat 51 

Taulukko 6. Teemahaastattelun teemat 51 

Taulukko 7. Projektien perustiedot 55 

Taulukko 8. Esikyselyn teemoittain saadut vastauskeskiarvot projektikohtaisesti 56 

Taulukko 9. Yksilöt ja kanssakäyminen tutkimuskohteena toimineissa projekteissa 

  58 

Taulukko 10.Toimiva ohjelmisto tutkimuskohteena toimineissa projekteissa 61 

Taulukko 11. Asiakasyhteistyö tutkimuskohteena toimineissa projekteissa 63 

Taulukko 12. Muutokseen vastaaminen tutkimuskohteena toimineissa projekteissa 66 

 

 

file:///C:/Users/Jaana%20%20koti/Desktop/HENRI/GGG%20HN%20261015%20LL%20korjattu%20sivulle%2037.docx%23_Toc433728998
file:///C:/Users/Jaana%20%20koti/Desktop/HENRI/GGG%20HN%20261015%20LL%20korjattu%20sivulle%2037.docx%23_Toc433728999
file:///C:/Users/Jaana%20%20koti/Desktop/HENRI/GGG%20HN%20261015%20LL%20korjattu%20sivulle%2037.docx%23_Toc433729000
file:///C:/Users/Jaana%20%20koti/Desktop/HENRI/GGG%20HN%20261015%20LL%20korjattu%20sivulle%2037.docx%23_Toc433729001
file:///C:/Users/Jaana%20%20koti/Desktop/HENRI/GGG%20HN%20261015%20LL%20korjattu%20sivulle%2037.docx%23_Toc433729001
file:///C:/Users/Jaana%20%20koti/Desktop/HENRI/GGG%20HN%20261015%20LL%20korjattu%20sivulle%2037.docx%23_Toc433729002
file:///C:/Users/Jaana%20%20koti/Desktop/HENRI/GGG%20HN%20261015%20LL%20korjattu%20sivulle%2037.docx%23_Toc433729002
file:///C:/Users/Jaana%20%20koti/Desktop/HENRI/GGG%20HN%20261015%20LL%20korjattu%20sivulle%2037.docx%23_Toc433729003
file:///C:/Users/Jaana%20%20koti/Desktop/HENRI/GGG%20HN%20261015%20LL%20korjattu%20sivulle%2037.docx%23_Toc433729004


 4 

VAASAN YLIOPISTO 

Teknillinen tiedekunta 

Tekijä:   Henri Nyholm 

Tutkielman nimi: Tapaustutkimus: Miten IT -organisaatio 

hyödyntää ketterän kehityksen arvoja ja pe-

riaatteita ohjelmistoprojekteissa? 

Ohjaajan nimi:  Laura Lappalainen 

Tutkinto:   Kauppatieteiden maisteri 

Oppiaine:   Tietotekniikka 

Opintojen aloitusvuosi:  2013 

Tutkielman valmistumisvuosi: 2016 Sivumäärä: 82 

TIIVISTELMÄ: 

 

Tämän pro gradu -tutkielman tutkimusaiheena on ketterä ohjelmistokehitys sekä ket-

terän kehityksen arvot ja periaatteet. Tutkielmassa luodaan lukijalle selkeä käsitys ket-

terän ohjelmistokehityksen taustasta sekä ketteryyden periaatteista ja arvoista. Tutkiel-

man tavoitteena on selvittää mitä hyötyjä organisaatio voi saavuttaa ketterillä toimin-

tatavoilla ja toisaalta, voiko ketteryys muodostua haitaksi tai uhaksi organisaatiolle. 

Tätä tarkastellaan erityisesti tutkimuskohteena olevan yrityksen tapauksessa. Tutkiel-

massa selvitetään mikä tai mitkä periaatteet ketterässä kehityksessä vaativat edelleen 

organisaatiotasolla lisähuomiota ja kuinka näitä periaatteita sekä niihin liittyviä käy-

täntöjä olisi mahdollista kehittää. 

 

Tutkielman teoreettinen viitekehys on muodostettu aiemmasta tutkimusaineistosta in-

duktiivisena kirjallisuuskatsauksena. Teoriakokonaisuus johdetaan ohjelmistokehityk-

sen alan kirjallisuudesta sekä tieteellisistä artikkeleista. Keskeisimpiä tutkimuksessa 

hyödynnettyjä lähteitä ovat the Agile Alliancen julkaisut sekä Robert C. Martinin teos 

Agile software development: principles, patterns and practices, joihin perustuu kette-

rän kehityksen arvot ja periaatteet. Tutkimuksen empiirinen osa on toteutettu teorioita 

testaavana kolmen (3) casen tapaustutkimuksena. Pyrkimyksenä on 1) löytää yhtäläi-

syyksiä onnistuneista projekteista ja 2) pystyä tuottamaan ennakoidusta syystä vastak-

kaisia tuloksia. 

 

Tutkimustuloksilla voidaan selkeästi osoittaa, kuinka kohteena toimiva IT-organisaa-

tio hyödyntää the Agile Manifeston mukaisia ketterän kehityksen periaatteita ja arvoja. 

Tutkimuksen tuloksena saadaan aikaan kuvaus ketterän kehityksen myötä organisaa-

tion saavuttamista hyödyistä sekä mahdollisista kehityskohteista tai haasteista. Tutki-

mustulosten perusteella voidaan vahvistaa, että ketterän ohjelmistokehitysprojektin 

onnistumisen tason ja projektissa hyödynnettyjen ketterien periaatteiden ja arvojen vä-

lillä on riippuvuus.  

 

 

AVAINSANAT: ketterä kehitys, ketterät menetelmät, ohjelmistokehitysprojekti,  pro-

jektihallinta 



 5 

UNIVERSITY OF VAASA 

Faculty of technology 

Author:   Henri Nyholm 

Topic of the Master’s Thesis: Tapaustutkimus: Miten IT -organisaatio  

hyödyntää ketterän kehityksen arvoja ja pe-

riaatteita ohjelmistoprojekteissa? 

Instructor:   Laura Lappalainen 

Degree: Master of Science, Economics and Business 

Administration 

Major:   Computer Science 

Year of entering the University: 2013 

Year of completing the Thesis: 2016  Pages: 82 

ABSTRACT: 

 

Subject of this Master’s thesis is agile software development and agile values and prin-

ciples. Theoretical part of the study is aiming to form clear picture of the background 

of agile software development and values and principles behind it. The aim of this 

study is to find out what kind of benefits an organization can reach by using agile 

values and principles and also to find out if those can militate against organization. 

This issue will be treated especially in the case of the subject organization. This thesis 

aims to find out which agile principles require more attention at organization level and 

how those principles could be developed. 

 

The theoretical framework of the study has been formed of earlier publications and 

studies as an inductive literary review. The theoretical framework is based on literature 

of the discipline of  software development and scientific researches. Publications of 

the Agile Alliance and Agile software development: principles, patterns and practices 

by Robert C. Martin form the most important references of the study. The empirical 

part of the study has been conducted as a case study that is based on three cases. The 

aim was 1) to find out similarities of successful projects and 2) to be able to find out 

oppositions of projects. 

 

The results of the study show how the subject organization takes advantage of the agile 

values and principles mentioned in the Agile Manifesto. As a result, this study forms 

a picture of benefits achieved and possible targets of development in the subject or-

ganization based on using agile software development. The results of the study con-

firm that there is relation between successful projects and the level of agility used in 

the projects. 

 

 

 

 

 

 

KEYWORDS: agile development, agile methodologies, software development pro-

ject,  project management 



 6 

1 JOHDANTO 

Projekti on tapa saavuttaa jokin päämäärä selkeästi suunniteltuna hankkeena. Perintei-

sesti projekteja voidaan löytää arjen yksinkertaisimmistakin ilmiöistä – esimerkiksi 

yksittäisen kotitalouden tietystä arvoltaan suuremmasta hankinnasta tai vaikkapa op-

pilaiden peruskouluesitelmästä. Tekniikan alalla ja erityisesti IT -organisaatioissa 

tuotteita ja palveluita rakennetaan projektiluontoisesti. Projekti ei toki ole vain tämän 

tieteen ja teollisuuden alan käyttämä tapa kehittää tuotteita. IT-projektit ovat usein 

muiden palvelualojen projekteihin verrattuina aikataulullisesti hyvin laajoja ja saatta-

vat olla kestoltaan merkittävän pitkiä, jopa useita vuosia. Digitalisaation murroksen 

myötä juuri IT –palvelualan projektit ovat hyvin seurattuja ja jokapäiväinen osa lähes 

kaikkien toimialojen uudistumista sekä liiketoiminnan kehittymistä digitaalisempaan 

suuntaan. IT –palvelualalla toimivat organisaatiot pyrkivät parantamaan asiakkaidensa 

kilpailukykyä kehittämällä näiden liiketoimintaa digitaalisin ratkaisuin. Projekteilla 

pyritään saamaan aikaan mahdollisimman suuri liiketoiminnallinen hyöty sekä asia-

kas- että toimittajaorganisaation näkökulmasta. Ominaista projekteille on käytössä 

olevat resurssit, olemassa olevat riskit, projektiin kuuluvat henkilöt tai tahot, mutta 

ennen kaikkea se, miten projektit kokonaisuutena toteutetaan ja kuinka projektin eri 

vaiheita hallitaan.  

 

Ohjelmistotuotannossa on viimeisten kahden vuosikymmenen ajan tehty muutosta 

kohti uudenlaista projektihallintaa – ketterää ohjelmistokehitystä.  Ketterällä ohjelmis-

tokehityksellä ja ketterillä menetelmillä pyritään luomaan uusi tapa toimia raskaam-

pien vaihejakomallien, kuten vesiputousmallin sijaan. Muutos kohti ketterää kehitystä 

perustuu alan asiantuntijoiden näkemyksiin siitä, miten ohjelmistokehitystä voitaisiin 

tehdä paremmin ja tehokkaammin keinoin päätavoitteena minimoida riskejä sekä toi-

mia mahdollisimman kustannustehokkaasti. Ketterät menetelmät ovat levinneet laa-

jalle vuoden 2001 ketterän ohjelmistokehityksen julistuksen, the Agile Manifeston 

esiintulon jälkeen, pyrkien vastaamaan edellä mainittujen perinteisten menetelmien 

raskaaseen rakenteeseen. Ketterässä kirjallisuudessa ketterillä menetelmillä viitataan 

ketterän allianssin Agile Alliancen asiantuntijoiden kehittämiin ja jalostamiin mene-

telmiin, kuten Scrumiin tai eXtreme Programmingiin. Menetelmäkohtaisista yksityis-

kohdista huolimatta näillä useilla eri menetelmillä on paljon yhteistä, kuten lyhyisiin 

iteraatioihin perustuvat elinkaaret, nopea ja suora palaute asiakkailta sekä jatkuva op-

piminen.  

 



 7 

Tässä tutkielmassa esitetään tapaustutkimuksena erään IT -organisaation tapa toteuttaa 

ketterää kehitystä sekä kuvataan ketterän ohjelmistokehityksen ominaispiirteet sekä 

käytetyimmät menetelmät. Tutkielmassa projektihallintaa tarkastellaan nykyaikaisesta 

näkökulmasta sekä luodaan käsitys siitä, että ketterä kehitys perustuu yksinkertaisten 

asiakokonaisuuksien oikeanlaiseen hallintaan ja sitä on mahdollista hyödyntää lopulta 

lähes missä tahansa projektissa. 

1.1 Tutkimuksen tavoite ja rajaus 

Tämän pro gradu -tutkielman teoreettinen viitekehys luo lukijalleen selkeän käsityk-

sen ketterän ohjelmistokehityksen taustasta sekä ketteryyden periaatteista ja arvoista. 

Siinä kuvataan näiden periaatteiden ja arvojen ilmentyminen sekä merkitys ketterän 

ohjelmistoprojektin aikana. Tutkielman empiirisessä tutkimusosiossa selvitetään, 

kuinka IT -ratkaisuja –ja palveluita tarjoava organisaatio hyödyntää ketterän ohjelmis-

tokehityksen arvoja ja periaatteita ohjelmistoprojekteissa käytännössä. Mikäli kohde-

organisaatio ei hyödynnä projekteissaan mitään tiettyjä tai tiettyä yleisesti käytettyä 

ohjelmistonkehitysmenetelmää (kuten Scrum tai eXtreme Programming), määritellään 

sen käyttämä menetelmä ja selvitetään sen suhde muihin yleisesti käytettyihin mene-

telmiin.  

 

Tutkielman tavoitteena on selvittää mitä hyötyjä tutkimuksen kohteena oleva organi-

saatio voi saavuttaa ketterillä toimintatavoilla ja toisaalta, voiko ketteryys muodostua 

haitaksi tai uhaksi organisaatiolle. Tutkielmassa saadaan selville mikä tai mitkä peri-

aatteet ketterässä kehityksessä vaativat edelleen organisaatiotasolla lisähuomiota ja 

kuinka näitä periaatteita sekä niihin liittyviä käytäntöjä olisi mahdollista kehittää.   

 

Tutkielman tutkimuskysymys on: 

 

Kuinka IT -ratkaisuja –ja palveluita tuottava organisaatio hyödyntää ketterän ohjel-

mistokehityksen arvoja ja periaatteita? 

 

Tutkimuskysymys voidaan jakaa seuraaviin alakysymyksiin: 

 Käytetäänkö organisaatiossa yleisesti käytettyjä ketteriä menetelmiä? Jos ei, 

onko sillä jokin oma menetelmä ja mikä on sen suhde yleisiin kehitysmenetel-

miin? 



 8 

 Miten organisaatio hyötyy ketteristä arvoista ja periaatteista? 

 Onko projektien onnistuneisuuden ja niissä hyödynnettyjen ketterien arvojen 

ja periaatteiden välillä riippuvuutta? 

1.2 Tutkimusaineisto ja -menetelmät 

Tässä pro gradu -tutkielmassa on käytetty kahta eri menetelmää tutkimusaineiston ke-

räämiseen. Esikyselyn avulla kerätään ennakkotietoa tutkimuskohteina olevista pro-

jekteista ja teemahaastattelulla tarkennetaan kyselyssä esiintyviä näkökulmia. Tutki-

musaineisto perustuu kolmeen tutkimuskohteena olleeseen ohjelmistokehitysprojek-

tiin. Alla on esitelty käytössä olleet aineistonkeruumenetelmät, jotka ovat kysely ja 

teemahaastattelu. 

 

Ensimmäinen tutkielman tiedonkeruutekniikoista on kysely. Kysely on tutkijan itsensä 

tapa kerätä aineistoa. Se on keskeinen menetelmä survey-tutkimukselle, mutta käytän-

nöllinen myös yhdistettynä kvalitatiiviseen tutkimusmenetelmään. Tässä tutkimuk-

sessa kysely toimii tukiaineistona ja tuo siten lisäarvoa juuri yhdistettynä kvalitatiivi-

seen aineistonkeruumenetelmään. Kysely voidaan toteuttaa monin erilaisin keinoin ja 

usealla eri tavalla. Kyselyä valittaessa tai käytettävää aineistonkeruumenetelmää pe-

rustellessa on tärkeää pohtia, milloin koehenkilöiden on saatava toimia vapaasti ja mil-

loin on järkevämpää käyttää ennalta määrättyä strukturoitua tekniikkaa. Kyselylomak-

keen huolellinen laatiminen – tutkimusaiheen valitsemisen ohella – voi olla hyvinkin 

merkittävässä asemassa tutkimuksen onnistumista ajatellen. Kysely voidaan perustaa 

avoimiin kysymyksiin, monivalintakysymyksiin tai asteikkoihin eli skaaloihin. Tässä 

tutkielmassa valittu asteikkoihin perustuva kysymystyyppi perustuu ajatukseen, että 

vastaaja antaa näkemyksensä siitä, kuinka voimakkaasti on samaa tai eri mieltä esite-

tystä väittämästä. (Järvinen & Järvinen 2011: 147.) 

 

Haastattelutekniikaksi voidaan valita tutkielmasta riippuen avoin, puolistrukturoitu tai 

strukturoitu haastattelu riippuen siitä, onko kysymysten vastausvaihtoehdot ennalta 

määritellyt. Tässä tutkielmassa tekniikaksi on valittu avoin haastattelu, jossa tutkimus-

teemat ohjaavat haastattelua. Tässä tutkimuksessa teemat on hyvin selkeästi johdetta-

vissa teoreettisesta viitekehyksestä, joten teemoihin perustuva haastattelu on toimivin 

vaihtoehto. Haastattelun kohteiksi on valittu kohdeorganisaatiosta kolme edustajaa, 

jotka ovat toimineet johtotehtävässä ketterässä ohjelmistoprojektissa. Haastattelussa 



 9 

saadaan avoimien kysymysten avulla  selville mahdollisimman kattavasti organisaa-

tiossa hyödynnettyjä ketteriä toimintatapoja. Haastattelussa tutkija keskustelee haas-

tattelun kohteena olevan henkilön kanssa, joka edustaa haastattelussa tietolähdettä. 

Haastattelun etuna on juuri elävä vuorovaikutustilanne, jolloin tutkijan on mahdollista 

haastattelutilanteessa tarkentaa kysymyksiään lisäkysymyksillä ja siten saada lisää 

uutta tietoa. Haastattelussa on erityisen tärkeää, että tutkija kykenee asettumaan haas-

tateltavan asemaan ja katsomaan tilannetta tämän silmin. (Järvinen & Järvinen 2011:.)  

1.3 Tutkielman rakenne 

Tutkielman toisessa luvussa esitellään tutkielman lähtökohta – ohjelmistoprojekti sekä 

sen elinkaari ja elinkaaren sisältö. Tutkielman kolmannessa luvussa esitellään tutki-

musaiheen perusta eli ketterä ohjelmistokehitys ja luodaan lukijalle käsitys ketteryy-

den lähtökohdista sekä taustalla merkittävästi vaikuttavasta Agile Alliancesta. Neljän-

nessä luvussa esitellään tutkielman läpiviennin kannalta tärkeässä roolissa olevia ket-

teriä menetelmiä ja niiden perusominaisuuksia. Tutkielman viides luku sisältää ku-

vauksen tutkimusympäristönä toimineesta kohdeorganisaatiosta sekä tutkielmassa 

käytetyistä tutkimusmenetelmistä. Kuudes luku käsittää itse tutkimusaineiston sekä 

tutkimustulokset. Seitsemännessä ja viimeisessä luvussa kuvataan tutkimuksen yh-

teenveto sekä esitetään mahdollisia jatkotutkimuskohteita.   



 10 

2 OHJELMISTOPROJEKTI 

Ohjelmistotuotteita rakennettaessa ja teknisiä ratkaisuja tarjotessa hyödynnetään usein 

erilaisia projektimalleja, joita perinteisesti ajatellaan elinkaarina. Ohjelmistoprojektin 

elinkaari alkaa tilannekartoituksella ja asiakkaan intressien määrittämisellä ja päättyy 

tilanteeseen, jossa ohjelmistotuotteen voidaan todeta olevan valmis siirrettäväksi syr-

jään ja mahdollisesti korvattavaksi uudella, nykyaikaisemmalla ja kehittyneemmällä 

tuotteella. Tällainen projekti tai elinkaari koostuu tietyistä vaiheista, jotka sisältävät 

usein tiettyjä prosesseja. Elinkaari määritellään tarkemmin alaluvussa 2.1.. Tekniikan 

alalla hyödynnetään yleisesti standardeja, jotka toimivat kansainvälisinä ohjeistuksina 

ja suuntaviivoina yhdenmukaisuuden takaamiseksi. Tässä luvussa kuvataan tekniikan 

alalla hyödynnettävän standardin IEEE Std 15288™ pohjalta ohjelmiston elinkaarta ja 

siihen sisältyvät prosessit sekä kuvataan perinteisimmin käytettyjä elinkaarimalleja, 

vesiputousmallia ja iteratiivista mallia. Vesiputousmalli valittiin esiteltäväksi, koska 

sitä pidetään perinteisenä elinkaarimallina ohjelmistokehityksessä ja iteratiivinen 

malli edustaa niin sanottua uutta, kevytrakenteisempaa ajattelua, joka on merkittävä 

osa ketterää kehitystä. 

2.1 Elinkaari 

Ohjelmistotuotanto perustuu tuotettavien tuotteiden tai palveluiden elinkaariin. Ohjel-

mistotuotteen ajatellaan syntyvän ja sen elinkaaren jatkuvan niin kauan, kun se on toi-

mintaympäristönsä käytössä. Ohjelmistojen elinkaarta on kuvattu alalle ominaisesti 

standardein. ISO/IEC 15228 -standardi kuvaa ohjelmiston elinkaaren, siihen kuuluvat 

prosessit ja sen toimintaympäristön tarkemmin. Tämän kansainvälisen standardin mu-

kaan kohteena olevaa tuotetta tai palvelua ajatellaan keinotekoisena järjestelmänä, 

joka on luotu tuottamaan palveluita määrätyssä ympäristössä käyttäjien ja sidosryh-

mien hyödynnettäväksi. Tällaiset järjestelmät voivat olla määriteltyjä toimimaan yk-

sittäisten tai useampien laitteiden, ohjelmistojen, ihmisten, prosessien, proseduurien, 

olosuhteiden tai luonnollisten olioiden kanssa. (IEEE Std 15288™ 2008: 52.) Tässä 

luvussa esitellään elinkaaren peruslähtökohdat sekä alalla perinteisimmin esiintyvät 

elinkaarimallit. 



 11 

2.1.1 Elinkaarimalli ja elinkaaren vaiheet 

Jokaisella edellä kuvatulla järjestelmällä on siis oma elinkaarensa, jota voidaan luon-

nehtia käyttäen abstraktia toiminnallista mallia, joka kattaa järjestelmän tarpeen, to-

teuttamisen, hyödynnettävyyden, kehitettävyyden ja hävittämisen. Tällainen järjes-

telmä kehittyy elinkaarensa aikana ihmisistä koostuvien organisaatioiden hallin-

noimien ja toteuttamien prosessien tulosten myötä. Nämä prosessit sekä niiden seu-

raukset, suhteet ja vaiheet määrittävät järjestelmän elinkaarimallin yksityiskohdat. 

Standardissa on määritetty joukko nimettyjä prosesseja, joiden pohjalta on mahdollista 

mallintaa järjestelmän elinkaarta. (IEEE Std 15288™ 2008: 10.) 

 

Elinkaaret vaihtelevat järjestelmän luonteen, tarkoituksen, käytön ja vallitsevien olo-

suhteiden mukaan. Huolimatta rajattoman laajasta elinkaarten kirjosta, on olemassa 

tietyt, välttämättömät vaiheet, jotka löytyvät jokaisesta kokonaisvaltaisesta järjestel-

mäelinkaaresta. Kukin vaihe suunnitellaan ja toteutetaan elinkaaren aikana harkiten 

sekä niillä on selkeä tarkoitus ja panos koko elinkaaressa. Vaiheet edustavat järjestel-

män elinkaaren pääperiodeita ja ne koskevat järjestelmäkuvauksen tai itse järjestelmän 

tilaa. Elinkaarivaiheet kuvaavat järjestelmän edistymistä, kehitystä ja sen saavuttamia 

virstanpylväitä elinkaaren aikana. Organisaation luodessa tai hyödyntäessä kohteena 

olevaa järjestelmää, se käyttää ns. päätösportteja (engl. Decision gates), jotka määrit-

tävät seuraavaksi toteutettavat toimet järjestelmän elinkaarella. Päätösporttien avulla 

voidaan hallita elinkaaren varrelle olennaisesti kuuluvia riskejä ja epätietoisuutta liit-

tyen kustannuksiin, aikatauluun ja toimivuuteen. Elinkaaren päävaiheet luovat perus-

tan näille ensisijaisille päätösporteille. Näin ollen elinkaarivaiheiden avulla yritysjoh-

dolla on korkeantason näkemys ja kontrolli toteutettavasta projektista tai teknisestä 

prosessista. (IEEE Std 15288™ 2008: 10-11.) 

 

Taulukossa 1 on esitelty yleisimmin käytetty esimerkki elinkaarivaiheista. Taulukossa 

on myös kuvattu kunkin vaiheen lähtökohtainen tarkoitus sekä mahdolliset päätös-

vaihtoehdot riskien- ja saavutustenhallintaan elinkaaren etenemisen aikana. Organi-

saatiot soveltavat vaiheita ja niiden järjestystä eri tavoin kyetäkseen vastaamaan käy-

tössä oleviin liiketoiminta- ja riskinhallintastrategioihin. Vaiheiden samanaikainen ja 

eri järjestyksissä tapahtuva toteuttaminen voi johtaa ominaisuuksiltaan hyvin erilaisiin 

elinkaariin. Vaiheittain järjestyksessä toteutettavat tavat ovat yleisesti käytettyjä, 

mutta vaihtoehtoisesti sopiva näiden risteymä voidaan kehittää. Standardissa viitataan 



 12 

tällaisen kehityksen riippuvan useista tekijöistä, kuten vallitsevasta liiketoimintakon-

tekstista, järjestelmän luonteesta ja monimutkaisuudesta, vaatimusten stabiiliudesta, 

teknologisista mahdollisuuksista, järjestelmän suorituskykyyn kohdistuvista vaati-

muksista eri vaiheissa sekä käytössä olevista resursseista ja budjetista. (ISO/IEC 

15288 2005: 57.) 

 

 

ELINKAARIVAIHE TARKOITUS PÄÄTÖSPORTIT 

KONSEPTI 
 Identifioi sidosryhmien 

tarpeet 

 Tutki konsepteja 

 Esitä toteuttamiskelpoisia 

ratkaisuja 

 Toteuta seuraava vaihe 

 Jatka tässä vaiheessa 

 Palaa edeltävään vai-

heeseen 

 Jäädytä projekti 

 Päätä projekti 

KEHITYS 
 Jalosta järjestelmän vaati-

mukset 

 Laadi ratkaisun kuvaus 

 Rakenna järjestelmä 

 Verifioi ja validoi 

TUOTANTO 
 Toteuta järjestelmät 

 Tutki ja testaa 

HYÖDYNTÄMINEN 
 Hoida järjestelmää tyy-

dyttääksesi asiakkaan tar-

peet 

TUKI 
 Ylläpidä järjestelmän suo-

rituskykyä 

VETÄYTYMINEN 
 Järjestelmän varastointi, 

arkistointi tai hävittämi-

nen 

Taulukko 1. Ohjelmiston elinkaaren vaiheet (ISO/IEC 15288 2005:57.)  

 

 

Jokainen vaihe tulee ottaa huomioon läpi järjestelmän elinkaaren ja niitä tulee harkita 

kaikissa muissakin elinkaaren vaiheissa. Jokainen järjestelmän elementti vaikuttaa ko-

konaisuuteen, joten eri vaiheiden ja järjestelmän osien tulee voida toimia yhtenä, 

eheänä kokonaisuutena läpi elinkaaren. Tällainen elinkaarivaiheiden ja toiminnallisten 

vaikuttajien välinen synergia on ehdotonta onnistuneiden projektitoimintojen saavut-

tamiseksi. Projektitiimin jäsenten välinen kommunikaatio sekä erilaisten toimijoiden 

ja organisaatioiden vastuuntuntoisuus eri elinkaaren vaiheissa johtavat johdonmukai-

seen sekä yhtenäiseen elinkaarikokonaisuuteen. (IEEE Std 15288™ 2008: 10-11.) 



 13 

2.1.2 Vesiputousmalli 

Ensimmäisen ohjelmistokehitysprojekteissa käytetyn elinkaarimallin, vesiputousmal-

lin esitteli nykyisessä muodossaan Winston W. Royce (1970). Vesiputousmalli on yk-

sinkertainen, vaiheesta seuraavaan etenevä elinkaarimalli. Vesiputousmalli perustuu 

nimensä mukaisesti siihen, että jokainen mallin vaihe suoritetaan vain kerran ja lop-

puun asti, kunnes siirrytään elinkaaren seuraavaan vaiheeseen – vesiputouksessa ei 

liikuta ylöspäin. 

  

 

 

 

 

Vesiputousmallin esitutkimusvaiheessa asetetaan asiakkaan näkemysten pohjalta ylei-

set vaatimukset koko toteutettavalle ohjelmistolle. Määrittelyvaiheessa tarkennetaan 

esitutkimusvaiheen tuloksena syntyneitä yleisiä vaatimuksia, laaditaan ohjelmistolle 

toiminnalliset ja tekniset vaatimukset sekä ei-toiminnalliset vaatimukset ja rajoitukset. 

Määrittelyn tuloksen syntyy dokumentti, joka tunnetaan toiminnallisena määrittelynä 

tai vaatimusmäärittelydokumenttina. Suunnitteluvaiheessa määritetään se, miten oh-

jelmisto lopulta rakennetaan. Tuloksena syntyy tekninen dokumentaatio, joka käsittää 

muiden muassa ohjelmiston arkkitehtuurin sekä moduulisuunnittelun. Toteutusvai-

Esitutkimus

Määrittely

Suunnittelu

Toteutus

Testaus

Ylläpito

 Vesiputousmallin vaiheet (Royce 1970) 



 14 

heessa tehdään itse koodaustyö ja toteutetaan halutunlainen ohjelmisto. Testausvai-

heessa tuotettu ohjelmisto testataan vaiheissa ja pyritään löytämään tuotetusta koodista 

mahdolliset virheet. Käyttöönottovaihe perustuu ohjelmiston julkaisemiseen asiak-

kaan käyttöön ja ylläpitovaihe ohjelmiston ylläpitotyöhön, kuten myöhemmin löyty-

vien virheiden korjaamiseen, ohjelmiston muutoksiin sekä laajentamiseen. (Haikala & 

Mikkonen 2011). 

2.1.3 Iteratiivinen malli 

Iteratiivinen elinkaarimalli on vuosikymmeniä kehittynyt ideologia, jossa ohjelmiston 

tuottaminen perustuu perättäisiin sykleihin eli iteraatioihin. Edellä kuvattu vesiputous-

malli on vahvasti iteratiivisen mallin taustalla – kaikki vaiheet suoritetaan miniprojek-

tin tavoin iteraatiossa läpi. Kiinteiden määrittelyjen sijaan iteratiivisessa mallissa ke-

hitystyö alkaa määrittelemällä ja suunnittelemalla vain osa ohjelmistosta. Kunkin ite-

raation jälkeen saadaan uusi versio ohjelmistosta. Iteratiivisen mallin perusajatuksena 

ovat juuri ajalliset vaatimukset – kullekin iteraatiolle määritetään aikataulu, johon 

mennessä kyseinen iteraatio tulee päätökseen. Iteraation aikana tehdään aiemmin 

suunniteltu työ ja iteraation päätyttyä pyritään saamaan ulkoisista lähteistä, kuten asi-

akkaalta kehitysehdotuksia ja esimerkiksi uusia vaatimuksia, jotka toteutetaan seuraa-

vassa iteraatiossa. Iteratiivisen mallin etuna on se, että kyetään tuottamaan toimiva 

malli ohjelmistosta hyvin aikaisessa vaiheessa projektia, jolloin toiminnallisten ja ra-

kenteellisten heikkouksien löytäminen on mahdollista jo projektin alussa. (Basili & 

Larman 2003: 2). 

2.2 Prosessit 

Ohjelmistoprojekti ja sen myötä ohjelmiston elinkaari kattaa poikkeuksetta tietyn 

määrän prosesseja, joilla kullakin on fokus jossain tietyssä projektin osassa tai elin-

kaaren vaiheessa. Tyypillisesti organisaatiot hajauttavat sisäiset liikkeenjohdolliset 

vastuualueensa ja toimintonsa. Yhdessä nämä alueet kuitenkin vaikuttavat organisaa-

tion liiketoiminnalliseen suorituskykyyn. IEEE Std 15288™-standardissa (2008: 59) 

organisaation prosesseja on käsitelty kolmen vastuualueen näkökulmasta: koko yhtiön 

kattavat prosessit, projekteja koskevat prosessit ja tekniset prosessit. Kunkin katego-

rian prosessit yhtenäisenä kokonaisuutena vaikuttavat tehokkaaseen järjestelmien luo-

miseen ja käyttämiseen, ja ovat sitä kautta merkittävä tekijä organisaation tavoitteiden 



 15 

saavuttamisen kannalta. Lisäksi eri organisaatiot ja organisaatioiden eri vastuualueet 

yleisesti luovat suhteita ja tiedostavat vastuitaan tekemällä sopimuksia. Sopimuksilla 

pyritään yhtenäistämään ja eheyttämään eri vastuualueilla tehtyjä päätöksiä tavoitellen 

yhteistä, yhdenmukaista liiketoiminnallista tarkoitusta. Kuviossa 2 on esitetty proses-

silajit ja niiden ominaisuudet. 

 

 

 

 

 

Seuraavissa kappaleissa esitellään kunkin edellä kuvatun prosessilajin pääpiirteet. So-

pimusprosessit ovat merkittävä tekijä, koska ohjelmistotuotannossa ja tietoteknisessä 

liiketoiminnassa organisaatiot ovat järjestelmille sekä toimittajia eli palveluntarjoajia 

että kuluttajia eli asiakkaita ja he käyvät kauppaa tuotteilla sekä palveluilla. Tehtyään 

sopimuksen, on kaksi organisaatiota tilanteessa, jossa organisaatio, hankkijan ase-

massa, teettää toisella, toimittajana toimivalla organisaatiolla tuotteita tai palveluita. 

 Prosessilajit (IEEE Std 15288 2008: 12). 



 16 

Yleisesti organisaatiot toimivat samanaikaisesti tai peräkkäin sekä järjestelmiä hank-

kivana että tuottavana osapuolena (Kuvio 3). Kuviossa pystysuunnassa esitettyjen or-

ganisaatioiden A ja B voidaan ajatella edustavan toimitusketjuun kuuluvia organisaa-

tioita, jotka käyvät kauppaa ollessaan samassa vaiheessa sillä hetkellä työn alla olevan 

projektinsa elinkaarella.  

 

 

 

 

 

Samanaikaisesti vaakasuunnassa kuvattu suhde organisaatioiden A ja C välillä esittää 

tilannetta, jossa organisaatiot ovat perättäisissä vaiheissa elinkaarellaan.  Kuviossa 3 

esitetään tilannetta, jolla halutaan selvittää, että organisaatiolla on usein sopimuksia 

 Organisaation prosessit (ISO/IEC 15288 2005:60.) 



 17 

eri yhteistyöorganisaatioiden kanssa samanaikaisesti – jotkut organisaatiot edustavat 

samassa elinkaaren vaiheessa toimivia, jotkut taas vaiheen edellä tai jäljessä ole-

via.(IEEE Std 15288™ 2008: 12.) 

 

Yhtiötä kokonaisuutena koskevat eli yhtiöprosessit pyrkivät IEEE- standardin 

15288™ (2008: 13) mukaan takaamaan, että organisaation hallinnollisten tahojen tar-

peet ja odotukset kohtaavat.  Tällaiset koko yhtiön kattavat prosessit koskevat yleisesti 

strategista johtoa, organisaation liiketoiminnan parantamista, resurssien ja varallisuu-

den järjestelyjä sekä kehittämistä tai riskienhallintaa. Vastuu tällaisista prosesseista on 

luonnollisesti organisaation korkeimmalla tasolla. Nämä prosessit ovat useissa orga-

nisaatioissa liiketoiminnallisen linjan taustalla ja selkeyttävät voiton tavoittelun motii-

veja. (IEEE Std 15288™ 2008: 13.)  

 

Projektiprosessit koskevat yritysjohdon allokoimien resurssien ja varallisuuden hal-

lintaa ja niiden kohdentamista organisaation tekemiin sopimuksiin sekä sopimusten 

täyttämiseen. Prosessit koskevat projektien hallintaa, erityisesti kulujen, aikataulujen 

ja tavoitteiden suunnittelua sekä toimintojen tarkastamista suunnitelmien ja suoritus-

kyvyn kriteerien mukaisuuden varmistamiseksi. Juuri projektiprosesseilla pyritään 

tunnistamaan toiminnot, joilla voidaan ehkäistä elinkaarella etenemisen hidastumista. 

(IEEE Std 15288™ 2008: 13.) 

 

Tekniset prosessit ilmenevät teknisinä toimintoina koko elinkaaren ajan. Niiden tar-

koituksena on muuntaa sidosryhmien tarpeet ensin tuotteeksi ja sitten, tuotetta sovel-

tamalla, tuottaa ylläpidettävä palvelu tarpeiden mukaisesti, joka saavuttaa asiakastyy-

tyväisyyden. (IEEE Std 15288™ 2008: 13.) 

 

Standardin IEEE 15288™ (2008: 13) mukaan järjestelmän elinkaaren aikana mikä ta-

hansa prosesseista voidaan toteuttaa vaatimusten mukaan missä tahansa vaiheessa, 

eikä niiden käytölle ole määrättyä järjestystä. Prosessien toteuttamisen järjestykseen 

ja ajankohtaan vaikuttaa usein sosiaaliset, kaupalliset, organisatoriset ja tekniset näkö-

kulmat, jotka kaikki voivat vaihdella ja elää merkittävästi järjestelmän elinkaaren ai-

kana. Järjestelmän elinkaari projektikokonaisuutena on monimutkainen prosessien 

muodostama systeemi, jolla voi olla normaalisti rinnakkaisia, iteratiivisia, toistuvia ja 

ajasta riippuvia ominaispiirteitä eli vaiheita voidaan tarvittaessa toistaa tai iteroida val-

litsevien tarpeiden mukaan. Esimerkiksi prosessien rinnakkaista käyttöä voi ilmetä 



 18 

useammissa projekteissa, joissa esimerkiksi suunnitteluun ja valmisteluun liittyviä toi-

mia toteutetaan samanaikaisesti ja eri projektien välillä, kun pyritään tuottamaan jär-

jestelmän osia useampiin projekteihin hyödynnettäväksi kustannustehokkuutta koros-

taen. Prosessien iteratiivinen toteuttaminen –esimerkiksi jonkin prosessin toistuva to-

teuttaminen tai hierarkkisella tasolla samaan aikaan toteutettava joukko prosesseja– 

on tärkeässä asemassa jatkuvan prosessitehokkuuden edistyksen kannalta. Esimerkiksi 

peräkkäisten verifiointi –ja integraatiotoimintojen välinen vuorovaikutus voi parantaa 

projektin etenemisen yhdenmukaisuutta merkittävästi. (IEEE Std 15288™ 2008: 13.) 

 

Prosessien toistuva käyttäminen eli saman prosessin toistuva toteuttaminen tai proses-

sijoukon toteuttaminen perättäisissä elinkaaren vaiheissa on esitetyn IEEE Std 

15288™ -standardin yksi avainkohdista. Prosessien tulokset informaatio–, artefakti–

tai palvelutasolla toimivat lähtökohtina samoille prosesseille, joita toteutetaan ylem-

mällä tai alemmalla tasolla. Tällaisin toiminnoin voidaan alkuperäisen prosessin tu-

losta uudelleenkäsiteltynä kehittää ja muokata samaa prosessia toistaen, joka edelleen 

mahdollistaa työtulosten yhdenmukaisuuden järjestelmän kaikilla arkkitehtuurisilla 

tasoilla. Järjestelmiin vaikuttavien tekijöiden muuttuva luonne vaatii jatkuvaa tarkkai-

lua liittyen toteutettaviin prosesseihin ja niiden toteutuksen oikeaan ajoitukseen. Täl-

laisia tekijöitä voivat olla muiden muassa operationaaliset ympäristömuutokset, uudet 

teknologiset mahdollisuudet, muuttuva järjestelmärakenne tai organisaatiota koskevat 

muutokset. Prosessien käyttö on siten hyvin dynaamista ja sen aiheuttavat useat ulkoi-

set tekijät, jotka vaikuttavat järjestelmän toteutukseen. Elinkaaren aikana toteutetta-

vien prosessien suunnitteluun, toteutukseen ja hallintaan vaikuttavat siis tutkielmassa 

jo aiemmin kuvatut elinkaaren vaiheet, joille on myös määritelty tietty tarkoitus sekä 

rakenne. Erityisesti samankaltaisilla markkina- ja tuotesektoreilla voidaan yhdenmu-

kaisilla ja helposti uusiokäytettävillä vaihe- ja prosessivalinnoilla rakentaa tarkoituk-

senmukainen ja tahokas elinkaarimalli mille tahansa järjestelmälle. (IEEE Std 

15288™ 2008: 13.) 

 



 19 

3 KETTERÄ OHJELMISTOKEHITYS 

Tässä luvussa kuvataan tällä hetkellä yleisesti käytössä oleva ketteryyden ja ketterän 

ohjelmistokehityksen määritelmä. Luvussa selvitetään, mitä ketteryys on, miten se on 

syntynyt, miten ketterä kehitys poikkeaa perinteisestä kehityksestä ja miten ketteryyttä 

sovelletaan ohjelmistoprojektiympäristössä. Luvussa käsitellään tutkielman teoreetti-

sen viitekehyksen kulmakivenä toimivat ketterän kehityksen arvot ja periaatteet. Ala-

luvussa 3.1 määritellään ketteryyden käsite ja ketteryyden syntyyn johtanut ideologia, 

alaluvussa 3.2 koko ketterän kehityksen peruskivenä toimiva, alan asiantuntijoiden 

muodostama Agile Alliance sekä heidän Agile Manifesto. Alaluku 3.3 luo lukijalle 

käsityksen siitä, miten ketterä ohjelmistokehitys eroaa perinteisestä ohjelmistokehi-

tyksen ajattelusta ja alaluvussa 3.4 esitellään käytännön projektityössä esiintyviä ket-

teriä piirteitä sekä kuvataan, millaista projektinhallintaa ketterästi toimiminen edellyt-

tää käytännössä. 

3.1 Ketteryyden määrittely ja ideologia 

Ketterä tarkoittaa terminä 1) kykyä liikkua nopeasti ja helposti sekä 2) kykyä ajatella 

ja ymmärtää nopeasti (Oxford Dictionaries 2015). Ketteryyttä konseptina pidetään hy-

vin monipuolisena. Sitä ovat käyttäneet hyvin monet ihmiset, viitatessaan hyvin eri-

laisiin ilmiöihin. 1990-luvun alusta lähtien ketteryyttä on käytetty terminä laajalti lii-

ketoiminnan alalla eri kentillä ja tieteenaloilla (Convoy 2009: 330). Cockburnin (2000: 

149) mukaan ketterä viittaa tehokkaana sekä helposti liikuteltavana olemiseen. Kette-

ryys voidaan määritellä tarkoittamaan laatua tai kykyä olla nopealiikkeinen (engl. 

quick moving) sekä vikkelä (engl. nimble). Tietojärjestelmän kehittämisen (Informa-

tion Systems Development, ISD) kontekstissa ketteryyden voi määritellä tietojärjestel-

män kehitysorganisaation kyvyksi havainnoida ja vastata nopeasti teknisiin muutok-

siin ja uusiin liiketoiminnallisiin mahdollisuuksiin (Lyytinen & Rose 2006: 183). Ket-

teryyden käsitteellistä taustaa tutkinut Kieran Convoy (2009: 341) määrittelee lopulta 

ketteryyden tarkoittamaan ohjelmistokehityksessä kehitysmenetelmän alituista val-

miutta äkillisesti tai olennaisesti aiheuttaa muutosta. Hän viittaa tällä proaktiiviseen 

eli ennakoivaan tai reaktiiviseen eli ympäröivään ilmiöön reagoivaan muutoksen tu-

kemiseen sekä muutoksesta oppimiseen edistäen asiakkaan kokemaa taloudellista, laa-

dullista ja yksinkertaista lisäarvoa. Tämän kaiken tulisi tapahtua hyödyntäen menetel-

män kollektiivisia komponentteja sekä sen suhdetta ympäristöönsä. 



 20 

 

Ohjelmistokehityksessä ketteryydellä pyritään tarjoamaan vastine liiketoimintayhtei-

sölle, joka vaatii nopeilla kehitysprosesseilla kevyempiä rakenteita. Äkillisesti kasva-

van ja epävakaan Internet-ohjelmistoteollisuuden kuten myös kasvavan mobiilin so-

vellusympäristön tapauksissa tilanteeseen törmätään yhä useammin. (Abrahamsson 

ym. 2002: 9.) 

 

Highsmith (2002: XXIII) kuvaa, että ailahtelevaisuus ja epävarmuus määrittävät yhä 

enemmän tämän päivän liiketoimintaa. Lahjakkaat, tekniset ihmiset haluavat työsken-

nellä organisaatioissa, joissa heillä on enemmän valtaa sen suhteen kuinka he työsken-

televät ja kuinka he vuorovaikuttavat kollegoidensa, asiakkaidensa ja johtonsa kanssa. 

Ongelmat, ihmiset ja ideat muuttuvat. Vaikka edelleen suunnitelmalähtöisillä kehitys- 

ja hallintatyyleillä on mahdollisuuksia ja jalansijaa, on kasvu ja kehitys ketteränä ja 

joustavana olemisen varassa. Ketterän kehityksen vaikutuksia ja ketterien menetel-

mien sopeuttamista tutkinut Peter Schuh (2005: 2) kuvaa, että ketterä kehitys on oh-

jelmiston rakentamismenetelmä, jossa luotetaan ihmisiin, tiedostaen muutos normina 

ja suosien alituista palautetta. Hänen mukaan ketterä lähestymistapa voidaan tiivistää 

seuraaviin periaatteisiin: 

 

- Käyttökelpoisen ja asiakkaalle arvokkaan ohjelmiston toimittaminen on ohjel-

mistokehitysprojektin tärkein yksittäinen tavoite 

- Projektitiimi toimii parhaiten, kun sillä on ”near-term”, toteuttamiskelpoiset ja 

tunnistettavissa olevat arvokkaat tavoitteet 

- Asiakkaat ovat tyytyväisimmillään, kun he tuntevat kontrolloivansa sitä, mitä 

kehitetään ja näkevät säännöllisesti todellisia tuloksia 

- Lyhyet ja säännölliset palautesilmukat ovat tarpeellisia sekä ohjelmistoprojek-

tin mittaamisen että etenemisen ohjauksen kannalta 

- Prosessien virtaviivaisuus sekä automatisointi (sekä hallinnan että ohjelmoin-

nin toimintojen) antaa ihmisille vapauden tehdä arvokkaampaa ja mielenkiin-

toisempaa työtä. 

 

Ketteryydessä voidaan siis todeta olevan kyse ihmisten ja heidän välisen vuorovaiku-

tuksen tärkeydestä sen sijaan, että kukin toimisi itsenäisesti. Lähtökohtaisesti tulisi 

ajatella, että toimivan tiimin muokkaaminen ympäristöön sopivaksi on ketteryydessä 

merkittävää – ei ympäristön muokkaaminen. Ketterässä kehityksessä ei ole pyrkimyk-



 21 

senä tuottaa yksityiskohtaista dokumentaatiota koskien järjestelmää ja koodia. Halu-

taan saada aikaan yksiselitteistä dokumentaatiota, joka kuvaa selkeästi järjestelmän 

sekä suunnitelmallisten päätösten perustelut. Pitkien, täsmällisten dokumenttien sijaan 

tiimin jäsenet halutaan osaksi projektia jatkuvalla läheisellä vuorovaikuttamisella tar-

koituksena siirtää tietoa eteenpäin tiimin jäsenien keskuudessa. Ketterä ajattelu koros-

taa asiakasyhteistyötä ja toimittajan sekä asiakkaan välistä alituista vuorovaikutusta.  

 

Ketterä kehitys sai alkunsa, kun 1990-luvun lopulla lukuisiin ohjelmistokehityksen 

menetelmiin alkoi kohdistua kasvavassa määrin julkisuutta. Kussakin näistä oli erilai-

nen yhdistelmä vanhoja ideoita, uusia ideoita ja muunneltuja vanhoja ideoita. Kaikki 

nämä metodologiat kuitenkin painottivat läheistä yhteistyötä ohjelmoijien ja liiketoi-

minta-asiantuntijoiden välillä sekä kasvokkain tapahtuvaa kommunikaatiota kirjoitet-

tua dokumentaatiota tehokkaampana. Metodologiat korostivat uuden järjestäytyneen 

liiketoiminnallisen arvon yleistä tuottamista, tiiviitä, itsestään ohjautuvia tiimejä, sekä 

keinoja, joilla koodin ja tiimin taitava toiminta järjestäytyisi parempaan suuntaan 

(Agile Alliance 2001). Ketterä ohjelmistokehitys nähdään vastavetona kömpelöille 

prosesseille, tehtävänään uudistaa tietokoneohjelmointi ohjelmistotuotannoksi ja 

muuntaa se helppohoitoiseksi, odotustenmukaiseksi, kuten mikä tahansa muu teknii-

kan tieteenala. Ketterä ajattelu on uudenlaista, koska sen takana seisovat ihmiset ovat 

kokemustensa perusteella todistaneet listaamansa ketterät käytännöt, soveltaneet 

niissä ihmislähtöisiä ydinarvoja sekä projektiympäristöjä ja osoittaneet todellisin sekä 

arvokkain keinoin, kuinka niiden avulla lähestytään parempaa ohjelmistojen rakenta-

mista. (Schuh 2005: 2.)  

3.2 The Agile Alliance ja Agile Manifesto 

Perinteistä lähestymistapaa, joka perustuu vesiputousmallin kaltaiseen vaihejakoon, 

pidetään raskaana, monien osakokonaisuuksien summana (Awad 2005: 2). Loputto-

masti laajuudeltaan kasvaneet, kehityksensä puolesta paikalleen pysähtyneet prosessit 

ohjelmistotiimeissä ajoivat vuonna 2001 ryhmän ohjelmistokehityksen alan asiantun-

tijoita yhteen hahmotellakseen arvot ja periaatteet, jotka sallisivat ohjelmistotiimien 

toimia nopeasti ja alan muutokseen vastaten. Nämä asiantuntijat kutsuivat ryhmäänsä 

nimellä the Agile Alliance. Ja seuraavien kuukausien aikana he loivat pohjan ketterälle 

ajattelulle – tuloksena syntyi The Manifesto of the Agile Alliance eli ketterän ohjelmis-



 22 

tokehityksen julistus, jota pidetään ketterän ajattelun peruskivenä ja joka tiivistää par-

haiten arvot ketterän kehityksen takana. Julistuksen sisältö on esitelty alla. (The Agile 

Alliance 2001.) 

 

Helmikuussa 2001, seitsemäntoista eri ketterien menetelmien edustajaa – agilistia – 

muodostivat ketterän allianssin – Agile Alliancen – edistääkseen näkemyksiään, joka 

johti ketterän ohjelmistokehityksen julistuksen – the Agile Manifeston – syntyyn. Mo-

nia ketteriä tekniikoita on käytetty jo ennen allianssin syntyä, muttei perustuen allians-

sin näistä monista tekniikoista kokonaisuutena muodostamaan toimivaan viitekehyk-

seen. (Agile Alliance 2001.) 

  

Agilistien kunnioittamat keskeiset arvot on esitetty seuraavassa (Agile Alliance 

2001.): 

 

”Löydämme parempia tapoja tehdä ohjelmistokehitystä, kun teemme sitä itse ja au-

tamme muita siinä. Kokemuksemme perusteella arvostamme: 

 

Yksilöitä ja kanssakäymistä enemmän kuin menetelmiä ja työkaluja 

Toimivaa ohjelmistoa enemmän kuin kattavaa dokumentaatiota 

Asiakasyhteistyötä enemmän kuin sopimusneuvotteluja 

Vastaamista muutokseen enemmän kuin pitäytymistä suunnitelmassa” 

 

The Agile Manifestossa julistetut 12 periaatetta ovat seuraavat (Agile Alliance 2001.): 

 

 Tärkein tavoitteemme on tyydyttää asiakas toimittamalla tämän tarpeet täyttä-

viä versioita ohjelmistosta aikaisessa vaiheessa ja säännöllisesti. 

 Otamme vastaan muuttuvat vaatimukset myös kehityksen myöhäisessä vai-

heessa. Ketterät menetelmät hyödyntävät muutosta asiakkaan kilpailukyvyn 

edistämiseksi. 

 Toimitamme versioita toimivasta ohjelmistosta säännöllisesti, parin viikon tai 

kuukauden välein, ja suosimme lyhyempää aikaväliä. 

 Liiketoiminnan edustajien ja ohjelmistokehittäjien tulee työskennellä yhdessä 

päivittäin koko projektin ajan. 

 Rakennamme projektit motivoituneiden yksilöiden ympärille. Annamme 

heille puitteet ja tuen, jonka he tarvitsevat ja luotamme siihen, että he saavat 

työn tehtyä. 



 23 

 Tehokkain ja toimivin tapa tiedon välittämiseksi kehitystiimille ja tiimin jä-

senten kesken on kasvokkain käytävä keskustelu. 

 Toimiva ohjelmisto on edistymisen ensisijainen mittari. 

 Ketterät menetelmät kannustavat kestävään toimintatapaan. Hankkeen omis-

tajien, kehittäjien ja ohjelmiston käyttäjien tulisi pystyä ylläpitämään työtah-

tinsa hamaan tulevaisuuteen. 

 Teknisen laadun ja ohjelmiston hyvän rakenteen jatkuva huomiointi edesaut-

taa ketteryyttä. 

 Yksinkertaisuus – tekemättä jätettävän työn maksimointi – on oleellista. 

 Parhaat arkkitehtuurit, vaatimukset ja suunnitelmat syntyvät itseorganisoitu-

vissa tiimeissä. 

 Tiimi tarkastele säännöllisesti, kuinka parantaa tehokkuuttaan, ja mukauttaa 

toimintaansa sen mukaisesti. 

 

Yksi agilisteista – Robert Martin (2002: 8) tiivistää ketterän ohjelmistokehityksen ju-

listuksen arvot nimenomaan prosessien kykyyn tuottaa asiakkaalle lisäarvoa ja asia-

kastyytyväisyyden maksimointiin perustuen. Hänen mukaan jokaisen ohjelmistokehit-

täjän ja jokaisen kehitystiimin ammattimainen tavoite on toimittaa korkein mahdolli-

nen määrä arvoa työntekijöilleen sekä asiakkailleen. Martin näkee prosessiajattelun 

hyödyntämisen huomattavan kasvun olevan ainakin osittain syyllinen aiempien pro-

jektien epäonnistumisiin sekä niiden heikkoon arvontuottamiskykyyn. Hänen mu-

kaansa ketterän ajattelun periaatteet ja arvot ovat perustuneet juuri prosessiajattelun 

vastavedoksi – ne on luotu keinoksi auttaa ohjelmistotiimejä rikkomaan jatkuvaa pro-

jektilaajuuden kasvua ja keskittymään yksinkertaisiin tekniikoihin tavoitteiden saavut-

tamiseksi.  

3.3 Ketterän ja perinteisen ohjelmistokehityksen eroavaisuudet 

Tässä alaluvussa käydään läpi yleisen tason eroja perinteisen, vaihejakoon perustuvan 

lähestymistavan ja ketterän lähestymistavan välillä. Näiden lähestymistapojen välillä 

on paljon yhtäläisyyksiä, mutta erittäin oleellisia eroavaisuuksia. Merkittävimpiä eroa-

vaisuuksia on käsitelty seuraavassa perustuen lähinnä Aitkenin ja Ilangon (2013), 

Wellsin, Dalcherin ja Smythin (2015) sekä Awadin (2005) tutkimuksiin.  

 



 24 

Aitken ja Ilango (2013) mainitsevat perinteisen ja ketterän lähestymistavan välisten 

eroavaisuuksien liittyvän erilaisiin ominaisuuksiin, kuten käytettyjen mallien vaihte-

levuuteen, mallien käyttötarkoitukseen sekä mallintamisen lähtökohtiin. Lähtökohtai-

sesti lähestymistapoja ei kuitenkaan nähdä täysin ristiriitaisina, eikä tulevaa nähdä pel-

kän ketterän lähestymistavan aikana. Awad (2005) nimittää perinteistä lähestymista-

paa ja perinteisiä menetelmiä raskaansarjan menetelmiksi, jotka perustuvat kattavaan 

suunnittelutyöhön, yksityiskohtaiseen dokumentaatioon ja laajaan suunnitelmaan. 

Raskaansarjan menetelmille Awad kuvaa vaihtoehtoisen, kevyemmän menetelmän – 

ketteryyden. Ketterän lähestymistavan kulmakiviksi hän mainitsee lyhyet iteratiiviset 

syklit, ja ketterän tiimin jäsenten hiljaiseen tietoon nojautumisen dokumentaation si-

jasta. Alla olevassa taulukossa (Taulukko 2) on listattuna Awadin näkemys merkittä-

vimmistä eroista perinteisen ja ketterän lähestymistavan välillä. 

 

 
  



 25 

 KETTERÄ PERINTEINEN 

LÄHTÖKOHTA Mukautuva Ennaltamäärätty 

ONNISTUMISEN MIT-

TAUSPERUSTE 

Liiketoiminnallinen arvo Suunnitelmanmukaisuus 

PROJEKTIKOKO Pieni Suuri 

JOHTAMISTYYLI Hajautettu  Autokraattinen 

SUHTAUTUMINEN MUU-

TOKSEEN 

Muutokseen mukautuva Muutosvastainen 

KULTTUURI Johto on osa tiimiä Johto selkeästi hierarki-

assa ylempänä 

DOKUMENTAATIO Vähäistä Raskasta 

PAINOTUS Ihmislähtöinen Prosessiorientoitunut 

SYKLIT Useita Yksittäinen 

TOIMINTAYMPÄRISTÖ Ennalta määrittelemätön/ 

Tutkiva 

Ennalta määritelty 

ENNAKKOSUUNNITTELU Minimoitua Korostettua 

SIJOITETUN PÄÄOMAN 

TUOTTO 

Projektin alusta alkaen Projektin lopussa 

TIIMIKOKO Pieni Suuri 

Taulukko 2. Ketterän ja perinteisen lähestymistavan merkittävimmät eroavaisuudet 

osa-alueittain. (Awad 2005.) 

 

 

Awadin (2005: 35) mukaan sekä raskailla että ketterillä menetelmillä on molemmilla 

vahvuuksia ja heikkouksia, mutta perimmäinen valinta näiden välillä tulisi perustua 

toteutettavan projektin kokoon, projektissa toimiviin ihmisiin sekä projektiin liittyviin 

riskeihin. Awad näkeekin juuri projektikoon olevan yksi rajoittavista tekijöistä kette-

ryyden projektikohtaista käytettävyyttä arvioidessa, koska perinteisen lähestymistavan 

hän kuvaa soveltuvan budjetin, projektitiimin koon ja keston mittapuulla suuriin pro-

jekteihin. Awad kuvaa ketteryyden yhdeksi lähtökohdaksi taas nimenomaan sen, että 

pienemmissä, ketterissä tiimeissä työskennellessä voidaan saavuttaa kaikkien ketterien 

arvojen mukaista etua. Hän lisää, että lähtökohtainen ratkaistava ongelma ketterissä 

projekteissa on myös kooltaan pienempi, jota on korostanut muiden muassa Alistair 

Cockburn, yksi alkuperäisistä agilisteista. Yhden käytetyimmän ketterän menetelmän, 

Scrumin,  kehittäjä Ken Schwaber (2004: 8) ei näe ratkaistavan ongelman suuruuden 



 26 

tai projektitiimin koon vähentävän toiminnan tehokkuutta. Hän korostaa itseorganisoi-

tuvaa tiimityötä ja nimenomaan tiimin kykyä tehdä ratkaisuja tilanteessa, jossa esimer-

kiksi tiimin suuruus nähdään ongelmaksi. Tällöin tiimin tulisi lähtökohtaisesti ohjata 

itse itsensä pienempiin osiin ja jatkaa projektityötä eteenpäin uudenlaisena. Myös Ait-

ken ja Ilango (2013: 4758) nostavat merkittävänä eroavaisuutena perinteisen ja kette-

rän lähestymistavan välillä projektijohdon – perinteisessä ohjelmistoprojektissa on 

projektipäällikkö, kun taas ketterässä projektissa vastuu projektista on itse tiimillä ja 

sillä on valmentajan tai masterin avulla kyky toimia itsenäisesti. Kestollisesti perintei-

nen lähestymistapa on huomattavasti ketterää pidempi menetelmä johtuen erityisesti 

kunkin vaiheen dokumentoinnista, kun taas ketteryys perustuu lyhyisiin iteraatioihin 

ja samanaikaisiin prosesseihin. Aitken ja Ilango mainitsevat dokumentoinnin olevan 

perinteisissä menetelmissä vastine ketterässä mallissa syntyvälle koodille ja toki koo-

dia toteutetaan myös perinteisessä lähestymistavassa, mutta dokumentointia tehdään 

huomattavasti enemmän. Alla olevassa taulukossa (Taulukko 3) on esitelty Aitkenin 

ja Ilangon näkemys eroavaisuuksista perinteisten sekä ketterien menetelmien välillä 

mukaillen ketteriä arvoja ja periaatteita. (Schwaber 2004: 8; Aitken & Ilango 2013: 

4758.) 

 

  



 27 

KETTERÄ LÄHESTYMISTAPA PERINTEINEN LÄHESTYMISTAPA 

Ihmis- ja yhteistyölähtöinen Prosessi- ja työkalulähtöinen 

Koodiin ja ohjelmointiin perustuva. 

Tuotettu toimiva ohjelmisto on onnistu-

misen mitta. Korostaa koodin ulkoasun 

ja selkeyden tärkeyttä. 

Dokumentteihin perustuva. Jokaista 

toimintoa verrataan/ mitataan doku-

mentein tai toimituskelpoisuuden mu-

kaan.  

Asiakkaat ovat mukana jatkuvasti. Asiakkaat eivät ole mukana jatkuvasti. 

Vaatimusmuutokset mahdollisia myös 

projektin edetessä ja myöhemmin pro-

jektin aikana, mikä mahdollistaa myös 

”suunnanmuutokset”. 

Vaatimusmuutoksia ei suosita projek-

tin etenemisen aikana. Suuntaa on vai-

kea muuttaa sopimusten syntymisen 

jälkeen. 

Toimitetaan asiakkaalle jatkuvasti toi-

mivaa ohjelmistoa. 

Ei suosi ohjelmiston jatkuvaa toimi-

tusta asiakkaalle. 

Syklien maksimikesto 2 kuukautta, 

usein ohjelmaa toimitetaan asiakkaalle 

jopa alle 2 viikon välein. 

Lyhyitä iteraatioita ei suosita. 

Ohjelmisto toimitetaan parhaalla mah-

dollisella tavalla yhdessä toimivien tii-

mien toimesta. 

Ei suosi itseorganisoituja tiimejä. 

Vaiheita ei noudateta muodollisesti. 

Erillistä analysointi –tai suunnitteluvai-

hetta ei ole. 

Ohjelmistokehityksen elinkaaren vai-

heita noudatetaan järjestelmällisesti, 

analysointia ja suunnitelmallisuutta 

suositaan. 

Ohjelmisto rakennetaan lyhyissä pät-

kissä, yksittäisinä ominaisuuksina tai 

”tarinoina”, joita voidaan kehitellä vai-

heittain. 

Jokainen määrittelyvaiheessa määri-

tetty vaatimus tulee olla toteutettu lo-

pullisessa tuotteessa.  

Kehittäjien ja asiakkaiden tai käyttäjien 

tulisi tavata säännöllisesti, jotta kehitys 

kestää läpi projektin. 

Kehittäjät ja asiakkaat ovat tekemi-

sissä vain projektin alussa ja lopussa. 

Taulukko 3. Ketterän ja perinteisen lähestymistavan eroavaisuudet periaatteittain. 

(Aitken & Ilango 2013.) 

 

 



 28 

Jo pelkästään Agile Manifeston (2001) sisältöä tarkkaillessa, voidaan huomata ihmis-

ten olevan poikkeuksellisen merkittävässä asemassa ketterässä kehityksessä ja kehi-

tysprojektiin kuuluvat ihmiset sekä näiden merkitys juuri erottaa ketterän ajattelun pe-

rinteisestä lähestymistavasta. Awad (2005: 37) korostaa ihmisissä erityisesti näiden 

taitoja sekä kokemusta ja näiden merkitystä ketterässä lähestymistavassa. Tiimin koos-

tuessa ihmisistä, joilla on useista eri tehtävistä ja tilanteista kokemusta, on tiimin si-

sällä helppo antaa palautetta ja huomata mahdollisia virheitä jo toiminnan aikana. Toi-

nen merkittävä ero on asiakkaan läsnäolo projektissa. Tämä aspekti on erittäin merkit-

tävä osa ketterää ajattelua ja uutta perinteiseen nähden. Suurin etu saavutetaan sillä, 

että asiakas voi tarkkailla koko projektin ajan sen edistymistä ja jokaisen iteraation 

aikana on asiakkaan toiveisiin perustuen mahdollista muuttaa kehitysprojektin suuntaa 

tai tuoda siihen uusia piirteitä. Awadin mukaan organisaatiokulttuuri on myös merkit-

tävässä asemassa valittaessa käytettävää menetelmää. Raskaampi, vaihejakoon perus-

tuva perinteinen lähestymistapa saattaa olla parempi vaihtoehto organisaatioissa, 

joissa ympäristömuutokseen reagointi ei yksinkertaisesti ole mahdollista tai vaatii 

huomattavia ponnisteluja. Lukuisiin rajoitteisiin, sääntöihin ja käytäntöihin pohjau-

tuva organisaatiomalli, joka ei suoranaisesti ole vastuussa muutoksesta tai jonka ei 

välittömästi ole pakko reagoida sitä ympäröivään muutokseen, ei toimi ketterässä lä-

hestymistavassa. (Awad 2005: 37.) 

 

Awadin mukaan suurimmat riskitekijät ohjelmistokehityksessä ovat projektien kriitti-

syyden ja muutoslähtöisyyden tasot. Nopeasti rakennettavat ja vähäisempää laadun 

varmistusta vaativat sovellukset ovat ketterään kehitykseen parhaiten sopivia. Ras-

kaansarjan menetelmiä taas tulisi suosia projekteissa, joiden kohteena ovat hyvin kriit-

tiset, käyttövarmat ja turvallisuuteen perustuvat järjestelmät, koska tällöin toteutetaan 

vaatimukset pitkään harkiten ja perusteellisesti ennen toteutukseen ryhtymistä. Muu-

toslähtöistä ajattelua korostavissa projekteissa on helppo valinta toteuttaa kohde ket-

terällä menetelmällä. Muutoksiin on huomattavasti helpompi reagoida asiakkaan ol-

lessa läsnä ja iteraatioiden ollessa lyhyempiä. Awad tiivistää riskien huomioimisen 

siten, että mitä poikkeuksellisemmat projektin olosuhteet ovat, sitä selkeämpi on pe-

rinteisen tai ketterän lähestymistavan valinta käytettäväksi. (Awad 2005:37.) 



 29 

3.4 Ketteryys ja projektihallinta 

Edellä kuvatun perusteella voidaan selkeästi tulkita ketterän ohjelmistokehityksen 

eroavan perinteisestä menetelmästä. Ketterää menetelmää valitessa on syytä tuntea 

myös toteutettava projekti ja ketterän menetelmän valinta tulee olla perusteltua. Edel-

täviä, perinteisen ja ketterän lähestymistavan eroja tukien, myös  Peter Schuh (2005) 

listaa erot ketterän ja perinteisen lähestymistavan välillä sekä korostaa ketterän tavan 

vahvuuksina kehitystiimin kommunikaatiota ja vastuuta, läpi projektin jatkuvaa jous-

tavaa suunnittelua, asiakkaan läsnäoloa, monipuolista joustavuutta prosessien ja työ-

kalujen valinnassa.  

 

Schuhin (2005: 10) mukaan ketterä tiimi vaatii tarkoituksenmukaisesti toimiakseen 

projektihallinnan toteutuksen niin, että se vastaa tiimin täydellisen toiminnan mahdol-

listaviin tarpeisiin ja tiimin intresseihin perustuen tuottaa säännöllisen palautteen mah-

dollistavia mekanismeja, jotka taas tukevat projektin etenemistä ja prosessien kette-

ryyttä. Projektijohdon tulee priorisoida juuri hallintalähtöisiä ketteriä käytäntöjä, kuten 

lyhyitä iteraatioita, tiheään tapahtuvia julkaisuja sekä tasaisen etenemistahdin ylläpi-

toa ja näiden hyödyntäminen perustuu projektijohdon myötävaikutukseen sekä yhteis-

työhön. Käytettävästä menetelmästä riippuen tiimin vastuun ja hallinnan tarve vaihte-

lee, kuitenkin tiedostaen, että tiimin läsnäolo päätöksenteossa on ketterille menetel-

mille poikkeuksetta ominaista. Yleisellä tasolla Schuh kuvaa, että agilistit ovat yksi-

mielisiä siitä, että voidakseen toimia ketterästi, projektijohdon on kuunneltava tiimiä 

ja vastattava sen tarpeisiin. Lyhyet iteraatiot ovat esimerkki edellä kuvatuista palaut-

teen mahdollistavista mekanismeista, koska ne mahdollistavat kokonaisvaltaisen edis-

tymisen seuraamisen, kun palautetta saadaan säännöllisesti ja lyhyin väliajoin. Tällöin 

tiimi saa selkeän kuvan siitä, toimivatko hyödynnetyt käytännöt, lakkaako jokin pro-

jektiin kuuluva käytäntö toimimasta sekä kykeneekö tiimi vastaamaan tehokkaimmin 

keinoin vaatimus –tai ympäristömuutoksiin.  

 

Ketterässä ohjelmistokehityksessä asiakkaan läsnäolo on yksi merkittävimmistä ar-

voista. Schuhin (2005: 11) mukaan ketterässä projektissa asiakas on jokin tiimin hel-

posti lähestyttävissä oleva taho –ei välttämättä yksittäinen henkilö, joka tuntee projek-

tin, vaan esimerkiksi ryhmä asiantuntijoita, jolla on valta tehdä projektia koskevia pää-

töksiä ja joka kykenee puhumaan yksimielisesti edustamansa organisaation puolesta, 

jolle projektin lopputulos aiheuttaa etua. Asiakkaan halutaan olevan mukana ketterässä 



 30 

projektissa sekä toiminnallisista että sananmukaisesti ketteristä syistä. Toiminnalli-

sesti katsottuna on luonnollista, että projektin lopputuloksena syntyy parempi tuote, 

kun mukana on yhtäläisellä panoksella ja tavoitteilla varustettu sekä tietämyksen että 

intressin omaava osapuoli. Toisekseen ketterä projekti vaatii asiakkaan jatkuvaa läs-

näoloa, jotta se voidaan toteuttaa ”juuri oikeaan tarpeeseen” -periaatteella (engl. just-

in-timei. Tämä tarkoittaa sitä, että toimitetaan vain tarvittavia tuotteita niitä tarvitse-

valle asiakkaalle, vasta silloin kun niitä tarvitaan. Tarkemmin tarkasteltuna tulee huo-

mioida myös se, että projektin edetessä elinkaarellaan, tehdään jatkuvasti suunnitte-

luun ja vaatimuksiin liittyviä päätöksiä, jotka vaativat asiakkaan sitoumusta ja osallis-

tumista. Asiakkaan läsnäolo on menetelmäkohtaista, mutta ketteryydessä asiakasyh-

teisyössä korostetaan asiakkaan kanssa päivittäin tapahtuvia neuvotteluita tai yksilöitä, 

jotka istuvat ja työskentelevät jatkuvasti tiimin kanssa samassa tilassa. Menetelmästä 

riippumatta on tavoite kuitenkin aina sama – helposti tavoitettava ja kommunikointia 

arvostava asiakas tarkoittaa, että vaatimuksia voidaan parannella ja jalostaa milloin 

tahansa. Ei kuitenkaan voida olettaa asiakkaan heti olevan osa tiimiä ja ketterää pro-

jektia, vaan perehdyttäminen ja osaksi tiimiä sekä ketterää lähestymistapaa hioutumi-

nen vie aikansa. Lopulta tavoitteena on taata, että asiakas tuntee luonnollisesti ole-

vansa läsnä uusien toimintojen määrittelyssä, kuvaamisessa ja suunnittelussa. (Schuh 

2005:11.) 

 

Ketterässä lähestymistavassa pyritään korostamaan ”vain välttämätön” -periaatetta. 

Tämä näkyy muiden muassa projektissa hyödynnettävien prosessien ja työkalujen va-

linnassa – projektitiimin tulee hyödyntää niitä prosesseja ja työkaluja, jotka tuottavat 

tarkoituksenmukaisesti tarkastuksia ja rakennetta pitäen niiden määrän rajallisena ja 

tavoiteltuna, ei yhtään laajempana. Tiimi voi esimerkiksi päättää, että tuotettua koodia 

tarkistetaan useita kertoja päivässä koko tiimin toimesta, eikä koodi leviä useita päiviä 

eri suuntiin useille yksittäisille työasemille jätettynä. Mikä tahansa prosessi tai työ-

kalu, joka ei ole tiimin yhteisesti hyväksymä tai toimii vastoin ”vain välttämätön” -

periaatetta, on tarpeetonta. Ketterässä lähestymistavassa on nimenomaan kyse siitä, 

että kaikki tämä tarpeeton halutaan ajoissa pyrkiä karsimaan projektin ulkopuolelle. 

Tästä tyypillinen esimerkki on dokumentaatio, josta ketterät toimijat pyrkivät hank-

kiutumaan eroon. (Schuh 2005: 11-12.)  

 

Schuh (2005: 13) mainitsee, että mikä tahansa projekti voi hyötyä ketterästä kehityk-

sestä. Tutkittaessa jotain ketteryyteen pyrkivää projektia, jonkin tietyn piirteen tai käy-

tännön puuttuminen saattaa määrittää suunnan sille, mitä menetelmää tai menetelmiä 



 31 

projektissa käytetään tai jonkin tietyn menetelmän valitseminen käytettäväksi tietyssä 

ketteryyteen pyrkivässä projektissa saattaa määrittää mitä piirteitä siinä tulisi esiintyä. 

Tällainen tilanne, jossa menetelmän valinta tai ketterien piirteiden määrittäminen on 

epäselvää, on haasteellinen, muttei estä projektin toteuttamista ketteränä. Tällöin tii-

min tulee kyetä hyödyntämään ketteryyttä. Tällaisessa tilanteessa olevalla projektitii-

millä on kaksi vaihtoehtoa. Ensinnäkin projektissa voidaan pyrkiä muuntamaan sen 

ympäristöä. Riippuen projektin yksityiskohdista tämä voi tarkoittaa kääntymistä si-

dosryhmien puoleen, keskustelun alulle panemista korkeamman tason johdon kanssa 

tai pyrkimystä muuttaa suhdetta asiakkaaseen. Mikäli nämä eivät tunnu toimivilta kei-

noilta, projekti tulee joka tapauksessa pitkällä aikavälillä katsottuna hyötymään ym-

päristön viemisestä kohti ketterämpää ajattelutapaa ja lähtökohtaa. Toinen vaihtoehto 

on ottaa käyttöön ketteriä käytäntöjä vaiheittain ja opportunistisemmasta lähtökoh-

dasta. Jos projektiympäristöä ei kyetä muokkaamaan, ei sitä voi kutsua ketteräksi. Silti 

on mahdollista omaksua hiljalleen, määrätietoisesti ja harkiten ketteriä käytäntöjä.  

 

Edellä kuvatussa pyritään selittämään sitä, että projekti hyötyy jopa yhden yksittäisen 

ketterän käytännön tai piirteen omaksumisesta. Tässä tulee huomioida, että tuon yhden 

yksittäisen käytännön tulee olla harkiten valittu, tiimin hyväksymä ja sen vaikuttami-

selle ja noudattamiselle tulee antaa tarpeellinen määrä aikaa. Schuhin mukaan tällaisen 

käytännön omaksuminen ei ole yksiselitteistä ja se voi vaatia useamman yrityksen, 

mutta lopulta, kun tiimi antaa jalan sijaa uusille toimintatavoille ja omaksuu ne hiljal-

leen, huomaa se lopulta joustamattomien rajoitusten katoavan ympäristöstään. Kette-

rien käytäntöjen oikeanlainen omaksuminen ja ketteriin arvoihin pyrkiminen voi saada 

aikaan merkittäviä tuloksia ympäristöjen valikoimassa. Ei-ketterissä ympäristöissä toi-

miminen voi tehdä ketterien käytäntöjen omaksumisesta vaikeaa, vähentää projektitii-

min tuottavuutta, uhata moraalia ja vaikeuttaa merkittävästi ketteryyden oppimista. 

Schuh kuitenkin kuvaa ketteryyden aina vievän projektin pitkällä aikavälillä parem-

paan suuntaan. (Schuh 2005: 13-14.) 

 

Schuhin (2005) näkemykset edellä kuvaavat ketterän projektinhallinnan oikeanlaisen 

toteuttamisen edellyttämiä projektien sisältämiä käytäntöjä. Chow ja Cao (2007) ovat 

kyselytutkimuksellaan tunnistaneet ja koonneet yhteen kriittisimmät menestystekijät 

ketterissä ohjelmistokehitysprojekteissa. Heidän havaintonsa tukevat Agile Manifes-

tossa esitettyjä ketteriä periaatteita: kolme merkittävintä menestystekijää ovat oikean-

lainen toimitusstrategia, ketterien tekniikoiden sopiva hyödyntäminen sekä tiimin tai-



 32 

dollinen kyvykkyys ja nämä kaikki kolme muodostuvat pitkälti Agile Manifeston si-

sällöistä. Myös kolme muuta tekijää – hyvä sekä ketterä projektijohto, ketteryysystä-

vällinen toimintaympäristö ja asiakkaan voimakas läsnäolo – mukailevat Agile Mani-

feston sisältöä. Taulukossa 4 on kuvattu kyseiset menestystekijät ominaisuuksineen. 

(Chow & Cao 2007: 968.) 

 

 

Menestystekijä Ominaisuudet 

Toimitusstrategia ohjelmistoa tulee toimittaa säännöllisesti 

tärkeimmät tuoteominaisuudet tulee toimittaa ensisijaisesti 

Ketterät tekniikat ohjelmiston rakenteen tulee olla yksinkertainen 

dokumentaatiota tulee tuottaa sopiva määrä 

Tiimin kyvykkyys/tai-

dot 

tiimin tulee olla asiantunteva ja motivoitunut 

johdolla tulee olla tietämystä ketteryydestä 

johdon tulee olla toimintatavoiltaan sopeutuva 

tiimi tulee kouluttaa asianmukaisesti projektin alussa 

Projektijohto vaatimusmäärittely tulee olla ketterästi toteutettu 

projektihallinta tulee olla ketterää 

projektin etenemistä tulee seurata selkein mekanismein 

kommunikoinnin tulee olla voimakasta 

projektin tulee edetä tasaisesti ja esteittä 

Toimintaympäristö koko tiimin tulee toimia samassa lokaatiossa 

tiimin tulee olla itseorganisoitunut 

tiimin tulee olla kooltaan pieni 

tiimin tulee olla yksittäinen kokonaisuus 

Asiakkaan läsnäolo asiakassuhteen tulee olla luonteeltaan positiivinen 

asiakkaan tulee olla voimakkaasti läsnä ja vaikuttaa päätöksiin 

asiakkaalla tulee olla täysi päätösvalta 

Taulukko 4. Tärkeimmät menestystekijät ketterässä ohjelmistokehitysprojektissa 

ominaisuuksineen (Chow & Cao 2007).  

 

  



 33 

4 KETTERIÄ MENETELMIÄ 

Ketterä lähestymistapa ohjelmistokehityksessä perustuu ketteriin menetelmiin, joita 

on viime vuosikymmeninä kehitetty ja niiden alkuperäisideoita jalostettu pidemmälle. 

Tänä päivänä käytössä on lukuisia erilaisia menetelmiä, joilla kuitenkin voidaan nähdä 

olevan hyvin paljon yhteisiä piirteitä. Tässä luvussa esitellään viimeisellä vuosikym-

menellä yleisimmin käytössä olleet sekä tämän tutkielman kannalta merkittävimmät 

ketterät menetelmät: ketterän lähestymistavan esittelemisen kannalta merkittävä eXt-

reme Programming (VersionOne: 2015) sekä tutkimusaineistossa merkittävää roolia 

näyttelevät Scrum ja Kanban.  

4.1 Extreme Programming (XP) 

Extreme Programming – jatkossa XP (lyh. eXtreme programming) – on ketterä ohjel-

mistokehitysmenetelmä, jonka on kehittänyt Kent Beck. Kuten alaluvussa 4.2 esitel-

tävä Scrum, on XP:kin iteratiivinen menetelmä. XP:n perusideologia on hyvin yhte-

neväinen tutkielmassa aiemmin esitettyihin Agile manifeston arvoihin ja käytäntöihin. 

XP:ia on pidetty tunnetuimpana ja laajimmin käytettynä ketteränä menetelmänä. Ny-

kyisin Scrum on menetelmistä käytetyin, mutta XP on yksi ensimmäisenä käyttöön 

omaksutuista menetelmistä (VersionOne 2015). Poikkeuksellisen XP:sta tekee se, että 

sitä on pidetty ainoana ketteränä menetelmänä, joka keskittyy ensisijaisesti ohjelmis-

tokehityksen koodauspuoleen (Schuh 2005: 19). Robert C. Martinin (2002) näkemyk-

sen mukaan XP on poikkeuksellinen käytäntöjensä vuoksi: 

 

”Extreme Programming on ketteristä menetelmistä tunnetuin. Se koostuu jou-

kosta yksinkertaisia, toisistaan riippuvaisia käytäntöjä. Nämä käytännöt toimivat 

yhdessä muodostaakseen kokonaisuuden, joka on sen yksittäisiä osia osioita 

eheämpi.” (Martin 2002: 11). 

 

XP:in suosio perustuu sen painottamaan asiakastyytyväisyyteen – sen sijaan, että toi-

mitettaisiin asiakkaalle kaikki mahdollinen yhdessä paketissa pitkällä tulevaisuudessa, 

toimitetaan XP:ssa tarvittu ohjelmisto tarvitunlaisena. XP:ssa pystytään vastaamaan 

muuttuviin asiakasvaatimuksiin myös ohjelmiston elinkaaren loppuvaiheessa. XP pai-

nottaa tiimityötä – johtajat, asiakkaat ja kehittäjät ovat kaikki tasavertaisia kumppa-

neita yhteistyössä toimivassa tiimissä. Kehitystiimi on XP:ssa jatkuvasti yhteydessä 



 34 

asiakkaaseen ja se kommunikoi koko ajan keskenään. XP:ssa korostuu ohjelmistotuot-

teiden toimitus asiakkaalle niin aikaisin kuin mahdollista, jolloin sitä voidaan paran-

nusehdotusten mukaan kehittää edelleen. XP koostuu pienemmistä osista, jotka yh-

dessä muodostavat eheän kokonaisuuden – taustalla ovat XP-arvot –ja käytännöt, 

jotka luovat perustan XP-säännöille. Kuviossa 4 on kuvattu XP- projektin sisältö ylei-

sellä tasolla. (Wells 2013.) 

 

 

 

 

Seuraavissa alaluvuissa käydään läpi XP:n neljä perusarvoa ja niiden välisiä suhteita, 

XP:n sääntöjä, roolitusta XP -projekteissa sekä yksityiskohtaisemmin XP -projektin 

elinkaarta. 

4.1.1 Arvot ja käytännöt 

XP perustuu neljään perusarvoon. Ensimmäinen on kommunikaatio, jota XP:ssa halu-

taan korostaa kommunikaatiota vaativilla käytännöillä. Tällaisia käytäntöjä ovat mui-

den muassa yksikkötestaus, parikoodaaminen tai tehtävien arviointi. Tällaisissa tilan-

teissa ohjelmoijien, asiakkaiden ja johdon on kommunikoitava.  

 

Toinen arvo on yksinkertaisuus, joka XP:ssa tarkoittaa tietynlaista varovaisuutta. Aja-

tellaan, että jonkin todella monimutkaisen toiminnon sijaan, jota ei mahdollisesti tulla 

koskaan käyttämään, on parempi tehdä jokin yksinkertainen toiminto, jota voidaan 

 Extreme Programming -projektin sisältö kuvattuna yleisellä tasolla (Schuh 

2005: 21) 



 35 

tarvittaessa muuttaa tai viedä monimutkaisempaan suuntaan. Tästä myöhemmästä 

muutoksesta ollaan myös tarvittaessa valmiita maksamaan.  Yksinkertaisuus kulkee 

XP:ssa käsi kädessä kommunikaation kanssa – mitä enemmän kommunikoit, sitä sel-

keämmin tiedät mitä tulee tehdä ja mitä ei. Mitä yksinkertaisempi järjestelmäsi on, sitä 

vähemmän se vaatii kommunikointia, joka taas johtaa relevantimpaan kommunikoin-

tiin, jolloin yksinkertaisuus voi ulottua jopa pienempään vaaditun henkilöstön mää-

rään.  

 

Kolmas arvo on palaute. Sitä saadaan edelleen arvostetun kommunikaation myötä asi-

akkaalta ja kollegoilta. Ohjelmoijat saavat XP:ssa palautetta tekemällä testausta ja ar-

viointia välittömästi toimeksiannon saatuaan, jolloin asiakkaat ja muu tiimi voi niin 

pian kuin mahdollista kommentoida toteutusta.  

 

Neljäs arvo on Extreme Programming -menetelmässä rohkeus. Rohkeus viittaa tässä 

kohtaa uskallukseen tuoda esiin myös monimutkaisempia ideoita, jotka saattavat ris-

keerata koko tuotannossa olevan projektin. Joskus ideat monimutkaisimmatkin ideat 

kuitenkin toimivat ja niistä syntyy menestys. Kommunikaation myötä on mahdollista 

esittää rohkeimmatkin ajatukset, Yksinkertaisuuden korostaminen tukee rohkeutta, 

koska yksinkertaisella pohjalla, tiimillä on varaa olla rohkeampi ja sen on helpompi 

kokeilla rohkeita asioita yksinkertaisemmassa järjestelmässä. Palaute taas takaa niin 

sanotun turvallisuudentunteen uusia asioita kokeillessa ja tiimi voi rohkeammin ko-

keilla asioita saadessaan niistä palautetta. XP:ssa kehitystiimin määrä rohkeasti vastata 

muuttuviin vaatimuksiin ja teknologiaan (Wells 2013). Beck (1999: 32-36) on esittä-

nyt myös viidennen arvon, kunnioituksen. Kunnioitus muita tiimiläisiä ja itse projektia 

kohtaan on perusta kaikille muille neljälle ja XP ei toimi ilman kokonaisuuden sisäistä 

kunnioitusta. 

 

Beck (1999: 47-48) listaa kaksitoista XP:lle ominaista käytäntöä selityksineen: 

 Suunnittelupeli (engl. the planning game) – Seuraava julkaisu tulee ennalta 

määritellä nopeasti vertailemalla liiketoiminnallisia prioriteetteja ja teknisiä ar-

vioita, suunnitelmaa voidaan tarvittaessa myöhemmin päivittää 

 Pienet julkaisut (engl. small releases) – Julkaisut tulee viedä yksinkertaisina 

nopeasti tuotantoon ja pienissä sykleissä julkaista uusia versioita 

 Järjestelmän metafora (engl. metaphor) – Tuotettavasta järjestelmästä tulee ja-

kaa kokonaisvaltainen, yksinkertainen tarina 



 36 

 Yksinkertainen rakenne ja suunnittelu (engl. simple design) – Järjestelmä tulee 

suunnitella niin yksinkertaisena kuin mahdollista ja liika monimutkaisuus tulee 

karsia sitä esiintyessä 

 Testaus (engl. testing) – Ohjelmoijat tekevät yksikkötestausta jatkuvasti ja sen 

tulee sujua virheettömästi kehittämistyön etenemiseksi. Asiakkaat testaavat 

vain valmiiksi saatettuja tuoteominaisuuksia 

 Uudelleenrakentaminen (engl. refactoring) – Ohjelmoijat uudelleenrakentavat 

järjestelmää säilyttäen sen tarkoituksenmukaisuuden, poistaen kaksinkertai-

suutta, edistäen kommunikaatiota ja yksinkertaisuutta sekä lisäämällä sen jous-

tavuutta 

 Pariohjelmointi (engl. pair programming) – Kaikki koodi tuotetaan pareittain 

– kaksi ohjelmoijaa yhdellä koneella 

 Koodin yhteisomistajuus (engl. collective ownership) – Kuka tahansa voi muo-

kata koodia missä tahansa järjestelmän osassa, missä tahansa vaiheessa 

 Jatkuva integrointi (engl. continuous integration) – Järjestelmää työstetään 

monta kertaa päivässä, aina kukin vaihe valmiiksi kerrallaan 

 40-tuntinen työviikko (engl. 40 hour week) – Työviikon pituus on rajoitettu 

40:een työtuntiin 

 Paikan päällä oleva asiakas (engl. on-site customer) – Tiimiin tulee kuulua 

lopullinen käyttäjä, jolta saada vastuksia milloin tahansa projektin aikana 

 Koodausstandardit (engl. coding standards) – Ohjelmoijat koodaavat sääntö-

jen mukaisesti korostaen kommunikaatiota 

 

XP:ssa yksikään edellä mainituista käytännöistä – testausta lukuun ottamatta – ei toimi 

yksinään. Ne vaativat ympärilleen muita käytäntöjä pysyäkseen tasapainossa. Arvojen 

ja käytäntöjen yhteenkuuluvuutta korostetaan tutkielman seuraavassa alaluvussa 4.1.2, 

joka kuvaa XP:n sääntöjä, jotka määrittelevät menetelmän työskentelytavat. 

4.1.2 Säännöt 

Don Wells (2013) kuvaa XP:n säännöt kaikkein yllättävimmäksi näkökulmaksi mene-

telmässä. Yksittäisinä monet pienet osaset eivät ole järkeenkäypiä, mutta yhdessä ne 

muodostavat selkeän kuvan. XP:n säännöt perustuvat edellä kuvattuihin arvoihin ja 

käytäntöihin. Alla on kuvattu projektin keskeisimpiä sääntöjä korostaen työskentely-

tapaa XP:ssa. 

 



 37 

Suunnittelu on kaksijakoinen käytäntö XP:ssa – koko projekti alkaa suunnittelulla 

(engl. planning), jonka merkittävimpänä sisältönä asiakas laatii käyttäjätarinat sen pe-

rusteella, mitä järjestelmän tulee voida tarjota heille. Suunnittelun toinen ulottuvuus 

on järjestelmän rakenteen suunnittelu (engl. designing), jonka toteuttaa kehitystiimi. 

Sen merkittävimpiä sääntöjä ovat muiden muassa yksikertaisuuden korostaminen, jär-

jestelmä metaforan valitseminen, koodin yhteisomistajuuden korostaminen käyttä-

mällä ideointityökaluina CRC-kortteja (engl. collaboration cards), yksinkertaisten 

kohdesovellusten (engl. spike solutions) suosiminen riskien minimoimiseksi ja lopulta 

säännöt korostavat, ettei tässä (aikaisessa) vaiheessa mitään toiminnallisuutta lisätä 

tuotteeseen sekä pyritään uudistamaan kokonaisuutta tehokkaammaksi aina kun mah-

dollista. 

 

Wells (2013) linjaa käytännön hallinnoinnin (engl. managing) säännöiksi avoimen 

työtilan antamisen kehitystiimille, tasaisen etenemisen korostamisen, kehitystyön 

aloittamisen päivittäin tapaamisella, projektin etenemisvauhdin mittaamisen sekä ih-

misten tiiminsisäisen liikkumisen osaamisen varmistamiseksi. Kuten kaikissa kette-

rissä projekteissa, tulee myös XP:n tapauksessa kyetä projektin aikana omaksumaan 

käytettävää menetelmää ja soveltamaan sitä omaan ympäristöön sopivaksi tarpeellisin 

korjauksin. 

 

Koodausta (engl. coding) koskevia sääntöjä ovat muiden muassa asiakkaan jatkuva 

läsnäolo, koodin tulee olla standardinmukaista, kaikki koodi tuotetaan pariohjelmoin-

tina, vain yksi pari integroi koodia kerrallaan ja integrointia tulee tehdä usein sekä 

koodi on aina yhteisomistuksessa.  

 

Testauksen (engl. testing) säännöt ovat: kaikki koodi tulee yksikkötestata ja ennen sen 

julkaisemista, tulee koodin läpäistä yksikkötestit. Kun vikoja löydetään, luodaan sille 

tarvittavat testit. Hyväksymistestejä tehdään mahdollisimman usein ja niiden tulokset 

tulevat julkisiksi.  

4.1.3 Roolit ja tiimit 

Extreme Programming toimii parhaiten pienissä kehitystiimeissä – vähintään kaksi ja 

enimmillään 12 on optimaalisin henkilömäärä tiimiä kohden, joskin laajimmissa pro-

jekteissa saadaan XP toimimaan tarkoituksenmukaisesti jopa 30 hengen tiimissä 

(Wells 2013; Schuh 2005: 22). Kuten edellä on jo kuvattu, toimii kehitystiimi asiakasta 



 38 

myöden samassa tilassa ja kaikkien tahojen tulee olla aina tavoitettavissa. XP:ssa roolit 

ovat: ohjelmoija, asiakas, testaaja, mittaaja, valmentaja, konsultti ja johtaja. XP:ssa on 

ominaista, että yksi henkilö voi toimia useammassa roolissa ja kaikki ovat yhteydessä 

asiakkaaseen. (Beck 1999: 105-111.) 

 

XP:ssa ohjelmoija (engl. programmer) arvioi ja kehittää toimintoja asiakkaan laati-

mista käyttäjätarinoista ja yhdessä ohjelmoijat luonnollisesti kirjoittavat koodin ja te-

kevät sen vaatiman yksikkötestauksen. Ohjelmoija laatii järjestelmän metaforan yh-

dessä asiakkaan kanssa – ohjelmoijaa pidetään XP:n sydämenä. Asiakas (engl. custo-

mer) on yhtä lailla merkittävässä, jopa haastavassa asemassa XP-projektissa – tämän 

tulee kyetä laatimaan selkeitä käyttäjätarinoita ja kyetä vaikuttamaan projektin omi-

naisuuksiin kuitenkaan niitä suoranaisesti hallitsematta. Tämä on usein kaikki uutta 

asiakkaalle projektin alkaessa ja projektin edetessä asiakkaan tulee kyetä tekemään 

merkittäviä päätöksiä ominaisuuksia priorisoitaessa. Testaajan (engl. tester) rooli on 

tukea asiakasta toiminnallisten testien laatimisessa, koska vetovastuu itse koodin tes-

taamisesta on ohjelmoijilla. Mittaaja (engl. tracker) seuraa projektin aikatauluja ja oh-

jaa kehitystiimiä niiden parantamisessa, sikäli kun projekti ei pysy alkuperäisessä ai-

kataulusuunnitelmassa. Ketterissä menetelmissä on usein henkilö, joka tuntee hyödyn-

nettävän menetelmän – XP:ssa on valmentaja (engl. coach). Hän varmistaa, että pro-

jekti toteutuu XP:n arvojen, käytäntöjen ja sääntöjen mukaisesti. XP-projektiin kuuluu 

konsultti (engl. consultant), joka toimii liiketoiminnallisena tai teknisenä asiantunti-

jana. Projektissa johtaja (engl. owner, ”big boss”) vastaa kokonaisvaltaisesti projektin 

päätöksenteosta, laaja-alainen kommunikaation kehitystiimin kanssa kuuluu olennai-

sesti johtajan tehtäviin. Hän on usein, joka kertoo, miten edetään, jos jokin poikkeaa 

odotuksista tai suunnitelmasta. (Beck 1999: 105-111.)  



 39 

4.1.4 Elinkaari 

Extreme Programmingissa ohjelmistotuotteella on kuusivaiheinen elinkaari: tutkimus-

vaihe, suunnitteluvaihe, iteraatiovaihe, tuotteistusvaihe, ylläpitovaihe ja päätösvaihe 

(Abrahammson ym. 2002). Seuraavaksi esitetyt vaihekuvaukset (Kuvio 4) perustuvat 

Abrahamssonin ym. (2002: 19-21) ja Beckin & Fowlerin (2000) näkemyksiin. 

 

 

 

 

Tutkimusvaiheessa asiakas laatii ensimmäiseen julkaisuun toivomansa toiminnot tari-

nakortteihin – kukin tuoteominaisuus omaan korttiinsa. Tässä vaiheessa kehitystiimi 

omaksuu projektissa käytettävät kehitystyökalut, teknologian ja käytännöt. Ominaista 

on, että projektin alkuvaiheessa laaditaan järjestelmästä prototyyppi, jonka avulla voi-

daan testata valittu teknologia ja tutkia järjestelmään sopivia arkkitehtuurivaihtoeh-

toja. Vaiheen kesto riippuu siitä, kuinka hyvin kehitystiimi –pääasiassa ohjelmoijat– 

tuntevat käytettäväksi valitun teknologian. 

 

 Extreme Programming -elinkaaren vaiheet mukailtuna (Abrahamsson 

ym. 2002:19) 



 40 

Suunnitteluvaiheessa tarinat priorisoidaan ja ensimmäisen pienen julkaisun sisällöstä 

tehdään päätös. Ohjelmoijat tutkivat tarinoiden vaativuutta, jonka perusteella luodaan 

alustava aikataulu. Suunnitteluvaihe kestää noin kaksi päivää. 

 

Ennen ensimmäistä julkaisua suoritetaan useampia iteraatioita iteraatiovaiheessa. 

Suunnitteluvaiheessa tehty alustava aikataulu on pilkottu iteraatioihin, jotka toteute-

taan tässä vaiheessa ennen niiden käyttöönottoa. Ensimmäisen iteraation tuloksena 

syntyy kokonaisvaltainen järjestelmäarkkitehtuuri, joka saavutetaan valitsemalla jär-

jestelmän rakentamista tukevat tarinat. Asiakas valitsee toivomansa tarinat kuhunkin 

iteraatioon ja jokaisen iteraation päätteeksi suoritetaan asiakkaan laatimat toiminnalli-

set testit. Viimeisen iteraation päätteeksi järjestelmä on valmis tuotantoon.  

 

Ennen kuin järjestelmä julkaistaan virallisesti asiakkaalle, tehdään tuotteistusvai-

heessa erilaisia testejä ja varmistuksia koskien järjestelmän suorituskykyä. Tässäkin 

vaiheessa on vielä mahdollista tehdä muutoksia ja niihin liittyvät päätökset tulee tehdä 

viimeistään tässä vaiheessa ennen julkaisemista. Jos muutoksia vielä vaaditaan, lyhen-

netään iteraation pituutta tässä vaiheessa olemaan enimmillään viikon pituinen. Mah-

dolliset myöhemmin toteutettavat ehdotukset tai valmiit ideat dokumentoidaan myö-

hempää implementointia varten. 

 

Ensimmäisen asiakkaalle tehdyn julkaisun jälkeen, tulee projektin kyetä pitämään ole-

massa oleva julkaisu tuotannossa ja samanaikaisesti tuottamaan uusia iteraatioita. 

Tämä on ylläpitovaihe, jossa vaaditaan myös asiakastuen ylläpitämistä ohjelmistoke-

hityksen ohella. Kehitystiimi voi tässä vaiheessa kokea rakenteellisia muutoksia, kun 

aktiivinen kehitysnopeus on hieman taantunut järjestelmän ollessa asiakkaan käytössä.  

 

Päätösvaihe perustuu siihen, ettei asiakkaalla ole enää uusia käyttöönotettavia tari-

noita. Tämä toki vaatii, että järjestelmä tyydyttää asiakkaan kaikilta osin – myös suo-

rituskyvyn ja luotettavuuden näkökulmista. Päätösvaiheessa kaikki tarpeellinen doku-

mentaatio on laadittu, eikä arkkitehtuuria, järjestelmärakennetta tai koodia enää muo-

kata. Päätösvaiheeseen on mahdollista päätyä myös, jos järjestelmä ei vastaa odotuksia 

tai sen jatkokehittäminen on liian kallista. 



 41 

4.2 Scrum 

Scrum on ketterä lähestymistapa innovatiivisten tuotteiden ja palveluiden kehittämi-

seen. Se on hallintalähtöinen menetelmä, joka on muihin menetelmiin verrattuna vai-

vaton ja yksiselitteinen ja sitä voidaan toteuttaa useissa erilaisissa projekteissa (Schuh 

2005: 23). Scrum sopii monimutkaisimpiin toimintaympäristöihin ja projekteihin eri-

tyisen hyvin, koska juuri Scrum-ympäristöissä vaaditaan kykyä tutkia ja vastata ha-

vaittuihin vaatimuksiin (Rubin 2013: 8). Scrum perustuu hyvin perinteiseen ketterän 

kehityksen ajatukseen – kehitystyö toteutetaan lyhyissä iteraatioissa, joiden pituus 

vaihtelee viikosta kuukauteen. Kunkin iteraation aikana itseorganisoitunut, poikkitoi-

mintoinen tiimi toteuttaa kaiken työn suunnittelusta testaukseen. Kunkin iteraation tu-

loksena tiimin tulisi kyetä tuottamaan valmiita, toimivia toimintoja. Tällä periaatteella 

kehitettävä järjestelmä toteutetaan iteraatioissa vaiheittain ja yhden iteraation loppu-

essa, alkaa seuraava jälleen nollatilanteesta suunnittelutyöllä. Scrumia käytetään eni-

ten ohjelmistotuotteiden kehittämiseen, mutta menetelmän ydinarvoja –ja käytäntöjä 

voidaan käyttää ja niitä on käytettykin erilaisten tuotteiden kehittämiseen. Menetelmä 

sopii esimerkiksi erityyppisten töiden organisointiin – esimerkiksi laitteistojen kehit-

tämisessä tai markkinointi –ja myyntihankkeissa. (Rubin 2013: 1-3.) 

 

Tässä alaluvussa esitellään Scrumin taustalla oleellisesti vaikuttavaa empiiristä pro-

sessien hallintaa, Scrumissa esiintyviä rooleja sekä kokonaisvaltaista viitekehystä tä-

män iteratiivisen menetelmän taustalla. 

4.2.1 Empiirinen prosessienhallinta 

Scrum ei ole standardoitu prosessi, jossa toteutetaan perättäisiä vaiheita, joiden taataan 

tuottavan toivottuja tuloksia, vaan kyse on työn organisoimisen ja hallinnan viiteke-

hyksestä. Se perustuu joukkoon arvoja, periaatteita ja käytäntöjä joka toimii pohjana 

projektissa lopulta käytettäville relevanteille käytännöille ja spesifeille lähtökohdille 

joiden mukaisesti Scrumia tulkitaan. Scrum on toimiva menetelmä monimutkaisten eli 

ennustamattomasti käyttäytyvien ongelmien ratkaisemiseksi. Scrumin taustalla on em-

piirinen prosessien hallinta (engl. empirical process control), joka on vastakohta mää-

ritellylle prosessienhallinnalle (engl. defined process control). Määritellyssä proses-

sien hallinnassa on kyse prosesseista, jotka toistuvasti tuottavat laadultaan hyväksyt-

täviä ja toimivia tuloksia kohtuullisin kustannuksin korkeimmalla mahdollisella laa-



 42 

dulla – empiirisessä projektien hallinnassa tällainen tilanne ei ole saavutettavissa joh-

tuen juuri aktiviteettien kompleksisuudesta. Scrumissa empiirisellä prosessien hallin-

nalla kuluja ja laatua voidaan hallita: 

 

 Korostamalla asiakkaalle projektin lopputuloksen kannalta merkittävimpiä nä-

kökulmia 

 Sallimalla asiakkaan tutkia tuotetta säännöllisesti ja täten maksimoimalla vaa-

timustenmukaisuuden 

 Jos asiakas näkee tuotteen poikkeavan tavoitteesta, sopeuttamalla tämän mah-

dollisimman pian kehitysprosessiin tai tuotteeseen. (Rubin 2013: 13; Schuh 

2005: 23; Schwaber 2004a.) 

4.2.2 Scrum-roolit 

Scrumissa roolitus on hyvin selkeä – menetelmässä on vain kolme eri roolia: tuotteen 

omistaja (engl. product owner), scrum-mestari (engl. ScrumMaster) ja kehitystiimi 

(engl. development team). Kaikki projektia koskeva hallintavastuu on jaettu näille kol-

melle. Tuotteen omistaja vastaa siitä, että kaikki projektissa panoksellaan mukana ole-

vat tahot tulevat kuulluiksi. Luomalla projektin alkuperäiset yleisvaatimukset, tuotta-

vuusobjektit (engl. return of investment (ROI) objectives) ja julkaisusuunnitelmat 

tuotteen omistaja vastaa projektin alulle saamisesta. Alkuperäisten yleisvaatimusten 

listaa kutsutaan tuotteen työlistaksi (engl. product backlog) ja tuotteen omistaja vastaa 

sen käytöstä varmistaen, että tärkeimmät toiminnot toteutetaan ensimmäisenä. Käy-

tännössä tuotteen omistaja priorisoi jatkuvasti tuotteen työlistaa ja ohjaa tärkeimpien 

toimintojen kehittämisen aina seuraavassa iteraatiossa eli on vastuussa siitä, mitä to-

teutetaan ja missä järjestyksessä. Kehitystiimi on taas vastuussa toiminnallisuuden ke-

hittämisestä. Tiimi on aina itseorganisoitunut, itsehallinnoitu ja poikkitoiminnollinen 

eli sen jäsenet toimivat yli tehtävärajojen. Kehitystiimin tehtävänä on päättää kuinka 

muuntaa tuotteen työlistassa odottavat vaatimukset osaksi projektin kohteena olevan 

tuotteen tai palvelun toiminnallisuutta. Tiimin jäsenet ovat kollektiivisesti vastuussa 

kunkin iteraation ja yhtälailla koko projektikokonaisuuden onnistumisesta. Scrum-

mestarin tehtävänä on opettaa projektissa mukana oleville tahoille Scrumin perustoi-

minta, jotta menetelmä saadaan toimimaan organisaatiokulttuurin mukaisesti, mene-

telmän perustana oleva joukko arvoja, periaatteita ja käytäntöjä huomioiden. (Schwa-

ber 2004a; Rubin 2013: 14-16.) 



 43 

4.2.3 Scrum-viitekehys 

Tässä luvussa esitettävä Scrum-viitekehys perustuu Rubinin (2013) sekä koko Scru-

min kehittäjien, Schwaberin ja Sutherlandin (2013) näkemyksiin. Scrum-prosessin lä-

pivienti perustuu aiemmin kuvatusti iteraatioihin, joiden tuloksena halutaan saada ai-

kaan valmiita toimivia tuoteominaisuuksia (engl. product increment tai product fea-

ture). Scrumissa iteraatiot ovat sprinttejä (engl. sprint). Sprintit ovat ajallisesti rajattuja 

– niille määritetään kesto, josta ei sen jälkeen poiketa. Yksittäinen sprintti voidaan 

ajatella kalenterikuukauden mittaiseksi projektiksi. Jokaisen sprintin –kuten projektin-

kin tavoitteena on saada aikaan jotain. Ennen sprinttiä määritellään mitä on rakenteilla 

ja tehdään joustava suunnitelma, joka ohjaa kuinka tämä rakennetaan. Lopulta tehdään 

suunnitelmanmukaisesti haluttu työ ja viedään projekti maaliin. Schwaber ja Suther-

land (2013) korostavat sprinttien etuina lyhyttä kestoa, jolloin monimutkaisuus ja ris-

kit pysyvät rajallisina. Eduksi he näkevät myös asioiden ennustettavuuden, kun kye-

tään läpi sprintin tutkimaan ja omaksumaan ympäristöä sekä kustannusriskien pysy-

misen alhaisina puhuttaessa vain kuukauden kustannusjaksoista.  

 

Sprintti alkaa sprintin suunnittelulla, joka on koko Scrum-tiimin yhdessä toteuttama 

vaihe. Suunnitteluvaihe kestää enintään 8 tuntia kuukauden kestoisessa sprintissä. 

Suunnitteluvaiheessa halutaan saada vastaukset kysymyksiin: 

  

1) Mitä voidaan tehdä tässä sprintissä?  

2) Kuinka haluttu työ saadaan tehdyksi? 

 

Kunkin sprintin lähtökohta perustuu tuotteen omistajan näkemykseen siitä, mitä sekä 

sisäisten että ulkoisten sidosryhmien odotusten perusteella halutaan luoda – Rubin kut-

suu tätä näkemystä ja lähtökohtaa nimellä the big cube. Koska tämä näkemys on usein 

varsin laaja, pilkotaan se osiin – joukoksi toivottuja tuoteominaisuuksia, jotka priori-

soidaan tuotteen omistajan laatimaan tuotteen työlistaan. Priorisointi perustuu lisäar-

von tuottoon, kustannustehokkuuteen, käytössä olevaan tietämykseen sekä riskienhal-

lintaan. Uusia ohjelmistotuotteita kehitettäessä tuotteen työlista kattaa luonnollisesti 

pelkästään uusia tuoteominaisuuksia. Vastaavasti, jos kyseessä on jo olemassa olevan 

ohjelmistotuotteen kehitysprojekti, voi työlista sisältää muiden muassa uusia tuote-

ominaisuuksia, muutoksia olemassa oleviin ominaisuuksiin, virheiden korjauksia tai 

teknisiä parannuksia. Se, mitä sprintin aikana kyetään siis toteuttamaan perustuu sii-



 44 

hen, että kehitystiimin, tuotteen omistajan ja tuotteen työlistan välillä on selkeä ym-

märrys. Kun sprinttikohtainen tavoite on asetettu, ja on selkeää, mitä kyetään ja halu-

taan saavuttaa, määritetään, kuinka tämä kaikki tapahtuu. Kehitystiimi päättää, kuinka 

se rakentaa toiminnalliseen muotoonsa tuotteen työlistasta poimitun tuoteominaisuu-

den sprintin aikana. Tuotteen työlistasta tässä sprintissä toteutettavaksi valittu ominai-

suus ja suunnitelma siitä kuinka se toimitetaan muodostavat sprintin tehtävälistan. 

Sprintin tehtävälistan avulla, koko suunnitteluvaiheen päätteeksi, kehitystiimin pitäisi 

kyetä selittämään tuotteen omistajalle ja Scrum-mestarille kuinka se tulee työskente-

lemään itseorganisoidusti saavuttaakseen sille asetetun tavoitteen ja luomaan odote-

tunlaisen tuoteominaisuuden. Kuviossa 6 on kuvattu Scrum viitekehys sprintin sisäl-

lön muodossa. (Rubin 2013: 20-22; Schwaber & Sutherland 2013.) 

 

 

Suunnitteluvaiheen päätyttyä kehitystiimi siirtyy Scrum-mestarin ohjaamana sprintin 

toteutukseen. Kuten edellä esitettiin, sprintin käytännön toteutus tapahtuu päivittäisinä 

yhteisinä Scrum-tuokioina (engl. daily Scrum), joiden perusteella kehitystiimi kykenee 

edelleen toimimaan itseorganisoidusti. Päivittäinen Scrum kestää yleisesti 15 minuut-

tia ja siinä kehitystiimi tutkii editymistä kohti sprintin tavoitetta sekä kuinka edistymi-

 Scrum -viitekehys (Rubin 2013:17) 



 45 

nen vastaa sprintin tehtävälistaa ja omaksuu toistensa näkemykset yhtenäisiksi saavut-

taen käsityksen tulevan vuorokauden työstään. Kehitystiimin kunkin jäsenen tulisi se-

littää seuraavat kysymykset: 

 

1) Mitä tein tavoitteemme saavuttamiseksi eilisen päivittäisen Scrumin jälkeen? 

2) Mitä teen tänään tavoitteemme saavuttamiseksi? 

3) Tunnistanko jotain esteitä tavoitteen saavuttamiseksi?  

 

Päivittäiset Scrumit edistävät kommunikointia, minimoivat muut tapaamiset, edistävät 

esteiden löytämistä, jolloin vaaditaan myös nopeaa päätöksentekoa sekä edistävät en-

nen kaikkea koko kehitystiimin tietämyksen tasoa. Tähän perustuu Scrum-kehittäjien 

ajatus asioiden tutkimisesta ja omaksumisesta tapaamisissa. (Rubin 2013: 23-25; 

Schwaber & Sutherland 2013)  

 

Sprintin toteutusvaiheen jälkeen lähtökohta on se, että Scrum-tiimillä tulisi olla käsis-

sään lopulliseen kehityksen kohteena olevaan ohjelmistotuotteeseen valmis tuoteomi-

naisuus lisättäväksi. Rubin (2013: 25) kuvaa valmista tuoteominaisuutta nimellä toi-

mituspotentiaalinen tuoteinkrementti (engl. potentially shippaple product increment). 

Tällä viitataan siihen, että sprintissä toteutettavaksi haluttu tuoteominaisuus tai tuote-

ominaisuuksien joukko on todellakin valmiiksi tehty ja täysin tarkoituksenmukaisella 

tavalla. Edellytyksinä pidetään korkealaatuisuutta ja potentiaalista toimitusvalmiutta. 

Sekä Rubin (2013:26) että Schwaber ja Sutherland (2013) pitävät tässä kohtaa tär-

keänä, että tuote on todellakin ”tehty” (engl. ”done”) ja määrittelevät tuotteen valmiina 

olon tarkasti. Heidän mukaan ”tehty” -tila vaihtelee merkittävästi Scrum-tiimistä riip-

puen, mutta oleellista tässä on, että jokaisella projektissa mukana olevalla taholla on 

yhteisymmärrys siitä, mitä tehdyn työn valmiina oleminen tarkoittaa, jotta voidaan 

taata yhdenmukainen hyväksyttävyys. Schwaber ja Sutherland (2013) mainitsevat, että 

Scrum-tiimit usein kokemuksen myötä kehittyvät oman ”tehty”-tilansa arvioimisessa 

– tämä näkyy esimerkiksi siinä, mitä lopulta kirjataan sprintin tehtävälistaan kyeten 

lukemaan ja huomioimaan tiimin suorituskyky ja mitä todellisuudessa kyetään yhden 

sprintin aikana saattamaan ”tehty”-tilaan. 

 

Jokaisen sprintin päätteeksi suoritetaan sprintin katsaus (engl. Sprint review), jossa 

tutkitaan aikaan saatua tuoteominaisuutta ja omaksutaan tuotteen työlistan tila – saa-

tiinko aikaan haluttu tulos ja tuleeko työlistaan tässä kohtaa muutoksia. Sprintin kat-

sauksessa koko Scrum-tiimi ja kaikki sidosryhmät käyvät yhdessä läpi, mitä sprintin 



 46 

aikana on tehty. Katsauksessa halutaan kyetä tuottamaan monitahoista palautetta ja 

miettimään yhdessä mitä tehdään seuraavaksi lisäarvon optimoimiseksi. Sprintin kat-

saukseen osallistuvat Scrum-mestari ja tuotteen omistajan kutsumat avainasemassa 

olevat sidosryhmät. Katsauksessa tuotteen omistaja kuvaa, mitä kohtia tuotteen työlis-

tasta on saatettu ”tehty”-tilaan ja mitä ei sekä kehitystiimi kertoo, mitkä asiat sprintin 

aikana onnistuivat, mitkä epäonnistuivat ja  kuinka esiintyneet esteet ratkaistiin. Ke-

hitystiimi myös demonstroi tehdyksi saatetun työn ja vastaa tuoteominaisuutta koske-

viin kysymyksiin. Katsaukseen kuuluu myös, että tuotteen omistaja esittää sen hetki-

sen tuotteen työlistan ja tekee siihen mahdollisia muutoksia tarvittaessa. Koko Scrum-

tiimi ja sidosryhmät käyvät läpi, mitä tehdään seuraavaksi, saadakseen aikaan arvoa 

tuottavan pohjustuksen seuraavan sprintin suunnittelulle. Tämän lisäksi tehdään kat-

saus koskien mahdollisiin muutoksiin tuotteen käyttöön tai tulevaan käyttöalueeseen 

liittyen sekä katsaus ajanhallintaan, budjettiin, potentiaalisiin esiin nousseisiin kykyi-

hin ja tuleviin odotettuihin tuotejulkaisuihin. Sprintin katsauksen tuloksena on uudel-

leenarvioitu tuotteen työlista, josta ilmenee mahdolliset seuraavassa sprintissä toteu-

tettavat tuoteominaisuudet. Tässä kohtaa tuotteen työlistaan on myös mahdollista 

tehdä muutoksia uusien mahdollisuuksien varalta.  

 

Sprintti päättyy aina mennyttä sprinttiä koskevaan jälkikatsaukseen (engl. Sprint ret-

rospective). Siinä Scrum-tiimin on mahdollista tutkia itseään ja luoda suunnitelma ke-

hityskohteille ennen seuraavaa sprinttiä. Sprintin jälkikatsauksen tarkoituksena on tut-

kia ihmisten, suhteiden, etenemisen ja työkalujen kannalta, kuinka viimeisin sprintti 

sujui sekä tunnistaa ja laittaa järjestykseen pääkohdat onnistumisista ja kehityskoh-

teista. Lopulta jälkikatsauksessa luodaan suunnitelma kehityskohteiden korjaamiseksi. 

4.3 Kanban 

Kanban -ajatus on syntynyt autovalmistaja Toyotan asiantuntijoiden toimesta ja sen 

juuret ovat jopa 1940-luvulla. Kanbania on alettu autoteollisuuden ohella myöhemmin 

soveltamaan myös muilla toimialoilla, kuten ohjelmistotuotannossa. Pyrkimällä tasa-

painottamaan tekeillä olevan työn määrää kehitystiimin kapasiteettiin, Kanban tarjoaa 

joustavammat suunnittelumahdollisuudet, nopeamman tuotannon, selkeän fokuksen 

sekä läpinäkyvyyden koko kehityssyklien ajan. Kanban edustaa juuri oikeaan tarpee-

seen (engl. just-in-time) -ajattelua sen perimmäisessä merkityksessään eli tavoitellaan 

ihanteellista toimitusaikaa sekä –määrää. (Atlassian 2015.) 



 47 

 

Alkuperänen Kanban on kuvattu sen kehittäjien toimesta tuotannonhallintajärjestel-

mäksi just-in-time tuotantoa varten. Kanbanin nähdään laskevan prosessinhallintakus-

tannuksia, koska se ei vaadi erillisiä, reaaliaikaisia järjestelmiä kutakin erillistä pro-

sessia ja ostajaa sekä näiden edellyttämiä tuotantoaikatauluja varten. Kanbanin näh-

dään tuottavan nopeaa dataa muuttuvassa tuotantokapasiteetissa, toimintavalmiudessa 

tai henkilöstön määrässä. Ajatus vain tarvittavan määrän tuottamisessa myös minimoi 

ylituotannon sekä mahdollistaa tuotannon optimoinnin kysynnän mukaiseksi. (Atlas-

sian 2015; Sugimori, Kusunoki, Cho & Uchikawa 1977.) 

4.3.1 Viitekehys 

Kanban-tiimi keskittyy ainoastaan siihen työhön, joka on juuri sillä hetkellä tuotan-

nossa. Kun työkokonaisuus saadaan valmiiksi, otetaan tuotteen työlistasta (engl. pro-

duct backlog) seuraava työkokonaisuus käsittelyyn. Tuotteen omistaja (engl. the pro-

duct owner), joka hallinnoi työlistaa, voi vapaasti uudelleenpriorisoida työlistan jär-

jestystä, koska tiimi työskentelee jatkuvasti yhden työkokonaisuuden kanssa, joten 

mahdolliset muutokset työlistassa eivät siten vaikuta heidän sen hetkiseen työhönsä. 

Maksimaalisen liiketoiminnallisen arvon tuottamiseksi on merkityksellistä, että tär-

keimmät tuoteominaisuudet ja työkokonaisuudet ovat työlistan kärjessä eli valmiina 

työstettäväksi seuraavaksi. Kanbanissa tärkein työn mittari on aikataulu ja suunnitel-

lun iteraation keston mukaisesti toimiminen. Iteraation kesto tässä tarkoittaa ajallista 

pituutta siitä, kun työ otetaan kehitystiimin toimesta vastaan siihen, kun tuoteominai-

suus tai työkokonaisuus toimitetaan eteenpäin. Kanban-tiimi muodostuu yksilöistä, 

joilla ei ole Scrumin tai eXtreme Programmingin tapaan nimettyjä tehtäviä eikä rooleja 

missään määrin, vaan kehitystiimin sisäisen tietämyksen jakaminen on erittäin merkit-

tävässä asemassa ja sitä on määrä edistää läpi työskentelyn. Heterogeenisin työtehtä-

vin voidaan myös edistää iteraation kestoa.  Kanban-viitekehyksessä koko tiimi on 

yhteisvastuussa siitä, että työkokonaisuus etenee prosessin läpi sulavasti. Kanbanissa 

halutaan pyrkiä rajoittamaan ja minimoimaan käsitteillä olevan työn (engl. WIP, work 

in progress). Mitä enemmän keskeneräisiä työkokonaisuuksia tai mitä useammassa 

projektissa tiimiläiset ovat samanaikaisesti mukana, sitä vaikeampaa ja monimutkai-

sempaa on työkokonaisuuksien tai yksittäisten tuoteominaisuuksien valmiiksi saatta-

minen.  



 48 

4.3.2 Kanban-taulu 

Kanbanissa on usein työn etenemisen ja yleisen seurannan tehostamiseksi käytössä 

jonkinlainen Kanban-taulu (Kuvio 6). (Atlassian 2015; VersionOne 2015.) 

 

 

 

 

Kanban-taululla tuotetaan selkeä kuva projektin etenemisestä, koska se näyttää kunkin 

kehitystiimin jäsenen tekemät tehtävät, selventää kunkin ominaisuuden priorisointia 

sekä sen avulla voidaan löytää projektin etenemistä hankaloittavat mahdolliset pullon-

kaulat. Sen avulla seurataan, mitkä tuoteominaisuudet ovat tuossa tehtäväksi, mitkä 

ovat parhaillaan tekeillä, mitä ominaisuuksia katselmoidaan ja mitkä ovat saatettu täy-

sin valmiiksi ”tehty”-tilaan. Taulun avulla tuotetaan siis vain halutut ominaisuudet ja 

minimoidaan edellä kuvatusti tekeillä olevan työn määrä. Keskityttäessä vain muuta-

maan tuoteominaisuuteen kerrallaan, julkaisut asiakkaalle ovat jatkuvia. Kanbanin 

avulla kyetään omaksumaan projekti asiakkaan tarpeiden mukaiseksi, koska käytössä 

ovat lyhyet palautekierrokset. Menetelmän toiminnan avain on keskittyminen jatku-

vaan etenemiseen välttämättömien iteraatioiden sijasta. (Ahmad, Markkula & Oivo 

2013.) 

 Esimerkki Kanban -taulusta (VersionOne 2015). 



 49 

 

Kanbania pidetään jokseenkin samankaltaisena menetelmänä kuin Scrum, mutta toki 

molemmilla on tietyt ominaispiirteensä, esimerkiksi Scrumissa tarkoin määritellyt 

roolit (tuotteen omistaja, Scrum-master ja kehitystiimi). Kanbanissa ei rooleja ole en-

nalta määritelty vaan kehitystiimi voi oman näkemyksensä ja toimivaltansa pui