OHJELMISTOPROJEKTINHALLINNAN KEHITTÄMINEN SCRUM-MENETELMÄLLÄ

OHJELMISTOPROJEKTINHALLINNAN KEHITTÄMINEN SCRUM-MENETELMÄLLÄ Panu Vuori Opinnäytetyö Kesäkuu 2014 Automaatioteknologian koulutusohjelma YAMK Tekniikan ja liikenteen ala

KUVAILULEHTI Tekijä(t) VUORI, Panu Julkaisun laji Opinnäytetyö Sivumäärä 76 Päivämäärä 6.6.2014 Julkaisun kieli Suomi Verkkojulkaisulupa myönnetty (X ) Työn nimi OHJELMISTOPROJEKTINHALLINNAN KEHITTÄMINEN SCRUM-MENETELMÄLLÄ Koulutusohjelma Automaatioteknologian koulutusohjelma. Ylempi ammattikorkeakoulututkinto. Työn ohjaaja(t) SELOSMAA, Seppo Toimeksiantaja(t) Metsys Oy VÄÄTÄINEN, Mika, Toimitusjohtaja Tiivistelmä Perinteisesti ohjelmistoprojektit ovat toteutettu hyödyntäen 1970-luvulla kehitetty vesiputousmallia. Tässä mallissa projekti viedään lävitse lineaarisesti etukäteen määriteltyjen vaiheiden mukaisesti. Vaiheet ovat: esitutkimus, määrittely, suunnittelu, toteutus, testaus, käyttöönotto ja ylläpito. Kun yksi vaihe on saatu päätökseen, voidaan siirtyä seuraavaan vaiheeseen, mutta myös paluu edelliseen vaiheeseen on mahdollinen. Teoriassa tämä malli toimii hyvin, mutta käytännössä tämä ei ole paras mahdollinen tapa toteuttaa ohjelmistoprojekteja. Ongelmia aiheuttaa mm. määrittelyvaiheessa tehdyn speksin muuttuminen projektin edetessä. Käytännössä on havaittu, että pysyviä vaatimusmäärittelyjä ei voida tehdä, koska osa vaatimuksista selviää vasta projektin aikana tai jo määritellyt vaatimukset muuttuvat kesken projektin. Edellä kuvattuihin ongelmiin on etsitty ratkaisua ns. ketteristä menetelmistä. Näissä menetelmissä arvostetaan yksilöä ennemmin kuin prosesseja ja työkaluja, toimivaa ohjelmistoa ennemmin kuin perusteellista dokumentaatiota, asiakasyhteistyötä ennemmin kuin hankalia sopimusneuvotteluja ja muutoksiin reagoimista ennemmin kuin suunnitelmien orjallista seuraamista. Kun perinteisessä vesiputousmallissa muutokset määrittelyvaiheessa tehtyyn speksiin aiheuttavat ongelmia ohjelmiston toteutusvaiheessa, niin ketterissä menetelmissä hyväksytään muutos ja ollaan valmiita reagoimaan niihin. Ketteriä menetelmiä on useita ja niistä yksi suosituimmista on Scrummenetelmä. Opinnäytetyössä tutkitaan ohjelmistotalo Metsys Oy:n projektinhallinnan muutosta perinteisestä vesiputousmallista ketterään Scrum-menetelmään. Työssä seurataan Scrum-menetelmän toimivuutta noin puoli vuotta kestävässä pilottiprojektissa, mikä päättyy lopulta toimivan järjestelmän käyttöönottoon. Avainsanat (asiasanat) Projektinhallinta, Scrum, ohjelmistokehitys, ketterä kehitys Muut tiedot

DESCRIPTION Author(s) VUORI, Panu Type of publication Master s Thesis Pages 76 Title The usage of Scrum in software development project Date 6.6.2014 Language Finnish Permission for web publication (X) Master s degree Program Automation technology Tutor(s) SELOSMAA, Seppo Assigned by Metsys Oy VÄÄTÄINEN, Mika, CEO Abstract Traditionally, software development projects have been executed using by as call waterfall model. Waterfall model is a sequential design process where projects go through linearly, in straight line with beforehand defined phases. Phases are conception, initiation, analysis, construction, testing, production implementation and maintenance. Phases are executed one at time and when one phase is completed next phase can be started, return to the previous phase is also possible. In theory, this model works well. But in practice this is not the best way to follow through the project. In many cases the requirement specification changes during the project and waterfall model are not able to react with agility needed. For the above-described problem the agile software development method have been developed. In an agile development method the main values are individuals over the process and tools, working software over the comprehensive documentation, customer collaboration over the contract negotiation and responding to changes over following exactly the plan. Several agile development method are known and the one of the most popular is Scrum. The aim of this thesis was implement Scrum software development method for the Metsys company and find the answers a questions: how the transformation from the waterfall model to Scrum model has succeeded and whether the Scrum gives any advantage the development teams? Keywords Agile, Scrum, project management, software development Miscellaneous

1 SISÄLTÖ 1 JOHDANTO... 5 2 OHJELMISTOTUOTANTO... 7 2.1 Perinteinen ohjelmistoprojekti... 7 2.2. Ongelmat ohjelmistotuotannossa... 9 2.3 Ketterät menetelmät... 11 2.3.1 Agile manifesti... 11 2.3.1.1 Arvo 1... 12 2.3.1.2 Arvo 2... 12 2.3.1.3 Arvo 3... 12 2.3.1.4 Arvo 4... 13 2.3.2 Scrum-menetelmä... 14 2.3.2.1 Empiirinen prosessin hallinta... 14 2.3.2.2 Scrumin arvot... 16 2.3.2.2.1 Sitoutuminen... 16 2.3.2.2.2 Keskittyminen... 16 2.3.2.2.3 Avoimuus... 16 2.3.2.2.4 Kunnioitus... 17 2.3.2.2.5 Rohkeus... 17 2.3.2.3 Scrumin roolit... 18 2.3.2.3.1 Tuotteen omistaja... 18 2.3.2.3.2 Scrum-mestari... 18 2.3.2.3.3 Kehitystiimi... 18 2.3.2.4 Scrum-prosessi... 19 2.3.2.4.1 Visiointi... 19 2.3.2.4.2 Tuotteen työlistan muodostaminen... 20 2.3.2.4.3 Sprintin suunnittelu... 20 2.3.2.4.4 Sprintti... 21 2.3.2.4.5 Päiväpalaveri (Daily Scrum)... 22 2.3.2.4.6 Sprintin katselmointi... 22 2.3.2.4.7 Sprintin jälkitarkastelu (Retrospektiivi)... 22 2.3.2.5 Scrumin dokumentit... 23 2.3.2.5.1 Tuotteen työlista... 23 2.3.2.4.2 Julkaisun edistymiskäyrä... 24

2 2.3.2.4.3 Sprintin työlista... 24 2.3.2.4.4 Sprintin edistymiskäyrä... 25 2.3.3 Muut ketterät menetelmät... 25 2.3.3.1 XP (extreme Programming)... 25 2.3.3.2 Adaptive Software Development (ASD)... 28 2.3.3.3 Crystal metodit... 29 3 LÄHTÖKOHDAT PROJEKTINHALLINAN KEHITTÄMISELLE.. 31 3.1 Metsys Oy... 31 3.2 Metsysin projektinhallinta... 31 3.3 Nykyisen projektinhallinnan kartoitus... 33 3.3.1 Hyvät puolet nykyisissä menetelmissä... 33 3.3.2 Haasteet nykyisissä menetelmissä... 34 3.3.2.1 Määrittelyvaihe... 34 3.3.2.2 Toteutusvaihe... 34 3.3.2.3 Testaus... 35 3.3.2.4 Ylläpito... 35 3.3.3 Kvantitatiivisen-kyselyn tulokset... 35 3.3.3.1 Ensimmäinen kysely ennen Scrum-projektia... 36 3.3.3.1 Toinen kysely projektin päätyttyä... 36 3.4 Scrumin soveltuminen Metsysin käytäntöihin... 36 3.5 Scrum-koulutus... 37 4 TOTEUTUS... 38 4.1 Wattensin projekti... 38 4.2 Projektin aloitus... 38 4.3 Projektin eteneminen... 40 4.3.1 Sprintti 1 (5.1.2011 19.1.2011)... 40 4.3.2 Sprintti 2 (19.1.2011 31.1.2011)... 42 4.3.3 Sprintti 3 (31.1.2011 14.2.2011)... 42 4.3.4 Sprintti 4 (14.2.2011 28.2.2011)... 43 4.3.5 Sprintti 5 (28.2.2011 14.3.2011)... 44 4.3.6 Sprintti 6 (14.3.2011 28.3.2011)... 45 4.3.7 Sprintti 7 (28.3.2011 11.4.2011)... 46 4.3.8 Sprintti 8 (11.4.2011 25.4.2011)... 48 4.3.9 Sprintti 9 (25.4.2011 9.5.2011)... 49 4.3.10 Sprintti 10 (9.5.2011 23.5.2011)... 49 4.3.11 Sprintti 11 (24.5.2011 23.5.2011)... 50 4.4 Projektin päättäminen... 51 5 TULOKSET... 52

