Ketterät prosessit kansainvälisessä ohjelmistotuotannossa

Transkriptio

1 hyväksymispäivä arvosana arvostelija Ketterät prosessit kansainvälisessä ohjelmistotuotannossa Rauli Poikela Helsinki HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

2 HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta/Osasto Fakultet/Sektion Faculty/Section Laitos Institution Department Matemaattis-luonnontieteellinen tiedekunta Tekijä Författare Author Tietojenkäsittelytieteen laitos Rauli Poikela Työn nimi Arbetets titel Title Ketterät prosessit kansainvälisessä ohjelmistotuotannossa Oppiaine Läroämne Subject Tietojenkäsittelytiede Työn laji Arbetets art Level Aika Datum Month and year Tiivistelmä Referat Abstract Sivumäärä Sidoantal Number of pages 10 sivua + 1 liitesivu Tämä kirjoitus on tarkoitettu Helsingin Yliopiston Tietojenkäsittelytieteen laitoksen alempien opinnäytteiden ja harjoitusten ulkoasun ja rakenteen ohjeeksi. Ohje soveltuu siten tieteellisen kirjoittamisen kurssille, ohjelmistotuotantoprojekteihin, seminaaritöihin ja pro gradu -tutkielmiin. ACM Computing Classification System (CCS): A.1 [Introductory and Survey], I.7.m [Document and text processing] Avainsanat Nyckelord Keywords Ketterät prosessit, kansainvälinen ohjelmistotuotanto, Scrum Säilytyspaikka Förvaringställe Where deposited

3 ii Muita tietoja Övriga uppgifter Additional information Sisältö 1 Johdanto 1 2 Ketterät prosessit ohjelmistokehityksessä Ketterien prosessien synty Ketterän ohjelmistokehityksen menetelmät Scrum-prosessimalli Kansainvälinen ohjelmistokehitys Kansainvälisen ohjelmistokehityksen ominaispiirteet Hajautetulle ohjelmistokehitykselle ominaiset haasteet Kansainväliselle ohjelmistokehitykselle ominaiset haasteet Ketterät prosessit kansainvälisessä ohjelmistokehityksessä Hajautetun Scrumin strategiat Integroitu Scrum pienessä kansainvälisessä projektissa Sisäkkäiset Scrumit laajassa kansainvälisessä projektissa Integroitu Scrum laajassa kansainvälisessä projektissa Yhteenveto 9 Lähteet 10 Lähteet (tulevaan käyttöön) 11

4

5 1 1 Johdanto Kansainvälinen ohjelmistokehitys on teknologian kehityksen myötä mahdollistunut myös pienempien ohjelmistoyritysten keskuudessa. Edulliset tietoliikenneyhteydet ja kommunikaatioteknologiat kuten VoiP-ratkaisut ja pikaviestimet ovat tehneet fyysisesti hajautetun projektiryhmän yhteydenpidosta nopeaa ja helppoa. Kynnys kansainvälistymiseen on laskenut ja pienikin ohjelmistoyritys voi hankkia osaamista sieltä, missä sitä on. Samaan aikaan ketterät prosessit ovat vallanneet alaa ohjelmistokehityksessä. Iteratiiviset prosessimallit, esimerkiksi Scrum, ovat yleisesti käytössä ohjelmistoyrityksissä perinteisten mallien rinnalla. Miten nämä mallit sopivat kansainväliseen ohjelmistokehitykseen? Ketteristä prosesseista ja kansainvälisestä ohjelmistokehityksestä on olemassa runsaasti tutkimustietoa ja kirjallisuutta. Sen sijaan ketterien prosessien soveltumista kansainväliseen ohjelmistokehitykseen on tutkittu vähemmän. Ketterien prosessien perusominaisuudet tekevät niiden soveltamisesta haastellisia kansainväliseen kehitystyöhön. Ketterille prosesseille tyypillisiä menetelmiä ovat XP:n pariohjelmointi, Scrumin jokapäiväiset 'seisten vietetyt' ryhmäkokoukset ja asiakas, joka on lähellä antamassa välitöntä palautetta. Tällaiset menetelmät soveltuvat hyvin kasvokkain tehtäviksi ja suosivat välitöntä, nopeaa ja epävirallista kommunikaatiotapaa. Ketterät prosessimallit ovatkin haasteellisia kansainvälisissä ohjelmistoprojekteissa, joissa kasvokkain tapaaminen on harvinaista ja kommunikaatiota vaikeuttavat tyypillisesti myös aika- ja kulttuurierot. 2 Ketterät prosessit ohjelmistokehityksessä Koska ketterät menetelmät ja Scrum-prosessimalli on jo käsitelty varsin kattavasti tämän seminaarin aiemmissa esityksissä, en lavenna näitä kappaleita toistaiseksi.

