Hajautettu ohjelmistokehitys Lean-näkökulmasta: tapaustutkimus hukkatekijöistä

Transkriptio

1 Hajautettu ohjelmistokehitys Lean-näkökulmasta: tapaustutkimus hukkatekijöistä Paula Mäenpää Helsinki Pro gradu -tutkielma HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

2 HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta Fakultet Faculty Laitos Institution Department Matemaattis-luonnontieteellinen Tekijä Författare Author Paula Mäenpää Työn nimi Arbetets titel Title Tietojenkäsittelytieteen laitos Hajautettu ohjelmistokehitys Lean-näkökulmasta: tapaustutkimus hukkatekijöistä Oppiaine Läroämne Subject Tietojenkäsittelytiede Työn laji Arbetets art Level Aika Datum Month and year Sivumäärä Sidoantal Number of pages Pro gradu -tutkielma sivua Tiivistelmä Referat Abstract Lean-losoan mukaan asiakkaalle tuotetaan oikea tuote oikeaan aikaan, tehokkaasti, joustavasti ja ilman arvoa tuottamatonta toimintaa eli hukkaa. Tutkielmassa tarkastellaan, missä määrin kehitystyö hajautetussa ympäristössä voi olla Lean-periaatteiden ja -päämäärien mukaista. Ongelmaa lähestyttiin analysoimalla, minkälaisia hukkia tutkimuskohteena olleessa hajautetussa projektissa ilmeni ja oliko työnkulku tehokasta. Tutkielman materiaalina hyödynnettiin kirjallisuuslähteitä. Lisäksi tutkielmaa varten suoritettiin empiirinen tapaustutkimus Software Factory -kurssilla talvella Tutkimusaineisto kerättiin havainoimalla työskentelyä ja haastattelemalla ohjelmistokehittäjinä työskennelleitä yliopistoopiskelijoita. Projekti oli hajautettu maantieteellisesti kahteen pisteeseen: A ja B. Tavoitteena oli tuottaa asiakkaalle protoversio uudesta mobiilisovelluksesta. Projekti oli sekä asiakkaan että opiskelijoiden näkökulmasta onnistunut: tuote valmistui ajallaan ja oppimiskokemus oli kaikille positiivinen. Tutkielman mielenkiinnon kohteena ei ole kuitenkaan projektin menestys, vaan tarkastelun kohteena ovat työtapojen ja työnkulun tehokkuudet. Tutkielmassa havaitaan, että projektissa ilmeni erilaisia hukkia. Osa hukista oli tiimiläisistä riippumattomia, mutta suurin osa oltaisiin voitu ehkäistä tai poistaa. Tarkemman analyysin kohteeksi valittiin yhteistoimintaongelmat, jotka liittyvät hukkaan tehoton kommunikaatio. Tutkielmassa havaitaan myös, että työnkulkua olisi ollut mahdollista optimoida yhteisiä käytäntöjä noudattamalla. Tapaustutkimuksen tulokset vahvistavat tutkimusten tuloksia tehokkaan kommunikaation ja yhteistoiminnan tärkeydestä hajautetuissa projekteissa. Heikkolaatuinen ja riittämätön yhteydenpito aiheuttaa erilaisia hukkia, kuten ylimääräisiä ominaisuuksia ja virheitä toteutettavassa sovelluksessa sekä turhaa odottelua eri pisteiden välillä. Kaikki hukat on tärkeää tunnistaa ja poistaa, mutta ilmeisesti juuri tehoton kommunikaatio aiheuttaa eniten muita hukkia hajautetuissa projekteissa. ACM Computing Classication System (CCS): D.2 [Software Engineering] Avainsanat Nyckelord Keywords Lean, hajautettu ohjelmistokehitys, hukka, kommunikaatio, yhteistoiminta Säilytyspaikka Förvaringsställe Where deposited Muita tietoja övriga uppgifter Additional information

3 Sisältö ii 1 Johdanto Tutkimustilanteen kartoitus Tutkimuskysymykset Tutkielman rakenne Teoriatausta Hajautettu ohjelmistokehitys Hajautettu ohjelmistokehitys käsitteenä Keskitetystä hajautettuun kehitykseen Hajautuksen organisointi Etuja hajautetussa ohjelmistokehityksessä Uhat hajautetussa ohjelmistokehityksessä Lean-losoa Toyota Production System Lean-losoan periaatteet Lean-periaatteet ohjelmistotuotannossa Seitsemän Lean-pääperiaatetta ohjelmistotuotannossa Hukka: arvoa tuottamaton toiminta Tutkielmassa tarkasteltavat hukat Lean-käsitteet hajautetussa ympäristössä Ketterä kehitysmalli Perinteinen ja ketterä ohjelmistokehitysprosessi