6 TULOSTEN ANALYSOINTI... 54 6.1 Scrum-menetelmän edut... 54 6.1.1 Sprintin suunnittelukokous... 54 6.1.2 Päiväpalaveri... 55 6.1.3 Sprintin katselmointi ja jälkitarkastelu... 56 6.1.4 Scrumin dokumentit... 56 6.1.4 Scrumin muut hyödyt Metsysille... 59 6.2 Scrum-menetelmän haasteet ja ongelmat... 59 6.3 Scrumin toimivuus Metsysin projektissa... 60 6.4 Vaikutus laatuun... 61 6.5 Vaikutus kustannuksiin... 62 7 POHDINTA... 62 LÄHTEET... 66 LIITTEET... 68 Liite 1. Agile Manifesti... 68 Liite 2. Ensimmäinen kysely... 69 Liite 3. Toinen kysely (ennen Scrum-projektia)... 69 Liite 4. Kolmas kysely (Scrum-projektin jälkeen)... 72 3 KUVIOT KUVIO 1. Vesiputousmallin prosessi.... 7 KUVIO 2. Scrum prosessikaavio.... 19 KUVIO 3. ADS-menetelmän prosessi.... 28 KUVIO 4. Crystal metodin kategoriat.... 30 KUVIO 5. Sprintti 1 edistymiskäyrä... 41 KUVIO 6. Sprintti 3 edistymiskäyrä... 42 KUVIO 7. Sprintti 4 edistymiskäyrä... 43 KUVIO 8. Sprintti 5 edistymiskäyrä... 45 KUVIO 9. Sprintti 6 edistymiskäyrä... 46 KUVIO 10. Sprintti 7 edistymiskäyrä.... 47 KUVIO 11. Sprintti 8 edistymiskäyrä.... 48 KUVIO 12. Sprintti 9 edistymiskäyrä.... 49 KUVIO 13. Sprintti 10 edistymiskäyrä.... 50 KUVIO 14. Sprintti 11 edistymiskäyrä.... 51

4 KUVIO 15. Julkaisun edistymiskäyrä.... 53 KUVIO 16. Tuotteen työlista.... 57 KUVIO 17. Julkaisun edistymiskäyrä.... 57 KUVIO 18. Sprintin työlista.... 58 KUVIO 19. Sprintin edistymiskäyrä.... 58

5 1 JOHDANTO Tässä opinnäytetyössä tarkastellaan Scrum-menetelmän soveltuvuutta ohjelmistotalo Metsys Oy:n ohjelmistoprojektien hallinnassa. Opinnäytetyössä vietiin läpi Metsysin ensimmäinen projekti käyttäen Scrum-menetelmää. Työssä analysoidaan tämän projektin onnistumista ja soveltumista Metsysin toimintaympäristöön ja - tapoihin. Scrum-menetelmä kuuluu ns. ketteriin menetelmiin, joita alettiin käyttämään ohjelmistoprojekteissa enemmissä määrin 1990-luvulla. Ketterien menetelmien pääpaino on toimivien ohjelmistojen tuottamisessa, suorassa viestinnässä ja nopeassa reagoinnissa muutoksiin. Ketterissä menetelmissä pyritään minimoimaan riski jakamalla ohjelmistokehitys lyhyisiin iteraatioihin, jotka kestävät tyypillisesti yhdestä neljään viikkoa. Kaikki ketterät menetelmät perustuvat Agile Manifestiin. Haastaviksi ohjelmistoprojektit tekee määritysten puutteellisuus tai niiden muuttuminen kesken projektin. Uutta järjestelmää tilatessaan asiakas ei aina itsekkään tiedä yksityiskohtaisesti mitä ominaisuuksia uudelta järjestelmältä toivotaan, tästä seurauksena järjestelmän määritykset ja tarpeet muuttuvat läpi projektin. Useasti Metsysin ohjelmistoprojekteissa on haasteita projektin läpinäkyvyydessä ja kommunikoinnissa projektiryhmän kesken. Lisäksi ohjelmistosuunnittelijoiden osallistuminen samanaikaisesti useaan projektiin luo haasteita projektien menestyksekkäälle läpiviemiselle. Näihin haasteisiin haettiin vastausta Scrummenetelmästä. Allekirjoittanut toimii pilottiprojektissa Scrum-mestarina, jonka vastuulla tässä projektissa on Scrum-menetelmien jalkauttaminen käytäntöön ja valvoa, että sovittuja menetelmiä noudatetaan projektissa. Lisäksi projektiin osallistuu projektiomistaja ja kolme ohjelmistosuunnittelijaa, projektiomistaja osallistuu myös ohjelmointityöhön. Projektin päämääränä on tuottaa automaattitrukkien ohjausjärjestelmä paperitehtaalle Itävaltaan.

6 Luvussa kaksi kerrotaan tietoperusta perinteisistä menetelmistä viedä läpi ohjelmistoprojekti ja syvennytään ketteriin-menetelmiin pääpainona Scrummenetelmä. Luvussa kolme analysoidaan Metsysin käytössä ollutta projektinhallintaa. Suoritimme kolmiosaisen mielipidekyselyn Metsysin henkilöstölle koskien käytössä olevaa projektinhallintaa ja sen toimivuutta. Kyselyn ensimmäisessä osiossa kysyttiin kaksi avointa kysymystä. Ensimmäisen kyselyn vastausten pohjalta suoritettiin kvantitatiivinen-kysely. Tämä kysely suoritettiin kahteen kertaan, ennen ja jälkeen pilottiprojektin. Luvussa neljä kerrotaan pilottiprojektin etenemisestä sprintti kerrallaan. Alun perin olimme suunnitelleet, että projekti pystytään viemään lävitse kuudessa kahden viikon pituisessa sprintissä. Lopulta projekti pitkittyi erinäisistä syistä 11 sprintin mittaiseksi. Luku viisi sisältää analysoinnin pilotti-projektista. Analysoin projektin onnistumista Scrum-menetelmän näkökulmasta ja tarkastelin Scrumin hyötyjä ja haasteita pilottiprojektissa Metsysin toimintaympäristössä. Luvuissa kuusi ja seitsemän pohditaan Scrum-menetelmän sopivuutta Metsysin toimintaympäristöön ja mietitään miten menetelmää voidaan jatkossa hyödyntää entistä paremmin Metsysin projektinhallinnassa.

7 2 OHJELMISTOTUOTANTO 2.1 Perinteinen ohjelmistoprojekti Perinteisesti ohjelmiston kehitystyö tai koko elinkaari on jaettu vaiheisiin ja siksi puhutaankin vaihejakomalleista. Perinteinen vaihejakomalli on vesiputousmalli (waterfall model), jonka yksi versio on esitetty kuviossa 1. 1970-luvulla kehitetty vesiputousmalli on näihin päiviin asti toiminut lähes aina ohjelmistokehitysprojektien pohjana. Vesiputousmallista on useita versioita vaiheineen, mutta yleisesti projektiin kuuluu ainakin määrittely, suunnittelu, toteutus, käyttöönotto ja ylläpito. Huolimatta vaiheistuksesta, kaikki vaiheet ovat riippuvaisia toisistaan. Vesiputousmallissa projekti etenee lineaarisena prosessina alusta loppuun. Toisinaan joudutaan palaamaan aiempaan vaiheeseen myöhemmin havaittujen seikkojen, kuten määrittelypuutteiden vuoksi. (Haikala & Märijärvi 2004, 36-37.) KUVIO 1. Vesiputousmallin prosessi. KUVIO 1. Vesiputousmallin prosessi. Esitutkimusvaihe alkaa yleisten, korkeamman tason vaatimusten selvittämisellä. Käytännössä tässä vaiheessa siis selvitetään miksi ohjelmisto tai järjestelmä tulee tehdä. Tämä vaihe on hyvin haastava, sillä asiakkaan todelliset tarpeet on saatava selville ja ne on ymmärrettävä perusteellisesti. Mikäli esitututkimusvaiheessa