6 2 2.1 Ketterien prosessien synty 2.2 Ketterän ohjelmistokehityksen menetelmät 2.3 Scrum-prosessimalli 3 Kansainvälinen ohjelmistokehitys Kansainvälisellä ohjelmistotuotannolla tarkoitetaan valtioiden rajat ylittävää ohjelmistokehitystä. Kansainvälisessä ohjelmistokehityksessä voi olla kyseessä perinteinen ohjelmistojen ja ohjelmistokomponenttien alihankinta taloudellisista syistä alhaisemman kustannustason maista. Tällöin toimittava taho on usein erillinen organisaatio, joka toimittaa ohjelmiston määritysten mukaisesti. Kyseessä voi olla myös ohjelmistoprojekti, jonka henkilöstö on hajautettu eri maihin, mutta joka työskentelee yhtenä projektiorganisaationa, muodostaen globaalin virtuaalisen tiimin. Tässä tutkielmassa keskityn pääasiassa projekteihin joiden resurssit sijaitsevat hajautetusti eri toimipisteissä. 3.1 Kansainvälisen ohjelmistokehityksen ominaispiirteet On useita syitä miksi yritys haluaisi ryhtyä kansainväliseen ohjelmistotuotantoon. Suuret kansainväliset yritykset haluavat usein keskittää eri toimialojensa parhaan osaamisen erikoistuneisiin toimistoihin, jolloin tiettyyn projektiin tarvittavaa osaamista saatetaan joutua kokoamaan useasta eri toimistosta [Lau04]. Kustannustekijät tai eri aikavyöhykkeillä sijaitsevien toimipisteiden mahdollistama vuorokauden ympäri jatkuva kehitystyö voivat myös olla syynä kansainvälisen projektin perustamiseen[key03]. Erikoisosaamista vaativissa projekteissa kansainvälistymisen motivaationa voi olla resurssipula, kun osaamista ei välttämättä löydy lyhyellä varoitusajalla maan rajojen sisältä eikä työntekijöiden siirtäminen maiden välillä ole välttämättä mahdollista [Lau04]. Kansainvälinen ohjelmistokehitys ei kuitenkaan tarjoa pelkkiä hyötyjä vaan myös haasteita. Kansainvälisessä ohjelmistokehityksessä haasteet jakautuvat kahteen pääkategoriaa: Ensiksi yleisesti hajautettujen projektien kohtaamat välimatkasta johtuvat ongelmat ja toiseksi kansainvälisille projekteille ominaiset kulttuuri- ja aikaerojen aiheuttamat ongelmat.