4 iii Scrum XP Agile manifeston arvojen ja Lean-periaatteiden yhteys Ketterät käytännöt kommunikaatio-ongelmien ratkaisuna Kokeellinen tutkimus Miten ongelmaa tutkitaan Tutkimuskohteen esittely Tiedon keräämisen välineet Empiiriset tulokset Tiimien työskentelytavat Prosessimalli Kanban-menetelmä Työtapojen tehokkuus Projektissa ilmenneet hukat Yhteistoiminta ja kommunikaatio projektissa Arvovirtauksen tehokkuus Työnkulku koko projektin ajalta Yhden tehtävän työnkulku Projektin onnistuminen Johtopäätökset Empiiriset tapaustutkimuksen tulokset

5 iv Työtapojen tehokkuus Arvovirtauksen tehokkuus Hajautetun projektin Lean-näkökulma Suosituksia Ehdotus hajautettujen projektien tarkistuslistaksi Tutkimuksen rajoitukset Yhteenveto Jatkotutkimuksen aiheita Lähteet 89 Liitteet 1 Sanasto 2 Haastattelukysymykset

6 1 Johdanto 1 Hajautettu ohjelmistokehitys on nykyään arkipäivää suurissa yrityksissä. Syitä keskitetystä hajautettuun ohjelmistokehitykseen siirtymiseen on useita, joista ylivoimaisesti suurin motiivi on taloudellisen hyödyn tavoittelu. Hajautukseen voidaan myös joutua, jos asiakas vaatii yrityksen kehittämiskeskuksen siirtämistä kotimaahansa. Hajautuksen edut ja uhat riippuvat usein katsantokannasta. Lean-losoa on lähtöisin autoteollisuudesta toisen maailman sodan jälkeen. Alun perin nimellä Toyota Production System tunnettu losoa kehitettiin teollisuuden tarpeisiin laadullisten prosessien ja tuottavuuden parantamiseksi. Tärkeimmät teemat ovat vain tilattujen tuotteiden valmistaminen ja niiden toimittaminen juuri oikeaan aikaan ja tuotannon keskeyttäminen välittömästi häiriötilanteissa. Tuotantotapa perustuu aktiiviseen arvoa tuottamattoman toiminnan eli hukan tunnistamiseen ja poistamiseen. Samoja periaatteita voidaan soveltaa myös ohjelmistoteollisuudessa. Nykypäivän suosituimpia ketteriä kehitysmalleja sekä keskitetyssä että hajautetussa ohjelmistokehityksessä lienevät Scrum ja extreme Programming. Leankirjallisuudessa niiden hyödyntämistä suositellaan perinteisten prosessimallien sijaan, koska perinteisissä kehitysmalleissa ei pystytä reagoimaan nopeasti asiakkaan muuttuviin vaatimuksiin, jolloin hukan ehkäiseminen vaikeutuu. Lean-ohjelmistokehitys on usein ketterää kehitystä. Tutkielmassa analysoidaan hajautetussa CoT-projektissa ilmenneitä hukkia ja arvovirtauksen tehokkuutta sekä pohditaan niiden merkittävyyttä. Tässä luvussa kartoitetaan nykyinen tutkimustilanne ja esitellään tutkimuskysymykset ja tutkielman rakenne.

7 2 1.1 Tutkimustilanteen kartoitus Hajautettua ohjelmistokehitystä käsittelevää tutkimusta on tehty paljon. Yrityksille on esitetty suosituksia, kuinka maantieteellisesti eri pisteisiin hajautettuja projekteja tulee hallinnoida erilaisin kehitysmallein. Usein suositellaan hyödynnettäväksi Scrum-prosessimallia tai vähintään joitakin sen menetelmiä. Joidenkin lähteiden mukaan tarvitaan myös perinteisistä kehitysmalleista tuttua muodollisuutta, jotta eri pisteissä sijaitsevat tiimit ovat kontrolloitavissa. Myös Lean-ohjelmistokehityksestä on tehty tutkimusta jo jonkin aikaa. Lean- losoan mukaan ohjelmistoprojektia tulisi hallinnoida ketterin kehitysmallein, sillä perinteiset kehitysmallit ovat joustamattomia ja raskaita. Tutkimuskohteet ovat useimmissa tapauksissa olleet projekteja, joissa ohjelmistokehittäjät työskentelevät samassa tilassa. Hajautusta ja Lean-ohjelmistokehitystä on tutkittu yleensä erillisinä teemoina. Tässä tutkielmassa pyritään selvittämään, voidaanko nämä teemat yhdistää menestyksellisesti, eli voiko kehitystyö hajautetussa ympäristössä olla Lean-periaatteiden mukaista. 1.2 Tutkimuskysymykset Tutkielman lähteinä käytetään tutkielmassa käsiteltyä kirjallisuutta. Lisäksi tutkielmaa varten suoritettiin empiirinen tapaustutkimus. Tutkimuksen kohteena oleva ohjelmistoprojekti CoT järjestettiin talvella 2011 Software Factory -kurssilla. CoTprojektiin liittyvä sanasto löytyy liitteestä 1. Tutkielmassa pyritään selvittämään, missä määrin kehitystyö hajutetussa ohjelmistokehityksessä voi olla Lean-periaatteiden ja -päämäärien mukaista. Kysymystä analysoidaan tarkastelemalla työskentelivätkö tutkimuskohteen projektilaiset te-