8 määritetyt asiakasvaatimukset ovat virheellisiä tai väärin ymmärretty, ei hyvään lopputulokseen ole mahdollista päästä. (Haikala & Märijärvi 2004, 37.) Määrittelyvaiheessa laaditaan ensin esitutkimusvaiheen tulosten perusteella vaatimusmäärittelydokumentti eli speksi, johon kirjataan kaikki asiakkaan tarvitsemat ominaisuudet. Tämäkin työvaihe vaatii äärimmäistä tarkkuutta, sillä juuri tätä dokukmenttia vasten tarkastellaan projektin lopuksi sisältääkö lopputuote kaikki tilatut ominaisuudet. Määrittelyvaiheessa työstetään vielä vaatimusmäärittelyn pohjalta ohjelmiston toteutusmäärittelydokumentti, jossa kuvataan ohjelmiston toiminnot sekä rajoitukset. Toteutusmäärittelydokumenttiin voidaan kirjata myös sellaisia ohjelmistoa koskevia vaatimuksia, mitkä eivät ole toiminnallisia vaatimuksia, esimerkiksi suoritustehoon liittyviä vaatimuksia. (Haikala & Märijärvi 2004, 38-39.) Suunnitteluvaiheessa suunnitellaan ohjelmiston toteutus toteutusmäärittelyn perusteella. Usein suunnitteluvaiheessa laaditaan ensin korkean tason suunnitelma (arkkitehtuurisuunnitelma) ja sen jälkeen suunnitellaan toteutus tarkammalla tasolla. (Haikala & Märijärvi 2004, 28-29) Toteutusvaiheessa kirjoitetaan itse ohjelmakoodi suunnitteludokumentin mukaisesti. Ohjelmointivaihe katsotaan päättyneeksi, kun kaikki vaatimusmäärittelyssä mainitut ominaisuudet on toteutettu ja lopullisesta ohjelmistosta saadaan virheetön käännös. (Haikala & Märijärvi 2004, 40.) Testaus on oma osaamisalueensa. Projektipäälikön täytyy ymmärtää testaamisen merkitys, koska jokaisessa projektissa testataan ja sen aiheuttama työmäärä on suuri. Huono testaaminen tai sen laiminlyönti saattavat aiheuttaa projektin lopputuloksessa ikäviä yllätyksiä. Projektin alkuvaiheessa on hyvä suunnitella strategia testaamiselle tai ainakin määritellä projektin eri vaiheille omat testaukset ja niille tavoitteet. (Lehtimäki 2006, 170.) Käyttöönotto vaiheessa kehitetty ohjelmisto luovutetaan asiakkaalle ja otetaan todelliseen käyttöön. Tässä vaiheessa ohjelmisto myös integroidaan tarvittaessa muihin ympäröiviin järjestelmiin rajapintojen kautta.

9 Ohjelmiston käyttöönoton jälkeen ohjelmisto siirtyy yleensä ylläpidon piiriin. Ylläpito on asiakkaan ongelmien ratkomista, esimerkiksi virheiden korjaamista, neuvontaa sekä parannusehdotuksien käsittelemistä. Ohjelmistotuotteiden tapauksessa tuotteella ei useinkaan ole varsinaista ylläpitovaihetta. Korjaukset, muutokset ja lisäykset toteutetaan projektissa, jossa toteutetaan tuotteen seuraava versio. (Haikala & Märijärvi 2004, 41.) 2.2. Ongelmat ohjelmistotuotannossa Eräs ohjelmistotuotannon tunnetuimmista asiantuntijoista, Frederic Brooks, mainitsee artikkelissaan No Silver Bullet ohjelmistotuotannon erityispiirteitä verrattuna perinteisiin tekniikan aloihin. Näitä erityispiirteitä ovat mm. ohjelmistojen luontainen monimutkaisuus, näkymättömyys ja muunneltavuus. Haikala & Märijärvi lisäävät listaan vielä ainutkertaisuuden, menetelmien skaalautumattomuuden ja ohjelmistoihin perustuvien järjestelmien tietynlainen epäjatkuvuus. Monimutkaisuus. Ohjelmistotuotteet ovat luonnostaan monimutkaisia. Koska ongelmat, joita ohjelmistot ratkovat, ovat monimutkaisia, myös ohjelmat ovat pakostakin monimutkaisia. Hyvälläkään ohjelmistosuunnittelulla monimutkaisuutta ei pystytä poistamaan huonolla suunnittelulla sitä kylläkin pystytään lisäämään. Ohjelmistotuotteen monimutkaisuus liittyy usein sen kokoon: suuret järjestelmät ovat yleensä myös monimutkaisia. (Brooks 1986, 3.) Näkymättömyys. Projektinhallinnan kannalta ohjelmistokehitystyön hankalin ongelma on näkymättömyys: ohjelmistotyön keskeneräisistä tuotoksista on hyvin hankala sanoa projektin valmiusastetta. Projekti saattaa esimerkiksi olla hyvin aikataulussa, vaikka puolet ajasta on jo käytetty eikä riviäkään ohjelmakoodia ole vielä kirjoitettu. Vastaavasti projekti saattaa olla pahasti myöhässä, vaikka vasta puolet ajasta on käytetty ja järjestelmätestaus on jo alkanut. Projektinhallinnassa onkin tärkeää pyrkiä tekemään projektin todellinen eteneminen näkyville mm. vaiheistamalla projekti tilanteeseen parhaiten sopivalla tavalla sekä erilaisten välietappien ja laadunvarmistustoimenpiteiden avulla. (Brooks 1986, 4.)

10 Muunnettavuus. Ohjelmistoja on helppo muuttaa. Tämä aiheuttaa ohjelmistoihin kohdistuvia muutospaineita. On tavallista, että ohjelmistolle asetetut vaatimukset tarkentuvat tai niitä muutetaan jo kehitysaikana puhumattakaan ohjelmiston ylläpitoajasta. Myös kustannustekijät saattavat vaikuttaa muutostarpeisiin. (Brooks 1986, 4.) Ainutkertaisuus. Ohjelmistoprojektit ovat yleensä ainutkertaisia siinä mielessä, että toisin kuin esimerkiksi rakennuksia tai siltojen rakennettaessa, samantapaista ohjelmaa ei ehkä ole tehty koskaan aikaisemmin. Tämä on seurausta mm. alan nopeasta kehityksestä, joka tuo sekä uusia sovelluksia että uutta teknologiaa jatkuvasti ohjelmistotekniikan piiriin. (Haikala & Märijärvi 2004, 30.) Skaalautumattomuus. Aiemmin hyväksi havaitut menetelmät eivät välttämättä toimi projektin koon kasvaessa. Pienehkön ohjelman tapauksessa (esimerkiksi alle 10 000 riviä) jokainen projektiin osallistuvista omaa yleensä riittävän tarkan käsityksen koko käsillä olevasta ohjelmistosta, ja projekti saattaa hyvinkin onnistua erinomaisesti ilman dokumentaatiota, projektisuunnitelmaa ja kunnollista projektinohjausta. Ongelmien ilmaantuessa projekti saattaa olla pelastettavissa jopa yksittäisen henkilön sankarisuorituksella. Vaikeuksiin ajautunutta suurta projektia ei voi pelastaa millään yksittäisellä uroteolla, eikä edes henkilökunnan lisääminen auta, päinvastoin, ns. Brooksin laki ja kokemus ovat osoittaneet, että ihmisten lisääminen myöhässä olevaan ohjelmistoprojektiin useimmiten myöhästyttää sitä vielä entisestään. (Haikala & Märijärvi 2004, 30.) Epäjatkuvuus. Ohjelmistoihin perustuvien järjestelmien käyttäytyminen virhetilanteissa on usein epäjatkuvaa. Pieni vika perinteisellä teknologialla toteutetussa laitteessa ei tavallisesti lopeta kokonaan sen toimintaa. Ohjelmistolle taas on tyypillistä, että mikä tahansa vähäpätöiseltäkin vaikuttava vika voi sekunnin murtoosassa saattaa koko järjestelmän käyttökelvottomaksi. Epäjatkuvuudesta johtuen ohjelmien toimintaa ei voida varmistaa testaamalla, koska kaikkia erikoistilanteita ja niiden yhdistelmiä ei mitenkään voida käydä testauksessa läpi. (Haikala & Märijärvi 2004, 30-31.)