7 Hajautetulle ohjelmistokehitykselle ominaiset haasteet Huomattava osa kansainvälisten ohjelmistokehitysprojektien kohtaamista ongelmista johtuu projektiryhmän hajautetusta sijainnista. Kun ihmiset eivät tapaa kasvokkain, kommunikaatioon tulee viiveitä ja tietoa hukkuu matkan varrella. Näiden ongelmien ratkaisussa kommunikointiteknologiat ja kommunikaatiossa käytettävät prosessit ovat tärkeitä. Hajaannus aiheuttaa myös inhimillisiä huolia. Ryhmähengen ja luottamuksen rakentaminen tiimin jäsenten välillä on vaikeaa kun projektiryhmän jäsenet tapaavat kasvokkain vain harvoin tai pahimmassa tapauksessa eivät ollenkaan. Luottamuksella muihin tiimin jäseniin on huomattava merkitys organisaation tehokkuudelle sekä ryhmien viihtyvyydelle ja luovuudelle [Key03, Pil06]. Vastuu jakautuu virtuaalisessa tiimissä tyypillisesti epätasaisemmin kuin kasvokkaisessa. Pillis ja Furumo havaitsivat tutkimuksessaan että virtuaalisessa työryhmässä oman työpanoksen laiminlyönti on huomattavasti yleisempää. Osa hajautetun ryhmän jäsenistä ei osallistunut lainkaan ryhmän työhön. Virtuaalisessa ryhmässä työskentely koettiin kaiken kaikkiaan vähemmän tyydyttäväksi kuin kasvokkaisessa tiimissä [Pil06] Kansainväliselle ohjelmistokehitykselle ominaiset haasteet Kaikki hajautetuille projekteille ominaiset haasteet koskevat myös kansainvälisiä ohjelmistokehitysprojekteja. Näiden lisäksi tyypillisiä ongelmia ovat kulttuuriset erot kommunikoinnissa ja työtavoissa, kielelliset vaikeudet kommunikoinnissa sekä aikaeron aiheuttamat vaikeudet projektiryhmän kommunikoinnissa ja kokousten järjestämisessä. Esimerkiksi kansallisten aksenttien ymmärtäminen saattaa osoittautua liian hankalaksi konferenssipuhelimen heikon äänenlaadun vuoksi [Ber07] tai yhteisten palaveriaikojen löytyminen voi olla vaikeaa, vaikka projektin jäsenet sijaitsivatkin pääpiirteittäin samalla aikavyöhykkeellä [Lau04]. Vaikka aikaerojen mahdollistama ympärivuorokautinen työskentely saattaa olla erittäin hyödyllistä kansainväliselle ohjelmistokehitysprojektille, aikaerot aiheuttavat myös paljon päänvaivaa projektien kommunikaation ja kokousten järjestämisessä. Tapaamisia ei voida järjestää spontaanisti silloin, kun niille on tarvetta, eikä kysymyksiin välttämättä voi saada vastausta saman päivän aikana. Onkin selvää että aikaerot projektiryhmien välillä hidastavat projektin työskentelyä. Espinosa, Nan ja Carmel tutkivat aikaeron eri asteiden vaikutusta projektin tehokkuuteen ja saivat mielenkiintoisia tuloksia. Tutkimuksen