8 3 hokkaasti ilman turhia hukkia ja kuinka tehokkaita projektin arvovirtaukset olivat. Tehokkuus arvioidaan projektitiimien ja asiakkaan näkökulmasta. Tutkimuskysymykset on esitetty GQM-paradigman (Goal-Question-Metric) mukaisesti taulukossa Analyysi Hajautettu ohjelmistokehitys 2. Jotta voidaan Löytää hukkaa 3. Mitä tulee 1. Työtapojen tehokkuus 2. Arvovirtauksen tehokkuus 4. Näkökulma Projektitiimit ja asiakas 5. Asiayhteys Hajautettu ohjelmistoprojekti CoT 6. Motivaatio Toteutuuko Lean Taulukko 1: Tutkimuskysymysten GQM-kehys [Bas93]. 1.3 Tutkielman rakenne Tutkielma on jaettu kuuteen osaan: johdanto, teoriatausta, kokeellinen tutkimus, empiiriset tulokset, johtopäätökset ja yhteenveto. Rakenne on havainnollistettu kuvassa 1. 2 Teoriatausta Tässä luvussa tarkastellaan tutkielman kannalta oleellisia käsitteitä. Hajautettua ohjelmistokehitystä voidaan hallinnoida esimerkiksi ketterin kehitysmallein (agile software development) ja Lean-periaatteita soveltaen. Ketterä ohjelmistokehitys tar-

9 4 Kuva 1: Tutkielman rakenne. koittaa tässä yhteydessä joukkoa kehitysmalleja, joille kaikille on yhteistä muun muassa iteratiivisuus, suora kommunikaatio ja toimivan ohjelmiston ensisijaisuus. Näitä käytäntöjä soveltavia kehitysmalleja on useita, joista yleisimmät ovat Scrum ja extreme Programming (XP). Lean-periaatteita noudattaen ohjelmistokehityksestä pyritään muokkaamaan mahdollisimman paljon arvoa tuottava prosessi. Luvussa 2.1 käsitellään hajautettua ohjelmistokehitystä ja luvussa 2.2 esitellään Lean-losoan mukainen ohjelmistotuotanto. Lopuksi luvussa 2.3 tarkastellaan yleisimpiä ketteriä kehitysmalleja. 2.1 Hajautettu ohjelmistokehitys Ohjelmistokehityksen hajauttaminen ei ole uusi ilmiö. Hajautettuja projekteja on ollut jo vuosikymmenten ajan. Globalisaatio yhdessä vaativamman kilpailun kanssa on osaltaan painostanut ja jopa pakottanut monia yrityksiä siirtymään entistä enemmän hajautettuun ohjelmistokehitykseen. Hajautetut projektit ovat nykyisin taval-

10 5 lisia varsinkin suurissa globaaleissa yrityksissä. Koska kommunikaatiovälineet ovat kehittyneet, eri aikavyöhykkeillä työskenteleminen ei aiheuta enää yhtä merkittäviä ongelmia kuin ohjelmistokehityksen alkuaikoina, jolloin hajautus oli vielä harvinaista Hajautettu ohjelmistokehitys käsitteenä Ohjelmistokehityksen hajautus on monitasoinen käsite. Se voidaan jakaa Prikladnickin et al. [PAD07] mukaan neljään luokkaan, jotka riippuvat projektin maantieteellisestä sijainnista ja omistajuudesta. Projekti on maantieteellisesti joko lokaali (onshore tai Distributed Software Development, DSD) tai globaali (oshore tai Global Software Developmet, GSD). Lokaalissa projektissa kehitystyö tapahtuu siinä maassa, jossa yrityksen päämaja ja muut toiminnot sijaitsevat. Globaalissa kehitystyössä hyödynnetään ulkomaisia resursseja siirtämällä osia kehitystyöstä pois yrityksen kotimaasta. Omistajuudella tarkoitetaan joko palveluiden ulkoistamista toiselle yritykselle (outsourcing) tai yrityksen omien resurssien hyödyntämistä (insourcing). Taulukossa 2 on kuvattuna nämä jaottelut. Osta Luo Lokaali (DSD) Lokaali ulkoistaminen Lokaali, yrityksen omat resurssit Globaali (GSD) Globaali ulkoistaminen Globaali, yrityksen omat resurssit Taulukko 2: Hajautetun ohjelmistokehityksen jaottelu eri luokkiin. Kun kyse on globaalista projektista, pelkän fyysisen etäisyyden lisäksi tulee huomioida myös ajallinen ja sosiokulttuurinen etäisyys [Åge06]. Henkilöiden ajallinen etäisyys estää tosiaikaisen kanssakäymisen. Sosiokulttuurinen etäisyys estää henkilöitä ymmärtämästä toisensa arvoja ja normatiivisia käytäntöjä.