11 2.3 Ketterät menetelmät Ketterät ohjelmistokehityksen menetelmät tulivat yleisempään käyttöön 1990-luvulla. Perinteisen ohjelmistosuunnittelun ja tuotannon mallit ja menetelmät eivät kyenneet kunnolla vastaamaan nopeasti kasvavan kehitystyön tarpeisiin. (Abrahamsson, ym. 2003,1) Ketterien menetelmien keskeisiä ominaisuuksia ovat nopeus ja yksinkertaisuus. Perusideana on toteuttaa sovellukseen vain keskeisimmät (ja välittömästi tarvittavat) ominaisuudet. Tämän jälkeen ensimmäinen versio sovelluksesta julkaistaan ja kootaan palaute. Palautteen pohjalta sovellukseen tehdään pieniä muutoksia. Tarkoituksena on kehittää sovellusta pienin askelin eteenpäin lisäten uusia ominaisuuksia ja pyrkiä varsin tiiviissä tahdissa julkaisemaan uusia versioita sovelluksesta palautteen kokoamista varten. Tämän inkrementaalisen kehitystyön tavoitteena on pystyä reagoimaan nopeasti liike-elämän tarpeisiin ja teknologian muutoksiin. Keskeistä on siis itaratiivisuus, jolloin suunnittelu-, määrittely-, toteutus- ja testausvaiheet limittyvät suunnittelu- ja toteutusprosessissa. (Abrahamsson, ym. 2003,1) Ketterät menetelmät pitävät suoraa viestintää (mieluiten kasvokkain) tärkeämpänä kuin kirjoitettuja dokumentteja. Useimmat ketterät tiimit työskentelevät samassa työtilassa, ja tiimiin kuuluvat kaikki, joita tarvitaan ohjelmiston saamiseen valmiiksi. Tämä tarkoittaa vähintään ohjelmoijia ja heidän asiakkaitaan. (Asiakkaat määrittelevät tuotteen ja voivat olla tuotepäälliköitä, liiketoiminta-analyytikkoja tai varsinaisia käyttäjiä.) Tiimiin voi kuulua myös testaajia, käyttöliittymäsuunnittelijoita, teknisiä kirjoittajia ja päälliköitä. (Wikipedia, 2014) 2.3.1 Agile manifesti Vuonna 2001 seitsemäntoista merkittävää ketterän menetelmän puolestapuhujaa kokoontui Utahissa keskustelemaan menetelmiensä yhteisestä perustasta. Tarkoitus oli luoda yhteistä pohjaa ketterille menetelmille ja edistää näin ketterän ajattelun leviämistä. Tuon kokoontumisen tuloksena he julkaisivat julistuksen nimeltä Agile Manifesto (LIITE 1), jota pidetään ketterän kehityksen perusmääritelmänä.

12 Manifestissa määritellään ketterille menetelmille neljä ydinarvoa, joita menetelmät noudattavat. 2.3.1.1 Arvo 1 Arvostetaan yksilöitä ja vuorovaikutustaitoja enemmän kuin prosesseja ja työkaluja. Ihmiset tekevät yhdessä töitä valmistaakseen ohjelmia, ketterä-kehitys asettaa suuren arvon näille ammattilaisille, jotka muodostavat projektiryhmän. Lisäksi, että projekti onnistuisi, ryhmälle tulee valita oikeat prosessit ja työkalut, jotka sopivat heidän ympäristöönsä, teknologioihin ja projektin tavoitteisiin. Projektiryhmän projekti väärillä prosesseilla ja työkaluilla voi epäonnistua. (Schuh 2005,3.) 2.3.1.2 Arvo 2 Arvostetaan toimivaa ohjelmaa enemmän kuin perusteellista dokumentaatiota. Kehitettävän ohjelman on tarkoitus antaa käyttäjälleen työn suorittamiseen lisäarvoa. Ketterän-kehityksen mielestä ei ole hyötyä hyvin suunnitelluista yksityiskohtaisista vaatimuksista, arkkitehtuurista ym. suunnitteludokumenteista, jos niitä ei pystytä yhdistämään toimivaan järjestelmään. Toimivan järjestelmän tulisi olla projektin toiminnan päätarkoituksena. Lisäksi liiallinen dokumentointi projektin aikaisessa vaiheessa voi olla hukkaan heitettyä aikaa, jos sitä ei ylläpidetä myöhemmin. Jos dokumentoinnista ja sen ylläpitämisestä tulee toiminnan päätarkoitus, voi se aiheuttaa projektin myöhästymisen. (Schuh 2005, 3-4) 2.3.1.3 Arvo 3 Arvostetaan yhteistyötä asiakkaan kanssa enemmän kuin hankalia sopimusneuvotteluja. Ketterä-kehitys uskoo, että yhteistyö asiakkaan kanssa pitää projektin oikeilla raiteilla. Liian usein prosessit, työkalut ja dokumentaatio voivat aiheuttaa sen, että projektin päämäärä häviää projektintekijöiltä. Agile projektiryhmillä on käytäntöjä, jotka ohjaavat niitä olemaan avoimia asiakkaan tarpeille. Lisäksi Agile edistääkin

13 sopimussuhteita siten, että se rohkaisee työskentelemään asiakkaan kanssa ja asiakkaalle. (Schuh 2005, 4) 2.3.1.4 Arvo 4 Arvostetaan muutoksiin vastaamista enemmän kuin suunnitelmien orjallista seuraamista. Muutoksia tapahtuu jokaisessa tietojärjestelmäprojektissa ja jokaisen tulee muuntaa itsensä työskentelemään muutosten parissa, koska muuten toimitetaan ala-arvoista tuotetta asiakkaan näkökulmasta katsottuna. Ketterä-kehitys tuo tähän käytäntöjä jotka ohjaavat tiimit mukautumaan projektissa muuttuviin vaatimuksiin ja ympäristötekijöihin. Lisäksi Agile kannustaa siihen, että projektiryhmä voi tarvittaessa räätälöidä prosesseja, suunnitelmia, dokumentaatiota ja sopimuksia saavuttaakseen päämäärän. (Schuh 2005, 4)

14 2.3.2 Scrum-menetelmä Scrum on yksi ketteristä menetelmistä joka pohjautuu Agile Manifestoon. Terminä Scrum tulee urheilusta ja tarkemmin Rugbystä, molemmissa yhteyksissä Scrumilla tarkoitetaan itseohjautuvan joukkueen tai ryhmän sopeutumista erilaisiin ja muuttuviin tilanteisiin. Scrumin kehittäjinä pidetään Jeff Sutherlandia, Ken Schwaberia, John Scumniotalesia ja Jeff McKennaa. Scrumia on hyödynnetty monimutkaisten tuotteiden kehittämisessä 1990 luvun alusta lähtien eli jo ennen Agile Manifestoa. Scrum ei ole tuotekehitysprosessi tai - tekniikka, vaan paremminkin viitekehys, jonka sisällä voi käyttää useita erilaisia prosesseja ja tekniikoita. (Schwaber, Surherland 2013, 3) Scrum tekee tuotehallinnon ja kehityksen menetelmien vaikutukset näkyviksi, jotta menetelmiä voidaan parantaa. Scrum koostuu scrum-tiimeistä rooleineen, tapahtumista, tuotoksista ja säännöistä. Jokainen elementti palvelee tiettyä tarkoitusta ja on tärkeä osa Scrumin onnistumista. Scrumin säännöt sitovat yhteen roolit, tapahtumat ja tuotokset ja ohjaavat niiden välistä vuorovaikutusta. (Schwaber, Surherland 2013, 3) Scrumin kehittäjät Schwaber ja Beedle (2004) ovat todenneet Scrumin olevan kevytrakenteinen ketterä projektinhallintamenetelmä, perustuen pienikokoiseen, päätäntävaltaiseen ja itsestään organisoituvaan tiimiin. Scrum-projektissa pyritään jokaisen iteraation (sprintin) aikana saada luotua valmista toiminnallisuutta asiakkaalle. Tarkoituksena on tunnistaa nopeasti projektia hidastavat esteet, maksimoida yhteistyötä, parantaa kommunikointia, ohjailla prosessina kiinnostuksen ja tarpeen välistä kaaosta ja saada ihmiset tuntemaan hyvää mieltä omasta työstään. Scrum-tiimin saadessa itse päättää ja suunnitella miten toteuttaa haluttu toiminnallisuus on sitoutuminen tekemiseen hyvä ja onnistuminen todennäköistä. (Schwaber 2004, xii - xiii.) 2.3.2.1 Empiirinen prosessin hallinta