8 4 mukaan projekteissa, joissa on pieniä aikaeroja, eteneminen oli kaikkein hitainta. Sen sijaan projekteissa, joissa tiimeillä ei ole ollenkaan samanaikaista työaikaa, etenemisnopeus on rinnastettavissa projekteihin, joissa kaikki työaika on samanaikaista [Esp07]. 4 Ketterät prosessit kansainvälisessä ohjelmistokehityksessä Ketterien prosessien yhteydessä käytettyjen menetelmien riippuvuus projektiryhmän fyysisestä sijainnista vaihtelee menetelmäkohtaisesti. XP:n pariohjelmointi, jossa projektiryhmän jäsenet istuvat saman työpisteen ääressä, on erittäin riippuvainen sijainnista. Ohjelmistokehityksen testi-lähtöisyydelle sijannilla puolestaan ei ole merkitystä. Hallinnollisena työkaluna ja työprosessina Scrum-prosessimalli soveltuu teoriassa kansainvälisen ohjelmistokehityksen hallintaan, mutta aiheuttaa tiettyjen menetelmiensä osalta haasteita. Kansainvälisessä käytössä Scrum-prosessi tarvitsee tarkkaa suunnittelua toimiakseen halutulla tavalla. 4.1 Hajautetun Scrumin strategiat Fyysisesti hajautetun ohjelmistokehitysprojektin Scrum-prosessimallin toteuttamiselle on kirjallisuudessa esitetty kolme vaihtoehtoa: eristetyt Scrumit, paikalliset Scrumit hajautetulla Scrumien Scrumilla ja integroidut Scrumit [Sut07]. Eristetyt Scrumit on menetelmistä yksinkertaisin. Samassa kansainvälisessä projektissa voi olla useita paikallisia Scrum-tiimejä, mutta nämä eivät kommunikoi keskenään. Tämä lähestymismalli ei sisällä kansainvälistä Scrum-prosessia, joten en syvenny siihen tutkimuksessani. Scrum Alliance suosittelee hajautetun Scrumien Scrumin strategiaa parhaana käytäntönä. Tässä strategiassa Scrum-tiimit ovat useimmiten kokonaan paikallisia tiimejä, jotka eivät ole erityisen riippuvaisia toisistaan. Tiimien Scrum-mestarit, jotka tyypillisesti ovat tiiminvetäjiä tai projektipäälliköitä, muodostavat oman hajautetun Scrum-tiiminsä. Tämä Scrumien Scrum kokoontuu säännöllisesti jakamaan tietoa eri Scrum-tiimien välille. Strategia kannustaa kommunikaatioon ja yhteistyöhön ja on suositeltava tapa tiimeille, joilla ei ole vielä vankkaa pohjaa ketteristä työskentelymenetelmistä. Integroidut Scrumit ovat Scrum-tiimejä, joiden jäsenet ovat fyysisesti hajautettuja eri toimipisteiden välillä, mutta jotka toimivat silti yhtenä Scrum-tiiminä. Integroidut Scrumit

9 5 on hallinnollisesti haasteellisin strategia, koska fyysinen hajautus vaikeuttaa tiimien yhteydenpitoa ja ylimääräisiä kustannuksia syntyy kommunikoinnista ja koordinoinnista. Integroidun Scrumin vahvoja puolia ovat kulttuuristen muurien murtaminen, työtapojen yhteensovittaminen ja laajemman yhteenkuuluvuuden tunteen luominen organisaatiossa. Jos Integroidun Scrumin strategian toteutus on onnistunut, fyysinen sijainti lakkaa olemasta merkityksellinen ja tuottavuudessa voidaan päästä lähelle pienen paikallisen tiimin tulosta. Integroitujen Scrumien strategiaa voidaan suositella kokeneille ketterille tiimeille. Kuvio 1: Hajautettujen Scrum-tiimien strategiat [Sut07] Tyypillisessä projektissa, jossa hyödynnetään kansainvälistä alihankintaa, tiimit toimivat erillisinä yksiköinään ilman Scrum-tyyppistä koordinointia. Ne voivat kuitenkin noudattaa Scrum-prosessia sisäisesti. Tämä voidaan mieltää alkeelliseksi versioksi eristettyjen Scrumien strategiasta [Sut07]. Erilaisista hajautetun Scrumin toteutuksista on olemassa muutamia tapaustutkimuksia, joista esittelen tässä tutkimuksessa kolme Integroitu Scrum pienessä kansainvälisessä projektissa Ketterät menetelmät ovat riippuvaisia jatkuvasta ja laadukkaasta palautteesta projektiryhmälle, jotta projekti voi vastata liiketoiminnan tarpeitten muutokseen. Hyvä kommunikaatio on kriittistä. Etäisyyksien myötä kommunikaatio hidastuu. Kun ongelmia tulee, hajautettu projektiryhmä on vaikeassa tilanteessa. Berczuk kuvasi tällaisen tilanteen tutkimuksessaan norjalaisen hakukoneyhtiö FASTin kehitystiimin hajaantumisesta yhtiön Norjan ja Yhdysvaltain toimistojen välille [Ber07].