11 6 Hajautetussa ohjelmistokehityksessä on paljon samoja ongelmia kuin keskitetyssä kehityksessä. Näitä ovat esimerkiksi heikko ohjelmistojen laatu, aikataulujen pettäminen ja kustannusarvioiden ylittyminen [Koa07]. Parnas [ÅgF06] on tullut tutkimuksessaan samaan tulokseen ja tarkentaa, että ilmiöt johtuvat kommunikaatioongelmista Keskitetystä hajautettuun kehitykseen Yritykset haluavat siirtyä hajautettuun ohjelmistokehitykseen useista syistä [Paa10, PAD07]. Näistä suurin osa liittyy taloudellisten etujen tavoitteluun. Jotkin seikat jopa pakottavat yrityksiä siirtymään hajautettuun kehitysmalliin. Globaalin yrityksen valtavia resursseja voidaan hyödyntää tehokkaammin jakamalla projekti eri maihin. Esimerkiksi jokaiselle projektille voidaan valita sopivimmat henkilöt osaamisen mukaan, kun henkilöstön sitouttaminen ei ole maantieteellisestä sijainnista riippuvaista. Prikladnick et al. [PAD07] lainaavat artikkelissaan IDC-raporttia, jonka mukaan globaalilla ulkoistamisella voidaan parantaa prosessia, kun toiminnot uudelleenorganisoidaan ja yhtenäistetään. Hajautuksella tavoitellaan usein kustannussäästöjä. Palkka- ja kehityskustannukset ovat eri maissa eri tasoisia. Kehitystyön osioita voidaan siirtää maihin, joissa kustannukset ovat kilpailukykyisemmät (Cost Competitive Countries). Kustannuksia voidaan jossain määrin säästää myös verotuksessa [MoH01], kun asiakkaana on jonkin valtion julkisen sektorin edustaja. Tällöin asiakas voi kuitenkin vaatia, että yrityksellä on kehittämiskeskus asiakkaan maassa. On tavallista, että yritykset fuusioituvat ja ostavat toisiaan. Hajautus on tällöin yrityksen sisäistä ja mahdollisesti globaalia. Jos eri pisteet toimivat itsenäisesti, yhteistyö niiden välillä saattaa Paasivaaran et al. [Paa10] mukaan olla jopa vaikeampaa kuin kahden eri yrityksen välillä.

12 7 Globaali hajautus tuo kehityksen lähemmäksi markkinoita ja asiakasta [Paa10]. Yrityksen on helpompi tutkia paikallisia markkinoita ja säädöksiä, jolloin ohjelmistoista saadaan paremmin asiakkaan tarpeita vastaavia. Hajautuksella pyritään nopeuttamaan kehitystyötä. Jos yrityksen omat henkilöstöresurssit ovat pienet, voidaan palkata esimerkiksi aliurakoitsija tekemään rinnakkaista kehitystyötä toisessa pisteessä. Kehitystyö voi olla hajautettu myös eri aikavyöhykkeille. Tällöin kehitystyön tuottavuutta voidaan Leen ja Yongin [LeY10] mukaan parantaa työskentelemällä ympärivuorokautisesti. Kilpailijaa nopeampi pääsy markkinoille on ehdoton kilpailuetu, josta seuraa lisäetuja maineen ja uusien tilausten muodossa. Yritys voi haluta keskittyä ydinosaamiseensa ja ostaa muun osaamisen toiselta yritykseltä. Toisaalta yritykseltä voi puuttua osaavaa henkilöstöä, jolloin palveluiden ostaminen toiselta yritykseltä saattaa olla turvallisempi ja nopeampi vaihtoehto kuin oman henkilöstön kouluttaminen. Aliurakoitsijan resursseja on myös helpompi karsia [Paa10]. Larman [Lar08, Lar10] on kirjoittanut isojen hajautettujen Scrum-projektien organisoimisesta. Hänen mukaansa isoa ohjelmistokehitystyötä ei kannata hajauttaa globaalisti useaan pisteeseen, vaikka se on mahdollista [Lar11]. Isojen järjestelmien kehittämiseen ei hänen mielestään tarvita paljon tiimejä. Useaan pisteeseen hajautettu kehitys ei ole erityisen organisoitunutta, vaikka hänen mukaansa niin usein luullaan. Siirtymistä suuriin globaaleihin hankkeisiin ei Larmanin mukaan tule tehdä kevein perustein Hajautuksen organisointi Menestyksekäs hajautettu projekti vaatii Ågerfalkin et al. [ÅgF06] mukaan erityisesti toimivaa koordinointia, kontrollia ja kommunikaatiota. Hajautetussa projek-