15 Perinteisesti ohjelmistoala on luonteeltaan täysin ennalta-arvaamaton ja monimutkainen rakenteeltaan. Ohjelmistosuunnittelijoiden osaaminen vaihtelee ja ohjelmistoala on jatkuvassa muutoksessa. Vaatimukset muuttuvat kesken projektin ja uusia tekniikoita tulee jatkuvasti käyttöönotettavaksi. (Leffingwell 2007, 45.) Täysin lineaarisessa ohjelmistokehityksessä teknologia, henkilöt ja vaatimukset kulkevat käsi kädessä. Jos tuotteen vaatimukset ovat projektin toteuttajalle hyvin selkeät ja heillä on täydellinen näkemys siitä, kuinka kehitystyö tapahtuu käytössä olevien teknologioiden kautta, on työssä vain vähän häiriöitä ja arvaamattomuutta. Tällöin työ etenee lineaarisesti ja virheiden ja uudelleen tekemisen määrä jää pieneksi. Kun puolestaan vaatimukset eivät ole projektin toteuttajalle selkeät ja käytetään uutta teknologiaa, lisääntyy häiriö projektissa. Paine julkaista uusia tuotteita käyttäen uutta teknologiaa on aiheuttanut sen, että varmuus ja luotettavuus on vaihdettu kilpailukyvyn hakemiseen. Tämä tekijä saa aikaiseksi sen, että kehitystiimit työskentelevät uusien teknologioiden kanssa, vaatimukset muuttuvat jatkuvasti ja aikataulut ovat tiukkia. (Schwaber & Beedle 2002, 91-93.) Scrum tukeutuu empiirisen prosessinhallintaan, jossa perusolettamuksena on, että kaikki tehtävät ovat aavistamattomia. Se käyttää iteratiivis-inkrementaalista (toistavaa-lisäävää) lähestymistapaa ennustettavuuden optimoimiseen, riskien kontrolloimiseen ja muutoksiin reagoimiseen. Kyky muuntautua tilanteen mukaan ja jatkuvasti arvioida tilanteita uudestaan korostuu empiirisessä prosessissa. Seuranta ja palaute auttavat tunnistamaan ongelmat. Tällöin projektiryhmä pystyy kykyjensä mukaan toimimaan tilanteen mukaisesti jokaisessa arvaamattomassa tilanteessa. Empiirisessä lähestymisessä tärkeintä on läpinäkyvyys, sopeutuminen ja tarkastelu. Läpinäkyvyys havainnollistaa ongelmat, tarkastelulla arvioidaan projektin tuloksia ja sopeuttaminen auttaa muutosten hyväksymiseen läpinäkyvyyden ja tarkastelun kautta. (Leffinwell 2007, 45.)

16 2.3.2.2 Scrumin arvot Scrum sisältää viisi perusarvoa, joihin sen toiminnot perustuvat. Perusarvot ovat sitoutuminen, keskittyminen, avoimuus, kunnioitus ja rohkeus. Nämä perusarvot saavat voimansa Scrum-projektin jäsenistä. Uudet teknologiat ja monimutkaiset vaatimukset saavat tiimit ajautumaan hankaliin tilanteisiin, joista niiden on noustava itse, ilman ulkopuolisen apua. Päämäärän saavuttaminen on kompromissien ja umpikujien takana, joten tiimin on oltava päämäärätietoinen ja sitoutunut velvoitteisiinsa. (Schwaber & Beedle 2002, 147.) 2.3.2.2.1 Sitoutuminen Tiimin tehtävä on sitoutua yhteiseen päämäärään. Tiimi on oikeutettu saamaan kaiken tuen, jotta he voivat saavuttaa sitoumuksensa. Perinteisissä menetelmissä tiimille usein vain annetaan ulkoa käsin työtehtäviä ja pahimmillaan vielä määrätään, miten työ on tehtävä. Scrumissa tiimi itse sitoutuu toimittamaan seuraavan sprintin aikana määrätyt toiminnallisuudet. Samalla tiimi saa sprintin aikana vapauden toimia parhaaksi katsomallaan tavalla. Scrum-mestari ja ympäröivä organisaatio on omalta osaltaan sitoutuvat tukemaan tiimiä poistamalla heitä häiritseviä tekijöitä. Jotta tiimi voi sitoutua johonkin tavoitteeseen, on tämän tavoitteen oltava niin selkeä, että sprintin jälkeen voidaan todeta, onko tiimi onnistunut vai ei. (Schwaber & Beedle 2002, 148.) 2.3.2.2.2 Keskittyminen Tee työsi hyvin. Keskity vain siihen, minkä olet luvannut tehdä äläkä huolehdi muusta. Jokaiselle sprintille asetetaan selkeä tavoite. Tämän tavoitteen saavuttaminen on tiimin tärkein tehtävä. Kaikki muut oheisaktiviteetit ovat toissijaisia. (Schwaber & Beedle 2002, 149-150.) 2.3.2.2.3 Avoimuus On tärkeää, että kaikki projektiin liittyvät tiedot ovat näkyviä kaikille. Scrumissa kaikki on avointa: projektin ja sprintin työlistat ovat julkisia, ja myös päiväpalaveri on

17 avoinna kaikille kiinnostuneille (joskin vain tiimiin kuuluvat saavat puhua). Myös jokaisen sprintin tulokset esitellään julkisesti. (Schwaber & Beedle 2002, 151.) 2.3.2.2.4 Kunnioitus Ihmisiä käsitellään yksilöinä heidän taustojensa ja kokemusten mukaan. On tärkeää kunnioittaa kutakin tiimin jäsentä juuri sellaisena kuin hän on. Tiimin itseorganisoituvuutta ja työrauhaa on myös kunnioitettava. Jokaisen tiimiläisen on kunnioitettava muita tekemällä jatkuvasti parhaansa, ja odotettava samaa myös muilta. (Schwaber & Beedle 2002, 152.) 2.3.2.2.5 Rohkeus Ole rohkea sitoutumaan, toimimaan, olemaan avoin ja odota muilta kunnioitusta. Keskittyneesti ja avoimesti toimiminen voi joissain tilanteissa vaatia rohkeutta. Esimerkiksi omat virheet on myönnettävä heti ja äänekkäästi, jotta niistä voidaan oppia. Usein tiimi itse tietää, miten joku ongelma kannattaa ratkaista, mutta joku ulkopuolinen taho on eri mieltä. Tällöin vaatii suurta rohkeutta toimia, mahdollisesti jopa vastoin yrityksen virallista toimintatapaa. Tätä ei kuitenkaan pidä sotkea vastuuttomuuteen. (Schwaber & Beedle 2002, 153.)

18 2.3.2.3 Scrumin roolit Vesiputousmallin mukaisissa projekteissa on yleensä ainakin määrittelijä, suunnittelija, ohjelmoija, testaaja ja projektipäällikkö. Projektipäällikköä lukuun ottamatta kussakin roolissa voi olla useampia henkilöitä ja toisaalta yksi henkilö voi joissain tapauksissa kuulua useampaankin rooliin. Scrum-projektissa esiintyy vain kolme eri roolia: Tuotteen omistaja, Scrum-mestari ja tiimi. 2.3.2.3.1 Tuotteen omistaja Tuotteen omistaja on henkilö, joka viime kädessä vastaa tuotteen ominaisuuksista, siis "omistaa" tuotteen. Tuotekehitysprojekteissa omistaja on tyypillisesti tuotepäällikkö, asiakasprojekteissa se voi olla asiakkaan edustaja tai toimittajan tekninen projektipäällikkö. Tuotteen omistajan tehtävänä on tehdä kaikki päätökset tuotteen ominaisuuksista ja toiminnallisuuksiin vaikuttavista seikoista. (Sininen meteoriitti, 2011) 2.3.2.3.2 Scrum-mestari Scrum-mestarin tehtävänä on huolehtia siitä, että tiimi voi tehdä työtään optimaalisella tavalla. Tiimiläiset raportoivat päivittäin ongelmista, jotka hidastavat töiden etenemistä ja mestarin tehtävänä on ratkoa nämä ongelmat. Tämän lisäksi hän johtaa päivittäiset aamupalaverit ja vastaa siitä, että Scrumia noudatetaan oikein. (Sininen meteoriitti, 2011) 2.3.2.3.3 Kehitystiimi Tiimiin kuuluvat kaikki henkilöt, jotka projektia ovat tekemässä. Tiimin sisältä ei erikseen nimitetä arkkitehteja, ohjelmoijia, testaajia tai käyttöliittymäsuunnittelijoita, vaan tiimiin kasataan henkilöitä, joilla on tarvittava osaaminen. Sitten tiimi yhdessä rakentaa tuotteen. Tällä halutaan korostaa kunkin tiimiläisen olevan projektin kannalta yhtä tärkeä ja että tiimi yhdessä vastaa tuotteen kaikista puolista, ei koskaan yksittäinen henkilö. Tiimin sisällä kaikki tekevät kaikkensa projektin edistämiseksi. Käytännössä eri ihmiset osaavat luonnollisesti eri asioita, ja on järkevää, että kukin tekee sitä, minkä osaa parhaiten. Olennaista kuitenkin on, että tiimi vastaa itse