10 6 FASTin tapauksessa projektiryhmä oli ehtinyt työskennellä projektin ensimmäiset kuukaudet samassa toimipisteessä ja harjoitella Scrumin käyttöä projektin hallintaan. Osan projektiryhmästä palatessa Norjaan tiimi hajaantui kahdelle eri mantereelle. Suurimmat hajaantumisen aiheuttamat ongelmat liittyivät kommunikointiin ja aikaeroon. Alussa kiusaus tehdä tiimikohtaisia poikkeuksia käytettyihin Scrum-menetelmiin oli suuri, mutta projektin edetessä tiimi havaitsi, että poikkeukset prosessista aiheuttivat vain lisää kommunikointivaikeuksia tulosten ollessa sitä parempia mitä orjallisemmin prosessia noudatettiin. Erilaiset työkalut kuten projekti-wikit ja työjonon käsittelyjärjestelmät osoittautuivat erittäin hyödyllisiksi etenkin projektin myöhemmässä, hajautetussa vaiheessa. Myös alkeellisemmilla työkaluilla oli merkityksensä. Esimerkiksi seinäkello, joka osoitti paikallista aikaa toisessa toimistossa, edisti tiimin yhteenkuuluvuuden tunnetta. Projektin työjakson (eng. sprint) pituus oli aluksi ollut neljän viikon mittainen. Tästä kuitenkin luovuttiin myöhemmin osin projektikohtaisista syistä, mutta myös koska projektiryhmä koki että pitkät työjaksot edistivät eristyneisyyttä tiimissä. Kun lyhentyneiden työjaksojen vuoksi suunnittelupalavereita ja lopputarkasteluita pidettiin kerran kahdessa viikossa, projektiryhmä pysyi paremmin selvillä projektin ja toistensa tilanteesta. Lyhentyneet työjaksot helpottivat myös projektin seurantaa. Hyvien tuotekehityskäytäntöjen noudattamisen hyödyllisyys on itsestäänselvää tuotekehitysprojekteille. Hajautetussa ympäristössä käytäntöjen noudattamisen hyöty korostui entisestään, koska noudattamatta jättämisen haittavaikutukset korostuivat. Projektin kuluessa tiimi alkoi pitää paremmin huolta siitä, että uusin koodi kääntyi aina ja yksikkötestit menivät läpi. Tällöin toimistot eivät törmänneet enää usein tilanteisiin joissa kehittäjät olisivat riippuvaisia eri aikavyöhykkeellä toimivan toimiston tekemistä korjauksista. Eniten päänvaivaa projektille tuotti päivittäisten Scrum-tapaamisten järjestäminen. Aikaeron vuoksi päivittäiset tapaamiset järjestyivät lopuksi siten, että Norjassa ne pidettiin työpäivän päätteeksi ja Yhdysvalloissa työpäivän alussa. Tällöin Scrumin kolmen kysymyksen protokolla johti omituiseen tilanteeseen, jossa osa tiimistä puhui siitä, mitä aikoo tehdä tänään ja toinen osa siitä, mitä aikoo tehdä huomenna. Norjan toimistolla päädyttiin myös pitämään aamuisin mini-tapaaminen käytännöllisyyden vuoksi. Teknologiakaan ei ollut ongelmatonta. Konferenssipuhelinten äänenlaatu osoittautui riittämättömäksi, jotta kaikkien puheesta olisi saanut selvää. Tästä syystä