13 8 tissa on vaikeampi kommunikoida kuin yhteen pisteeseen keskitetyssä projektissa. Varsinkin globaalisti hajautetussa projektissa, joissa on usean tunnin aikaero eri pisteiden välillä, kommunikaation vaikeus korostuu entisestään. Toimiva kommunikaatio onkin osoittautunut yhdeksi tärkeimmistä huomioon otettavista asiosta hajautetuissa projekteissa. Rameshin et al. [RCM06] mielestä hajautettua ohjelmistokehitystä ei kannata yrittää hallita pelkästään perinteisellä tai ketterällä prosessimallilla. Tärkeintä heidän mielestään olisi löytää tasapaino eri kehitysmallien välillä. Tutkijoilla ei ole Batran et al. [BXV10] mukaan vielä yksimielisyyttä siitä, milloin ja miten näitä malleja tulisi hyödyntää keskenään. He tulivat tapaustutkimuksessaan siihen tulokseen, että tasapaino on saavutettavissa. Heidän mielestään sekä ketteryyttä että perinteiseen prosessimalliin liittyvää kontrollia tarvitaan, jotta saavutetaan tavoitellut päämäärät: ilman kontrollia ketteryys voi olla hajautetussa ympäristössä kaoottista ja toisaalta kontrolli ilman ketteryyttä voi aiheuttaa joustamattomuutta. Paasivaara et al. toteavat kahdessa eri tutkimuksessaan [PaL06, PDL08], että pieni hajautettu projekti voi olla menestyksekäs, jos siinä sovelletaan ketteriä menetelmiä, mutta isommat projektit vaativat vielä lisää tutkimusta. Viime vuonna julkaisemassaan teknisessä raportissa Paasivaara et al. [Paa10] tarjoavat konkreettisia ohjeita yrityksille hajautettujen projektien hallinnoimisesta ja organisoimisesta Scrum-kehitysmallin mukaisesti. Tässä tutkielmassa ohjeita käsitellään soveltuvin osin empiirisen tapaustutkimuksen yhteydessä Etuja hajautetussa ohjelmistokehityksessä Hajautuksella oletetaan olevan erilaisia etuja keskitettyyn kehitykseen verrattuna. Seuraavassa hajautetun ohjelmistokehityksen edut on jaoteltu lähteiden ja kirjoittajan oman näkemyksen mukaisesti osittain todettuihin ja ei todettuhin etuihin. Osit-

14 tain todettu etu on etu, jonka hyödyt on havaittu useassa lähteessä. Ei todettuja etuja on tutkittu vähemmän tai tutkimustulokset ovat ristiriitaisia. 9 Osittain todetut edut Kehityskustannuksia voidaan vähentää palkkaamalla osa kehittäjistä halvemman palkkatason maista [Paa10]. Tämä toisaalta lisää kommunikaatio-ongelmia sekä vaikeuttaa ihmisten ja töiden koordinointia ja kontrollia [OHÅ06]. Voidaan lisäksi miettiä, kuinka kustannustehokasta on järjestää koulutusta useisiin maihin useilla eri kielillä. Kun osa kehitystyöstä on lähellä markkina-aluetta, tuote voidaan räätälöidä vastaamaan paremmin paikallisia markkinoita ja määräyksiä [OHÅ06, Paa10]. Toisaalta samalla täytyy huomioda sosio-kulttuuriset ongelmat, kun kehittäjiä on eri kulttuureista. Kun kehitystyö on lähellä asiakasta, voidaan tehostaa muun muassa vaatimusmäärittelyprosessia, jolloin tuote oletettavasti vastaa paremmin asiakkaan tarpeita. Jos ohjelmiston arkkitehtuuria ei voida jakaa suhteellisen itsenäisiin moduuleihin, voivat päällekkäisyydet aiheuttaa Mockusen ja Grinterin [HeG99] mukaan merkittäviä ongelmia tehtävien koordinoinnissa. Hajautus voi jopa pakottaa ohjelmiston arkkitehtuurin modulaarisuuteen. Conchúirin et el. [OHÅ06] mukaan kehitystyön modulaarisuus voi vähentää kommunikaatiotarvetta tiimien välillä, kun tehtävät on voitu jakaa itsenäisiksi osioiksi. Globaalit markkinat tarjoavat laajemmat työvoimaresurssit [Paa10]. Toisaalta saattaa olla vaikeaa löytää jokaisesta pisteestä juuri tietyt ammattilaiset tiettyihin tehtäviin [OHÅ06]. Kun kehitystyö on hajautettu maahan, jossa asiakas sijaitsee, tuote voidaan räätälöidä vastaamaan paikallisen kulttuurin erityispiirteitä.