19 yhteisöllisesti tehtävien jaosta, jolloin työtehtäviä ei ajauduta pompottelemaan henkilöltä toiselle tyyliin Tämä ei kuulu minulle, tuo on koodarin homma tai dokumentoija paikalle, koodini on valmis. (Sininen meteoriitti, 2011) 2.3.2.4 Scrum-prosessi Scrumin prosessimalli (Kuvio 2.) koostuu viikosta kahteen kuukauteen kestävistä sykleistä eli sprinteistä ja siihen liittyvistä aikajaksotetuista ominaisuuksista. Kuviosta 2 vasemmalta oikealle päin prosessi alkaa visiosta, jonka pohjalta tehdään ensimmäinen versio tuotteen työlistasta (Product Backlog). Ennen jokaista sprintin alkua pidetään sprintin suunnittelukokous, jossa käydään lävitse tuotteen työlista ja valitaan sieltä sprintin työlistaan (Sprint Backlog) toteutettavat työt. Käytännöntyöt toteutetaan sprintin aikana sprintin työlistaa noudattaen, päivittäin järjestetään 15 minuutin pituinen päiväpalaveri. Sprintin lopussa järjestetään sprintin katselmointi, missä käydään lävitse sprintin saavutukset ja lisäksi järjestetään sprintin retrospektiivi missä tunnistetaan ja priorisoidaan tärkeimmät asiat, jotka menivät hyvin, sekä asiat, joita muuttamalla työ sujuisi jatkossa vieläkin paremmin. Seuraava sprintti alkaa välittömästi edellisen loputtua.(schwaber, 2004, 7-9.) KUVIO 2. Scrum prosessikaavio. 2.3.2.4.1 Visiointi Ennen projektin aloittamista luodaan korkean tason visio siitä, mitä projektilta halutaan. Visio vastaa kysymyksiin miksi projekti tehdään ja mitä projektin lopputuotteena saadaan. (Sininen meteoriitti, 2011)

20 2.3.2.4.2 Tuotteen työlistan muodostaminen Vision jälkeen muodostetaan alustava tuotteen työlista, lista tuotteeseen tarvittavista ominaisuuksista. Ennen toteutuksen aloittamista tuotteen omistajan on priorisoitava ominaisuuslista. (Sininen meteoriitti, 2011) 2.3.2.4.3 Sprintin suunnittelu Sprintin suunnittelukokous on yhden päivän mittainen työpaja, minkä ensimmäisellä puoliskolla valitaan tuotteen työlistasta seuraavan sprintin vaatimukset ja toinen puoli käytetään seuraavan sprintin valmisteluun. Kokoukseen osallistuvat Scrum-mestari, tuotteen omistaja ja tiimi. Ulkopuolisia asiantuntijoita voidaan pyytää konsultoimaan joissain erityistietämystä vaativissa toimenpiteissä. Ulkopuolisia kuunteluoppilaita kokoukseen ei päästetä. Tuotteen omistajan on priorisoitava tuotteen työlista ennen kokousta. Mikäli tuotteen työlista tai tuotteen omistajaa ei ole saatavilla kokoukseen, Scrum-mestarin on edustettava tuotteen omistajaa. Tiimi päättää kuinka suuri osa tuotteen työlistasta voidaan valita seuraavaan sprinttiin. Tuotteen työlistan analysointiin ei voida käyttää enemmän aikaa kuin kokouksen ensimmäinen on puolisko. Mikäli jotkut kohdat vaativat selvitystä, se on tehtävä sprintin aikana. Suunnittelukokousta ei voida jakaa useammalle päivälle, eikä puoliskojen välissä pidetä mitään erityistä taukoa. Työpajan jälkipuoliskolla tuotteen omistajan on henkilökohtaisesti oltava paikalla vastaamassa tiimin kysymyksiin. Tiimi vastaa itsenäisesti siitä, miten sprintin työlistaksi valitut vaatimukset muutetaan julkaistavissa olevaksi tuotteen osaksi.

21 Työpajan lopputuotteena on seuraavan sprintin työlista. Työlistan ei tarvitse olla lopullinen, mutta sen on oltava riittävän hyvä, jotta sprintin toteuttaminen voidaan aloittaa. (Sininen meteoriitti, 2011) 2.3.2.4.4 Sprintti Sprintin pituus on rajattu yhdestä viikosta kahteen kuukauteen. Tämä on sellainen aika, jossa tiimin on ehdittävä toteuttaa jotain merkittävää, mikä on julkaistavissa olevaa laatua. Tätä pidemmät työrupeamat alkavat jo vaatia tarkempaa suunnittelua ja dokumentaatiota työn tueksi. Myöskään tuotteen omistaja ja muut sidosryhmät eivät usein halua odottaa tätä kauempaa ilman että näkevät todellista edistymistä projektissa. Tiimi voi etsiä ulkopuolista apua sprintin aikana. Kukaan ei saa tyrkyttää tukeaan tiimille, eikä kommentoida tiimin tekemisiä sprintin aikana. Tiimi on täysin itseohjautuva. Tiimi sitoutuu tuotteen työlistaan sprintin suunnittelukokouksessa. Sprintin aikana tuotteen työlistan muuttaminen on kiellettyä. Jos ilmenee että sprintti ei ole toteuttamiskelpoinen, Scrum-mestari voi keskeyttää sen koska tahansa ja aloittaa uuden sprintin suunnittelukokouksen. Scrum-mestari voi tehdä tämän omasta aloitteestaan tai jos tiimi tai tuotteen omistaja pyytää sitä. Tyypillisiä syitä sprintin keskeyttämiselle on valitun teknologian osoittautuminen käyttökelvottomaksi, odottamattomat muutokset liiketoimintaympäristössä tai mikäli joku ulkopuolinen tekijä on häirinnyt tiimiä. Jos tiimi toteaa, ettei kykene suoriutumaan sprintistä, se voi neuvotella tuotteen omistajan kanssa, mitkä ominaisuudet voidaan siirtää seuraaviin sprintteihin. Jos liian suuri osa sprintistä näyttää jäävän valmistumatta, Scrum-mestari voi keskeyttää sprintin edellä kuvatusti. Jos tiimi toteaa että se ehtisi toteuttamaan enemmän kuin mihin oli sitoutunut, se voi neuvotella tuotteen omistajan kanssa mitä ominaisuuksia sprinttiin voidaan lisätä. Tiimiläisillä on kaksi hallinnollista velvollisuutta sprintin aikana: heidän on osallistuttava päiväpalaveriin ja pidettävä sprintin työlista ajan tasalla. Sprintin

22 työlistan on oltava julkisesti nähtävillä ja arviot jäljellä olevasta työmäärästä on päivitettävä päivittäin. (Sininen meteoriitti, 2011) 2.3.2.4.5 Päiväpalaveri (Daily Scrum) Joka päivä tiimi kokoontuu yhteen lyhyeen tilannepalaveriin, jossa kukin tiimin jäsen vastaa kolmeen kysymykseen: 1. Mitä teit edellisen päivän aikana? 2. Mitä aiot tehdä seuraavan päivän aikana? 3. Mitkä tekijät estävät (tai hidastavat) sinua saavuttamasta sprintin tavoitteita? Palaveriin osallistuvat ainakin kaikki tiimin jäsenet ja scrum-mestari. Palaveri on myös avoin kaikille muille, jotka ovat jollain tavalla projektista kiinnostuneita. Vain tiimiläiset saavat kuitenkin puhua. Tapahtuman tarkoitus on nimenomaisesti tarjota kaikille tieto siitä, missä projekti menee ja mitä ongelmia sillä on. Jos jostain asiasta pitää keskustella tarkemmin, sitä varten pidetään oma palaverinsa, jossa ovat läsnä vain ne henkilöt, joita asia koskettaa. Päiväpalaverin suositeltava kesto on 15 minuuttia ja usein palaverin venähtämisen ehkäisemiseksi se pidetään seisten. (Sininen meteoriitti, 2011) 2.3.2.4.6 Sprintin katselmointi Jokaisen sprintin lopuksi tiimi esittelee valmista tuotetta tuotteen omistajalle. Sprintin lopuksi tuotteen siis pitäisi olla periaatteessa käyttöönotettavissa: se on toteutettu, testattu, dokumentoitu, käyttöliittymä on valmis ja niin edelleen. Näin omistaja voi päättää joko seuraavan sprintin tekemistä tai tuotteen käyttöönottamisesta. Tähän tapahtumaan saa osallistua kuka tahansa, joka on projektista kiinnostunut. (Sininen meteoriitti, 2011) 2.3.2.4.7 Sprintin jälkitarkastelu (Retrospektiivi) Kunkin sprintin lopuksi tiimi, Scrum-mestari ja omistaja tarkastelevat päättynyttä sprinttiä. Kukin tiimin jäsen kertoo omasta näkökulmastaan, mikä sprintissä meni