11 7 projektiryhmä siirtyi käyttämään Skypeä konferenssipuheluihin, mikä toimi paremmin Sisäkkäiset Scrumit laajassa kansainvälisessä projektissa Kun Scrumia käytetään projektinhallinnan menetelmänä suurissa kansainvälisissä projekteissa, projektin kansainvälisyyden ja toimipaikkojen lukumäärän merkitys projektin onnistumiselle pienenee suhteessa projektin muihin ominaisuuksiin kuten projektin laajuuteen. Projektin ollessa tarpeeksi suuri se on helppo pilkkoa pienempiin hallittaviin kokonaisuuksiin, jotka ovat pääasiassa kasvokkain työskentelevien tiimien toteutettavissa. Tällöin kansainvälisen kommunikoinnin osuus kokonaiskommunikaatiosta vähenee. Smits ja Pshigoda analysoivat Scrumin käyttöä tällaisen laajan, hajautetun ja kansainvälisen projektin toteutuksessa [Smi07]. BMC Software sovelsi Scrum-metodologiaa kehittäessään 'Identity Management' -tuotteestaan seuraavan version. Kyseessä oli laaja projekti, jossa työskenteli aluksi neljä ohjelmistokehitystiimiä. Näistä kehitystiimeistä kaksi oli kansainvälisesti hajautettuja ja kaksi paikallisia. Kansainvälisten tiimien jäsenet työskentelivät Israelissa, Yhdysvalloissa ja Ranskassa. Paikalliset tiimit työskentelivät Israelissa. Projektin omistajat muodostivat oman tiiminsä, joka oli myös hajautettu Israelin, Ranskan ja Yhdysvaltojen välille. Lisäksi projektiin nimitettiin arkkitehti, joka toimi muiden projektin tiimien ulkopuolella. Projekti käynnistyi kaikkien projektiin osallistujien tapaamisella Tel Avivissa, jossa projektin osalliset tutustuivat. Projektin ensimmäinen julkaisu suunniteltiin yhdessä. Projektin jatkuessa projektin johto laajensi myöhempien julkaisujen yhteydessä projektin tavotteita ja lisäsi projektiin tiimejä. Suurimmillaan projektissa oli 14 kehitystiimiä omistajatiimin lisäksi. Scrumin käyttö projektin hallintaan aiheutti aluksi ongelmia kun arkkitehturaalisia vaatimuksia muutettuun työjonon (eng. product backlog) tehtäviksi (backlog item), jotka Scrumissa ovat ennemmin ominaisuus- tai tarinavetoisia. Projektin omistajien osallistuminen oli haasteellista: Omistajaryhmän jäsenten intressit koskivat koko projektia, mutta sen jäsenet olivat hajaantuneet fyysisesti eri toimipaikkoihin, jotka sijaitsivat eri aikavyöhykkeillä. Projektin arkkitehdin ja laadunhallinnan roolit ja vastuut organisaatiossa olivat epäselviä. Projektin dokumentointi oli erityisen haasteellista, koska ominaisuuksien kehittäminen, testaus ja dokumentointi saman työjakson aikana koettiin mahdottomaksi. Projektin aikana ei löydetty yhteistä työtapaa dokumentointiin. Suunnittelusessiot koettiin hyvin haasteellisiksi. Projektissa koettiin ensisijaisen tärkeäksi