15 10 Ei todetut edut Gumm [Gum07] tuli empiirisessä tutkimuksessaan siihen tulokseen, että hajautus mahdollistaa työrauhan, joka lisää yksilön työpanoksen laatua. Kehittäjän työ ei häiriinny jatkuvien keskeytysten vuoksi, koska muodollista kommunikaatiota on vähemmän, kun kokouksia on hankalampi järjestää. Ihmiset käyttivät vähemmän aikaa kommunikoimiseen ja keskittyivät intensiivisemmin omaan työhönsä. Paasivaara et al. [Paa10] toteavat hajautetun kehitystyön nopeuttavan tuotteen markkinoille pääsyä. Heidän mielestään kehitystyötä nopeutetaan palkkaamalla lisää henkilöstöä toisesta maasta työskentelemään rinnakkain lokaalin tiimin kanssa. Toisaalta Herbslebin at al. [HMF01] mukaan monessa pisteessä työskentely kestää paljon kauemmin kuin keskitetty työskentely ja vaatii useamman henkilön työpanoksen saman laajuisen ja yhtä monimutkaisen tehtävän suorittamiseen. Kesto pitenee muun muassa viivästysten vuoksi. Lisäksi Conchúir et al. [OHÅ06] ovat sitä mieltä, että ympärivuorokautisella työskentelyllä, jossa tehtäviä välitetään eteen päin eri aikavyöhykkeiden välillä (follow-the-sun), ei nopeuteta kehitystyön syklien läpimenoaikaa vaan enintään joitakin osia siitä, kuten testausta. Kun projektissa on eri kulttuurin edustajia ja erilaisissa organisaatioissa työskennelleitä ihmisiä, on oletettavaa, että parhaita käytäntöjä ja innovatiivisuutta on enemmän. Vähäisen epämuodollisen kommunikaation vuoksi innovatiivisuuden ja parhaiden käytäntöjen jakaminen ei ole Conchúirin et al. [OHÅ06] mukaan kuitenkaan merkittävää. Hajautuksen edut on jaoteltu taulukossa 3 kahteen ryhmään: osittain todettu etu ja ei todettu etu.

16 11 Osittain todettu etu Ei todettu etu Kehityskustannusten minimointi Kehitys lähellä markkina-aluetta ja asiakasta Kehitystyön modulaarisuus Uudet ja isommat työvoimaresurssit Paikallisen kulttuurin erityisvaatimuksiin vastaaminen Työskentely rauhassa ja pienemmän paineen alla Projektin kesto kalenteriajassa lyhenee Parhaat käytännöt, innovatiivisuus Taulukko 3: Hajautetun kehityksen oletetut edut Uhat hajautetussa ohjelmistokehityksessä Hajautuksella katsotaan olevan myös uhkia. Seuraavassa esitellyt uhat on jaettu kolmeen ryhmään lähteitä ja kirjoittajan omaa arviointia käyttäen: ajallinen etäisyys, maantieteellinen etäisyys ja sosio-kulttuurinen etäisyys. Jaottelut ovat osittain hieman päällekkäisiä, sillä erityyppiset kommunikaatio-ongelmat liittyvät vahvasti jokaiseen kategoriaan. Ajallinen etäisyys Ajallinen etäisyys eri pisteiden välillä johtuu yleensä aikaeroista. Tällöin päällekkäisiä työtunteja on vähän tai ei ollenkaan. Aikaerot aiheuttavat kommunikaatio-ongelmia, kun vastausten odottelu aiheuttaa viivästyksiä. Kommunikaatio-ongelmat voivat aiheuttaa edelleen muita ongelmia, kuten väärinymmärrysten ja virheiden myöhäisen havaitsemisen. Herbslebin ja Grinterin [HeG99] mukaan laadukkaalla suunnitelmalla voidaan vähentää kommunikaatiotarvetta, kun

17 12 ohjelmiston arkkitehtuuri voidaan jakaa suhteellisen itsenäisesti suunniteltaviin moduuleihin. Globaaleissa projekteissa on usein paljon ajallisia riippuvuuksia, jotka vaikeuttavat resurssisuunnittelua ja heikentävät Lean-näkökulmastakin oleellista toimitusvarmuutta (on-time delivery) [HeG99]. Toimitusvarmuudella tarkoitetaan prosessin ja toimitusketjun tehokkuutta. Maantieteellinen etäisyys Cookin ja Nevillen [CoC05] mukaan maantieteellinen etäisyys kehittäjien välillä aiheuttaa merkittäviä yhteistoimintaongelmia. Hajautetun ympäristön yhteistyöongelmia tutkitaan omalla ohjelmistotuotannon alueellaan (Collaborative Software Engineering). Ohjelmistoarkkitehtuurin laadukas suunnitelma eli mitä suunnitellaan, ei Herbslebin ja Grinterin [HeG99] mukaan yksinään riitä koordinoinnin toteuttamiseen, vaan on tärkeää tietää myös milloin, kuka, miten ja missä suunnitellaan. Tällöin projektin koordinointi on heidän mielestään paremmin hallittavissa. Jos ohjelmiston arkkitehtuurisuunnittelma ei ole tarpeeksi modulaarinen, voivat eri pisteissä suoritettavat työtehtävät riippua toisistaan merkittävästi. Ristiriitaiset olettamukset tehtävistä eri pisteissä säilyvät Herbslebin ja Grinterin [HeG99] mukaan kauemman aikaa hajautetussa kuin keskitetyssä ohjelmistokehityksessä. Maantieteellinen etäisyys vähentää epämuodollista kommunikaatiota, mikä e- delleen heikentää ryhmähenkeä, luottamusta ja Mockusen ja Herbslebin [MoH01] mukaan jopa halua kommunikoida toisiin pisteisiin. Henkilö voi kokea hankalaksi selvittää, kehen ottaa yhteys, jolloin keskustelun aloittaminen voi tuntua työläältä. Toisissa pisteissä työskenteleviin ohjelmistokehittäjiin voi olla vaikea luoda suhdetta pelkkien sähköisten viestimien välityksellä. Epämuodollisen kommunikaation puuttuessa, kaikenlainen päivittäinen kans-