23 hyvin ja mitä voisi parantaa. Lopuksi tiimi yhdessä priorisoi kehityskohteet ja pyrkii toteuttamaan muutokset seuraavan sprintin aikana. Sprintin jälkitarkastelun jälkeen kierros alkaa alusta uuden sprintin suunnittelulla. Tässä vaiheessa omistaja voi jälleen vapaasti muuttaa tuotteen työlistaa, ja tiimi arvioi taas uudelleen, minkä ominaisuuksien toteuttamiseen se voi sitoutua. (Sininen meteoriitti, 2011) 2.3.2.5 Scrumin dokumentit Scrumin dokumentaatio pitää sisällään neljä dokumenttia, jotka ovat tuotteen työlista (Product Backlog), sprintin työlista (Sprint Backlog), julkaisun edistymiskäyrä (Relese Burndown) ja sprintin edistymiskäyrä (Sprint Burndown). 2.3.2.5.1 Tuotteen työlista Tuotteen työlistassa listataan kaikki vaatimukset tuotteelle, jota kehitystiimit(t) kehittävät. Tuoteomistaja vastaa tuotteen työlistasta, sen sisällöstä, saatavuudesta ja priorisoinnista. Tuotteen työlista ei ole koskaan valmis ja sen ensiversio sisältää ainoastaan tunnetut ja parhaiten ymmärretyt vaatimukset. Tuotteen työlista kehittyy yhdessä itse tuotteen ja sen käyttöympäristön kanssa. Tuotteen työlista on dynaaminen ja se muuttuu jatkuvasti sisältämään vaatimukset, jotka tuote tarvitsee ollakseen tarkoituksenmukainen, kilpailukykyinen ja hyödyllinen. Tuotteen työlista on olemassa yhtä kauan kuin tuote. (Schwaber, Surherland 2013, 12) Tuotteen työlista sisältää kaiken tarpeellisen menestyvän tuotteen kehittämiseksi ja julkaisemiseksi. Tuotteen työlista on lista kaikista ominaisuuksista, toiminnoista, teknologioista, parannuksista ja korjattavista virheistä, jotka tullaan toteuttamaan tuleviin tuotejulkaisuihin. Jokaisella työlistan kohdalla on kuvaus, prioriteetti ja aikaarvio. Prioriteetti määritellään riskin, lisäarvon ja tarpeellisuuden perusteella. Tuotteen työlista järjestetään sen kohtien prioriteettien mukaan. Korkeimman prioriteetin kohdat ohjaavat seuraavaksi aloitettavaa kehitystä. Korkeampi prioriteetti tarkoittaa, että työlistan kohta on kiireellisempi, sitä on ehditty suunnitella enemmän ja sen arvosta vallitsee suurempi yksimielisyys. Korkeamman prioriteetin kohdat ovat selkeämpiä ja sisältävät tarkempaa tietoa kuin matalamman prioriteetin kohdat. Korkeamman prioriteetin kohtien suurempi selkeys kasvattaa myös aika-arvioiden

tarkkuutta. Mitä matalampi prioriteetti, sitä vähemmän työlistan kohdasta tiedetään ja sitä vaikeampaa kohtaa on ymmärtää. (Schwaber, Surherland 2013, 12) 24 2.3.2.4.2 Julkaisun edistymiskäyrä Julkaisun edistymiskäyrä on diagrammi, joka esittää tuotteen työlistassa jäljellä olevan työmäärän suhteessa aikaan. Arvioitu työmäärä on missä tahansa yksikössä, jonka scrumtiimi ja organisaatio on valinnut. Tuotteen työlistan vaatimuksille annetaan alustavat aika-arviot julkaisun suunnittelun yhteydessä sekä sitä mukaa, kun uusia vaatimuksia lisätään tuotteen työlistaan. Aika-arviot tarkentuvat tuotteen työlistan säännöllisissä tarkasteluissa. Aika-arvioita voi muuttaa milloin tahansa muulloinkin. Aika-arvioiden antamisesta vastaa kehitystiimi. Tuoteomistaja voi vaikuttaa kehitystiimiin auttamalla sitä ymmärtämään ja valitsemaan kompromisseja, mutta lopullisen aika-arvion antaa aina kehitystiimi. Tuoteomistaja pitää ajantasaisen julkaisun edistymiskäyrän jatkuvasti näkyvillä. Jäljellä olevan työmäärän muutoksista voidaan myös piirtää trendiviiva. (Schwaber, Surherland 2013, 13) 2.3.2.4.3 Sprintin työlista Sprintin työlista koostuu tehtävistä, jotka kehitystiimin tulee toteuttaa muuttaakseen tuotteen työlistasta valitut kohdat julkaisukelpoiseksi tuoteparannukseksi. Tehtävät määritellään useimmiten sprintin suunnittelukokouksessa. Ne kuvaavat työtä, jonka kehitystiimi tunnistaa tarpeelliseksi sprintin tavoitteeseen pääsemiseksi. Sprintin työlistaan valitut kohdat tulee hajottaa niin pieniksi, että sprintin edistyminen voidaan havaita päiväpalavereissa. Sprintin työlistan kohdan tyypillinen koko on yksi miestyöpäivä tai vähemmän. (Schwaber, Surherland 2013, 14) Kehitystiimi ylläpitää ja päivittää sprintin työlistaa koko sprintin ajan. Aloittaessaan sprintin toteutustyön kehitystiimi voi havaita, että tarvitaankin vähemmän tai enemmän tehtäviä kuin suunniteltiin, tai että jokin tehtävä tulee viemään enemmän tai vähemmän aikaa kuin arvioitiin. Kehitystiimi lisää tarvittavat uudet tehtävät sprintin työlistaan. Kun tehtäviä työstetään tai ne valmistuvat, kunkin tehtävän arvioitu jäljellä oleva työmäärä päivitetään. Mikäli tehtävä havaitaan tarpeettomaksi, se poistetaan. Ainoastaan kehitystiimi voi muuttaa sprintin työlistaa, sen sisältöä tai aika-arvioita

25 sprintin aikana. Sprintin työlista on selkeästi näkyvä, reaaliaikainen kuva työstä, jonka kehitystiimi suunnittelee saavansa valmiiksi sprintin aikana. Tämän vuoksi sprintin työlista on täysin kehitystiimin omistuksessa ja hallinnassa. (Schwaber, Surherland 2013, 14) 2.3.2.4.4 Sprintin edistymiskäyrä Sprintin edistymiskäyrä on diagrammi, joka esittää sprintin työlistassa jäljellä olevan työmäärän suhteessa aikaan. Sprintin edistymiskäyrä piirretään laskemalla yhteen kaikki sprintin työlistassa olevat aika-arviot ja päivittämällä tätä lukua kerran päivässä. Luku kuvaa sprintin koko jäljellä olevaa työmäärää päivän tarkkuudella. Piirtämällä viiva sprintin kokonaistyömäärää päivän tarkkuudella kuvaavien pisteiden läpi kehitystiimi näkee konkreettisesti etenemisensä kohti sprintin tehtävien valmistumista. Tehtäviin käytetyn työajan pituudella ei ole Scrumissa merkitystä. Ainoastaan jäljellä oleva työmäärä ja päivämäärä ovat kiinnostavia muuttujia. (Schwaber, Surherland 2013, 14) 2.3.3 Muut ketterät menetelmät Ketteriä menetelmiä on olemassa kymmenkunta ja jokaisella on omat kannattajansa. Kaikilla menetelmillä on yhteinen perusmääritelmä, joka pohjautuu yhdessä sovittuun Agile Manifestoon. Seuraavassa on kerrottu lyhyesti muutamasta muusta ketterästä menetelmästä. 2.3.3.1 XP (extreme Programming) Extreme Programming on nimensä mukaisesti hyvin ohjelmointikeskeinen menetelmä. Ensimmäinen XP-projekti suoritettiin maaliskuussa 1996. Siitä lähtien menetelmää on käytetty menestyksekkäästi ympäri maailmaa useissa erikokoisissa projekteissa eri teollisuusaloilla. (Asteins, Granville, Novak 2002, 1) XP:n vahvuus on sen asiakastyytyväisyyden korostaminen. Lisäksi menetelmä antaa ohjelmistokehittäjille mahdollisuuden reagoida nopeasti asiakkaan muuttuville vaatimuksille. Menetelmä korostaa tiimityöskentelyä. Johtajat, asiakkaat ja ohjelmistokehittäjät ovat kaikki tasa-arvoisia jäseniä yhteisessä tiimissä. Tiimit ovat itseorganisoituvia. XP:ssä toteutetaan yksinkertaista, mutta tehokasta työskentely-