12 8 suunnittelusessioiden tapahtuminen kasvokkain, joten projektissa investoitiin huomattavasti suunnittelusession osallistujien lennättämiseen samaan paikkaan. Toinen tärkeä vaatimus hyvälle suunnittelusessiolle oli saada työjono valmiiksi hyvissä ajoin suunniteltavalle työjaksolle. Projektiryhmien määrän kasvaessa Scrum-prosessin '15-minuuttisten päivittäisten tapaamisten' koko alkoi kasvaa liian suureksi osallistujamäärältään ja liian vaikeasti koordinoitavaksi aikavyöhyke-erojen vuoksi. Ongelma ratkaistiin projektissa sisäkkäisellä Scrum-projektirakenteella. Projektin viisitoista tiimiä jakautuivat useaan 'Scrumien Scrum' -tason ryhmään, joiden Scrum-mestarit kokoontuivat raportoimaan Scrummestarien Scrum-mestarille, muodostaen projektiin 'Scrumien Scrumien Scrum' -tason Integroitu Scrum laajassa kansainvälisessä projektissa SirsiDynixillä on arviolta 4000 kirjasto- ja konsortiumiasiakasta maailmanlaajuisesti. Kun SirsiDynix päätti kehittää kokonaan uuden järjestelmän korvaamaan vanhaa kirjastojärjestelmäasennusta, yritys valitsi alihankkijakseen venäläisen StarSoft Development Labsin, jolla on paljon kokemusta ketteristä menetelmistä. Projektin Yhdysvaltain toimiston kehitystiimiin Utahissa kuului 30 henkeä ja StarSoftin alihankkijoina projektiin liittyi 26 Pietarista käsin työskentelevää venäläistä [Sut07]. Projektin Scrum-strategiaksi valittiin Integroitu Scrum, jossa tyypillinen tiimi koostui 3-5 henkilöstä Utahissa ja neljästä tai useammasta henkilöstä Pietarissa. Lisäksi jotkin tiimien jäsenistä työskentelivät Seattlessa, Denverissä, St. Louisissa ja Kanadan Waterloossa. Projektien Scrummestarit olivat aina Utahissa ja pitivät Scrumien Scrumin paikallisesti. Kymmenen tunnin aikaeron johdosta Scrum-tapaamiset pidettiin kello 7:45 Utahin aikaa, joka on 17:45 Pietarin aikaa. Tiimit havaitsivat kuitenkin, että oli tarpeellista jakaa sähköpostilla vastaukset Scrumin kolmeen kysymykseen ennen tapaamisia. Tämä lyhensi telekonferenssien kestoa ja helpotti kielimuurin aiheuttamia ongelmia. Lisäksi Pietarin tiimi piti oman paikallisen kokouksensa joka työpäivän alussa. Työjaksojen pituudeksi muodostui kaksi viikkoa kuten FASTin tapauksessa. Jokainen työjakso alkoi jakson suunnittelukokouksella. Jakson päätökseksi suunnitellut ominaisuudet olivat valmiit ja ne demottiin. Projektin aikana valmiin määritelmä laajennettiin sisältämään täysi testaus. Keskeneräiset työkokonaisuudet pyrittiin pitämään tiukasti työjaksojen sisäisinä eikä keskeneräinen työkokonaisuus saanut valua työjaksosta toiseen, koska se aiheutti viiveitä, kasvatti riskiä ja rikkoi ketterän kehityksen periaatteita.

13 9 Vaatimukset toteutetaan normaalisti Scrumissa käyttäjätarinoiden muodossa. Tämän projektin tarpeisiin käyttäjätarinat eivät kuitenkaan olleet tarpeeksi tarkkoja, koska kirjastokäytännöt poikkeavat toisistaan kansainvälisellä tasolla. Käyttäjätarinoiden sijaan käytettiin hyvin yksityiskohtaisia käyttötapauskuvauksia. Projekti oli eräs tuottavimmista dokumentoiduista Scrum-projekteista. Projekti tuotti 671,688 koodiriviä 14,5 kuukauden aikana 56 henkilön toimesta. Projektin aikana koodille suoritettiin radikaali uudelleenjärjestely kahdesti. Tällä tavoin koodin koosta vähennettiin 275,000 riviä. Projekti pääsikin tuottavuudessaan lähelle pienten paikallisten Scrum-tiimien lukemia. 5 Yhteenveto Ketterät menetelmät ovat vaivattomasti sovellettavissa suurissa kansainvälisissä projekteissa, koska projektin suuresta koosta johtuen kokonaiset kehitystiimit pystytään sijoittamaan samaan toimipisteesseen, jolloin ne kykenevät halutessaan käyttämään ketteriä menetelmiä paikallisesti. Tarvittaessa nämä paikalliset ketterät tiimit voivat toteuttaa Scrum-prosessimallia hajautetusti Scrumien Scrum-strategialla. Suurissa projekteissa haasteet ovatkin pääasiassa hallinnollisia. Pienempien kansainvälisten projektien yhteydessä on tyypillisempää, että yksittäinen kehitystiimi on hajautettu useamman toimipisteen välille. Tällöin tiimi saattaa olla lähtökohtaisesti pakotettu valitsemaan Integroidun Scrumin strategian. Pienessä organisaatiossa on myös vähemmän resursseja käytettävissä työnteon fasilitointiin ja projektin käytössä olevien kommunikaatioteknologioiden ja kommunikaatiotapojen merkitys korostuu. Integroidun Scrumin strategia soveltuu kuitenkin myös laajempiin kansainvälisiin projekteihin, mikäli osallistuvat työntekijät ovat kokeneita ketterien menetelmien hyödyntäjiä. SirsiDynix pystyi esittämään kunnioitettavia tuottavuuslukuja Integroidun Scrumin strategialla organisoidussa projektissaan.