18 13 sakäyminen toisissa pisteissä työskentelevien henkilöiden kanssa jää oletettavasti vähemmälle. Tärkeäksikin koettu epämuodollinen tieto saattaa jäädä välittämättä toisaalle. Myös muodollista tietoa saattaa jäädä välittämättä. Kehitystyön modulaarisuus voidaan nähdä myös uhkana. Jos hajautetut tiimit työskentelevät liian itsenäisesti ilman riittävää kommunikaatiota, voi seurauksena olla ongelmia myöhemmässä ohjelmiston osien integrointivaiheessa [OHÅ06]. Globaaliin projektiin liittyy usein erilaisia lainsäädäntöjä eri maissa, jotka saattavat monimutkaistaa kehitystyöhön liittyvää byrokratiaa. Teknologioiden kehittyessä koko ajan, eri maissa vallitsevat infrastruktuurierot ja -puutteet pienenevät. Mockusen ja Herbslebin [MoH01] mukaan eri tasoiset verkkoyhteydet, kehitysympäristöt ja testauslaboratoriot aiheuttanevat kuitenkin edelleen joitakin ongelmia globaaleissa projekteissa. Sosio-kulttuurinen etäisyys Globaaleissa projekteissa kaikki eivät kommunikoi äidinkielellään. Sosio-kulttuuriset erot aiheuttavat kieliongelmien lisäksi kulttuurieroista johtuvia ongelmia, jotka vaikeuttavat kommunikaatiota. Toisessa kulttuurissa normaalina pidettyä käytöstä voidaan toisessa pitää loukkaavana. Koulutus- ja kokemuserot voidaan varovaisesti nähdä innovatiivisuuden ja parhaiden käytäntöjen lähteenä. Conchúir et al. [OHÅ06] ovat kuitenkin sitä mieltä, että saavutettu hyöty on minimaalinen, koska kasvotonta kommunikaatiota on vähän. Hajautetuissa projekteissa työskentelevät kehittäjät voivat myös kokea alemman palkkatason kehittäjät uhkina, joille ei haluta jakaa tietoa. Kokemuserot lisäävät oletettavasti myös kustannuksia, kun erilaiset prosessit ja työskentelytavat täytyy kouluttaa. Taulukossa 4 esitetyt uhat on jaettu kolmeen ryhmään: ajallinen etäisyys, maantieteellinen etäisyys ja sosio-kulttuurinen etäisyys.

19 14 Ajallinen Maantieteellinen Sosio-kulttuurinen Aikaerot Ajalliset riippuvuudet Projektin koordinointi ja kontrolli Työtehtävien riippuvuus toisistaan Vähäinen epämuodollinen kommunikaatio Tärkeän tiedon välittämättä jättäminen Kehitystyön modulaarisuus Lainsäädännöt Infrastruktuurin puutteet tai erot eri maissa Kulttuuri- ja kielierot Kokemus- ja koulutuserot Taulukko 4: Hajautuksen uhat. 2.2 Lean-losoa Raman [Ram98] määrittelee Lean-käytännön mukaisen toiminnan sellaiseksi, jossa oikeat asiat valmistetaan oikeassa paikassa oikeaan aikaan ensimmäisellä kerralla. Samalla vältetään turhaa työtä ja ollaan avoimia muutokselle. Womackin ja Jonesin [WoJ96b] mukaan Lean-periaatteita noudattamalla tehdään enemmän vähemmällä. Toisin sanoen Lean-päämääränä on tuottaa asiakkaalle arvoa mahdollisimman pienillä resursseilla Toyota Production System Toyota Production System (TPS) on toisen maailman sodan jälkeen autoyhtiössä Toyota Motor Corporation kehitetty tuotantojärjestelmä. Eiji Toyoda (1913 ) ja Taiichi Ohno ( ) olivat huomanneet, ettei Japanin autoteollisuudessa voida