ympäristöä, jonka avulla tiimit pystyvät työskentelemään erittäin tuotteliaasti. (Asteins & ym. 2002, 4-8) 26 XP tuo ohjelmistoprojekteihin viisi keskeistä ominaisuutta: viestintä, yksinkertaisuus, palaute, kunnioitus ja rohkeus. Ohjelmistokehittäjät ovat jatkuvasti yhteydenpidossa sekä asiakkaiden että kollegoiden kanssa, tämä parantaa viestinnän toimivuutta. Ohjelmakoodin rakenne pidetään yksinkertaisena ja selkeänä. Ohjelmoijat saavat hyödyllistä palautetta ohjelmastaan testaamalla ohjelmistoaan ensimmäisestä päivästä lähtien. Lisäksi asiakkaalle toimitetaan ohjelmisto niin aikaisessa vaiheessa, kuin on mahdollista ja saadun palautteen pohjalta tehdään ehdotetut muutokset. Jokaisen onnistuneen iteraation jälkeen kehittäjien kunnioitus omaan ja tiimin muiden jäsenten tekemiseen lisääntyy. Tältä pohjalta tiimin jäsenet pystyvät rohkeasti reagoimaan muuttuviin vaatimuksiin ja teknologiaan. (Asteins & ym. 2002, 4-8) Extreme Programming-menetelmään sisältyy myös useita yksinkertaisia sääntöjä. Yksittäiset säännöt saattavat kuulostaa hankalilta ja jopa naiiveilta, mutta yhdessä säännöt muodostavat selkeät arvot ja periaatteet XP:lle. Säännöt on rakennettu tasapainottamaan toisiaan, joten on tärkeää, että sääntöjä noudatetaan yhdessä. Alla listattuna 14 sääntöä, mihin XP perustuu: 1. Asiakkaan edustaja työskentelee suoraan projektitiimin kanssa. 2. Käytä metaforia vaikeiden kokonaisuuksien kuvailemiseen. 3. Suunnittelu 4. Lyhyet palaverit 5. Testit ennen koodia 6. Yksinkertaisin mahdollinen rakenne ohjelmakoodiin 7. Pariohjelmointi 8. Kaikilla käytössä yhteiset ohjelmointistandardit 9. Ohjelmakoodin jaettu omistajuus 10. Intergroikaa jatkuvasti 11. Refaktoroikaa 12. Julkaisut pienissä inkrementeissä 13. Varokaa loppuun palamista 14. Hyväksykää muutokset (Asteins & ym. 2002, 4-15)

27

28 2.3.3.2 Adaptive Software Development (ASD) Adaptive Software Development (ASD) on suunnattu selkeästi projektin hallinnan kehittämiseen. Menetelmä ei ota kantaa ohjelmistokehitystekniikoihin, vaan niiden osalta kehitystiimille jätetään vapaat kädet.(highsmith 2000, 70) ASD:ssä, kuten muissakin agile-menetelmissä muutosta ohjelmistoprojektissa pidetään luonnollisena. ASD:ssä poikkeamat kesken projektin mielletään oikeaan suuntaan ohjaaviksi, positiivisiksi asioiksi. Perusajatuksena on, että alun perin suunniteltu järjestelmä ei ole projektin lopussa se, mitä toimeksiantaja lopulta haluaa. (Highsmith 2000, 43) ASD:n prosessi muistuttaa tavoitteiltaan ja sisällöltään perinteistä vesiputousmallia. Erona vesiputousmalliin on kuitenkin se, että vaiheet voivat olla osittain samanaikaisia ja aikaisempiin vaiheisiin palaaminen on otettu huomioon. Lisäksi toteutusvaihe suoritetaan agile-menetelmille tutuissa iteraatioissa. ASD:n prosessi koostuu kuvion 3 mukaisesti kolmesta päävaiheesta: spekulointi (speculate), yhteistyö (collaborate) ja oppiminen (learn). Jokainen päävaihe sisältää tarkempia alivaiheita. (Highsmith 2000, 41,84) KUVIO 3. ADS-menetelmän prosessi.

29 2.3.3.3 Crystal metodit Alistar Cockburn julkaisi Crystal-metodit vuonna 1997 ja ne olivat mukana, kun sovittiin ketteristä-menetelmistä Agile Manifestissä vuonna 2001. Crystal-metodit ovat joukko projektinhallinnan käytäntöjä, joita voi soveltaa erilaisiin ja erikokoisiin ohjelmistoprojekteihin. Menetelmien lähtökohta on tarjota ihmislähtöisiä projektinhallinta malleja ohjelmistoprojektin suunnittelemiseksi. Crystal ei tarjoa valmista prosessia, vaan ainoastaan joukon ohjeita ja sääntöjä, joiden perusteella jokainen projektiryhmä voi räätälöidä omiin tarkoituksiinsa sopivan prosessin. (Cockburn 2007, 335-337) Kaikki Crystal-metodit noudattavat näitä Cockburnin määrittelemiä sääntöjä sekä prosessinsuunnitteluperiaatteita. Säännöissä mainitaan mm. että ohjelmistokehityksen on oltava inkrementaalista ja että prosessinarviointipalavereja on pidettävä ainakin jokaisen inkrementin lopussa ja alussa. (Cockburn 2007, 339) Cockburin seitsemän prosessinsuunnitteluperiaatetta on: 1. Mitä suuremmaksi tiimin koko kasvaa, sitä raskaampi ja kontrolloidumpi prosessin tulee olla. 2. Kriittisemmät projektit vaativat tiukemman ja tarkemmin määritellyn prosessin. 3. Kommunikointi kasvotusten on tehokkain kommunikointi tapa. 4. Ylimääräiset vaiheet ja vaihetuotteet tulevat kalliiksi. 5. Palautteen ja kommunikoinnin lisääminen vähentää vaihetuotteiden tarvetta. 6. Omaksutut työskentelytavat, taidot ja ymmärtäminen mieluummin, kuin prosessit, kaavamaisuus ja dokumentit. 7. Tehokkuudesta voi tinkiä toimissa, jotka eivät voi muodostua pullonkaulaksi. (Cockburn 2007, 182) Crystal-menetelmät ovat kategorioitu suoritettavan projektin laajuuden ja kriittisyyden mukaan (kuvio 4). Jos projektiin osallistuvia henkilöitä on kuusi tai alle, valitaan Crystal Clear. Henkilömäärän ollessa 7-20 on suositeltavaa valita Crystal Yellow. Kaikista suurimmissa projekteissa, 41 80 henkilöä on paras valinta Crystal Red. Mitä

30 suuremmaksi tiimin koko kasvaa, sitä raskaampi ja kontrolloidumpi prosessin tulee olla. (Cockburn 2007, 186) Kriittisyydet ovat myös jaettu neljään kategoriaan viasta koituvien mahdollisten seurausten mukaan. Lievin kategoria on mukavuuden menettäminen (C = Comfort). Seuraavat kategoriat ovat taloudellinen tappio (D = Discretionary money) ja merkittävä taloudellinen tappio (E = Essential money). Äärimmäisen kriittisyyden kategoria on vika, jonka seurauksena voi olla kuolema (L = Life). Kriittisemmät projektit vaativat tiukemman ja tarkemmin määritellyn prosessin. (Cockburn 2007, 338) KUVIO 4. Crystal metodin kategoriat.