Hajautettu ohjelmistokehitys Lean-näkökulmasta
Hajautettu ohjelmistokehitys Lean-näkökulmasta: tapaustutkimus hukkatekijöistä Paula Mäenpää Helsinki 23.9.2011 Pro gradu -tutkielma HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta Fakultet Faculty Laitos Institution Department Matemaattis-luonnontieteellinen Tekijä Författare Author Paula Mäenpää Tietojenkäsittelytieteen laitos Työn nimi Arbetets titel Title 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 23.9.2011 96 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 2011. 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 ii Sisältö 1 Johdanto 1 1.1 Tutkimustilanteen kartoitus . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Tutkimuskysymykset . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Tutkielman rakenne . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Teoriatausta 2.1 2.2 2.3 3 Hajautettu ohjelmistokehitys . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1 Hajautettu ohjelmistokehitys käsitteenä . . . . . . . . . . . . . 5 2.1.2 Keskitetystä hajautettuun kehitykseen . . . . . . . . . . . . . 6 2.1.3 Hajautuksen organisointi . . . . . . . . . . . . . . . . . . . . . 7 2.1.4 Etuja hajautetussa ohjelmistokehityksessä . . . . . . . . . . . 8 2.1.5 Uhat hajautetussa ohjelmistokehityksessä . . . . . . . . . . . . 11 Lean-losoa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.1 Toyota Production System . . . . . . . . . . . . . . . . . . . . 14 2.2.2 Lean-losoan periaatteet . . . . . . . . . . . . . . . . . . . . 15 2.2.3 Lean-periaatteet ohjelmistotuotannossa . . . . . . . . . . . . . 16 2.2.4 Seitsemän Lean-pääperiaatetta ohjelmistotuotannossa . . . . . 17 2.2.5 Hukka: arvoa tuottamaton toiminta . . . . . . . . . . . . . . . 22 2.2.6 Tutkielmassa tarkasteltavat hukat . . . . . . . . . . . . . . . . 23 2.2.7 Lean-käsitteet hajautetussa ympäristössä . . . . . . . . . . . . 28 Ketterä kehitysmalli 2.3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . Perinteinen ja ketterä ohjelmistokehitysprosessi . . . . . . . . 32 33 iii 2.3.2 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.3.3 XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.3.4 Agile manifeston arvojen ja Lean-periaatteiden yhteys . . . . . 38 2.3.5 Ketterät käytännöt kommunikaatio-ongelmien ratkaisuna . . . 40 3 Kokeellinen tutkimus 41 3.1 Miten ongelmaa tutkitaan . . . . . . . . . . . . . . . . . . . . . . . . 41 3.2 Tutkimuskohteen esittely . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.3 Tiedon keräämisen välineet . . . . . . . . . . . . . . . . . . . . . . . . 44 4 Empiiriset tulokset 4.1 4.2 4.3 4.4 45 Tiimien työskentelytavat . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.1.1 Prosessimalli . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.1.2 Kanban-menetelmä . . . . . . . . . . . . . . . . . . . . . . . . 48 Työtapojen tehokkuus . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Projektissa ilmenneet hukat . . . . . . . . . . . . . . . . . . . 50 4.2.2 Yhteistoiminta ja kommunikaatio projektissa . . . . . . . . . . 55 Arvovirtauksen tehokkuus . . . . . . . . . . . . . . . . . . . . . . . . 70 4.3.1 Työnkulku koko projektin ajalta . . . . . . . . . . . . . . . . . 71 4.3.2 Yhden tehtävän työnkulku . . . . . . . . . . . . . . . . . . . . 71 Projektin onnistuminen . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5 Johtopäätökset 5.1 50 Empiiriset tapaustutkimuksen tulokset 74 . . . . . . . . . . . . . . . . . 74 iv 5.2 5.1.1 Työtapojen tehokkuus 5.1.2 Arvovirtauksen tehokkuus 5.1.3 Hajautetun projektin Lean-näkökulma 5.3 . . . . . . . . . . . . . . . . . . . . 78 79 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Ehdotus hajautettujen projektien tarkistuslistaksi . . . . . . . 80 Tutkimuksen rajoitukset . . . . . . . . . . . . . . . . . . . . . . . . . 6 Yhteenveto 6.1 75 . . . . . . . . . . . . . Suosituksia 5.2.1 . . . . . . . . . . . . . . . . . . . . . . Jatkotutkimuksen aiheita . . . . . . . . . . . . . . . . . . . . . . . . . Lähteet Liitteet 1 Sanasto 2 Haastattelukysymykset 85 86 88 89 1 1 Johdanto 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. 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. Leanlosoan 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- 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 1. 1. 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- 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- 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. 2.1.1 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. Lokaali (DSD) Osta Luo Globaali (GSD) Lokaali Globaali ulkoistaminen ulkoistaminen Lokaali, yrityksen Globaali, yrityksen omat resurssit 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ä. 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. 2.1.2 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ä. 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. 2.1.3 Hajautuksen organisointi Menestyksekäs hajautettu projekti vaatii Ågerfalkin et al. [ÅgF06] mukaan erityisesti toimivaa koordinointia, kontrollia ja kommunikaatiota. Hajautetussa projek- 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ä. 2.1.4 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- 9 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. 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ä. 10 Ei todetut edut Gumm [Gum07] tuli empiirisessä tutkimuksessaan siihen tulok- seen, 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. 11 Osittain todettu etu Kehityskustannusten minimointi Kehitys lähellä markkina-aluetta ja asiakasta Kehitystyön modulaarisuus Uudet ja isommat työvoimaresurssit Paikallisen kulttuurin erityisvaatimuksiin vastaaminen Ei todettu etu Työskentely rauhassa ja pienemmän paineen alla Projektin kesto kalenteriajassa lyhenee Parhaat käytännöt, innovatiivisuus Taulukko 3: Hajautetun kehityksen oletetut edut. 2.1.5 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ä aikaerois- ta. 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 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 Herb- slebin 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ä edelleen 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- 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. 14 Ajallinen Aikaerot Ajalliset riippuvuudet Maantieteellinen 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 Sosio-kulttuurinen 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. 2.2.1 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 (19121990) olivat huomanneet, ettei Japanin autoteollisuudessa voida 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 Changed the World, The Machine That nimen Lean. 2.2.2 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- 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. 2.2.3 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 17 toimivien tiimien jäseninä synkronoidaan (synchronize) jatkuvasti. Lisäksi ohjelmisto vakautetaan (stabilize) jaksoittain projektin edetessä, eikä vasta kerralla projektin lopussa. Imuohjausta voidaan havainnollistaa ohjelmistotuotannossa esimerkiksi käyttämällä Kanban-menetelmää. Menetelmän avulla voidaan havaita ja korjata arvovirtauksen mahdolliset tukoskohdat. Imuohjaukseen liittyvä JIT-periaate ei ole Ramanin mielestä sellaisenaan sovellettavissa ohjelmistotuotantoon. Ohjelmistoteollisuudessa on tavallista, että tuotteisiin lisätään ominaisuuksia, joista kehittäjät ajattelevat asiakkaan olevan kiinnostunut. Loppuasiakkaalle ei kuitenkaan saisi tuottaa mitään sellaista, mitä ei olla erityisesti tilattu. Ohjelmistosta saattaa muussa tapauksessa kasvaa liian suuri ja monimutkainen. Jatkuva pyrkimys lähemmäksi täydellisyyttä poistamalla hukkaa liittyy ohjelmistotuotannossa SEI CMM -mallin korkeimpaan tasoon 5. Sen pääperiaatteet ovat jatkuva prosessien parantaminen ja virheiden määrän minimoiminen. 2.2.4 Seitsemän Lean-pääperiaatetta ohjelmistotuotannossa Mary ja Tom Poppendieck [PoP06] summaavat Lean-losoan ohjelmistokehityksessä seitsemään pääperiaatteeseen: 1. Poista hukka (Eliminate waste) 2. Luo kokonaisvaltaista laatua (Build quality in) 3. Tehosta oppimista (Create knowledge) 4. Päätä mahdollisimman myöhään (Defer commitment) 5. Toimita mahdollisimman nopeasti (Deliver fast) 18 6. Arvosta ihmisiä (Respect people) 7. Optimoi kokonaisuus (Optimize the whole) Poista hukka Jatkuva pyrkimys hukan poistamiseksi on Lean-losoan ydin. Muilla periaatteilla on vain vähäinen merkitys, mikäli hukkaa ei saada poistettua. Hukan tunnistamisesta pitäisi tehdä kaikille projektissa työskenteleville arkipäiväinen asia. Ei riitä, että ohjelmistokehittäjät pystyvät poistamaan hukan toiminnastaan, vaan myös muiden projektin sidosryhmien on sitouduttava tunnistamaan ja poistamaan hukkaa. Tässä tutkielmassa keskitytään eritoten listan ensimmäiseen pääperiaatteeseen. Seuraavassa luvussa 2.2.5 käsitellään hukka-käsitettä tarkemmin. Luo kokonaisvaltaista laatua Laatua on vaikea määritellä tyhjentävästi. Ohjel- mistokehityksessä ehkä käytetyin malli laadun arviontiin on kypsyysmalli SEI CMM. Voidaan ajatella, että mitä ylemmällä tasolla työskennellään, sitä lähempänä ollaan Lean-ajatusmallin mukaista toimintaa. Asiakkaan on voitava luottaa koko ohjelmistoon, ei vain joihinkin sen osiin. Koodin jatkuva testaus, integrointi ja refaktorointi ovat oleellisia asioita kokonaisvaltaisen laadun saavuttamiseksi. Testivetoisessa kehityksessä (Test Driven Development, TDD) testit kirjoitetaan ennen ohjelmakoodia. Lean-losoan mukaisesti uuttaa koodia ei lisätä järjestelmään, ennen kuin vanha on testattu ja korjattu. Virheen löytyessä, muu toiminta keskeytetään siksi aikaa, kunnes koodi on korjattu. Virheiden lisääminen virhelistoihin tuottaa jonoja, jotka ovat osittain tehtyä työtä eli hukkaa. Koodin integrointi täytyy tehdä tarpeeksi usein, esimerkiksi kerran päivässä, jotta integroinnista itsestään ei tule liian isoa työvaihetta. Refaktoroinnilla vältytään koodin duplikaateilta, jotka ovat ylimääräistä koodia eli hukkaa. Koodin testaus, kääntäminen, 19 integrointi ja kaikki rutiininomainen toiminta on mahdollisuuksien mukaan automatisoitava. Testaus ja simulointi ovat esimerkkejä dynaamisista laadunvarmistuskäytännöistä. Staattisissa laadunvarmistuskäytännöissä ohjelmakoodia ei suoriteta, vaan laatua varmistetaan esimerkiksi tarkastelemalla dokumentaatiota [HVZ04]. Leanperiaatteen mukaan kokonaisvaltaisen laadun kannalta olisi tärkeää varmistaa, että varsinkin dynaaminen laadunvarmistus on sisällytetty prosessiin koko kehityksen ajan. Ketterissä menetelmissä laadun varmistus on enemmän Lean-periaatteen mukaista kuin vesiputousmallissa, koska kaikkiin iteraatiohin ja koko arvovirtaan on sisällytetty dynaamista laadunvarmistusta. Vesiputousmallissa koodin testaamiseen päästään vasta erillisessä testausvaiheessa, kun ohjelma on käytännössä valmistunut. Kaikista laatutekijöistä täytyisi kuitenkin huolehtia koko ohjelmistokehityksen ajan ja laatua täytyy pyrkiä parantamaan jatkuvasti. Tehosta oppimista Valmistavassa teollisuudessa työ on voitu standardoida ja jakaa niin pieniin osiin, että tehtävästä selviää ilman erityistä osaamista. Toisin kuin linjatyö, ohjelmistokehitys on jatkuvaa uuden oppimista. Toimintaympäristöä prosesseineen ja ihmisiä toimintatapoineen on käytännössä mahdotonta normittaa. Jokaisen projektiin liittyvän henkilön on omaksuttava jatkuvasti uusia asioita muun muassa valmistettavasta tuotteesta. Ongelmanratkaisutaitojen jatkuva parantaminen tehostaa oppimista. Ongelmanratkaisumallilla PDCA (Plan-Do-Check-Act) voidaan varmistaa, että koko projektin ajan pyritään hyödyntämään tietoa mahdollisimman tehokkaasti [PoP06]. Aluksi tunnistetaan ja analysoidaan ongelma (Plan), jonka jälkeen kehitetään ja testataan mahdollinen ratkaisu ongelmaan (Do). Lopuksi mitataan, kuinka tehokas ratkaisu on ja voidaanko sitä tehostaa vielä jotenkin (Check) ja sovelletaan ratkaisu käytännössä (Act). Tämän jälkeen päädytään taas suunnittelemaan. Kuvassa 2 on 20 havainnollistettu sykli, joka jatkuu koko projektin ajan. Kuva 2: Ongelmanratkaisumalli ja jatkuvan parantamisen ajattelutapa PDCA. Lisäksi pariohjelmointi, Wikin ylläpito, dokumentaatiot ja selkeästi kommentoitu ohjelmakoodi ovat menetelmiä ohjelmistokehittäjien oppimisen tehostamiseksi. Pariohjelmoinnilla hankittu tieto koodista on useamman kuin yhden kehittäjän hallussa. Wikiin lisätty tieto kasvaa vähitellen ja se on helposti kaikkien käytettävissä. Dokumentaatiot ja koodin kommentit selventävät ja auttavat hahmottamaan jo tehtyä työtä. Ohjelmistokehitykseen liittyy tunnetusti paljon epävarmuutta [SMÅ10]. Tulevaisuuden ollessa epäselvä, muun muassa vaatimukset saattavat muuttua projektin edetessä. Mahdollisimman myöhäiseksi jätetyillä päätöksillä varmistetaan, että ratkaisut perustuvat tosiasioihin eivätkä arvailuihin tai ennustuksiin. Näin vältetään kiireellä tehtyjä, mahdollisesti puutteellisia, päätöksiä. Optimaalisen ratkaisun etsiminen vaihtoehtoja rajaamalla (set-based concurrent engineering) mahdollistaa päätösten jättämisen viime hetkeen [SWL99]. Mahdollisia suunnitteluratkaisuja (desing engineering) ja toteutusratkaisuja (manufacturing engineering) tutkitaan rinnakkaisesti eri tiimeissä ja niitä karsitaan vähitellen, kunnes päädytään sopiviin suunnittelu- ja toteutuspäätöksiin. Rinnakkaisuuden ansiosta eri vaihtoehtoja pystytään tutkimaan nopeasti ja päätökset voidaan tehdä 21 myöhään. Tällainen lähestymistapa saattaa olla kalliimpi kuin lineaarinen yhden vaihtoehdon tarkasteleminen kerrallaan (point-based serial engineering), mutta ajallisesti kriittisissä tapauksissa välttämätön. Toimita mahdollisimman nopeasti Ketterien kehitysmallien yleistyttyä asi- akkaat ovat tottuneet tiheätahtisiin toimituksiin. Toiminnallisuuksiin sijoitetulla pääomalla on sitä suurempi tuotto (Return on Investment, ROI), mitä aikaisemmin ne saadaan käyttäjien hyödynnettäviksi. Lisäksi lyhyiden iteraatioiden mahdollistama ohjelmiston nopea toimittaminen asiakkaalle tarjoaa kehitystiimeille nopeasti arvokasta palautetta. Mitä nopeammin tuote toimitetaan, sitä vähemmän asiakas ehtii muuttamaan mieltään. Vesiputousmallin mukainen toimitus voi kestää useita kuukausia, ennen kuin asiakkaalle toimitetaan mitään. Tällöin on mahdollista, että asiakas tulee jossain vaiheessa kehitystyön aikana muuttamaan mieltään jo tehdyn toiminnallisuuden osalta. Muutosten tekeminen alentaa liikevoittoa. Ketterien kehitysmallien mukaisesti kehitystyön kestäessä vain 14 viikkoa, on todennäköisempää, että asiakas ei ehdi muuttamaan mieltään ennen toimitusta. Lyhyet iteraatiot varmistavat myös, että ollaan täyttämässä asiakkaan tämän hetkistä tarvetta, eikä tehdä pari kuukautta sitten sovittuja asioita. Toimituksen tehokkuutta voidaan tarkastella jonoteorian avulla [PoP06]. Littlen lain mukaan läpimenoaika voidaan arvioda oheisella kaavalla, jossa kaavan yläosa kuvaa hukkaa (Work in Process, WIP) ja alaosa virtaa: läpimenoaika = keskeneräisten töiden määrä keskimääräinen valmistumistahti Mitä lyhyempi läpimenoaika on, sitä tehokkaampi on myös arvovirtaus. Läpimenoa voidaan tehostaa jakamalla työ pieniin eriin ja minimoimalla keskeneräisten töiden määrää. 22 Arvosta ihmisiä Ihmisiä tulee kunnioittaa ja arvostaa tasa-arvoisina työnteki- jöinä. Tehtävään sopivaksi valitulla henkilöllä pitää ajatella olevan tarpeeksi osaamista ja päätösvaltaa itsenäiseen työskentelyyn. Päätöksiä ei pidä tehdä heidän puolestaan, vaan on luotettava kaikkien pyrkivän samaan yhteiseen päämäärään tehokkaasti työskennellen. On Lean-periaatteen vastaista ajatella, että kaikkeen löytyy yksi paras ratkaisu [PoP06]. Kaikkia työskentelytapoja voidaan parantaa ja kehittää, mutta tehostamisen täytyy lähteä työtä tekevistä ihmisistä itsestään. Optimoi kokonaisuus Kokonaisuuden optimointi tarkoittaa toimintatapoja, joil- la pyritään tehostamaan koko arvovirtaa, ei vain joitakin tiettyjä toimintoja tai tiimejä. Jokaisen toiminnon on tähdättävä samaan päämäärään. Yhtä lailla jokaisen tiimin on työskenneltävä kohti yhteistä tavoitetta. Jos jotakin tiettyä prosessin vaihetta aletaan optimoimaan, on mahdollista, että se tehdään toisten vaiheiden kustannuksella. Projektin kokonaisuutta voidaan analysoida arvovirtakartalla (value stream map) [PoP06]. Karttaa varten päätetään alku- ja loppupisteet, joiden väliin sijoitetaan tuotteen valmistukseen tarvittavia toimintoja. Toisin sanoen arvovirtakartta on aikajana, joka sisältää askeleet konseptista valmiiseen tuotteeseen. Valmiista kartasta voidaan päätellä turhia toimintoja, sahausliikkeitä toimintojen välillä ja viivästyksiä eli kartoitetaan erilaisia hukkia. 2.2.5 Hukka: arvoa tuottamaton toiminta Womack ja Jones [WoJ96b] määrittelevät kaikki tuotekehityksen toiminnot kolmeen luokkaan: arvoa tuottavat (value adding), arvoa tuottamattomat (non-value-adding) ja vaaditut arvoa tuottamattomat toiminnot (required non-value adding). Leanlosoan mukaan tuotantoprosesseja tehostetaan poistamalla niistä erityyppisiä hukkia eli arvoa tuottamattomia toimintoja. Mutta mitä arvoa tuottava toiminta on? 23 Pichlerin [Pic08] mukaan voidaan kysyä seisestä toiminnasta? Olisinko asiakkaana valmis maksamaan ky- Jos vastaus on kyllä, on todennäköistä, että toiminta on arvoa tuottavaa. Toisaalta Womackin ja Jonesin määrittelemät vaaditut arvoa tuottamattomat toiminnot voivat olla myös sellaisia, jotka eivät asiakkaan mielestä tuota arvoa, mutta joita ei voida poistaa. Tällaisia toimintoja voivat olla esimerkiksi lakien ja sopimusten määrittelemät asiat. Kirjallisuudessa hukaksi määritellään tyypillisesti vain arvoa tuottamaton toiminta (muda). Caldwellin [Cal08] mielestä hukkaa ovat myös epäsäännöllisyys (mura) ja ylikuormitus (muri). Tässä tutkielmassa hukkaa tarkastellaan arvoa tuottamattomana toimintana. Epäsäännöllisyyden ja ylikuormituksen katsotaan olevan hukkaan vahvasti liittyviä käsitteitä. Womackin [Wom06] mielestä epäsäännöllisyys ja ylikuormitus ovat perimmäiset syyt arvoa tuottamattoman toiminnan syntyyn. Hänen mielestään on ensisijaisen tärkeää kiinnittää huomiota työn epäsäännöllisyyden ja ylikuormituksen poistamiseen tarkasteltaessa mitkä toiminnot eivät tuota lisäarvoa. Esimerkiksi turha vaihtelu työtavoissa [mura] aiheuttaa ihmisten ylikuormitusta [muri], josta voi syntyä virheitä [muda]. Jos työn epäsäännöllisyyteen ja ylikuormitukseen ei kiinnitetä erityistä huomiota, saatetaan Womackin mukaan tuotantoprosesseihin palauttaa jo aiemmin poistettuja arvoa tuottamattomia toimintoja. 2.2.6 Tutkielmassa tarkasteltavat hukat Lean-losoan tärkein periaate on kyky tunnistaa erilaisia hukkia. Arvon tunnistamisen jälkeen suunnitellaan toimintatapa löytää erilaisia hukkia. Kun hukka on kohdennettu, voidaan keskittyä sen poistamiseen. Seuraavassa on listattu seitsemän hukkaa (1.7.) Poppendieckien mukaan sekä kaksi muuta tutkielman kannalta oleellista hukkaa (8.9.). Seitsemän ensimmäisen hukan lähteenä käytetään Poppendieck- 24 ien [PoP06] teosta. 1. Siirtäminen (Handos) 2. Uudelleen opettelu (Relearning) 3. Virheet (Defects) 4. Osittain tehty työ (Partially done work) 5. Ylimääräiset ominaisuudet (Extra features) 6. Tehtävien vaihtelu (Task switching) 7. Odottelu (Delays) 8. Tehoton kommunikaatio (Ineective communication) 9. Tiedon hukka (Knowledge waste) Siirtäminen Siirtämisellä tarkoitetaan erityisesti työtehtävien siirtämistä hen- kilöltä toiselle. Töiden siirtäminen aiheuttaa usein viivästyksiä, tietokatkoksia ja väärinymmärryksiä. Erityisesti tarpeeton siirtäminen on hukkaa. Tiedon siirtämistä voidaan tehdä dokumentaation kautta tai kommunikoimalla kasvotusten. Ei-kasvotusten tapahtuvassa kommunikaatiossa, esimerkiksi sähköpostin lukemisessa, häviää tärkeää sanatonta tietoa. Myös kasvotusten tapahtuvassa tiedon siirtämisessä henkilöltä toiselle syntyy hukkaa. Ohjelmistokehittäjän siirtäessä ohjelmoimansa koodin testaajalle, syntyy hukkaa. Testaaja ei voi olla tietoinen koodin sisällöstä ennen kuin lukee sen dokumentaation, jolloin syntyy viivästyksiä testaajan selvittäessä koodia itselleen. 25 Uudelleen opettelu Asioiden uudelleen opettelu tuottaa hukkaa. Pahimmassa tapauksessa palataan huomaamatta kokeilemaan jotain jo aiemmin toimimattomaksi todettua asiaa uudestaan. Jo päätetyistä asioista tulisi pitää kirjaa. Kirjanpito ei saa olla kaiken kattavaa ja massiivista, vaan dokumentaation täytyy olla hyödyllistä ja tarkkaan harkittua. Poppendieckit ovatkin sitä mieltä, että aiemmin tuttujen ja unohdettujen asioiden uudelleen keksiminen on kenties paras määritelmä uudelleen tekemiselle kehitystyössä. Jos ihmisten osaamista ei hyödynnetä parhaalla mahdollisella tavalla, aiheutetaan vielä merkittävämpää hukkaa kuin asioiden uudelleen opettelulla. Virheet Virheet ohjelmakoodissa ovat yleisiä. Niiden määrää ja laatua voidaan kuitenkin pyrkiä minimoimaan oikeilla toimintatavoilla. Lean-näkökulmasta testausta täytyy tehdä usein ja alusta asti, jotta virheiden löytäminen ei jää prosessin loppupäähän. Erinäisten vikalistojen ylläpitämistä täytyy välttää. Virheiden korjaaminen suoritetaan heti niiden löydyttyä ja virheelle luodaan testi, jottei samanlaisia ongelmia enää synny. Näin toimimalla vältytään Poppendieckien mukaan rutiininomaiselta virheiden löytämiseltä veriointivaiheessa. Jos ohjelmisto saapuu veriontivaiheeseen jatkuvasti täynnä virheitä, on koko prosessi viallinen. Testaus ei ole heidän mielestään virheiden korjaamista. Osittain tehty työ Työ on osittain tehtyä, mikäli sen osia on jonoissa tai varas- toissa. Esimerkiksi testaamaton koodi on osittain tehtyä työtä, sillä se on odottamassa pääsyä testaukseen. Lean-periaatteen mukaan kehitystyön täytyy edistyä alusta loppuun sujuvasti ja tehokkaasti. Lopputuotteen koodin tulee olla integroitu, testattu, dokumentoitu ja käyttöön otettava. Ainoa tapa saavuttaa tämä, on Poppendieckien mukaan jakaa työ lyhyisiin iteraatioihin. Yksi iteraatio sisältää kaikki luetellut vaiheet. Kun jokainen vaihe on tarpeeksi pieni, on todennäköisempää, että prosessi etenee tehokkaammin ja työ valmistuu nopeammin. 26 Ylimääräiset ominaisuudet Lopputuotteesta löytyvät ylimääräiset ominaisuu- det ovat yksi ohjelmistotuotannon suurimmista lähteistä hukalle. Vain noin viidesosa tyypillisen tilaustyönä tehdyn ohjelmiston ominaisuuksista ja toiminnallisuuksista on säännöllisessä käytössä ja noin kahta kolmasosaa ominaisuuksista käytetään harvakseltaan. Ylimääräinen koodi monimutkaistuu kasvaessaan ja sen ylläpitämisestä tulee kalliimpaa ja ongelmallisempaa. Jos ominaisuudelle ei ole sen hetkistä aitoa taloudellista etua, sitä ei tulisi valmistaa. Aikainen spesikaatio saattaa Poppendieckien mukaan lisätä ylimääräisiä ominaisuuksia. Kun asiakkaalta pyydetään listausta kaikista tarvittavista ominaisuuksista, on todennäköistä, että myös vähemmän tärkeät ominaisuudet tulevat listatuiksi. Asiakas ei välttämättä tiedä projektin alussa, mitkä ominaisuudet todella ovat tärkeitä, joten on tärkeää pystyä tekemään tällaiset päätökset mahdollisimman myöhään. Tehtävien vaihtelu Tehtävien vaihtelu vie aikaa ja häiritsee keskittymistä. Vaih- don jälkeen tehtävään täytyy syventyä uudestaan. Eri asioiden tekeminen samaan aikaan ohjelmistokehityksessä ei useinkaan ole järkevää vaan aiheuttaa turhaan hukkaa. Odottelu Odottelu lienee yksi suurimmista hukan aiheuttajista. Tarvittavan tie- don pitäisi Lean-losoan mukaan olla saatavissa juuri oikeaan aikaan. Liian aikainen tieto voi muuttua ja liian myöhäinen tieto voidaan joutua jättämään huomiotta. Monimutkaisen byrokratian vuoksi päätösten tekeminen on hidasta, mikä aiheuttaa paljon odottelua. Kehitystyötä hidastaa myös ajoittaisen avun tarve toisilta henkilöiltä. Tarvittava henkilö ei ole aina heti tavoitettavissa tai vapaana, joten hänen apuaan joudutaan odottamaan. Ihmisten lisäksi odottelua voivat aiheuttaa muun muassa laitteistohankinnat. 27 Esimerkiksi testaukseen voidaan tarvita laitetta, jossa ohjelmistoa tullaan käyttämään. Odottelu vaikuttaisi olevan hukka, jota on suhteellisen vaikea kontrolloida. Tehoton kommunikaatio Vääräntyyppinen kommunikaatio aiheuttaa hukkaa. Esimerkiksi teknisistä yksityiskohdista keskusteleminen sähköpostin välityksellä on tehotonta. Graebschin et al. [GSL07] tekemässä tutkimuksessa huomattiin, että kyseiseen toimitukseen meni sähköpostitse aikaa kolmesta tunnista yli vuorokauteen. Tapaamisella oltaisiin päästy nopeampaan yhteisymmärrykseen. Kommunikaation täytyy olla myös laadultaan ja määrältään tehokasta. Tiedon hukka Arvovirtaukset ohjelmistokehityksessä koostuvat MacManuksen [Mac05] mukaan enemmän tiedosta kuin materiasta. Hänen mielestään arvovirtauksesta on siten löydettävissä tietoon liittyviä hukkia. Poppendieckien määrittelemät seitsemän hukkaa voidaan ajatella myös tiedon hukkana seuraavasti: 1. Siirtäminen: tiedon tarpeetonta siirtämistä ihmisten, organisaatioiden ja järjestelmien välillä. 2. Uudelleen opettelu: tiedon liiallinen prosessointi. 3. Virheet: virheelliset tiedot ja raportit. 4. Osittain tehty työ: käyttämätön tai työn alla oleva tieto. 5. Ylimääräiset ominaisuudet: tuotetaan ja jaetaan enemmän tietoa kuin tarvitaan. 6. Tehtävien vaihtelu: tarpeeton liikkuminen (fyysinen tai työpisteellä eri järjestelmien välillä liikkuminen). 7. Odottelu: ei saatavissa olevan tiedon aiheuttamaa joutoaikaa. 28 2.2.7 Lean-käsitteet hajautetussa ympäristössä Lean-elementeillä on joitakin erityispiirteitä hajautetussa ympäristössä, jotka selitetään seuraavissa kappaleissa. Kaikki kohdat ovat kirjoittajan omia arvioita. Poista hukka Tunnistettu ja poistettu hukka pisteessä A, mikä vaikuttaa myös pisteeseen B, on poistettava myös pisteessä B. Tällaisia voivat olla asioiden ja ihmisten odottelu pisteiden välillä, päällekkäiset työt, integroimaton koodi ja kaikenlaiset ongelmat kommunikaatiossa pisteiden välillä. Jos piste A onnistuu menestyksekkäästi poistamaan hukkaa tiimien välillä aiheuttavat seikat, voi piste B palauttaa ne omalla toiminnallaan, mikäli B ei pyri aktiivisesti poistamaan kyseistä hukkaa. Siirtäminen Tehtävä voidaan siirtää pisteestä toiseen esimerkiksi sähköpostin kautta. Koska hajautetussa ympäristössä siirtäminen on usein kasvotonta, kasvaa riski aiheuttaa siirtämisestä aiheutuvaa hukkaa. Uudelleen opettelu Tiedon kulussa pisteiden välillä on usein viivästyksiä. Jokin uusi asia on saatettu havaita toimimattomaksi pisteessä A, mutta tietoa ei olla heti välitetty pisteeseen B. Tällöin piste B opettelee huonoksi havaittua asiaa turhaan, kun tieto toimimattomuudesta olisi ollut jo saatavilla. Koko projektin kannalta B opettelee asiaa uudelleen. Virheet Virheitä syntyy aina sekä keskitetyssä että hajautetussa kehityksessä. Tiedon virheellisyys saattaa aiheuttaa isompia ongelmia hajautetussa ympäristössä, jos kommunikointi on tehotonta ja väärinymmärryksiä ei huomata ajoissa. Osittain tehty työ Hajautetuissa projekteissa eri pisteet integroivat luomansa koodin yhteiseen koodikantaan. Integroimaton koodi, toisin sanoen viivästetty in- 29 tegrointi (delayed integration), on osittain tehtyä työtä. Jos eri pisteiden koodia ei integroida tarpeeksi usein, aiheutetaan sahausliikettä. Koodi ei olekaan enää integroitavissa yhteiseen koodikantaan, koska integrointia viivästettiin, jolloin koodia täytyy ensin muokata uudestaan. Ylimääräiset ominaisuudet Tiedon kulku pisteiden ja asiakkaan välillä on tär- keää ehkäistäessä ylimääräisiä ja turhia ominaisuuksia. Jokaisen pisteen on tiedettävä, mitä asiakkaan kanssa on sovittu, jottei eri pisteissä tehdä omia versioita samasta ominaisuudesta. Kun tieto lisääntyy, pienenee päällekkäisen työn tekemisen riski. Tehtävien vaihtelu Koska kehitys on hajautettua, joudutaan toisten tiimien kans- sa kommunikoimaan sähköisesti. Tämä saattaa aiheuttaa tehtävien vaihtelua esimerkiksi sähköpostin ja tekeillä olevan tehtävän välillä enemmän kuin keskitetyssä kehityksessä. Odottelu Fyysinen etäisyys aiheuttaa odottelua, kun toisen tiimin henkilöitä ei tavoiteta heti. Globaalissa hajautuksessa myös aikaerot aiheuttavat odottelua, kun eri tiimit työskentelevät eri rytmissä. Tehoton kommunikaatio Kommunikaatiota on oltava sopiva määrä. Hajaute- tussa kehityksessä saatetaan välittää tietoa liian vähän, jos tiedon välityksen tarvetta ei aktiivisesti tiedosteta. Toisaalta saatetaan liioitella ja välittää sellaistakin tietoa, mitä toisessa pisteessä ei sillä hetkellä tarvita. Tasapainon löytäminen voi olla aluksi vaikeaa. Myös kommunikaation laatuun on kiinnitettävä huomiota, koska kommunikaatio on usein kasvotonta. Viestin sisältö on yhtä tärkeää kuin kommunikaation määrä. 30 Tiedon hukka Hajautetussa ympäristössä työskentely on osittain kasvotonta, jolloin tieto välitetään dokumentaation välityksellä. Jotta ei pääse tapahtumaan väärinkäsityksiä, on dokumentaation laatuun kiinnitettävä erityistä huomiota. Taulukkoon 5 on koottu ensimmäisen Lean-periaatteen poista hukka erityis- piirteitä hajautetussa ympäristössä. Lean-kehityksen periaate Hajautuksen kannalta erityistä 1. Poista hukka Kommunikointi eri pisteiden välillä: tiedostetaan tarvittaessa hukka kaikissa pisteissä 1.1 Siirtäminen Kasvoton tiedon tai työn siirtäminen toiselle 1.2 Uudelleen opettelu Tiedon kulku pisteiden välillä 1.3 Virheet Kommunikaation tärkeyden korostuminen 1.4 Osittain tehty työ Viivästetty integraatio 1.5 Ylimääräiset ominaisuudet Tiedon kulku: kaikilla heti sama tieto 1.6 Tehtävien vaihtelu Kommunikointi toisiin pisteisiin 1.7 Odottelu Aikaerot ja fyysinen etäisyys 1.8 Tehoton kommunikaatio Kommunikaation määrä ja laatu 1.9 Tiedon hukka Kasvoton tiedon kulku Taulukko 5: Lean-periaatteen poista hukka erityispiirteitä hajautetussa ym- päristössä. Luo kokonaisvaltaista laatua Hajautetuissa projekteissa korostuu jatkuvan in- tegroinnin tärkeys. Sen lisäksi, että kehittäjä kääntää, testaa ja integroi koodin paikallisesti, tulee koodi integroida mahdollisimman usein myös tiimien yhteiseen koodikantaan. 31 Tehosta oppimista Oppimista tulee pyrkiä tehostamaan yhteisillä kokouksilla ja varmistamalla, että tieto kulkee mahdollisimman sujuvasti eri pisteiden välillä. Näin tehostetaan nopeaa oppimista myös hajautetuissa projekteissa. Päätä mahdollisimman myöhään Eri tiimeissä voidaan tarkastella rinnakkain useita eri suunnittelu- ja toteutusvaihtoehtoja. Päätösten teko voidaan jättää mahdollisimman myöhäiseksi, kun vaihtoehtoja on alusta asti paljon. Tämä voidaan toteuttaa keskitetyssäkin kehityksessä, mutta hajautetut projektit ovat usein suurempia, jolloin useampi henkilö voi tutkia eri vaihtoehtoja. Toimita mahdollisimman nopeasti Nopea toimitus on joidenkin lähteiden mu- kaan tehokkaampaa hajautetuissa projekteissa ympärivuorokautisen työskentelyn vuoksi. Arvosta ihmisiä Kun kommunikoidaan kasvottomasti, toisiin tiimiläisiin voi olla vaikea luottaa. Toinen tiimi saatetaan helposti ajatella ulkojoukoksi, kun oma tiimi ajatellaan sisäjoukkona. Tällaisilla asenteilla vahvistetaan ajattelumallia me vastaan he. Maantieteellisesti toisaalla sijaitsevan tuntemattoman ihmisen arvostaminen saattaa olla vaikeaa senkin vuoksi, ettei hänen osaamistaan tiedetä. Optimoi kokonaisuus Työskentelyrytmi eri tiimeissä tulisi olla synkronoitu. Ke- hityssyklien synkronointi tahdistaa tiimien työskentelyä, jolloin optimoidaan koko hajautetun projektin etenemistä. Taulukkoon 6 on koottu Lean-periaatteiden 27 erityispiirteitä hajautetussa ympäristössä. 32 Lean-kehityksen periaate Hajautuksen kannalta erityistä 2. Luo kokonaisvaltaista laatua Jatkuva integrointi yhteiseen koodikantaan 3. Tehosta oppimista Tiedon kulku pisteiden välillä 4. Päätä mahdollisimman myöhään (Usein) enemmän henkilöitä suunnittelu- ja toteutusratkaisuja rajaamaan 5. Toimita mahdollisimman nopeasti Työskentely ympärivuorokautisesti 6. Arvosta ihmisiä Luottamuspula ja asenteet 7. Optimoi kokonaisuus Kehityssyklit eri pisteissä Taulukko 6: Lean-periaatteiden 27 erityispiirteitä hajautetussa ympäristössä. 2.3 Ketterä kehitysmalli Ketterälle ohjelmistokehitykselle on lähes mahdotonta tarjota kattavaa ja kaikkien hyväksymää määritelmää. Kaikilla ketterillä kehitysmalleilla on kuitenkin Agile Manifeston [Agi01] mukaan neljä yhteistä arvoa: • yksilöiden ja vuorovaikutuksen arvostaminen ennen prosesseja ja työkaluja, • toimiva sovellus ennen kokonaisvaltaista dokumentaatiota, • asiakasyhteistyö ennen sopimusneuvotteluita ja • muutoksiin reagoiminen ennen suunnitelman noudattamista. Lisäksi ketterät kehitysmallit noudattavat 12:ta periaatetta, joihin sisältyvät muuan muassa tiheät toimitussyklit, muuttuvien vaatimusten hyväksyminen ja kestävän kehityksen suosiminen ylläpitämällä tasaista työtahtia. 33 2.3.1 Perinteinen ja ketterä ohjelmistokehitysprosessi Ohjelmistotuotannon osatehtäviin sisältyy yleisesti määrittely, suunnittelu, toteutus, testaus sekä käyttö ja ylläpito. Ohjelmistojen kehitysmallit voidaan määritellä sen mukaan, miten edellä mainitut vaiheet suoritetaan. Perinteisessä vesiputousmallissa on vain yksi kehityssykli ja sen vaiheet suoritetaan lineaarisesti jokainen vaihe kokonaisuudessaan ennen seuraavaa. Tämä tarkoittaa, että yksi vaihe voi kestää jopa kuukausia. Suoritettujen vaiheiden välillä ei saisi olla sahausliikettä. Todellisuudessa aiempiin kehitysvaiheisiin tullaan usein palaamaan [Roy70]. Kuvassa 3 havainnollistetaan vesiputousmallin mukaista prosessia. Kuva 3: Vesiputousmalli. Ketterässä kehitysmallissa eri prosessivaiheet ovat samankaltaiset kuin vesiputousmallissa. Merkittävin ero vesiputousmalliin verrattuna on sen iteratiivisuuden ja keveyden mahdollistama nopea toimitus. Ohjelmistoa kasvatetaan vähitellen lisäämällä siihen jokaisen kehityssyklin aikana uusia ominaisuuksia. Yhden kehityssyklin pituus on vain 14 viikkoa ja syklejä voi kertyä yli 10 [ASR02, GMS10]. Lisäksi yhden kehityssyklin sisällä on pienempiä iteraatioita. Kuvassa 4 havainnollistetaan ketterää prosessimallia kuvaamalla prosessin ensimmäinen iteraatio. Ketterä ohjelmistokehitys on kattotermi, joka käsittää useita erilaisia kehitysmalleja ja käytäntöjä. Seuraavissa luvuissa tullaan käsittelemään kehitysmalleja 34 Kuva 4: Ketterä prosessimalli [Kon08]. Scrum ja XP korkealla tasolla. Scrum soveltuu erityisesti projektinhallintaan ja XP keskittyy enimmäkseen toteutuskäytäntöihin. 2.3.2 Scrum Scrum kehitettiin aikanaan ohjaamaan järjestelmän kehitysprosessia [ASR02]. Menetelmässä ei määritellä mitään erityisiä toteutuskäytäntöjä vaan siinä keskitytään tehostamaan tiimiläisten toimintaa, jotta tuote valmistuu joustavasti toistuvasti muuttuvassa ympäristössä. Määritelmä Scrum-prosessi sisältää kolme vaihetta: alkupeli, kehitysvaihe ja jäl- kipeli. Alkupeli sisältää korkean tason suunnittelua ja ohjelmiston arkkitehtuurin määrittelyä. Suunnitteluvaiheessa tuotteen työlistaan (product backlog) lisätään kaikki tunnetut vaatimukset. Ohjelmiston arkkitehtuuri suunnitellaan tuotteen työlistalla olevien vaatimusten mukaisesti. Kehitysvaihe on prosessin ketterä osa: kehi- 35 tystyö jaetaan 14 viikon mittaisiin pyrähdyksiin. Jokainen pyrähdys sisältää kaikki perinteiset ohjelmistokehitysvaiheet määrittelystä toimitukseen. Kun vaatimukset on täytetty, siirrytään jälkipeli-vaiheeseen. Integroinnin, testauksen ja lopullisen dokumentoinnin jälkeen tuote on valmis toimitettavaksi kokonaisuudessaan. Kuvassa 5 on havainnollistettu eri vaiheiden sisältö. Kuva 5: Scrum-kehityksen vaiheet [ASR02]. Scrum-kehitysmallissa on käytössä kaksi kolme erilaista työlistaa: tuotteen työlista, toteutusvaiheen työlista (sprint backlog) ja joskus myös julkaisun työlista (release backlog). Jokaisen pyrähdyksen aluksi tarkastellaan toteutusvaiheen työlistaa. Se sisältää tuotteen työlistalta valittuja vaatimuksia, jotka aiotaan valmistaa kyseisen pyrähdyksen aikana. 36 Roolit Henkilöille määritellään Scrum-projektissa roolit. Tärkeimpiä rooleja ovat tuoteomistaja, Scrum-mestari ja Scrum-tiimi. Tuoteomistaja edustaa asiakasta ja varmistaa, että tiimi tuottaa arvoa. Tuoteomistajan tehtävänä on määritellä ja priorisoida käyttäjätarinat ja lisätä ne tuotteen työlistalle. Scrum-mestari huolehtii, että prosessit etenevät suunnitellusti ja tiimi voi työskennellä mahdollisimman tehokkaasti. Scrum-tiimi käsittää 59 henkilöä ja sen vastuuna on tuotteen valmistus. Kaikki kehittäjät Scrum-tiimissä osallistuvat aktiivisesti toteutusvaiheen työlistan luontiin. 2.3.3 XP XP kehitettiin ratkaisuksi perinteisten ohjelmistokehitysmallien pitkien toimitussyklien aiheuttamiin ongelmiin [ASR02]. Se on kokoelma käytäntöjä, kuten TDD, jatkuva integrointi ja koodin yhteisomistus. Kaikki käytännöt olivat olemassa jo ennen XP-kehitysmallia. Uutta oli näiden käytäntöjen teoretisoiminen ja hyödyntäminen tehokkaasti yhdessä. Taulukkoon 7 on listattu kaikki Beckin [Bec99] määrittelemät 12 XP-käytäntöä. Määritelmä Termi extreme (äärimmäinen) kuvaa kehitysmallin tapaa käyttää tavanomaisia periaatteita ja käytäntöjä äärimmäisellä tasolla. Esimerkiksi kaikki ohjelmointi suoritetaan pariohjelmointina, ei vain jossain projektin vaiheessa tai vain joidenkin ohjelmistokehittäjien osalta. Beckin sanoin XP on kevyt, tehokas, mata- lariskinen, joustava, ennustettava, tieteellinen ja hauska tapa kehittää ohjelmistoja. XP on tarkoitettu suhteellisen pienille projekteille, joissa tiimikoot ovat 210 henkilöä. Roolit Jokaisella henkilöllä on jokin rooli ja vastuualue. Henkilöllä voi olla use- ampi rooli samanaikaisesti. Ohjelmoija luo mahdollisimman yksinkertaista koodia ja kirjoittaa moduulitestit. Asiakas määrittelee käyttötapaukset ja toiminnalliset testit 37 1. Suunnittelupeli The Planning Game 2. Pienet julkaisut Small releases 3. Järjestelmän vertauskuva Metaphor 4. Yksinkertaisuus Simple design 5. Testaus Testing 5.1 Testivetoinen kehitys TDD 5.2 Asiakastestaus Customer tests 6. Refaktorointi Refactoring 7. Pariohjelmointi Pair Programming 8. Yhteisomistus Collective ownership 9. Jatkuva integrointi Continuous integration 10. Tasainen tahti 40 hour week 11. Asiakas paikan päällä On-site customer 12. Toteutuskäytännöt Coding standards Taulukko 7: XP-käytännöt Beckin mukaan. sekä päättää, milloin eri vaatimukset on täytetty. Testaaja muun muassa auttaa asiakasta toiminnallisten testien määrittelyssä. Valvoja antaa palautetta tiimiläisten toiminnoista ja arvioi jokaisen iteraation etenemistä. Valmentaja on vastuussa XP-prosessista. Konsultti on ulkopuolinen henkilö, jolla on jokin tietty tekninen osaamisalue, jonka avulla hän ohjaa tiimiä. Johtaja huolehtii tiimin tarpeista ja tekee tärkeät päätökset. Neljä arvoa Kehitysmallilla on neljä Beckin [Bec99] määrittelemää arvoa, jotka palvelevat sekä ihmisten että yritysten tarpeita: kommunikaatio, yksinkertaisuus, palaute ja rohkeus. Hänen mielestään toimimaton kommunikaatio ei ole sattumaa, 38 vaan ihmiset aiheuttavat sen itse omalla toiminnallaan. Kommunikaatio pyritäänkin ylläpitämään sujuvana hyödyntämällä erilaisia käytäntöjä, jotka vaativat toimivaa kommunikaatiota. Tällaisia ovat esimerkiksi pariohjelmointi ja tehtävien arvionti. Beckin mukaan on tärkempää tehdä asia ensin yksinkertaisesti ja vasta myöhemmin tarvittaessa muuttaa sitä, vaikka muutos maksaisikin enemmän. Tällöin vältytään tuottamasta jotain monimutkaista, jota ei ehkä koskaan tulla tarvitsemaan. Yksinkertaisuus liittyy kommunikaatioon, koska kommunikaatiolla asioista saadaan yksinkertaisempia. Mitä yksinkertaisempi järjestelmä on, sitä vähemmän tarvitaan kommunikaatiota ihmisten välillä. Järjestelmän nykytilasta saatu palaute on arvokasta tietoa. Ohjelmistokehityksessä optimismi on vaarallinen asenne, joka voi estää löytämästä virheitä ohjelmakoodista ja saamasta tietoa asiakkaalta. Konkreettinen palaute muun muassa testauksen muodossa estää olettamuksien aiheuttamia ongelma. Mitä enemmän saadaan palautetta, sitä parempaa on kommunikaatio. Tällöin myös järjestelmästä tulee yksinkertaisempi. Rohkeus auttaa ohjelmoijaa kokeilemaan uskomattomalta vaikuttavia ratkaisuja, jotka toisinaan tuottavat erinomaisia tuloksia. Ilman kommunikaatiota, yksinkertaisuutta ja palautetta, rohkeus on kuitenkin vaarallista. 2.3.4 Agile manifeston arvojen ja Lean-periaatteiden yhteys Agile manifeston neljällä arvolla ja Lean-periaatteilla voidaan nähdä yhtymäkohtia. Taulukossa 8 havainnollistetaan joitakin tällaisia yhtäläisyyksiä. Ketterät tiimit ovat itseorganisoituvia ja valtuutettuja ratkaisemaan itse ongelmansa. He myös koordinoivat omat tehtävänsä. Lean-näkökulmasta asia nähdään pitkälti samoin: yksilön arvostaminen on tiimityöskentelyä, vastuun antamista sekä toisten mielipiteiden kuuntelemista ja arvostamista. Kummastakin näkökulmasta 39 tyytyväinen työntekijä on tehokkaampi ja tyytyväisen asiakkaan tae. Laajat dokumentaatiot ovat ketterien kehitysmallien mukaan turhaa työtä ja Lean-mielessä hukkaa. Ketterissä kehitysmalleissa jokaisen syklin päätteeksi asiakkaalle esitellään jotain valmista toimivaa koodia. Lean-näkökulmasta toimiva sovellus on tärkeä monella tavalla. Testaamaton koodi on hukkaa, joten heti alusta alkaen pyritään välttämään suurien virheraporttien laatimista ja ryhdytään tuottamaan valmista testattua ja integroitua koodia. Näin tuotetaan kokonaisvaltaista laatua, eikä pyritä kasvattamaan erinäisiä varastoja ja jonoja siirtämällä tehtäviä tulevaisuuteen. Ketterissä kehitysmalleissa sopimusneuvotteluja tehdään koko projektin ajan sopimalla aina iteraatioiden vaihtuessa seuraavaksi toteutettavat ominaisuudet. Käytännössä tämä on asiakkaan kanssa työskentelyä ilman kirjallisia sopimuksia. Tehosta oppimista -periaate liittyy vahvasti asiakasyhteistyöhön, sillä ohjelmistokehitys on jatkuvaa uuden oppimista ja yksi tärkeimmistä palautteen antajista on asiakas. Tiivis asiakasyhteistyö edesauttaa arvon tunnistamista, jolloin valmistettu tuote vastaa asiakkaan tarpeita. Ketterien kehitysmallien etu perinteiseen vesiputousmalliin verrattuna on niiden joustavuus ja mahdollisuus reagoida nopeasti muutoksiin. Päätä mahdollisimman myöhään -periaate mahdollistaa nopean reagoimisen muutoksiin, mikä ei ole mahdollista, jos noudatetaan jo projektin alussa tehtyjä suunnitelmia. Poppendieckien [PoP06] mukaan arvolla on ohjelmistokehityksessä tapana muuttua, joten muutoksiin on pystyttävä varautumaan. Lean on vielä suhteellisen nuori käsite ohjelmistoteollisuudessa. Sitä ei pidä ajatella ketterien kehitysmallien vaihtoehtona vaan niiden seuraavana vaiheena, kuten Abrahamsson [Les11] mainitsee Tietokone-lehden haastattelussa. Hänen mukaansa Ketterä kehitys soveltuu koneiston kehittämiseen, kun taas Leanilla voidaan 40 Agile manifeston arvot Lean-periaate Yksilöt ja vuorovaikutus ennen Kunnioita ihmisiä prosesseja ja työkaluja Toimiva sovellus ennen Luo kokonaisvaltaista laatua kokonaisvaltaista dokumentaatiota Asiakasyhteistyö ennen Tehosta oppimista sopimusneuvotteluita Muutoksiin reagoiminen ennen Päätä mahdollisimman myöhään suunnitelmien noudattamista Taulukko 8: Agile manifeston arvojen ja Lean-periaatteiden yhteys. pureutua organisaatioon. Voidaan siis ajatella, että Lean sisältää agile manifeston arvot. 2.3.5 Ketterät käytännöt kommunikaatio-ongelmien ratkaisuna Hajautetun projektin menestyminen vaatii tehokasta yhteistoimintaa eri pisteiden välillä ja mikään muu sen saavuttamiseksi ei ole niin tärkeää kuin tehokas kommunikaatio. Kommunikaatio-ongelmat tiimien välillä on useissa lähteissä [MoH01, PaL06, GMS10] määritelty merkittävimmäksi ongelmaksi hajautetussa ohjelmistokehityksessä. Tehoton kommunikaatio on hukkaa ja sen poistaminen on oleellista riippumatta projektin rakenteesta. Ketterillä menetelmillä voidaan Pikkaraisen et al. [PHS08] tutkimuksen mukaan parantaa sekä muodollista että epämuodollista kommunikaatiota ohjelmistoprojekteissa. Muun muassa avoin toimistotila, pyrähdyksien suunnittelu ja päivittäiset kokoukset parantavat kommunikaatiota lisäämällä sitä. 41 Pikkarainen et al. ovat sitä mieltä, ettei ketteristä kehitysmalleista ole sellaisenaan kommunikaatio-ongelmien ratkojaksi laajennettuihin ympäristöihin, joissa useat sidosryhmät ja kehittäjätiimit ovat mukana saman ohjelmiston kehitysprosessissa. Kuitenkin esimerkiksi Scrum-käytäntöjä voidaan tutkimusten [VäK08, SMÅ10] mukaan käyttää parantamaan kommunikaatiota hajautetuissa projekteissa, kunhan niitä sovelletaan oikein. 3 Kokeellinen tutkimus Suoritetun tapaustutkimuksen tarkoituksena oli kerätä materiaalia tutkimuskysymysten analyysia varten. Analysoitua materiaalia verrattiin kirjallisuudesta löytyviin tutkimuksiin. Ensimmäisessä luvussa 3.1 selitetään, miten tutkimusongelmaa on tutkittu. Luvussa 3.2 esitellään tutkimuskohde ja viimeisessä luvussa 3.3 tiedonkeräämisen välineet. 3.1 Miten ongelmaa tutkitaan Tapaustutkimus suoritettiin laadullisena tutkimuksena, jonka avulla pyrittiin ymmärtämään tutkittavia ilmiöitä. Tutkimuksessa käytettiin hypoteesia vahvistavaa triangulaatiota, jossa kahta tai useampaa menetelmää käytetään mittaamaan yhtä tutkimuskohdetta [RuH09]. Aineisto kerättiin haastattelemalla ohjelmistokehittäjiä kasvotusten ja havainnoimalla työskentelyä paikan päällä [Mäe11a, Mäe11b]. Lisäksi tietoa kerättiin Wikistä, versionhallintaohjelmistosta ja sähköisestä Kanban-taulusta. Tutkimustiloina toimivat todellista ohjelmistokehitystilaa simuloiva Software Factory [Abr10] sekä toinen luokkatila. Software Factory -tila on suunniteltu vastaamaan mahdollisimman tarkasti oikeaa ohjelmistokehittäjän työtilaa. Kaikki tässä 42 tilassa tapahtuva tallennettiin videolle ja äänitettiin. Lisäksi kaikki tietokoneella tehty tallennettiin. Toisessa pisteessä sijainneessa luokkatilassa ei äänitetty eikä tallennettu työskentelyä. 3.2 Tutkimuskohteen esittely Projektissa Cloud of Things (CoT) työskenteli kaksi kehitystiimiä: A ja B. A koostui kahdeksasta ja B kuudesta ohjelmistokehittäjästä. Fyysinen välimatka tiimien välillä oli noin 400 kilometriä. Asiakasta Tieto Oyj edusti kaksi tuoteomistajaa: T1 ja T2 . Tuoteomistajan T1 työpiste sijaitsi lähellä pistettä A. Hän vieraili kummankin tiimin luona noin joka toinen viikko ja oli demotilaisuudessa paikan päällä vuoroin pisteessä A ja vuoroin pisteessä B. T2 osallistui demotilaisuuksiin tavallisesti etäyhteydellä. Tuoteomistaja T2 oli hieman teknisempi. Lisäksi projektiin liittyi pisteessä B järjestetty käytettävyyskurssi (UCD-kurssi), jota hyödynnettiin käyttöliittymäsuunnittelussa. Projektissa ei ollut havaittavissa yhtä hajautettua tiimiä, vaan työskentely tapahtui kahdessa itsenäisessä tiimissä (two-site). Kuvassa 6 havainnollistetaan projektin kokoonpanoa. Pallot kuvaavat henkilöitä ja viivat kommunikaatioväyliä. Tuoteomistajan T1 kanssa kommunikoitiin kummastakin tiimistä. Tuoteomistajaan T2 oltiin yhteydessä tiimistä A, mutta tiimin B yhteydenpidosta ei ollut havaintoja eikä asia tullut esille haastatteluissa. Oletettavasti teknisempiä asioita tiedusteltiin enemmän tiimistä A käsin. Käytettävyyskurssilaiset kommunikoivat vain tiimin B kanssa. Tiimiläiset koostuivat suomalaisista ja ulkomaalaisista opiskelijoista, joten tiimien välisenä yhteisenä kielenä käytettiin englannin kieltä. Sisäiseen kommunikaatioon tiimissä B käytettiin suomen kieltä ja tiimissä A englannin kieltä. Kommunikoimiseen tiimien välillä käytettiin videoneuvottelulaitteistoa, puhelinta, sähkö- 43 Kuva 6: Projektin sosiaalinen rakenne. postia, Skype-pikaviestipalvelua ja työpöydän jakamiseksi TeamViewer-ohjelmaa. Lisäksi Tiimillä A oli käytössään interaktiivinen taulu SMART board. Tuoteomistajiin oltiin yhteydessä sähköpostitse ja puhelimitse. Kenellekään tiimiläisistä ei osoitettu mitään tiettyjä rooleja. Projektissa ei siis ollut esimerkiksi testaajia, tietokantaohjelmoijia, Scrum-mestaria tai agile-valmentajaa. Projekti oli seitsemän viikon mittainen. Miestyöviikon pituus oli 24 tuntia eli kuusi tuntia päivässä, koska perjantai pidettiin vapaapäivänä. Pisteestä A oli kolme henkilöä (21 % kaikista kehittäjistä) poissa projektin aktiivisesta työajasta kuuden päivän ajan (21 % projektin kestosta). Taulukossa 9 on esitetty yhteenveto projektin perustiedoista. Työtunneissa ei olla otettu huomioon projektin ulkopuolisten käytettävyyskurssilaisten työpanosta. Kenelläkään tiimiläisistä ei ollut aikaisempaa kokemusta hajautetusta ohjelmistokehityksestä. Scrum-prosessimallista ja Kanban-menetelmästä oli vähäistä kokemusta parilla henkilöllä. Tiimissä A oli kokonaisuudessaan enemmän ohjelmointikokemusta. Ohjelmointiosaaminen pisteessä B vaihteli merkittävästi. Projektin tavoitteena oli tuottaa prototyyppi uudelle pilvipalveluita hyödyntävälle mobiilituotteelle ShopMate. Tuotteeseen tehtiin niin paljon ominaisuuksia, 44 Tiimi A Tiimi B Henkilömäärä 8 6 Työviikkotunnit/hlö 24 24 Työviikkotunnit/tiimi 192 144 Työpäivät/hlö 2228 28 Työpäivät/tiimi 206 168 Taulukko 9: Projektin perustiedot. kuin seitsemässä viikossa ehdittiin. 3.3 Tiedon keräämisen välineet Tutkimus suoritettiin havainnoimalla työskentelyä ilman osallistumista [Mäe11a] ja haastattelemalla kehittäjiä [Mäe11b]. Haastattelun muoto oli puolistrukturoitu ja kesto 2045 minuuttia. Lisäksi tuoteomistajilta saatiin lyhyt palaute projektin päätyttyä. Havaintoja tehtiin pisteessä A paikan päällä neljänä ensimmäisenä viikkona ja projektin jälkeisenä jälkiarviontipäivänä (debrieng). Lisäksi pisteessä B oltiin paikan päällä heidän jälkiarviontipäivänään. Yhteensä havaintoja tehtiin 46:n tunnin ajan. Tutkimusta varten haastateltiin viisi henkilöä: kaksi pisteessä A ja kolme pisteessä B. Haastattelut pisteessä A suoritettiin projektin puolivälin jälkeen ja pisteessä B projektin jälkiarviontipäivänä. Kaikkia haastateltavia ohjeistettiin olemaan keskustelematta haastattelun sisällöstä toisten henkilöiden kanssa. Pisteen A henkilöt eivät olisi ehtineet keskustella keskenään, sillä haastattelut suoritettiin peräkkäin, mutta pisteessä B tähän oli teoreettinen mahdollisuus. Haastateltavat pisteessä A valittiin arvioidun kokemuksen ja projektissa esiintyneen aktiivisuuden perusteella. Toinen henkilöistä oli aiemmin työskennellyt Soft- 45 ware Factory -kurssilla ja toisellakin oli projektikokemusta aiemmilta kursseilta. Pisteessä B haastateltavat valikoituivat satunnaisesti sen mukaan, kuka oli vapaana. Haastattelut nauhoitettiin ja litteroitiin lähes sanatarkkaan tutkimuksen analyysivaihetta varten. Seuraavassa luvussa 4 siteerataan haastattelukysymysten vastauksia ja jälkiarviontipäivän havaintoja [Mäe11b]. Mainitut havainnot ovat havainnointipäiväkirjasta [Mäe11a]. Haastateltavat on nimetty satunnaisesti niin, että An vastaa tiimin A kehittäjää ja Bn tiimin B kehittäjää: [A1 ], [A2 ], [B1 ], [B2 ] ja [B3 ]. Numerointi ei välttämättä vastaa haastattelujärjestystä. 4 Empiiriset tulokset Tässä luvussa esitellään hajautettuun ohjelmistoprojektiin kohdistuvan empiirisen tutkimuksen tulokset. Hajautettujen projektien Lean-näkökulmaa on tutkittu vielä vähän, mutta voidaan varovaisesti arvioida, että hajautetussa ympäristössä erinäiset hukat korostuvat. Tapaustutkimuksessa pyritään selvittämään, missä määrin hajautettu ohjelmistokehitys voi olla Lean-periaatteiden ja päämäärien mukaista. Tuloksia tarkastellaan kahden tutkimuskysymyksen kautta: 1. Työskentelivätkö projektilaiset tehokkaasti ilman hukkia. 2. Oliko arvovirtaus tehokas. Luvussa 4.1 kuvataan tiimien työskentelytavat, luvussa 4.2 tarkastellaan työtapojen tehokkuutta ja luvussa 4.3 kartoitetaan arvovirtauksen tehokkuutta. Lopuksi luvussa 4.4 selvitetään kuinka onnistunut projekti oli kokonaisuudessaan. 46 4.1 Tiimien työskentelytavat Tässä luvussa esitellään projektissa käytetty prosessimalli ja Kanban-menetelmä. 4.1.1 Prosessimalli Projektin alussa kehittäjiä ohjattiin käyttämään projektin hallintaan Scrum-prosessimallia ja työnkulun visualisoimiseen Kanban-menetelmää. Muutama henkilö tiimistä A ilmaisi halunsa käyttää perinteistä tai jotain muuta ketterää prosessimallia, josta heillä olisi ollut kokemusta. Käytetty prosessimalli oli jonkinasteinen Scrumban-järjestelmä, jossa pyritään hyödyntämään Kanban-menetelmän ja Scrumkehitysmallin parhaita puolia [KnS09]. Säännöllisesti kummassakin tiimissä käytössä olleita käytäntöjä olivat viikon mittaiset pyrähdykset, säännölliset demot ja pyrähdyksien suunnittelu demotilaisuuden päätteeksi. Scrum-kokous kestää noin 15 minuuttia ja sen aikana vastataan kolmeen kysymykseen: Mitä olet tehnyt edellisen Scrum-kokouksen jälkeen?, Mikä on hankaloittanut työtäsi? ja Mitä aiot tehdä seuraavaan Scrum-kokoukseen mennessä?. Kokouksia pidettiin joka aamu tiimissä B. Tiimissä A niiden hyödyntäminen lopetettiin projektin puolivälissä, koska sovitusta kokousajasta oli joka viikko joku myöhässä ja kokouksen alkua odotellessa ei aina työskennelty tehokkaasti. Kokousten pitäminen lopetettiin erään tiimiläisen mukaan tarkoituksellisesti, sillä: Ne [Scrum-kokoukset] eivät toimineet. [A2 ] Projektissa ei ollut erillistä toteutusvaiheen työlistaa, vaan käytössä oli pelkkä tuotteen työlista. Kuvassa 7 on esitetty käytössä ollut työlista. Ensimmäisessä sarakkeessa on toiminnallisuuden nimi, toisessa sarakkeessa toiminnallisuus kuvataan tarkemmin ja kolmas sarake sisältää tarkennusta vaativia asioita. 47 Kuva 7: Tuotteen työlista. Tuotteen työlistan toiminnallisuudet priorisoitiin ominaisuuslistaan, jota päivitettiin koko projektin ajan. Kuvassa 8 osittain näkyvä ominaisuuslista on projektin viidennen pyrähdyksen lopulta. Ensimmäinen sarake kuvaa toiminnallisuuden tämänhetkistä tilaa, toinen prioriteettia, kolmas sisältää toiminallisuuden nimen ja viimeisessä sarakkeessa toiminnallisuus kuvataan tarkemmin. Tehtävien jako tiimien välillä tehtiin pyrähdyksen päätteeksi pidetyn demotilaisuuden lopuksi tai myöhemmin tilaisuuden jälkeen. Aikaisempi kokemus ja kiinnostus vaikuttivat tehtäväjakoon. Jos tehtävät loppuivat kesken pyrähdyksen, voitiin uusia tehtäviä kysellä esimerkiksi Skypen välityksellä toiselta tiimiltä. Vaihtoehtoisesti voitiin itsenäisesti valita seuraava tehtävä työlistalta. Tiimi B kyseli mieluummin apua toiselta tiimiltä ja tiimi A toimi itsenäisemmin. Wikistä löytyi vain kahden ensimmäisen pyrähdyksen suunnitelmat, joten kaikista suunnitelmista ei ole erillistä dokumentaatioita. Ensimmäinen suunnitelma näkyy kuvassa 9. Oletettavasti ominaisuuslista korvasi pyrähdysten suunnitteludoku- 48 Kuva 8: Sovelluksen ominaisuulista. mentaatiot. 4.1.2 Kanban-menetelmä Kanban on imuohjaukseen perustuva Lean-menetelmä, jolla ohjataan tuotantoprosesseja ja visualisoidaan työnkulku. Menetelmässä käytetään taulua, joka on jaettu sarakkeisiin, jotka vastaavat prosessin työvaiheita. Jokaisen työvaiheen WIP pyritään määrittelemään optimiksi, jolloin prosessiin ei aiheuteta tukoksia tai odottelua työvaiheiden välille. Näin arvovirtaus pyritään pitämään tasaisena. Kummallakin tiimillä oli käytössään Kanban. Aluksi kummallakin oli omansa: pisteessä A fyysisellä seinällä ja pisteessä B verkossa. Toisella ja kolmannella viikolla oli käytössä yksi yhteinen Kanban verkossa. Seuraavilla viikoilla tiimi A päätti ottaa 49 Kuva 9: Ensimmäisen pyrähdyksen suunnitelma. fyysisen taulun takaisin käyttöön. Tällöin pisteessä A oli käytössä kaksi päivitettävää taulua. Viimeisenä kahtena viikkona Kanban-taulua käytettiin pisteessä A lähinnä raportointivälineenä. Verkossa olevalla Kanban-taululla oli kolme saraketta: ToDo, Doing ja Done. Tiimin A käytössä olleella fyysisellä taululla oli viisi saraketta: ToDo, Analysis, Doing, Review ja Done. Taulujen sarakekohtaisia WIP-arvoja ei rajoitettu. Kuvassa 10 näkyy, kuinka yhteinen Kanban on jaettu kahteen osaan niin, että kummallakin tiimillä on omat itsenäiset kaistansa. Vihreät työkortit esittävät sovellukseen toteutettavia ominaisuuksia, vaaleat yleisiä tehtäviä ja siniset työkortit ovat parannuksia. Yleinen tehtävä voi olla esimerkiksi XML-aiheen tutkimus. Kanban- taulussa käytettiin myös punaista työkorttia, joka kuvasi korjattavan virheen. Punainen kahdeksankulmio, jonka sisällä on valkoinen ruksi, kuvaa työkortin tukostilaa (blocked). Tukostilassa työkortti ei etene, vaan odottaa jonkin muun asian suoritusta. 50 Kuva 10: Tiimien yhteinen Kanban verkossa. 4.2 Työtapojen tehokkuus Seuraavissa aliluvussa tarkastellaan projektilaisten työtapojen tehokkuutta analysoimalla havaittuja hukkia ja projektilaisten yhteistoimintaa ja kommunikaatiota. 4.2.1 Projektissa ilmenneet hukat Projektin Wikissä olleessa Kanban-tutoriaalissa esiteltiin lyhyesti Lean-losoan tärkeimpiä periaatteita ja hukkatekijöitä. Kehitystyössä ei ollut kuitenkaan havaittavissa erityistä pyrkimystä hukkien tunnistamiseen ja poistamiseen. Seuraavassa tarkastellaan projektissa ilmenneitä hukkia, jotka on lopuksi koottu erilliseen taulukkoon 10. 51 Siirtäminen Tiedon siirtäminen tiimien välillä aiheutti muun muassa ylimääräisiä ominaisuuksia, kun välitettävä tieto oli puutteellista: Esim. B oli piirtänyt käyttöliittymään sellaisia toiminnallisuuksia, joita ei toteuteta ja se toiminnallisuus on nyt toteutettu. Kun B lähetti kuvat tiimille A, he eivät huomanneet sanoa, että ovat jo toteuttaneet tän [jokin toiminnallisuus]. Nyt meillä on kaksi toteutusta samasta toiminnallisuudesta, jotka toimii ihan eri tavalla. [A1 ] Kyllä joo niitäkin ilmeni [tehtävissä päällekkäisyyksiä tiimien välillä]. Aika usein jonkinlainen [verkko-Kanban] Kanban-moka. Ei ollut Kanban syystä tai toisesta ajan tasalla. Lähdettiin toteuttamaan eri tiimeissä samaa toiminnallisuutta. Luotettiin Kanbaniin. Välillä ei ehkä olisi pitänyt tai siihen olisi pitänyt voida luottaa. [B2 ] Uudelleen opettelu Uudelleen opettelua aiheutui versionhallintaohjelman käyt- töongelmista. Syy oli mitä todennäköisimmin osaamistasolla: Yhtäkkiä tekemäni koodi oli kadonnut GIT:istä [versionhallintaohjelmistosta] jonnekin. En tiedä minne. Jouduin tekemään koodin uudestaan. [Tiimin A jälkiarviointi] Virheet Niin asiakas kuin projektitiimitkin olivat sitä mieltä, että sovelluksesta löytyy joitakin pieniä virheitä, mutta mitään erityistä ei tullut esiin jälkiarviointitilaisuudessa. Testatussakin koodissa on aina virheitä, joten testaamisen vähyys saattoi lisätä virheiden mahdollisuutta: ...Voimassa oleva Hudson-palvelin [testauspalvelin], muttei tähän mennessä kirjoitettu montaakaan testiä. [A2 ] 52 ...Käytettiin hirveästi aikaa Hudsonin laittamiseen. Meillä ei ole käytännössä minkäänlaisia testejä tähän projektiin. Ei olla ihan varmoja toimisiko Hudson. Tai siis Hudson saadaan toimimaan Androidin kanssa, mutta kukaan ei ole jaksanut tehdä minkäänlaisia testejä. Hudson oli muutenkin kohtalaisen turhaa ajanhukkaa. [A1 ] ...Hudson oli ajatus, että käytetään, mutta ei oikeastaan hyödynnetty. Alun perin oli tarkoitus tehdä yksikkötestit, mutta ne ei oikein tuntunut soveltuvan tähän. Ei ollut oikein yksikkötestattavaa. [B2 ] Osittain tehty työ Testaamaton ja integroimaton koodi on jonoon siirrettyä työtä. Kummatkin olivat jonkin verran toisistaan riippuvaisia: Jos testauspalvelin oltaisiin saatu toimimaan heti alussa, yhteinen koodiintegraatio olisi tapahtunut paljon nopeammin. Muuten aika paljon osaamistasolla ongelmia, ei välttämättä osata käyttää GIT:iä työkaluna järkevästi. [A2 ] ...Osa ajatteli, että kun ei saada continuous integration -palvelua toimimaan, ei hyötyä kirjoittaa testejä tai ei niin kiire koodin integroinnin kanssa. [A2 ] Ylimääräiset ominaisuudet Siirtäminen aiheutti ylimääräisiä ominaisuuksia, joista mainittiin ensimmäisen hukan kohdalla. Tehtävien vaihtelu Kanban-taululla olleet tehtävät olivat varsinkin projektin alussa välillä liian isoja. Tämä johti keskeytyksiin, kun liian isoja tehtäviä jouduttiin pilkkomaan pienempiin osiin. 53 Sitäkin [tehtävien määrittelyä] opittiin siinä aikanaan. Kun ei tosissaan sitä kokemusta ollut, niin kyllähän siinä välillä tuli ihan huonojakin määrityksiä. Siis liian isoja tehtäviä. Ei osattu sillai mitoittaa. [B2 ] Alussa ei [määritelty hyvin tehtäviä]. Hyvin riippuvainen siitä, millainen kokemus henkilöllä on. Paranee koko ajan. Ei henkilöä, joka katsoisi, että kaikki tarvittava on taululla, kun on omatkin tehtävät tehtävänään... [A2 ] Jonkin verran keskeytyksiä Kanbanissa, koska liian isoja taskeja [tehtäviä]. [Tiimin A jälkiarvionti] Vaikka tehtävä oli pilkottu oikean kokoiseksi, sitä ei aina saatettu loppuun asti, ennen kuin aloitettiin toinen tehtävä. Tämä saattoi johtua siitä, että jonkin tehtävän oli valmistuttavakin ennen tekeillä olevaa tehtävää tai tehtäviä saatettiin vaihdella myös jostakin muusta syystä: Olisi pitänyt suunnitella taskit projektin alussa. Tehtäviä ei siis tehty loppuun asti, kun aloitettiin toinen. [Tiimin A jälkiarviointi] Tekeillä oleva tehtävä jouduttiin toisinaan keskeyttämään myös siksi, että työkortteja jouduttiin käydä tarkentamassa Kanban-taululla: Ongelma oli enemmän projektin suunnittelussa, joka vuosi myös Kanbaniin kun sinne piti sitten laittaa mitä oli tekemässä. Mutta kun ei ollut suunnittelua, sinne sitten kerääntyi epämääräisiä työtehtäviä, joita joku aina vähän väliä pyysi tarkentamaan... [A2 ] 54 Odottelu Tiimissä B oli tiimin A näkemyksen mukaan jonkin verran passiivista odottelua, kun ei tiedetty mitä tehdä, ja pikaviestimien kautta tulleisiin viesteihin ei aina ehditty vastaamaan heti: Pisteessä B ollut ilmeisesti liian vähän tehtävää tai vastaavaa. En ymmärrä syytä, miksi ovat odottaneet demotilaisuutta. Eivät ole toimineet ihan täysin itsetoimisesti. Eivät ottaneet itselleen lisää työtä. [A2 ] Useampaankin otteeseen jonkin verran jouduttiin odottamaan. Pääasiassa keskusteltiin Skypen kautta ja joskus saattoi tovi mennä, että sai jonkinlaista vastausta. Harvemmin kuitenkaan mitään pitkiä aikoja. Ei siis mitenkään kovin kriittistä. [B2 ] Projektin ulkopuolisen käytettävyyskurssin tuotoksia jouduttiin toisinaan odottelemaan: Jonkin verran joo [odottelua]. Käyttöliittymäsuunnitelmien kanssa... [A1 ] Taukokäytännöt vaihtelivat. Esimerkiksi ensimmäisellä viikolla erään kokouksen väliin sovittu 15:n minuutin tauko pitkittyi 37:ään minuuttiin. Osa tiimiläisistä meni syömään, vaikka oltiin sovittu, että pidetään vain lyhyt tauko. Tiedon vastaanottamista jouduttiin toisinaan odottelemaan, kun tuoteomistajalle T2 oli yritetty soittaa. Hän oli huonosti tavoitettavissa puhelimitse ja yleensä oli päädytty lähettämään tiedustelut sähköpostiviesteinä. Vastauksia kysymyksiin jouduttiin toisinaan odottelemaan monta tuntia: Teknisempi asiakas ei ollut tarpeeksi paikalla/tavoitettavissa. [Tiimin A jälkiarviointi] 55 Pisteessä A jouduttiin odottamaan testauspalvelimen ja yhteisen koodikannan käyttöönottoa: ...Käytin suunnilleen 3 päivää tämän asian virittämiseen itse. B oli saanut toimimaan, mutta A ei...Jos testauspalvelin oltaisiin saatu toimimaan heti alussa, yhteinen koodi-integraatio olisi tapahtunut paljon nopeammin. [A2 ] Projektin alussa kesti muutaman päivän, ennen kuin kaikilla oli salasanat tarvittaviin järjestelmiin. Asiakkaan tilaama testauspuhelin pisteeseen A saatiin vasta projektin loppupuolella, koska puhelimen toimittajalla oli ongelmia. Pisteeseen B puhelinta ei saatu koskaan: Me ei saatu niitä kännyköitä ikinä tänne pisteeseen B... [B1 ] Asiakkaan palomuuria ei saatu projektin aikana auki ja web service -linkkiä ei saatu lopulta toimimaan. Asiakkaan tietoturva-asioita oli tiukennettu vuodenvaihteessa, minkä vuoksi kyseiset asiat viivästyivät: Asiakas ei tiennyt, etteivät web servicet ja puhelinasiat tule toimimaan. Luotettiin asiakkaaseen, ja luovuttiin web service -asiasta vasta projektin keski- tai loppupuolella. [Tiimin A jälkiarviointi] Tehoton kommunikaation Seuraavassa luvussa 4.2.2 käsitellään yhteistoiminta- ongelmat ja siihen liittyvä hukka tehoton kommunikaatio. 4.2.2 Yhteistoiminta ja kommunikaatio projektissa Kommunikaatiohävikki on hukkaa, joka aiheutuu vääränlaisesta kommunikaatiosta. Liian vähäinen kommunikaatio lisää virheiden ja väärinymmärrysten mahdollisuut- 56 Hukka Lähde 1. Siirtäminen Puutteellinen tieto 2. Uudelleen opettelu Toteutettu toiminnallisuus katosi versionhallintaohjelmasta 3. Virheet Ei järjestelmällistä testausta 4. Osittain tehty työ Testaamatonta ja integroimatonta koodia 5. Ylimääräiset ominaisuudet Siirtäminen: kommunikaatio- ja yhteistoimintaongelmia tiimien välillä 6. Tehtävien vaihtelu Kanban-taululla liian isoja tehtäviä Kun huomattu, että toisen tehtävän on valmistuttava ensin Tehtävien tarkentamistarve 7. Odottelu Avun/ohjeiden odottelu Käyttöliittymäsuunnitelmat Liian pitkät tauot Tuoteomistan T2 tavoittaminen IT-tuki: salasanat Testauspalvelin ja yhteinen koodikanta Testauspuhelimet Asiakkaan palomuuri ja web service -linkki 8. Tehoton kommunikaatio Käsitellään kappaleessa 4.2.2 Taulukko 10: Projektissa ilmenneet hukat ja niiden lähteet. ta. Toisaalta tiivis kommunikointi silloin kun se on turhaa, on myös hukkaa (communication overhead). Kommunikaation tarve voi vaihdella esimerkiksi sen mukaan, missä vaiheessa projektia ollaan [GMS10]. 57 Kommunikaatio-ongelmat ovat yksi hajautettujen projektien tunnistetuimpia uhkia. Tämä lienee seurausta siitä, että ohjelmistokehitys on riippuvaista ihmisten vuorovaikutuksesta [SMÅ10]. Tehoton kommunikaatio on itsessään hukkaa, mutta myös aiheuttaa muita hukkia. Projektissa oli havaittavissa alusta asti joitakin ongelmia yhteistoiminnassa. Sidosryhmien yhteistoiminta ja kommunikaatio valittiin tarkemman analyysin kohteeksi edellä mainituista syistä. Seuraavissa kappaleissa analysoidaan projektissa ilmenneiden yhteistoimintaongelmien aiheuttajia kalanruotokaaviolla (Ishikawa diagram). Kaavio esittää syyseuraus-suhteita: kalan pää ilmaisee ongelman (seuraus) ja jokainen iso ruoto esittää yhtä pääkategoriaa (syy). Ruodosta lähtee alaspäin pienempiä ruotoja, jotka saadaan esittämällä kysymys miksi. Mitä pienempi ruoto on, sitä lähempänä ollaan pohjimmaista syytä. Syy-seuraussuhteita voidaan tarkastella myös toisinpäin. Tällöin kaaviossa liikutaan alhaalta ylöspäin ja käytetään sanaa aiheuttaa tai aikaansaa. Kuvassa 11 esitetään analyysin kohteena olevat pääkategoriat: ihmiset, tieto/taito, ympäristö, prosessit, johtaminen ja laitteet/välineet. Jatkossa kirjoittajan tulkinnan mukaan erityisen vahvat ja oleelliset havainnot on merkitty kaavioihin paksummilla ruodoilla. Ihmiset Tiimiläisillä oli havaittavissa ennakkoluuloisuutta toisen tiimin henkilöitä kohtaan. Tämä johtui oletettavasti fyysisen etäisyyden vuoksi syntyneestä me vastaan he -ajattelumallista. Lisäksi tiimiläiset ajattelivat hajautuksen tarkoittavan tiukasti kahteen paikkaan hajautettua kehitystyötä, jossa kumpikin tiimi on täysin itsenäinen yksikkönsä: ...Kommunikaatio ei olisi toiminut tai olisi paljon sekavampaa, jos olisi ollut yksi iso tiimi. Vaikea saada selvää kuvaa henkilöstä, jonka on nähnyt kerran neljä tuntia ja jolla on joku kummallinen Skype-nimi tai vastaavaa. Samassa tilassa voi eleistä nähdä, ymmärsikö toinen mitä 58 Kuva 11: Yhteistoimintaan negatiivisesti vaikuttaneet tekijät. tarkoitin. [A2 ] Projektin alussa pidetyssä ensimmäisessä ja lopulta ainoassa fyysisesti yhteisessä kokouksessa ei tavoitettu luottamusta, mikä olisi tärkeää ryhmähengen kannalta: Yhteistyö alkoi nihkeästi ensimmäisessä kokouksessa. B ei ollut valmistautunut tarpeeksi. [Tiimin A jälkiarviointi] Fyysisen etäisyyden aiheuttaman kasvokkaisen kommunikaation puuttuessa toinen tiimi ajateltiin joskus etäiseksi ja jopa häiritseväksi tekijäksi: Ei selkeää kuvaa, mitä tiimi B pitää meistä. Viestittäminen on ollut suhteellisen letkeää. Tietyt henkilöt meidän tiimin sisällä kokee kaikki ulkopuoliset tekijät vähän häiriöksi tässä projektissa. [A2 ] Tapaerot vaikuttivat kommunikaatioon joidenkin henkilöiden kohdalla vähentäen avun pyytämistä. Tähän saattoi vaikuttaa henkilön kulttuuri tai persoona: 59 Periaatteessa joo [tarvittaessa saatu pyydettäessä heti apua], riippuu siitä, mistä asioista on ollut vastuussa. Käytöstavoista/kulttuurista riippuvaista. Hiljaiset ei kysy apua niin nopeasti. Pitää käydä kattomassa miten menee. [A2 ] Tiimien välillä ilmeni toisinaan erimielisyyksiä, mikä saattoi vaikuttaa kommunikaatiohalukkuuteen: Kyllähän tapahtui parikin sosiaalisesti hankalaa tilannetta. Eripuraa syntyi välillä, mikä aika paljon varmaan johtui siitä turhautumisesta, kun projekti ei ihan edennyt alkuperäisten odotusten mukaan. [B2 ] Eräässä tiimien välisessä kommunikaatiotilanteessa yksi tiimiläinen turhautui johonkin erimielisyyteen siinä määrin, että kääntyi videoneuvottelun aikana poispäin kamerasta ja kuiskasi: Mä kohta jyrään yksin ton! Moni koki, että muilla on erilaiset odotukset ja näkemykset projektilta. Tämä saattoi lisätä muun muassa väärinymmärrysten mahdollisuutta: ...kun ihmisillä ei ole minkäänlaista selvää näkemystä siitä, että millainen se pitäisi olla se koko projekti [ohjelma] projektin lopussa. [A1 ] ...Kommunikaatio hieman ongelmallista, koska epäilen, että tiimeillä on erilainen näkemys siitä, mitä tämä projekti oikeasti tarkoittaa. Esim. demoissa painotetaan eri featureja, mikä on luonnollista, koska riippuu siitä, mitä on tehnyt. [A2 ] 60 ...Useampaan otteeseen kävi ilmi, ettei tiimeillä ollut yhtenäistä näkemystä ja oli väärinymmärryksiä ja ristiriitaisia käsityksiä. Ei nyt ihan ehkä ihan joka päivä, mutta useita projektin aikana... [B2 ] Tiimiläiset kokivat konseptin liian avoimeksi, koska he eivät tienneet tarkalleen alusta asti, mitä ollaan tekemässä: Tiedolla [asiakas] liian avoin konsepti. [Tiimin B jälkiarviointi] Henkilöiden tavoitettavuudessa oli välillä pieniä ongelmia. Toisinaan jouduttiin odottamaan vastauksia toiselta tiimiltä, tuoteomistajalta tai tuloksia käytettävyyskurssilta. Syyt ongelmaan on käsitelty edellisen kappaleen 4.2.1 kohdassa odottelu. Liian itsenäisesti toimiminen voi olla seurausta henkilön vahvasta uskosta omaan näkemykseen. Tämä vähensi kommunikaatiota: Joillakin liian vahvoja persoonia. [Tiimin B jälkiarvionti] Se, että joku sooloilee ja tekee ihan omiaan, on minun mielestäni pahempi asia kuin se, ettei osaa. Pisteessä A oli ainakin yksi tosi vahva persoona, joka veti sitä hommaa sinne, minne se halusi. Itse yritän tietoisesti mukautua siihen toisten näkökulmaan. [B3 ] Tiimissä A oli enemmän kokemusta ohjelmistojen tekemisestä, mikä vaikutti asenteisiin työskennellä yhtenä tiiminä. Saatettiin kokea, ettei toisen tiimin kanssa tarvitse kommunikoida niin paljon, koska osataan paremmin itse. Toisaalta ihmisillä on erilaiset sosiaaliset tavat, jolloin toisen henkilön keskeyttäminen ja avun saaminen voi olla vaikeampaa: 61 Kommunikoinnin määrään ei vaikuttanut niinkään välineet vaan asenteet. Ei aitoa yhteistyötä. [Tiimin B jälkiarviointi] Ei [olla jouduttu pyytämään apua toiselta tiimiltä]. Tehtäväjako on kuitenkin ollut niin selkeä. Tiimissä A ihmiset eivät ole kiinnostuneita puhumaan asioista, vaan tekevät vaan. Tämä aiheuttaa ongelmia myöhemmin. Johtunee siitä, että tiimissä [projektissa] ihmisillä erilainen kokemustaso ja käyttäytymistavat erilaisia. Keskeyttävät helpommin toisen työt. [A2 ] Kuvassa 12 on esitetty pääkategorian ihmiset yhteistoimintaan negatiivisesti vaikuttaneet syyt. Tieto/taito Kommunikaation tehokkuuteen vaikuttaa oleellisesti kielitaito. Tii- missä B koettiin, että kaikkea ei päästy ilmaisemaan, koska osalla henkilöistä kielitaito ei ollut tarpeeksi vahva. Koettiin kuitenkin, että pakotettuna käyttämään englannin kieltä myös tiimin sisäisenä kielenä, kommunikointi toisen tiimin kanssa olisi toiminut lopulta paremmin: Kieliongelmia. Lukeminen ja kirjoittaminen helpompaa, joten Skypeily oli helpompaa kuin puhe. Harjoituksen puute. Olisi varmasti parantunut, jos koko ajan olisi pitänyt puhua englantia. [Tiimin B jälkiarviointi] Englannin käyttäminen toi osaltaan lisää haasteita ja vaikeutti [kommunikaatiota]. Jos haluttiin olla ihan varmoja, että ymmärretään tiimien välillä toisiamme, haluttiin, että sieltä [tiimistä B] oli joku suomenkielinen yhteydessä. [B2 ] Toimintaohjeet projektin alussa olivat joidenkin mielestä liian tarkkoja tai toisaalta epätarkkoja. Prosessimalli oltaisiin haluttu valita itse tai valitusta pro- 62 Kuva 12: Yhteistoimintaan negatiivisesti vaikuttaneet tekijät: ihmiset. sessimallista olisi pitänyt olla jonkinlainen koulutus: Pakotettiin agileen malliin...Ihmiset eivät osanneet/tienneet, mitä agile on tarpeeksi...Ohjeistusta enemmän tai vähemmän, mutta ei näin miten nyt oli. [Tiimin A jälkiarviointi] Kokemuksen kautta omaksutut pohjataidot vaikuttavat siihen, miten kokouksissa ja palavereissa kommunikoidaan. Pohjataitojen puute voi vaikuttaa haluttomuuteen esittää kysymyksiä tai kommentteja, kun itseluottamusta ei ole vielä tarpeeksi: 63 ...Esim. X:n kieliset ja Y:n kieliset puhuvat ja muut ovat hiljaa kokouksessa tai keskustelevat keskenään. Johtuen ehkä siitä kokemuksen puutteesta. Ei halua näyttää, ettei osaa, tai ei oikein osaa kysyä oikeassa kohtaa. [A2 ] Projektin tavoitteet olivat joillekin epäselviä ja tekemisen tavoitteellisuus ei ollut ilmeistä kaikille alusta asti: Käytännössä olisi pitänyt olla paljon enemmän yhteistyötä. Asiakas ei oikein tiennyt mitä haluaa. Jotenkin sellainen tavoite [tekemisen tavoitteellisuus] puuttui koko projektilta. Oli sekainen olo, että mitä tässä tehdään. Mikään ei ollut valmiina. Silloin, kun asiakas oli paikalla, tuntui, että se oli kiinnostunut, mutta kun se oli jossain muualla, tuntui, ettei sitä oikeastaan loppujen lopuksi kiinnostanut se, mitä me tehdään. [B3 ] Kuvassa 13 on esitetty pääkategorian tieto/taito yhteistoimintaan negatiivisesti vaikuttaneet syyt. Ympäristö Kehittäjätiimien ympäristöksi tässä yhteydessä mielletään asiakas ja käytettävyyskurssi. Kumpikin tiimi pyrki usein esittämään oman näkemyksensä tuoteomistajalle. T1 antoi eräässä tilanteessa kummallekin tiimille eri vastauksen samaan kysymykseen. Tämä johtui siitä, että toisena asiansa esittänyt tiimi pystyi perustelemaan näkemyksensä vakuuttavammin, minkä vuoksi T1 pystyi oikeutetusti vaihtamaan vastauksensa. Tästä aiheutui ongelmia, koska päätöksiä ei aina välitetty toiseen tiimiin: 64 Kuva 13: Yhteistoimintaan negatiivisesti vaikuttaneet tekijät: tieto/taito. ...Eräs toiminnallisuus varmistettiin asiakkaaltakin, mutta sitten ilmeisesti tiimit sai ihan erilaisen varmistuksen ja käsityksen sen jälkeen, kun oli asiakkaan kanssa keskustellut. Molemmat kyseli erikseen asiakkaalta. Se on vähän hämärä kohta, miten näin pääsi käymään. Se luonnollisesti tuotti vähän turhaa työtä. Vääränlaista featurea lähdettiin tekemään sitten. [B2 ] Asiakkaalla oli tiukennettu tietoturva-asioita vuodenvaihteessa, minkä vuoksi jotkin tekniset asiat eivät toteutuneet odotetussa aikataulussa. Osa tiimiläisistä tulkitsi asian niin, ettei asiakas ollut valmistautunut projektiin tarpeeksi: ...Asiakas ei ole ollut valmis tähän projektiin siinä vaiheessa kun se alkoi. Tuntuu siltä, että aloittivat samaan aikaan tai pikkasen myöhemmin teknisen puolen omasta toteutuksestaan. [A2 ] 65 Tuoteomistajat eivät esittäneet tiimeille alusta asti valmista konseptia, minkä jotkut tiimiläiset ajattelivat tarkoittavan, ettei asiakas tiedä mitä haluaa. Kurssin alussa tuoteomistajille oli esitetty yliopiston puolelta toive, ettei heiltä tarjottaisi liian paljon valmista materiaalia. Tiimiläiset tulkitsivat, että työskentelyllä ei ole tavoitteellisuutta, kun konsepti puuttuu: Puolet tietämättömyydestä johtuu asiakkaan tietämättömyydestä myös. Olisi ollut hyvä, että asiakas olisi edes tiennyt, mitä haluavat projektilta. [A1 ] Kommunikaatio tiimien ja käytettävyyskurssin välillä ei ollut tarpeeksi tehokasta: Ongelma oli siinä, kuinka heitä [käytettävyyskurssilaisia] kuullaan. Toisaalta eivät itsekään ehkä tulleet tarpeeksi mukaan toiseen ryhmään. Mutta tilanne oli varmaan liian epäselvä, ei ollut selvää, miten pitäisi toimia, kun kurssit [Software project -kurssi ja käytettävyyskurssi] olivat erillisiä. [T1 ] Kuvassa 14 on esitetty pääkategorian ympäristö yhteistoimintaan negatiivisesti vaikuttaneet syyt. Prosessit Tavat hyödyntää Kanban-tauluja vaikuttivat osaltaan yhteistoiminnan tehottomuuteen. Kenellekään ei ollut vastuuta taulujen ylläpidosta ja niiden päivittäminen oli vaihtelevaa, koska niitä ei pidetty erityisen tärkeinä ja ne koettiin hankaliksi. Esimerkiksi ensimmäisellä viikolla pisteen A fyysisellä Kanban-taululla oli eri tehtäviä kuin mitä jotkut olivat tekemässä. Taulujen sisällöt olivat siten epäluotettavia. Projektin loppupuolella Kanban-taulua käytettiin lähinnä raportointivälineenä suoritetuista tehtävistä: 66 Kuva 14: Yhteistoimintaan negatiivisesti vaikuttaneet tekijät: ympäristö. En ole varma viikosta 5, mutta kahtena viimeisenä viikkona ei seinällä ollut Kanban muuttunut mielestäni juuri mitenkään, eikä kukaan sitä juuri katsellutkaan. Verkossa olevaan tehtiin myös kahtena viimeisenä viikkona vähän muutoksia ja lopussa vain dumpattiin tehtyjä asioita sinne, mutta ei niitä kukaan minun tietääkseni pisteessä A katsellut. Kovin vähän koko projektin aikana kukaan kanbaneja katseli ja mielestäni ei niistä suurta hyötyä ollut. [A1 ] Viikoilla 56 ei ollut Kanbania. Kaikki oli niin selvää Kanban-mielessä. Tieto kulki paremmin ilman Kanbania. Kanbania käytettiin enemmän dokumentointina: työskenneltiin nopeammin kuin Kanban. Taskit lisättiin suoraan Done-sarakkeeseen. [Tiimin A jälkiarviointi] Aina vähän laiskasti päivitettiin. Siihen ei aina voinut luottaa.... [B1 ] Tiimien välisen tehokkaan kommunikaation kannalta yhteinen Kanban verkossa oli erinomainen ratkaisu: ...Yhteinen Kanban olisi paras. Yhteinen Kanban vaikutti kommunikaa- 67 tion määrään, kun nähtiin suoraan mitä kukin tekee. [B1 ] Kanban oli kuitenkin jaettu kahteen kaistaan, mikä ei ollut kaikkein tehokkain tapa hyödyntää taulua. Tiimissä A Wikiä pyrittiin hyödyntämään uudelleen opettelun vähentämiseksi ja tiedon jakamisessa tehokkaammin. Kun joku teki jotain sellaista, jota muutkin joutuvat myöhemmin tekemään, tehtiin asiasta tutoriaali Wikiin kaikkien luettavaksi. Vain yksi henkilö opetteli asian kunnolla alusta asti. Tiimin B puutteellinen ja epäsäännöllinen dokumentointi Wikiin saattoi aiheuttaa joitakin kommunikaatioongelmista johtuvia hukkia: Ehkä B käytti sitä liian vähän. B teki itsekseen, eikä jakanut sitä minnekään. A teki minun mielestäni hyvin: dokumentoi puolivalmiitkin tekeleet aina jonnekin. Olisi pitänyt informoida, että nyt on lisätty tämmöinen juttu tänne [Wikiin]. [B3 ] Tiimeillä oli erilliset Scrum-kokoukset. Pisteessä A niiden käyttö lopetettiin kolmannen viikon aikana, koska ne eivät toimineet. Erilliset kokoukset johtuivat oletettavasti siitä, että tiimit kokivat työskentelevänsä kahtena täysin itsenäisenä tiiminä, joiden ongelmat ovat heidän omiaan. Kuvassa 15 on esitetty pääkategorian prosessit yhteistoimintaan negatiivisesti vaikuttaneet syyt. Johtaminen Päätöksenteko oli vaihtelevaa. Tiimeillä ei ollut kokemusta hajaute- tuista projekteista ja he näkivät projektin jaettuna kahteen erilliseen ja itsenäiseen tiimiin. Projektissa ei myöskään ollut mitään yhtenäisiä käytäntöjä päätöstentekoon tai niiden noudattamiseen, mistä aiheutui toisinaan ongelmia: 68 Kuva 15: Yhteistoimintaan negatiivisesti vaikuttaneet tekijät: prosessit. Puhuttiin, että asiat pitäisi hyväksyttää sekä asiakkaalla että toisella tiimillä. Näin ei kuitenkaan toimittu. Käytännöt pitäisi päättää alussa, eikä niin, että kumpikin tiimi keksii niitä kilpaa... [B3 ] Suunnittelupäätöksistä päästiin aina lopulta johonkin yhteisymmärrykseen, mutta joitakin ongelmia saattoi aiheutua turhasta kiireestä, halusta aloittaa toteutus ilman suunnittelua ja kehityssyklien lyhyydestä (4 päivää): Projektissa on pidetty kiirettä koko ajan myös sellaisissa tilanteissa, joissa ei ole ollut mitään tarvetta sellaiseen. Tämä on heijastunut työntekotapaan mahdollisesti... [A2 ] 69 Pick a feature and implement it, learn by doing. [Tiimissä A kuultu kommentti viikolla 3] Projektissa ei haluttu kenellekään kehittäjälle mitään erityisiä rooleja. Scrummestarin puuttuminen saattoi osaltaan heikentää kommunikaation tasoa. Kuvassa 16 on esitetty pääkategorian johtaminen yhteistoimintaan negatiivisesti vaikuttaneet syyt. Kuva 16: Yhteistoimintaan negatiivisesti vaikuttaneet tekijät: johtaminen. Laitteet/välineet Tiimien yhteinen koodikanta saatiin käyttöön vasta projektin puolivälissä osittain siksi, ettei sitä pidetty kiireellisenä, kun testauspalvelinkaan ei ollut toiminnassa. 70 Testauspalvelinta ei saatu toimimaan heti projektin alusta lähtien. Tämä johtui suurimmaksi osaksi tiimiläisten kokemattomuudesta. Kukaan ei ole tehnyt Androidilla mitään aiemmin. [A1 ] Se [testauspalvelin] on paljon hankalampi kuin mitä yleensä. Androidalusta on sen verran uusi... [A2 ] ...[testauspalvelin] Toimisi varmaan hyvin tietokoneohjelmien kanssa, mutta niin hirveä työ laittaa Androidille. [A1 ] Videoneuvottelun aloittaminen oli usein työlästä, kun ohjelmistojen kanssa oli teknisiä ongelmia. Projektin toisella viikolla hitaampi Skype korvattiin tehokkaammalla Adobe Connect Pro -ohjelmalla. Demotilaisuuksissa asetuksia ei saatu siirtymään tietokoneelta toiselle, jolloin demoa ei saatu näkyviin halutulla tietokoneella. Tällöin jouduttiin turvautumaan hätäratkaisuun: kauemman tietokoneen näyttöä kuvattiin webkameralla. Videoneuvotteluissa oli vaikea huomata, jos jollakin on asiaa, kun viittausta tai muuta puheenvuoron pyytämistä oli hankala nähdä monitorilta. Tällöin puhuttiin usein yhtäaikaa. Kuvassa 17 on esitetty pääkategorian laitteet/välineet yhteistoimintaan negatiivisesti vaikuttaneet syyt. 4.3 Arvovirtauksen tehokkuus Arvovirtauksen läpimenoaika on aika, joka kuluu, kun asiakas esittää tilauksensa ja saa tuotteen käyttöönsä. Arvovirtaa voidaan arvioida työnkulkua tarkastelemalla. Tässä luvuissa esitetään työnkulku sekä koko projektin ajalta että yhden tehtävän osalta. 71 Kuva 17: Yhteistoimintaan negatiivisesti vaikuttaneet tekijät: laitteet/välineet. 4.3.1 Työnkulku koko projektin ajalta Arvovirtausta projektin alusta loppuun voidaan pitää optimina, koska projektilaisilla ei olisi ollut mahdollisuutta vaikuttaa koko projektin läpimenoaikaan, koska kurssi oli joka tapauksessa seitsemän viikon mittainen. Prototyyppiin oli tarkoitus tehdä niin paljon ominaisuuksia kuin ehditään. Projektissa oli seitsemän pyrähdystä, jotka lähes kaikki olivat hieman erilaisia. Päivittäisiä Scrum-kokouksia ei hyödynnetty jokaisessa pyrähdyksessä, vaan pisteessä A niiden käyttö lopetettiin projektin puolivälissä. Myös Kanban-taulujen hyödyntäminen vaihteli paljon eri viikkoina. Tämä epäsäännöllisyys työtavoissa [mura] vaikutti osaltaan projektissa ilmenneisiin ongelmiin. 4.3.2 Yhden tehtävän työnkulku Projektilaisilla oli mahdollisuus vaikuttaa yksittäisten tehtävien läpimenoaikaan työja toimintatavoillaan. Työskentelyssä oli joitakin arvovirtaa heikentäviä toimintatapoja, jotka eivät tuottaneet asiakkaalle lisäarvoa. Näitä hukkia tarkasteltiin tar- 72 kemmin luvuissa 4.2.1 ja 4.2.2. Yhden tehtävän työnkulkua voidaan kuvata tarkastelemalla Kanban-taulujen käyttöä. Tauluja hyödynnettiin projektissa vaihtelevasti. Pisteessä B käytettiin vain sähköistä Kanban-taulua, mutta pisteessa A käytössä oli myös fyysinen Kanbantaulu, joten prosessissa oli kaksi tapaa edetä. Tehtävät valittiin sähköiselle Kanban-taululle joka viikko demotilaisuudessa priorisoidulta ominaisuuslistalta. Kuvan 18 vuokaavio esittää prosessia yhden työkortin etenemisestä alusta loppuun. Kuvattu tilanne on projektin puolivälistä. Lyhenne tkortti tarkoittaa työkorttia, fk fyysistä Kanban-taulua ja lyhenne vk verkossa olevaa sähköistä Kanban-taulua. Koska pisteessä B ei ollut fyysistä Kanban-taulua, prosessi oli heidän osaltaan yksinkertaisen suoraviivainen ja työkortti siirrettiin Doing-sarakkeesta suoraan Done-sarakkeeseen. Tehtävien arvioinnit tehtiin henkilökohtaisesti ilman vertaisarviointia, joten Review-saraketta ei tarvittu. Myöskään tehtävän analysointiin ei katsottu tarvittavan erillistä saraketta. Prosessi on esitetty kuvan 18 vasemmassa reunassa. Pisteessä A työnkulku eteni kahden taulun ylläpitämisen vuoksi hieman monimutkaisemmin. Kuvan 18 oikea reuna kuvaa tätä prosessia. Arvionnin jälkeen työkortti siirrettiin joko takaisin Doing-sarakkeeseen tai eteen päin Done-sarakkeeseen. Done-sarakkeen jälkeen oli vielä käytävä erikseen siirtämässä verkossa olevan Kanban-taulun työkortti sarakkeeseen Done. 4.4 Projektin onnistuminen Projektin tavoitteena oli valmistaa protoversio uudenlaiselle tuotteelle. Samalla projekti oli opiskelijoille turvallinen tapa tutustua työelämään. Jälkiarviointipäivänä joku tiimiläisistä mainitsi hieman pettyneenä tuotteen olevan fake product. Koska 73 Kuva 18: Vuokaavio Kanban-taulujen käytöstä projektin puolivälissä. kyseessä oli kuitenkin protoversio, ei ollut lähtökohtaisestikaan tarkoitus toimittaa valmista tuotetta markkinoille. Poppendieckien [PoP06] kirjan nimi Implementing Lean Software Development: From Concept to Cash, kuvaa prosessia tuotteen valmistuksesta aina tilauksesta toimitukseen. Tämä tarkoittaa, että tuotteella pitää olla konsepti ennen sen valmistamista. Tiimiläisillä ei ollut valmista konseptia. Ennen projektin alkua konseptia alustettiin asiakkaan pitämässä pintapuolisessa tuotteen esittelytilaisuudessa. Projektin tuottamaa protyyppiä voitaisiin tarkastella enemmän konseptin määrittelynä kuin tuotteen valmistamisena. Aikarajoja kunnioitettiin, eivätkä aikataulut pitkittyneet. Jokaisen iteraation lopuksi pidetyssä demotilaisuudessa oli aina jotain uutta ja mielenkiintoista esitet- 74 tävää asiakkaalle. Asiakkaalla ei ollut tarkkoja odotuksia projektilta, mutta heiltä oltiin erittäin tyytyväisiä lopputulokseen. He voivat välittömästi käyttää sovellusta hyödykseen. Myös oppilaat olivat tyytyväisiä sovellukseen ja saamaansa oppimiskokemukseen. Havaitut hukat eivät vaikuttaneet projektin lopputulokseen likaa, vaan onnistuttiin tuottamaan prototyyppi, johon asiakas oli tyytyväinen. Ilman havaittuja hukkia tuotteeseen oltaisiin kuitenkin oletettavasti ehditty tekemään enemmän ominaisuuksia. 5 Johtopäätökset Lean voidaan määritellä toisiinsa linkitettyjen arvoa tuottavien toimintojen jatkumoksi, josta on poistettu arvoa tuottamattomat toiminnot. Toisin sanoen arvovirtaus on tehokas ja työtavoissa ei ilmene hukkia. Tämän tutkielman tarkoitus oli selvittää, voiko hajautettu ohjelmistokehitys olla edellä mainitun määritelmän mukainen. Tuloksia varten tutkittiin ja analysoitiin CoT-projektin työskentelyä. Luvussa 5.1 vastataan tutkimuskysymyksiin ja pohditaan niiden merkittävyyttä. Luvussa 5.2 ehdotetaan tapaustutkimuksesta johdettua tarkistuslistaa hajautetun projektin yhteistoiminnan ja kommunikaation tehostamiseksi. 5.1 Empiiriset tapaustutkimuksen tulokset Tässä luvussa vastaan tutkimuskysymyksiin: 1. Työskentelivätkö projektilaiset tehokkasti ilman hukkia. 2. Oliko arvovirtaus tehokas. 75 5.1.1 Työtapojen tehokkuus Oletettavasti CoT-projektissa ajauduttiin modulaarisuuteen. Tähän viittaavat projektin alussa käytetyt erilliset Kanban-taulut, yhteisen Kanban-taulun jako kahteen kaistaan ja projektin toisena ja kolmantena päivänä pisteessä A esitetyt kysymykset: Mitä se hajautus edes on? Miten jaetaan työtä/tehtäviä AB? Mitä se B tekee? Projektin tiukka modulaarisuus olisi saattanut aiheuttaa ongelmia, mikäli asiaa ei oltaisi tiedostettu. Vaikka tarkoitus ei välttämättä ollut työskennellä niin itsenäisesti kuin tiimit lopulta työskentelivät, vältyttiin vakavilta ongelmilta. Haastattelussa kävi ilmi, että lisääntynyt kommunikaatiotarve oltiin tiedostettu. Joitakin hukkia kuitenkin ilmeni, kun kommunikaatio ei ollut aina tehokasta. Useimmiten tehottomuus johtui siitä, että välitetty tieto oli ollut yhteisellä Kanban-taululla tai sähköpostiviestissä puutteellista. Tästä voidaan päätellä, että pelkästään kommunikaatiotarpeen [määrä] tiedostaminen ei riitä, vaan myös kommunikaation sisältö [laatu] on tärkeää. Uudelleen opettelu versionhallintaohjelmasta hävinneen koodin takia oli mitä varmimmin käyttäjätason ongelma. Tiimiläiset järjestivät pienen koulutuksen versionhallintaohjelman käytöstä. Joko koulutus oli riittämätön, ohjelmassa oli virhe tai käyttäjä käytti ohjelmaa väärin. Oletettavin syy tähän hukkaan on viimeisin. Virheet korjattiin heti niiden löydyttyä eikä niitä siirretty virhelistoille odottamaan testausvaihetta. Virhelista on virheiden varasto eli hukkaa. Projektissa onnistuttiin välttymään tältä hukalta, mutta toisaalta valmiiseen tuotteeseen saatoi jäädä virheitä, sillä testausta ei suoritettu järjestelmällisesti. Löydetylle virheelle olisi voitu kirjoittaa testi, ettei se toistuisi myöhemmin. Vaikutti siltä, että testaus- 76 ta ei pidetty niin tärkeänä, koska asiakas ei ollut määritellyt tiukkoja laatukriteereitä tuotteelle. Testausta vähensivät myös testauspalvelinongelmat. Työtavat olivat tehokkaita siinä mielessä, että virheet korjattiin heti, mutta tehottomia virheiden ehkäisemiseksi. Osittain tehtyä työtä olisi ollut vähemmän, mikäli versionhallintaohjelmisto ja testauspalvelin oltaisiin saatu toimimaan projektin alusta asti. Testaamatonta koodia ei kannata integroida yhteiseen koodikantaan, ja testaamista ei voida suorittaa tehokkaasti ennen testauspalvelimen toimimista. Tehtävien vaihtelu liittyi Kanban-taulun työkorttien määrittelyyn. Kokemuksen puute vaikeutti tehtävien määrittelyä ja toisaalta Kanban menetelmänä oli monelle vieras. Projektin alussa pidettiin pieni Kanban-koulutus, mutta pelkkä koulutus ei kuitenkaan riitä tehtävien määrittelyn osaamiseen. Tehtävien vaihtelu liittyi siis vahvasti kokemustaustaan ja osaamiseen. Odottelu on hukkaa, jota ei voida käytännössä täysin ehkäistä missään projektissa. Sitä voidaan kuitenkin pyrkiä minimoimaan. Ilmeisin odottelu, mitä tiimiläiset itse olisivat voineet vähentää, aiheutui sovittujen asioiden noudattamatta jättämisestä. Esimerkiksi sovittujen taukojen noudattaminen olisi tehostanut kaikkien työaikaa. Paikalla olevat eivät olisi joutuneet odottelemaan ja myöhässä paikalle tulleet eivät olisi tarvinneet kertausta, jos joitakin asioita oltiin jo käsitelty. Ylivoimaisesti suurin osa tiimiläisistä riippumattomasta hukasta aiheutui odottelusta: tuoteomistajan tavoittaminen, IT-tuki, laitteistohankinnat, asiakkaan palomuurin aukeneminen ja web service -linkin toimiminen. Viimeiset kaksi seikkaa olivat hukkaa tiimiläisten näkökulmasta. Ne olivat projektin kannalta myös merkittävimmät hukat. Usea tiimiläinen teki turhaa ohjelmointityötä useamman viikon ajan. Toiminnallisuudet joihin palomuuri ja web service liittyivät, olivat tärkeitä asiakkaalle, joten tiimiläiset olettivat asiakkaan saavan IT-asiansa valmiiksi projek- 77 tia varten. Asiakkaaseen luotettiin, eikä asioiden laita selvinnyt tiimiläisille ja tuoteomistajille kuin vasta projektin puolivälissä, jolloin toteutetut toiminnallisuudet jouduttiin hylkäämään. Yhteistoiminta- ja kommunikaatio-ongelmia analysoitiin luvussa 4.2.2 kalanruotokaavion avulla. Merkittävin keino tehostaa kommunikaatiota ja yhteistoimintaa on selvittää ihmisiin liittyvät ongelmat. Suurin osa kommunikaatio-ongelmista johtui enemmän tavoista ja halusta kommunikoida kuin välineistä. Myös ihmisiä ohjaavat prosessit ovat tärkeitä ja niiden hyödyntäminen on oltava järjestelmällistä. Esimerkiksi työnjohdon tulee olla johdonmukaista. Koulutuksella ja ohjeistamisella voidaan parantaa joitakin tieto/taito-kategorian ongelmia, mutta osaaminen ohjelmistokehityksessä karttuu suurimmaksi osaksi kokemuksen kautta. Kategoriaan ympäristö liittyvät syyt voidaan minimoida varmistamalla, että kaikilla projektilaisilla on samanlainen käsitys projektin tavoitteellisuudesta ja sidosryhmien välillä on riittävästi laadukasta kommunikaatiota. Esimerkiksi tiimiläiset kokivat, että tuoteomistaja oli epäjohdonmukainen, koska hän antoi eri vastaukset kummallekin tiimille. Ongelma ei kuitenkaan johtunut tuoteomistajasta, vaan siitä, että tietoa ei jaettu tiimien välillä. Tiimien työskentelystä löytyi tehokkaita toimintatapoja, kuten virheiden korjaaminen heti, tutoriaalien tekeminen Wikiin kaikkien saataville ja asiassa pysyminen demotilaisuuksissa. Edellä mainittujen kappaleiden perusteella ensimmäiseen tutkimuskysymykseen joudutaan kuitenkin toteamaan, että tiimiläiset eivät työskennelleet täysin tehokkaasti ilman hukkia. Suurin osa hukista olisi ollut ehkäistävissä noudattamalla yhteisesti päätettyjä asioita, hyödyntämällä valittuja menetelmiä ja teknologioita järjestelmällisesti ilman epäsäännöllisyyttä [mura] ja kiinnittämällä huomiota tehokkaaseen kommunikaatioon. 78 5.1.2 Arvovirtauksen tehokkuus CoT-projektissa sovellettiin imuohjaukseen perustuvaa Kanban-menetelmää, joka ei rajaa työskentelyä timeboxing-käytännön mukaisesti erillisiin pyrähdyksiin. Projektin prosessimallina oli käytössä Scrum, joten käytettiin pyrähdyksiä, mutta ilman toteutusvaiheen työlistaa, joka olisi määritellyt yksiselitteisesti, mitä seuraavan pyrähdyksen aikana tuotetaan. Kanban-menetelmän idea perustuu katkottomaan työskentelyyn, jossa tehtävät virtaavat ToDo-sarakkeesta Done-sarakkeeseen sujuvasti [KnS09]. Virtaus ei pysähdy pyrähdysten vaihtuessa, joten erillistä toteutusvaiheen työlistaa ei olisi ollut mielekästä käyttää. Pyrähdyksen aikana kaikki tehtävät valittiin Kanban-taululle tuotteen työlistalta. CoT-projektin tuotteen työlista esiteltiin luvussa 4.1.1. Kanban-menetelmää ei kuitenkaan hyödynnetty tehokkaasti. Tiimissä A Kanban-taulujen käyttö vaihteli suuresti projektin aikana. Tiimiläisten mielestä niiden käyttö oli koko projektin ajan turhaa ja häiritsevää. Tästä johtuen niiden käyttö muuttui lopulta raportoinniksi suoritetuista tehtävistä. Kummassakaan tiimissä tauluihin ei voitu luottaa, joten niillä ei voinut tehokkaasti visualisoida projektin tilaa. Luvussa 4.3.2 esitetystä kuvasta 18 ilmenee, että Kanban-prosessi oli monimutkainen. Usean eri Kanban-taulun käyttö ei ollut tehokasta. Kaksi tiimiä olisi voinut hyödyntää yhteistä sähköistä taulua, joka näkyisi esimerkiksi työtilojen seinillä olevilta näytöiltä. Tällöin vuokaaviosta poistuisi toinen reitti ja prosessi yksinkertaistuisi ja tehostuisi. Sähköiseen Kanban-tauluun olisi suositeltavaa lisätä ainakin sarakekohtainen WIP, jolla vältetään tukoksia. Arvovirtauksen tehokkuuden määrittelyksi olisi voitu tehdä arvovirtakartta vuokaavion lisäksi. Koska toimintojen välisiä odotteluita ei selvitetty, arvovirtakartasta olisi tullut epätarkka. Vuokaaviosta voidaan kuitenkin päätellä, että tiimin B 79 arvovirta oli tehokas, ehkä jopa liian yksinkertainen selventääkseen tehtävän tilaa. Tiimissä A käytettiin kahta polkua yhden tehtävän suorittamiseen, mikä monimutkaisti prosessia. Toimintoja oli tarpeeksi selventämään tehtävän tilaa, mutta arvovirtaa olisi mahdollista virtaviivaistaa poistamalla toinen reitti kaaviosta. 5.1.3 Hajautetun projektin Lean-näkökulma Suoritetun tutkimuksen perusteella CoT-projektissa ei toimittu Lean-losoan mukaisesti poistaen aktiivisesti hukkaa. Arvovirtaa olisi voitu tehostaa ja työtavoista löytyi parannettavaa. Tuloksista ei ole kuitenkaan mahdollista tehdä yleistystä, ettei hajautettu ohjelmistokehitys voisi olla Lean-periaatteiden mukaista. Tutkielman pääkysymystä voidaan lähestyä aiemmin luvussa 2.2.7 esiteltyjen kahden taulukon avulla analysoimalla, voiko jokin hajautuksen kannalta erityinen tekijä estää projektia olemasta Lean-periaatteiden ja -päämäärien mukainen. Onko esimerkiksi odottelua eri tiimien välillä aina siinä mittakaavassa, että siitä tulee merkittävä hukka? Globaaleissa projekteissa, joissa päällekkäistä työskentelyaikaa on vähän, riski pitkiin odotusaikoihin on selvä. Jatkoanalyysi on niin laaja, että se vaatii jatkotutkimusta. Projektissa kartoitetut hukat on esitetty luvun 4.2.1 taulukossa 10. 5.2 Suosituksia Tehottomasta kommunikaatiosta ja puutteellisesta yhteistoiminnasta aiheutunutta hukkaa voidaan pyrkiä ehkäisemään hajautetuissa projekteissa monin eri tavoin. Ratkaisuksi on ehdotettu muun muassa ketteriä menetelmiä [VäK08, SMÅ10], mutta kyseisen hukan ehkäisemiseen liittyy muutakin. Seuraavassa ehdotetaan hajautettujen projektien yhteistoiminnan ja kommunikaation tehostamiseksi tarkistuslistaa, joka on johdettu tapaustutkimuksesta. 80 5.2.1 Ehdotus hajautettujen projektien tarkistuslistaksi Tarkistuslista on johdettu luvussa 4.2.2 käsitellystä kalanruotokaaviosta. Listan jaottelu voitaisiin tehdä monella tapaa, mutta ohessa on haluttu seurata kalanruotokaavion jaottelua. Tarkistuslista on tarkoitettu pienille hajautetuille projekteille, joissa tiimejä on 23. Ihmiset Hajautetun projektin alussa on tarpeellista järjestää aloitustapaaminen. CoT-projektissa tiimi B saapui puoleksi päiväksi pisteeseen A, jossa pidettiin yhteinen kokous. Tämä ei ollut tarpeeksi luottamuksen saavuttamiseksi, mikä näkyi asenteissa ja ennakkoluuloissa. Parin päivän työskentely yhdessä olisi saattanut parantaa tilannetta. Aloitustapaamisen jälkeen tiimien on siis työskenteltävä yhteisessä tilassa vähintään 12 päivän ajan, jolloin toiset tiimiläiset tulevat tutuiksi. Lisätapaamisia järjestetään tarpeen mukaan erityisesti projektin ongelmallisissa kohdissa. Tällainen tilanne projektissa oli niin sanottu henkinen romahtaminen projektin puolivälin jälkeen, kun tiimi A halusi pitää yhden päivän lomaa tekemättä mitään. Lisätapaaminen olisi saattanut vähentää turhautumista, kun asioita oltaisiin voitu purkaa yhdessä. Tehokkaat ja monipuoliset kommunikaatiovälineet ovat tärkeitä työvälineitä hajautetuissa projekteissa. Sekä muodolliseen että epämuodolliseen kommunikaation tarkoitettuja välineitä tarvitaan. CoT-projektissa ei ilmennyt puutteita kommunikaatiovälineissä, vaan havaitut ongelmat liittyvät niiden käyttöön. Tiimiläisten osaamisen kartoitus on oleellinen osa aloitustapaamista. Ihmiset kokevat olevansa hyödyllisia ja arvostettuja, kun saavat tehdä osaamaansa työtä. CoT-projektissa tehtävät jaettiin pitkälti osaamisen mukaan: tiimissä A toteutettiin enemmän sovelluksen logiikkaa ja tiimissä B suunniteltiin enemmän käyttöliittymää. 81 Prosessit Tarkistuslistaan on valittu Kanban, sillä se on Lean-losoan mukainen menetelmä, jolla visualisoidaan projektin tila. CoT-projektissa menetelmän hyödyntäminen oli epäsäännöllistä ja puutteellista. Hajautetussa projektissa Kanban tulisi olla verkossa kaikkien tiimien muokattavissa, ilman eri kaistoja ja taulu voisi olla myös työtilojen seinillä erillisillä näytöillä. Paasivaaran ja Lasseniuksen [SMÅ10] mukaan Scrum-kokoukset ovat tärkein Scrum-käytäntö hajautetuissa projekteissa. Hajautetussa ympäristössä Scrum-kokoukset voidaan pitää yhteisesti. Koska kasvokkainen kommunikaatio ei ole mahdollista, kokous voidaan pitää videoneuvotteluna. CoT-projektista puuttuneet yhteiset kokoukset olisivat lisänneet tiedon välitystä, koheesioita ja luottamusta tiimien välillä sekä nopeuttaneet ongelmien havaitsemista. Lyhyet pyrähdykset selkeine päämäärineen lisäävät Välimäen ja Kääriäisen [VäK08] mukaan hajautettujen projektien näkyvyyttä ja parantavat tiimiläisten motivaatiota. Eri tiimit saavat tasaisin aikavälein palautetta tekemästään työstä, jolloin projektin suunnittelu ja muuttaminen on joustavampaa. Pyrähdysten suunnittelu voidaan tehdä yhdessä eri tiimien kesken. Tiimien yhteiset sähköiset työlistat ovat tärkeitä hajautetuissa projekteissa. Listojen on oltava kaikkien nähtävillä. Kun tiimejä on vähän, voidaan pitää yhteiset demotilaisuudet, jolloin palautetta voidaan antaa ja vastaanottaa tehokkaasti. Kaikkien tiimiläisten ei tarvitse osallistua demotilaisuuteen. Retrospektiivi on tiimien pitämä kokous, jossa tarkastellaan pyrähdyksen onnistumista tuotteen kannalta. Kokous pidetään pyrähdyksen päätteeksi. CoT-projektissa pidettiin demotilaisuuden päätteeksi pieni keskustelu päättyneestä pyrähdyksestä, mutta jäi epäselväksi, kuinka hyödyllinen tämä kokous oli. Retrospektiivissä voidaan hyödyntää luvussa 2.2.4 käsiteltyä ongelmanratkaisumallia PDCA. 82 Ohjelmiston elinkaarenhallinta -työkaluilla (Application Lifecycle Management tool, ALM) mahdollistetaan kellonajasta riippumaton tiedon jakaminen ja hallinta [VäK08]. Samalla ALM parantaa kommunikaatiota ja yhteistoimintaa. ALM integroi kaikki projektissa tarvittavat tiedot yhteen paikkaan. Kokonaisvaltainen ALMratkaisu on kuitenkin kallista [Kol11]. Oletettavasti halvempi ratkaisu on varmistaa, että kaikki tarvittava tieto on tallessa jossain turvallisesti ja löydettävissä helposti. Tieto/taito Jos tiimiläisillä ei ole kokemusta hajautetussa projektissa työsken- telystä, tulee siitä tarjota ohjeistusta projektin alussa. Tiimiläisten on ymmärrettävä perusperiaatteet hajautetusta ohjelmistokehityksestä, jottei sitä voida tietämättömyydestä johtuvista syistä pitää tekosyynä joidenkin ongelmien syntyyn. CoT-projektissa hajautuksen ajateltiin olevan syy osaan kommunikaatio-ongelmista. Vaikka hajautus aiheuttaakin kommunikaatio-ongelmia, niiden tiedostaminen vähentänee niistä aiheutuvaa stressiä. Myös muun ohjeistuksen tulee olla riittävää. Projektin alussa sitoudutaan arvostamaan toisia projektilaisia ja ymmärretään, että kaikilla on erilaiset kokemustaustat ja kyvyt. Tämä tarkoittaa, että muiden mielipiteitä kuunnellaan, toisia rohkaistaan ilmaisemaan omat mielipiteensä ja tiimiläisten annetaan itse valita tehtävänsä. Ympäristö Koska projekteissa tarvitaan usein asiakkaan resursseja, on asiakkaan oltava valmistautunut ja sitoutunut projektiin heti alusta alkaen. CoT-projektissa asiakkaan resursseja olivat esimerkiksi asiakkaan palomuuri. Tuoteomistajat eivät tienneet vielä projektin puolivälissä, että palomuuria ei tulla saamaan auki. Tämä aiheutti turhaa työtä ja odottelua. Asiakas oli sitoutunut ja valmistautunut, mutta vuodenvaihteessa tiukentuneet tietoturva-asiat aiheuttivat projektille odottamattomia ongelmia. Selkeät tavoitteet ja odotukset projektilta lisäävät arvon tuntemusta. CoT- 83 projektissa asiakkaalla ei ollut selkeitä odotuksia projektilta, sillä ainut tavoite oli tuottaa protyyppi, johon tehdään niin paljon toiminnallisuuksia kuin ehditään. Tiimiläiset kokivat tämän stressaavaksi, eikä heillä ollut aina selkeää kuvaa siitä, mikä toiminnallisuus tai tehtävä on asiakkaalle tärkein, vaikka toteutettavat toiminnallisuudet priorisoitiin tuoteomistajan toimesta viikoittain. Kirjoittaja ei saanut selvitettyä syytä tähän epäselvyyteen. Joka tiimissä on tunnettava toimiala ja toiminnallisuudet, joita sovellukseen ollaan tuottamassa. Välimäen ja Kääriäisen mukaan tietoa tiimien välillä voidaan jakaa vierailijoiden toimesta ja käyttämällä toteutusvaiheen työlistaa, johon on määritelty toiminnallisuuksien tarkemmat ominaisuudet. CoT-projektissa tuoteomistaja T1 vieraili tasaisin väliajoin kummassakin pisteessä. Kuten aiemmin on käynyt ilmi, tämä ei välttämättä riittänyt tiedon kulkuun tiimien välillä, koska tuoteomistajan kanssa päätettyjä aioita ei aina välitetty toiselle tiimille. Ratkaisuna tähän kirjoittaja ehdottaa sopimuksia toimintatavoista ja -käytännöistä. Voidaan esimerkiksi laatia sopimus, että tuoteomistajan kanssa päätetyt asiat talletetaan jonnekin kaikkien tiedossa olevaan paikkaan, jonne kaikilla tietoa tarvitsevilla henkilöillä on pääsy. Eräs testaamisen arvoinen ratkaisu voisi olla tiedon tallettaminen verkkosivulle, josta tiimiläisille lähtee RSS-ilmoitus aina kun sivua päivitetään. Tällöin jokainen tiimi pysyy ajantasalla päätetyistä asioista, ja tuoteomistaja voi luottaa siihen, että asia välittyy joka pisteeseen. Johtaminen Kirjoittaja suosittelee, että hajautus toteutetaan Scrum-prosessi- mallilla, jossa tiimien välisessä kommunikaatiossa otetaan huomioon suurempi muodollisuuden tarve. Ennen projektin alkua on selvitettävä, jos tarvitsee järjestää Scrum-koulutusta. Sovittuja menetelmiä ja käytäntöjä on noudatettava tai toimintatapojen epäsäännöllisyys aiheuttaa ihmisten ylikuormitusta, joka edelleen aiheuttaa erinäisiä hukkia [Wom06]. 84 Tiimit saattavat tarvita myös Kanban-koulutusta. Jos tiimeillä on yhteinen koulutus, voidaan samalla sopia kuinka yhteistä Kanban-taulua aletaan hyödyntää. Tulee sopia ainakin saraketyypit ja sarakekohtaiset WIP-luvut. CoT-projektissa oli jonkinlainen koulutus, mutta eri pisteissä menetelmää hyödynnettiin eri lailla. Jokaiseen tiimiin täytyy Välimäen ja Kääriäisen [VäK08] mukaan järjestää tarvittavat Scrum-roolit, jotta kommunikaatio olisi tehokasta eri pisteiden välillä. Samat roolit on järjestettävä jokaiseen pisteeseen. Yhdellä henkilöllä voi olla myös monta roolia. CoT-projektissa ei nimetty rooleja tuoteomistajaa lukuun ottamatta. Scrum-prosessimalli oli useimmille täysin uusi asia, joten saattaa olla, ettei nimetyistä rooleista olisi ollut merkittävää hyötyä. Hajautettuja projekteja on vaikea koordinoida ja kontrolloida [ÅgF06]. Sovituilla toimintatavoilla ja -käytännöillä voidaan pyrkiä vähentämään tiimien välisiä yhteistoimintaongelmia. Sopimuksilla voidaan varmistaa, että eri pisteissä työskentelevät tiimiläiset noudattavat yhteisesti päätettyjä asioita ja siten tehostetaan myös yhteistoimintaa. Haastatteluissa ilmeni, että CoT-projektissa oltaisiin toivottu sopimuksia, joilla olisi estetty liian vahvojen persoonien dominoiminen. Laitteet/välineet Projektin alussa on varmistettava, että infrastruktuuri on no- pea ja tehokas. Tietoliikenneyhteyksien on toimittava hajautetussa projektissa moitteettomasti. Tarkistuslista Taulukkoon 11 on koottu hajautettua projektia varten lista, jo- ta täyttämällä voidaan tarkistaa, että tarvittavat asiat on huomioitu. Sarakkeeseen OK merkitään X, jos käytäntö on kunnossa ja järjestetty. Tarkistuslistaa voidaan tarkentaa projektikohtaisesti: kommunikaatiovälineisiin voidaan lisätä valitut välineet, ALM-työkalut voidaan tarkentaa, sopimukset voidaan listata tarkasti ja niin edelleen. 85 Kategoria Ihmiset Käytäntö OK Aloitustapaaminen ja työskentely yhdessä Lisätapaamiset tarvittaessa Tehokkaat kommunikaatiovälineet Osaamisen kartoitus Prosessit Yhteinen sähköinen Kanban Yhteiset Scrum-kokoukset Pyrähdykset _kpl ja niiden suunnittelu yhdessä Sähköiset työlistat Yhteiset demotilaisuudet Yhteiset retrospektiivit Tarvittavat ALM-ratkaisut Tieto/taito Tarpeeksi ohjeistusta projektin alussa Sitoudutaan arvostamaan toisia Ympäristö Valmistautunut ja sitoutunut asiakas Selkeät tavoitteet ja odotukset Tiedonkulku sidosryhmien ja tiimien välillä Johtaminen Tarvittaessa Scrum-koulutus Tarvittaessa Kanban-koulutus Tarvittavat Scrum-roolit Sopimukset toimintatavoista ja -käytännöistä Laitteet/välineet Tehokas infrastruktuuri Taulukko 11: Pienen hajautetun projektin tarkistuslista. 5.3 Tutkimuksen rajoitukset Tapaustutkimus on tutkimusmenetelmä, jossa keskitytään ymmärtämään yksittäistä tapahtumaa. Yhden tapaustutkimuksen tuloksista ei voida tehdä yleistyksiä, mutta 86 toisaalta niiden avulla on mahdollista tuottaa uudenlaisia teorioita [Eis89]. Suoritetusta tapaustutkimuksesta ei näin ollen voitu johtaa yleistyksiä, mutta tuloksista voitiin kuitenkin johtaa jatkotutkimuksen aiheita. Tieteellisestä näkökulmasta on tärkeää huomioida, että tutkimuksen tulokset perustuvat haastateltavien subjektiivisiin näkemyksiin ja kirjoittajan tulkintoihin havainnoistaan. Koska kyseessä oli hajautettu projekti, havainnoija ei voinut olla paikan päällä kummassakin pisteessä. Siten voidaan ajatella, että havaintojen määrä oli karkeasti puolet siitä, mitä se olisi voinut olla keskitetyssä projektissa. Havainnot olisivat voineet olla erilaisia toisessa pisteessä, jossa kaikki puhuivat suomen kieltä. Haastateltaviksi valittiin vain suomalaisia opiskelijoita. Vaikka projektissa oli eniten suomalaisia henkilöitä, olisi voinut olla hyödyllistä haastatella myös muiden kulttuurien edustajia. Tutkimusta olisi voinut monipuolistaa myös haastattelemalla Software Factoryn opettajia ja tuoteomistajia. 6 Yhteenveto Tutkielman tavoitteena oli selvittää, missä määrin hajautettu ohjelmistokehitys voi olla Lean-periaatteiden ja päämäärien mukaista. Ohjelmistoprojektien hajautusta ja Lean-ohjelmistokehitystä on tutkittu erillisinä teemoina, mutta yhdistettynä niitä on tutkittu vähemmän. Tutkielmassa ongelmaa analysoitiin lähdekirjallisuutta hyödyntäen ja suorittamalla empiirinen tapaustutkimus. Lean-losoa sisältää useita periaatteita ja päämääriä. Arvoa tuottamaton toiminta eli hukka on Leanlosoan keskeisin käsite, sillä sen määrä kuvaa tietyllä tasolla projektin tehokkuutta. Tutkimuskysymystä lähestyttiin analysoimalla mitä hukkia projektissa esiintyi ja kuinka tehokasta tiimiläisten työnkulku oli. 87 Tutkielman materiaalia varten käsiteltiin aiheen kannalta keskeisimmät käsitteet: hajautettu ohjelmistokehitys, Lean-losoa ja yleisimmät ketterät kehitysmallit (agile software development). Hajautus voi olla ajallista, maantieteellistä tai sosiokulttuurista. Lisäksi se voidaan nähdä ulkoistamisena tai yrityksen omien resurssien käyttämisenä ja lokaalina tai globaalina. Kirjallisuudessa ei ole vielä yksimielisyyttä siitä, miten hajautus tulisi organisoida, jotta työskentely olisi tehokasta. Joidenkin mielestä hajautus ei ole koskaan kannattavaa. Hajautus on kuitenkin yleistä, vaikka siihen liittyy uhkia. Riippuu usein katsantokannasta, nähdäänkö jokin seikka uhkana vai etuna. Lean-losoan päämääränä on jatkuva prosessien tehostaminen ja arvon tuottaminen asiakkaalle. Arvoa tuotetaan poistamalla toiminnoista kaikki havaitut hukat. Ohjelmistoprosesseja voidaan tehostaa hyödyntämällä ketterien kehitysmallien menetelmiä ja käytäntöjä. Esimerkiksi pienet julkaisut lisäävät arvoa tarjoamalla kehittäjille arvokasta palautetta usein. Tutkielmassa suoritettiin tapaustutkimus Software Factory -kurssilla talvella 2011. Tapaustutkimuksen projekti oli hajautettu kahteen pisteeseen. Toisessa pisteessä työskenteli suomenkielisiä ja toisessa sekä suomenkielisiä että ulkomaalaisia yliopisto-opiskelijoita. Tutkimuksen aineisto kerättiin havainnoimalla työskentelyä paikan päällä ja haastattelemalla kehittäjiä. Tehoton kommunikaatio on hukka, joka aiheuttaa merkittäviä ongelmia hajautetuissa projekteissa. Kommunikaatiota voi olla liian vähän tai se voi olla laadullisesti heikkoa. Tehoton kommunikaatio aiheuttaa myös muita hukkia ja on sen vuoksi erityisen merkittävä hukka. Kirjoittaja valitsi tutkielman tarkemman analyysin kohteeksi yhteistoimintaongelmat ja siihen vahvasti liittyvän tehottoman kommunikaation. Tapaustutkimuksen projektissa havaittiin tehottoman kommunikaation lisäksi myös muita hukkia ja työnkulku olisi voinut olla tehokkaampaa. Osa hukista olisi ollut ehkäistävissä järjestelmällisyydellä ja sovittuja asioita noudattamalla. Käytet- 88 tyä Kanban-mentelmää yksinkertaistamalla oltaisiin voitu tehostaa työnkulkua ja poistaa joitakin hukkia kuten tehtävien vaihtelu. Tapaustutkimuksella ei pyritty tuottamaan yleistettäviä vastauksia tutkimuskysymyksiin, vaan tavoitteena oli analysoida tulosten merkittävyyttä. Tuloksista voitiin johtaa jatkotutkimuksen aiheita. 6.1 Jatkotutkimuksen aiheita Tutkielmassa ei otettu kantaa projektin tuottamaan ohjelmiston arkkitehtuuriin, vaikka siitä on olemassa seikkaperäinen dokumentaatio. Conwayn lain [Con68] mukaan ohjelmiston arkkitehtuuri heijastaa sitä rakentavan organisaation rakennetta. Lakia tulee tutkia vielä hajautetussa ympäristössä, jotta saadaan selville, heijastaako hajautetun projektin toteuttama ohjelmiston arkkitehtuuri tiimien rakennetta. Tuloksista voidaan analysoida tiimien välistä kommunikaatiota. Kanban visualisoi työnkulkua ja siten se on hyödyllinen työkalu hajautetuissa projekteissa. Jatkotutkimusta tarvitaan selvittämään, kuinka Kanban-menetelmää olisi tehokkainta hyödyntää hajautetuissa projekteissa, kun tiimejä on useampi kuin kaksi. Käyttöliittymää suunnitellut UCD-kurssi oli liian eristetty muusta projektista. Yhteistoiminta tiimien ja UCD-kurssin välillä olisi voinut olla tehokkaampaa. Käyttöliittymäsuunnittelun ja Scrum-kehitysmallin menestyksellinen yhdistäminen hajautetuissa projekteissa tarvitsee lisätutkimusta. Jatkotutkimuksessa työnkulkua tulee kartoittaa mahdollisen vuokaavion lisäksi myös arvovirtakartoilla, joilla havainnollistetaan odottelun aiheuttamaa hukkaa. Luvussa 5.2.1 ehdotettua hajautetuille projekteille tarkoitettua tarkistuslistaa yhteistoiminnan ja kommunikaation tehostamiseksi täytyy tutkia vielä lisää ja tarkentaa. 89 Poppendieckien [PoP06] mukaan tuotteella pitää olla konsepti ennen sen toteuttamista. Projektissa täydellistä konseptia ei ollut ja moni tiimiläinen koki sen ongelmaksi. Koettiin, että tekemisestä puuttui tavoitteellisuus. Tutkimusta aiheesta tulee jatkaa tarkastelemalla, missä määrin hajautettu ohjelmistokehitys voi olla Lean-periaatteiden ja -päämäärien mukaista, kun konseptia ei olla määritelty täydellisesti. Tutkielman aihe oli laaja, eikä tulosten odotettu kattavan kaikkia hajautetussa projektissa ilmeneviä ongelmia. Oleellista oli analysoida, mistä kartoitetut hukat johtuivat ja olisiko joitakin niistä voitu ehkäistä. Suoritetusta tapaustutkimuksesta ei voida tehdä yleistettäviä johtopäätöksiä kysymykseen, voiko kehitystyö hajautetussa ympäristössä olla Lean-periaatteiden ja päämäärien mukaista. Vastausta varten tarvitaan lisää tutkimusta. Lähteet Abr10 Abrahamsson, P., Unique Infrastructure Investment: Introducing the Software Factory. URL Agi01 Software Factory Magazine, http://www.softwarefactory.cc/. Principles Behind the Agile ASR02 [30.8.2011]. Manifesto., agilemanifesto.org/principles.html. 1,1(2010), sivut 23. 2001. http:// [12.4.2011]. Abrahamsson, P., Salo, O., Ronkainen, J. ja Warsta, J., Agile Software Development Methods: Review and Analysis. portti, VTT Publications, 2002. URL publications/2002/P478.pdf. Bas93 URL Tekninen ra- http://www.vtt.fi/inf/pdf/ [23.5.2011]. Basili, V. R., Applying the Goal/Question/Metric Paradigm in the Experience Factory. Proceedings of the Tenth Annual CSR (Centre for 90 Software Reliability) Workshop, Application of Software Metrics and Quality Assurance in Industry, Bec99 Beck, K., 1993, sivut 123. Extreme Programming Explained: Embrace Change. Addison- Wesley Professional, 1999. BXV10 Barta, D., Xia, W., VanderMeer, D. ja Dutta, K., Balancing Agile and Structured Development Approaches to Successfully Manage Large Distributed Software Projects: A Case Study from the Cruise Line Indus- Communications of the Association for Information, try. 27,1(2010), sivut 379394. Cal08 Caldwell, K., Managing Outcomes in a Lean Enterprise. azine. Quality Mag- http://www.qualitymag.com/CDA/Articles/Feature_ URL Article/BNP_GUID_9-5-2006_A_10000000000000452187. CoC05 [12.4.2011]. Cook, C. ja Churcher, N., Modelling and Measuring Collaborative Software Engineering. Proceedings of ACSC2005: Twenty-Eighth Aus- tralasian Computer Science Conference, volume 38 of Conferences in Research and Practice in Information Technology, Con68 Conway, M. E., How Do 14,5(1968), sivut 2831. URL committees.html. CuS96 Cusumano, an M. Approach ware Product Institute 1996. of URL Datamation, Invent? http://www.melconway.com/research/ [8.8.2011]. A. for Committees 2005, sivut 267277. ja Selby, Balancing Development. Technology R. W., Flexibility Synchronize-and-stabilize: and Tekninen (MIT), Sloan Structure raportti, School of in Soft- Massachusetts Management, http://dspace.mit.edu/bitstream/handle/1721.1/ 2636/SWP-3930-36131765.pdf?sequence=1. [18.7.2011]. 91 Eis89 Eisenhardt, search. 550. K. M., Building Theories The Academy of Management Review, URL Case Study Re- 14,4(1989), sivut 532 http://pages.cpsc.ucalgary.ca/~sillito/cpsc-601. 23/readings/eisenhardt-1989.pdf. Åge06 from [13.9.2011]. Ågerfalk, Pär, J., Towards Better Understanding of Agile Values in Global Software Development 1. Proceedings of the Workshop on Ex- ploring Modeling Methods for Systems Analysis and Design (EMMSAD'06), held in conjunctiun with the 18th Conference on Advanced Information Systems (CAiSE'06), Luxembourg, Luxembourg, EU, 2006, sivut 375382. ÅgF06 Ågerfalk, Pär, J. ja Fitzgerald, B., Flexible and Distributed Software Processes: Old Petunias in New Bowls. Communications of the ACM, 49,10(2006), sivut 2734. GMS10 Green, R. Mazzuchi, T. ja Sarkani, S., Communication and Quality in Distributed Agile Development: An Empirical Case Study. Academy of Science, Engineering and Technology, World 61,49(2010), sivut 322328. GSL07 Graebsch, M., Seering, W. P. ja Lindemann, U., Assessing Information Waste in Lean Product Development. Proceedings of the 16th Interna- tional Conference on Engineering Design (ICED07), Gum07 Gumm, D.-C., Mutual Dependency of Distribution, Benets and Causes: An Empirical Study. Proceedings of the International Conference on Global Software Engineering (ICGSE '07), HeG99 2007, sivut 112. 2007, sivut 113124. Herbsleb, J. D. ja Grinter, R. E., Splitting the Organization and In- 92 HMF01 tegrating the Code: Conway's Law Revisited. in 21st International Conference on Software Engineering (ICSE 99), 1999, sivut 8595. Herbsleb, J. D., Mockus, A., Finholt, T. A. ja Grinter, R. E., An Empirical Study of Global Software Development: Distance and Speed. In 23nd International Conference on Software Engineering, 2001, sivut 8190. HVZ04 Huo, M., Verner, J., Zhu, L. ja Babar, M. A., Software Quality and Agile Methods. Computer Software and Applications Conference, 2004. COMPSAC 2004. Proceedings of the 28th Annual International, 2004, sivut 520525. Koa07 Korkala, M. ja Abrahamsson, P., Communication in Distributed Agile Development: A Case Study. EUROMICRO-SEAA, 2007, sivut 203 210. Kol11 Kolehmainen, A., Alm:stä tulee arkipäivää. Tietoviikko. URL http://www.tietoviikko.fi/kaikki_uutiset/almsta+tulee+ arkipaivaa/a583887. Kon08 [13.9.2011]. Kontio, M., Architectural manifesto: Adopting agile development, Part 1, 2008. URL http://www.ibm.com/developerworks/architecture/ library/ar-archman1/index.html. KnS09 Kniberg, H. ja Skarin, M., Kanban and Scrum making the most of both. Information Queue. kanban-scrum-minibook. Lar08 [26.7.2011]. Larman, C., URL http://www.infoq.com/minibooks/ [8.8.2011]. Scaling Lean and Agile Thinking and Orga- nizational Tools. Addison-Wesley Professional, 2008. URL http://www.craiglarman.com/wiki/index.php?title=Book_-_ 93 Scaling_Lean_and_Agile_-_Thinking_and_Organizational_Tools. [23.5.2011]. Lar10 Larman, C., Practices for Scaling Lean & Agile Develop- ment: Large, Multisite, and Oshore Product Development with Large-Scale Scrum. Addison-Wesley Professional, 2010. URL http://www.craiglarman.com/wiki/index.php?title=Book_-_ Practices_for_Scaling_Lean_and_Agile. Lar11 Larman, C., Scaling Lean & Agile: Large, Multisite or Oshore Delivery. Information Queue. URL http://www.infoq.com/presentations/ Large-Multisite-or-Offshore-Delivery. LeY10 [23.5.2011]. [8.8.2011]. Lee, Seiyoung ja Yong, H.-S., Distributed Agile: Project Management in a Global Environment. Empirical Software Engineering, 15,2(2010), sivut 204217. Les11 Leskinen, S., Ken on maassa ketterin? Tietokone, 12,5(2011), sivut 5458. Mac05 MacManus, H. L., (PDVSM) Manual. Product Development Value Stream Mapping Väitöskirja, MIT Lean Advancement Initiative, 2005. Mäe11b Mäenpää, P., Haastattelut ja jälkiarvioinnit: Software Factory - projekti., 2011. Mäe11a Mäenpää, P., Havainnointipäiväkirja: Software Factory -projekti., 2011. MoH01 Mockus, A. ja Herbsleb, J., Challenges of Global Software Development. Proceedings of the 7th International Symposium on Software Metrics, 2001, sivut 182184. 94 Mid01 Middleton, P., Lean Software Development: Two Case Studies. Quality Control, MiJ11 Software 9,4(2001), sivut 241252. Middleton, P. ja Joyce, D., Lean Software Management: BBC Worldwide Case Study. Engineering Management, IEEE Transactions on, 99, sivut 113. OHÅ06 Ó Conchúir, Eoin and Holmstrom, Helena and Ågerfalk, Pär and Fitzgerald, Brian, Global Software Development: Never Mind the Problems Are There Really Any Benets? search Seminar in Scandinavia, Ohn88 Ohno, T., 29th Information Systems Re- 2006, sivut 114. Toyota Production System: Beyond Large-Scale Production. Productivity Press, 1988. PAD07 Prikladnicki, R., Audy, J., Damian, D. ja de Oliveira, T., Distributed software development: Practices and challenges in dierent business strategies of oshoring and onshoring. Global Software Engineering, 2007. ICGSE 2007. Second IEEE International Conference on, 2007, sivut 262274. Paa10 Paasivaara, M., af Ornäs, N. H., Hynninen, P., Lassenius, C., Niinimäki, T. ja Piri, A., Practical Guide to Managing Distributed Software Development Projects. Tekninen raportti, Aalto University School of Sciense and Technology, 2010. PDL08 Paasivaara, M., Durasievwicz, S. ja Lassenius, C., Distributed Agile Development: Using Scrum in a Large Project. Global Software Engi- neering, 2008. ICGSE 2008. IEEE International Conference on, sivut 8795. 2008, 95 PHS08 Pikkarainen, M., Haikara, J., Salo, O., Abrahamsson, P. ja Still, J., The Impact of Agile Practices on Communication in Software Development. Empirical Software Engineering, Pic08 13,3(2008), sivut 303337. Pichler, R., The Three M's - The Lean Triad. Information Queue. URL http://www.infoq.com/articles/lean-muda-muri-mura. [8.8.2011]. PaL06 Paasivaara, M. ja Lassenius, C., Could Global Software Development Benet from Agile Methods? Proceedings of the IEEE international conference on Global Software Engineering, PoP06 Poppendieck, M. ja Poppendieck, T., velopment: From Concept to Cash. Ram98 2006, sivut 109113. Implementing Lean Software De- Addison-Wesley Professional, 2006. Raman, S., Lean Software Development: Is it Feasible? Avionics Systems Conference. The AIAA/IEEE/SAE, 17th Digital 1,1(1998), sivut 1318. RCM06 Ramesh, B., Cao, L., Mohan, K. ja Xu, P., Can Distributed Software Development Be Agile? Communications of the ACM, 49,10(2006), sivut 4146. RuH09 Runeson, P. ja Host, M., Guidelines for Conducting and Reporting Case Study Research in Software Engineering. ing, Roy70 Empirical Software Engineer- 14,2(2009), sivut 131164. Royce, W. W., Managing the Development of Large Software Systems. Technical Papers of Western Electronic Show and Convention WesCon, 1970, sivut 19, URL http://www.cs.umd.edu/class/spring2003/ cmsc838p/Process/waterfall.pdf. SMÅ10 [2.9.2011]. Smite, D., Moe, N. B. ja Ågerfalk, P. J., Springer, 2010. Agility Across Time and Space. 96 SWL99 Sobek, D. K., Ward, A. C. ja Liker, J. ples of Set-Based Concurrent Engineering. view, 40,2(1999), sivut 6783. Toyotas.pdf. VäK08 URL K., Toyota's Princi- Sloan Management Re- http://6sigma.mty.itesm.mx/ [19.7.2011]. Välimäki, A. ja Kääriäinen, J., Patterns for distributed scrum - a case study. Proceedings of the 4th International Conference on Interoperabil- ity for Enterprise Software and Applications, IESA 2008, 2008, sivut 8597. WoJ96a Womack, J. P. ja Jones, D. T., Beyond Toyota: How to Root Out Waste and Pursue Perfection. Harvard Business Review, Lean Thinking. WoJ96b Womack, J. P. ja Jones, D. T., WJR90 Womack, J. P., Jones, D. T. ja Roos, D., the World. Wom06 Rawson Associates, 1990. URL muda.pdf. Simon & Schuster, 1996. The Machine That Changed Womack, J., Mura, Muri, Muda? ELetter. my. 74, sivut 140158. Lean Enterprise Acade- http://www.leanuk.org/downloads/jim/mura_muri_ [4.4.2011]. 1 Liite 1. Sanasto Ohessa on listattu CoT-projektiin liittyvien termien selitykset. Asiakas Tieto Oyj Tuoteomistaja Tiimiläinen Asiakkaan edustaja Pisteessä A tai B työskentelevä kehittäjä Projektilainen Tuoteomistaja tai tiimiläinen 1 Liite 2. Haastattelukysymykset Tapaustutkimuksen haastatteluissa esitetyt kysymykset on listattu oheen. Jokainen haastattelu eteni eri lailla, joten kaikkia kysymyksiä ei esitetty kaikille haastateltaville. Prosessi ja työkalut Minkälainen prosessimalli teillä oli? Minkälainen työkaluketju (toolchain) tiimeillä on? Onko testausta paljon vielä edessä? Mitä erityistä työkaluketjussa on hajautuksen kannalta? Jouduttiinko tekemään enemmän koodin refaktorointia, koska projektissa on kaksi tiimiä? Suunnitellaanko pyrähdykset tiimien kesken? Saatiinko tuotettua tuote, jonka asiakas oli halunnut? Oliko asiakas tyytyväinen? Aiheuttivatko tekniset ongelmat vaikeuksia projektin etenemiseen? Onko siis Hudson-palvelimen toimimattomuus tiimiläisistä riippumaton asia? Kanban Miten Kanban-menetelmää hyödynnettiin? Oliko Kanban-taululla realistinen määrä tehtäviä? Määriteltiinkö tehtävät hyvin eli pilkottiinko tehtävät tarpeeksi pieniksi? Kuinka tehtävä hyväksyttiin suoritetuksi? Oliko odottelua? Jouduttiinko joskus keskeyttämään jokin tehtävä siksi, että huomattiin, että jokin muu asia on hoidettava loppuun ennen kyseistä tehtävää? Suunniteltiinko joitain tehtäviä liian aikaisin? liian tarkkaan? turhaan? Demo Käsiteltiinkö demossa vain demoon kuuluvia asioita? Miten tehtävät jaetaan tiimien kesken? Määriteltiinkö toiminnallisuudet demossa asiakkaan kanssa? Saatiinko demossa seuraavaan pyrähdykeen valitut tehtävät aina tehtyä ajallaan? Pystyttiinkö tehtäviä muokkaamaan niin, että ne ehdittäisiin tekemään seuraavaan demoon sovitusti? Kommunikaatio/Informaation kulku 2 Käytettiinkö tiimien väliseen kommunikaatioon sähköpostia? Oliko tehtävissä päällekkäisyyksiä tiimien välillä? Oliko sellaisia kehittäjäryhmä, joissa on henkilöitä kummastakin tiimistä? Oliko kommunikaatiota tiimien välillä tarpeeksi? Miten sitä voisi parantaa? Oliko kommunikaatiota tiimien ja asiakkaan välillä tarpeeksi? Miten Wikiä hyödynnettiin? Oliko tilanteita, ettei tiedetty mitä jonkin ohjelman toiminnallisuuden on tarkoitus tehdä? Miten tilanne on ratkaistu? Onko asiakas saatu aina tarvittaessa kiinni? Onko tarvittava tieto ollut aina saatavissa? Tiesivätkö kehittäjät aina, mitä heidän tulee tehdä? Oletteko joutuneet pyytämään toiselta tiimiltä apua? Jos tarvittiin apua, jouduttiinko odottelemaan toisen tiimin/henkilön vastausta? Oletko kokenut tätä ongelmaksi? Sosiaaliset näkökohdat Oliko kulttuuri- tai persoonallisuuseroilla merkitystä kommunikaatioon liittyen? Tulivatko tiimit hyvin toimeen keskenään? Vaikuttiko se työnkulkuun? Jouduttiinko asioita puskemaan läpi? Hajautus Miten hajautus näkyy projektissa? Onko asiakkaaseen oltu tarpeeksi yhteydessä? Miten hajautus toimi projektissa? Tarvittaisiinko hajautettuun projektiin henkilö, jolla on vahva näkemys siitä, mitä hajautus on?
© Copyright 2024