20 15 soveltaa kilpailijoilla käytössä olevia massatuotannon periaatteita. Prosesseja voitiin heidän mukaansa kuitenkin tehostaa vastaamaan kilpailijoiden tasoa. TPS-tuotantojärjestelmä perustuu Ohnon [Ohn88] mukaan täydelliseen hukan poistoon ja ehkäisyyn. Kaksi tärkeintä periaatetta ovat tuotannon keskeyttäminen välittömästi häiriötilanteissa (Jidoka, Stop-the-Line) ja vain tilattujen tuotteiden valmistaminen ja niiden toimittaminen juuri oikeaan aikaan (Just-in-Time, JIT). Tuotantoa pyritään jatkuvasti parantamaan laadultaan ja tuottavuudeltaan. TPS sai myöhemmin Womackin et al. [WJR90] kirjassa The Machine That Changed the World, nimen Lean Lean-losoan periaatteet Womack ja Jones [WoJ96a, WoJ96b] määrittelevät Lean-losoan viiden perusperiaatteen mukaiseksi: arvo (value), arvovirta (value stream), tasainen arvovirtaus (ow), imuohjaus (pull) ja täydellisyys (perfection, kaizen). Arvo määritellään aina asiakkaan tarpeen kautta. Esimerkiksi insinöörit ja asiantuntijat vääristävät arvoa lisäämällä tuotteeseen kompleksisuutta, jolla ei ole asiakkaan kannalta hyötyä. Arvovirta kuvaa kaikkia vaadittavia toimintoja, joilla asiakkaalle valmistetaan tuote. Kaikkien vaiheiden on kommunikoitava keskenään tai saatetaan tuottaa kaksoiskappaleita. Arvoa tuottavien toimintojen on edettävä tasaisesti. Yksiköt, jotka suorittavat yhtä tehtävää isoissa erissä, tulee poistaa prosessista. Tuotannonohjauksen tulee perustua imuohjaukseen, jolloin ei tuoteta mitään sellaista palvelua tai tuotetta, mitä asiakas ei ole vielä tilannut. Asiakas tässä yhteydessä tarkoittaa loppuasiakasta tai prosessin seuraavaa työvaihetta. Tähän liittyy tuotannonohjausstrategia JIT. JIT-periaatteella pyritään ehkäisemään turhia kus-

21 16 tannuksia, kuten tuotetun materiaalin varastointia. Jokaista valmistettua tuotetta kohden löytyy yksi tilaus, mikä tarkoittaa, että tehdään vain sitä, mitä asiakas pyytää ja vain silloin kun asiakas pyytää. Työntöohjaus (push) perustuu tilausten odotuksiin ja tällaista strategiaa tulee välttää. Täydellisen prosessin tavoittelu ei lopu koskaan: ajan lyhentäminen, kustannusten pienentäminen ja virheiden minimointi jatkuvat aina Lean-periaatteet ohjelmistotuotannossa Ramanin [Ram98] mielestä Lean soveltuu kaikkiin prosesseihin ja siten myös ohjelmistotuotantoon. Tätä alunperin teollisuudessa käyttöönotettua strategiaa onkin sovellettu menestyksekkäästi myös ohjelmostotuotannossa [Mid01, MiJ11]. Womackin ja Jonesin määrittelemät perusperiaatteet ovat Ramanin mukaan sovellettavissa valmistavasta teollisuudesta ohjelmistoteollisuuteen. Teollisuuden lajista riippumatta on tärkeää keskittyä tuottamaan asiakkaalle arvoa. Mitään teknologiaa ei pidä arvostaa vain teknologian itsensä vuoksi, vaan käyttötarkoitus on kartoitettava perusteellisesti. Ramanin mielestä esimerkiksi nopealla prototypoinnilla voidaan kartoittaa arvoa ohjelmistotuotannossa. Arvovirta käsittää kaikki toiminnot asiakkaan tilauksesta tuotteen luovuttamiseen. On tärkeää tunnistaa tällä välillä tapahtuvat toiminnot ja eritoten toiminnot, jotka tuottavat asiakkaalle arvoa. Näin voidaan havaita arvoa tuottamattomia toimintoja ja pyrkiä poistamaan niitä. Yhdeksi työkaluksi ohjelmistoprosessien parantamiseksi arvovirtojen tunnistamiseen Raman mainitsee SEI CMM -mallin. Tasainen arvovirtaus tarkoittaa tuotannon toimintojen etenemistä ilman turhia pysähdyksiä, takaisin virtauksia (back ow) ja virheitä. Arvovirtauksessa ei ole tällöin turhia jonoja. Ohjelmistuotuotannossa tämä vastaa Ramanin mielestä kehitysmallia sync-and-stabilize [CuS96]. Ihmisten työskentelyä yksilöinä ja rinnakkain