14 10 Lähteet Smi07 Sut07 Ber07 Lau04 Key03 Pil06 Esp07 Smits, H., Pshigoda, G., Implementing Scrum in a Distributed Software Development Organization. Sutherland, J., Viktorov, A., Blount, J., Puntikov, N., Distributed Scrum: Agile Project Management with Outsourced Development Teams. System Sciences, HICSS th Annual Hawaii International Conference on Jan Page(s):274a - 274a. Berczuk, S., Back to Basics: The Role of Agile Principles in Success with an Distributed Scrum Team. AGILE Aug Page(s): Lau, R., Delivering projects with virtual teams. IEEE International Volume 2, Issue, Oct Page(s): Keyzerman, Y., Trust in Virtual Teams. Professional Communication Conference, IPCC Proceedings. IEEE International Sept Page(s): 10 pp.- Pillis, E., Furumo, K., Virtual vs. Face-to-Face Teams: Deadbeats, Deserters, and Other Considerations. Proceedings of the 2006 ACM SIGMIS CPR conference on computer personnel research: Forty four years of computer personnel research: achievements, challenges & the future. Session 8.2 Pages: Espinosa, J. A., Nan, N., Carmel, E., Do Gradations of Time Zone Separation Make a Difference in Performance? A First Laboratory Study. Second IEEE International Conference on Global Software Engineering. ICGSE Aug Page(s):12-22

15 11 Lähteet (tulevaan käyttöön) Col07 Lee06 San07 Edw02 Cus03 Abr03 Sal08 Nid05 Coldewey, J., Link, J., Marquardt, K., Agility unlimited? OOPSLA '07: Companion to the 22nd ACM SIGPLAN conference on Object oriented programming systems and applications companion, October 2007 Lee, G., DeLone, W., Espinosa, J.A., Ambidextrous coping strategies in globally distributed software development projects. Communications of the ACM, October 2006 Sanders, D., Using Scrum to manage student projects. Journal of Computing Sciences in Colleges, October 2007 Edwards, H.K., Sridhar, V., Analysis of the Effectiveness of Global Virtual Teams in Software Engineering Projects, Proceedings of the 36th Hawaii International Conference on System Sciences, 2002 Cusumano, M., et al., Software Development Worldwide: The State of the Practice. IEEE Software, Volume 20, Number 6, Nov/Dec 2003, Abrahamsson, P., Warsta, J., Siponen, M.T., Ronkainen, J., New Directions on Agile Methods: A Comparative Analysis. ICSE'03: Proceedings of the 25th International Conference on Software Engineering on 3-10 May 2003 Pages Salo, O., Abrahamsson, P., Agile methods in European embedded software development organisations: a survey on the actual use and usefulness of Extreme Programming and Scrum Software. IET Volume 2, Issue 1, February 2008 Page(s): Nidiffer, K., E., Dolan, D., Evolving Distributed Project Management. IEEE Software, vol. 22, pages 63-72, Sep/Oct 2005