hyväksymispäivä arvosana
arvostelija
Mura, muri, muda – lean-filosofian hukkakäsitteet ohjelmistokehityksessä
Henri Karhatsu, Simo Moilanen
Helsinki 2.12.2009
HELSINGIN YLIOPISTO
Tietojenkäsittelytieteen laitos
HELSINGIN YLIOPISTO − HELSINGFORS UNIVERSITET – UNIVERSITY OF HELSINKI Tiedekunta/Osasto − Fakultet/Sektion – Faculty/Section
Matemaattis-luonnontieteellinen Laitos − Institution − Department Tietojenkäsittelytiede
Tekijä − Författare − Author
Henri Karhatsu, Simo Moilanen Työn nimi − Arbetets titel − Title Mura, muri, muda - lean-filosofian hukkakäsitteet ohjelmistokehityksessä Oppiaine − Läroämne − Subject Seminaari: Suurten ohjelmisto-intensiivisten järjestelmien ketterä kehittäminen Työn laji − Arbetets art − Level
Seminaari Aika − Datum − Month and year
2.12.2009 Sivumäärä − Sidoantal − Number of pages
17 Tiivistelmä − Referat − Abstract
Tässä seminaarityössä käsitellään valmistavan teollisuuden tarpeisiin kehitettyä lean-
tuotantofilosofiaa ohjelmistokehityksen näkökulmasta. Erityisesti keskitytään kolmeen hukka-
käsitteeseen, jotka ovat mura (työn epätasaisuus), muri (ylikuormitus) sekä muda (arvoa
tuottamaton toiminta). Lisäksi esitetään keinoja, joilla tätä hukkaa voidaan ohjelmisto-
kehityksessä poistaa.
Työssä havaitaan, että ohjelmistokehityksessä hukkaa on ihmisten ylikuormitus (muri), turha
vaihtelu työmenetelmissä (mura) sekä mudan osalta ylimääräiset toiminnot, keskeneräinen ja
odottava työ, tarpeeton käsittely, tehtävien vaihtuminen, testauksen läpäisseet virheet, odottelu
ja luovutukset.
Hukan poistoon ohjelmistokehityksessä löytyy työkaluja muun muassa ketteristä menetelmistä
(agile methods). Näitä ovat esimerkiksi Scrum-prosessimalli, lähellä asiakasta oleminen ja
lyhyet iteraatiot.
ACM Computing Classification System (CCS): D.2.9 Software engineering - Management
Avainsanat – Nyckelord − Keywords
lean, ohjelmistokehitys, hukka, muda, mura, muri Säilytyspaikka − Förvaringställe − Where deposited
Muita tietoja − Övriga uppgifter − Additional information
ii
Sisältö
1 Johdanto .................................................................................................... 1
2 Lean-ajattelu ja hukka ............................................................................... 3
2.1 Lean-filosofian historiaa ja perusperiaatteet ............................................................................ 3
2.2 Hukan kolme muotoa – mura, muri ja muda ........................................................................... 4
2.3 Muda ja sen alakäsitteet.............................................................................................................. 6
3 Lean-ajattelu ohjelmistokehityksessä ..................................................... 8
3.1 Lean-periaatteiden soveltuvuus ohjelmistokehitykseen ........................................................... 8
3.2 Hukka ohjelmistokehityksessä ................................................................................................. 10
3.3 Hukan poistaminen ohjelmistokehityksessä ............................................................................ 13
4 Yhteenveto ............................................................................................... 16
Lähteet ............................................................................................................. 18
1
1 Johdanto
Lean on toisen maailmansodan jälkeen Toyotalla kehitetty filosofia yrityksen toiminnan
ohjaamiseen [WJR90]. Leanissä yrityksen tuotantoketju pyritään virtaviivaistamaan
poistamalla siitä kaikki, mikä ei tuota arvoa eli on hukkaa (waste). Sittemmin lean-
ajattelua on alettu soveltaa myös ohjelmistotuotantoon.
Tässä seminaarityössä keskitytään ohjelmistokehityksessä esiintyviin hukan muotoihin
sekä keinoihin, joilla hukkaa saadaan poistettua. Hukan päämuodot ovat mura (työn
epätasaisuus), muri (ylikuormitus) ja muda (arvoa tuottamaton toiminta), joista
viimeisin jakaantuu useaan alakohtaan. Näistä kaksi ensimmäistä on jäänyt
tutkimuksessa vähemmälle huomiolle, ja siksi niihin kiinnitetään tässä seminaarityössä
erityistä huomiota.
Lean-kirjallisuudessa on kaksi tapaa määritellä hukka. Toisen mukaan hukkaa ovat
edellä kuvatut kolme asiaa eli mura, muri ja muda [mm. Cal08]. Toisen määritelmän
mukaan taas hukka on yhtä kuin muda eli kaikki arvoa tuottamaton toiminta [mm.
Smi06, Pic08]. Jälkimmäinen määritelmä perustuu ajatukselle, että epätasaisuus ja
ylikuormitus eivät sinänsä ole hukkaa mutta ne on syytä ottaa huomioon hukkaa
poistettaessa. Molemmat ovat kelvollisia määritelmiä, mutta tässä seminaarityössä
käytetään joka tapauksessa ensimmäistä; hukka sisältää siis sekä muran, murin että
mudan.
Seminaarityön tutkimuskysymys on: miten mura, muri ja muda esiintyvät ohjelmisto-
kehityksessä ja miten niitä voidaan poistaa? Tähän kysymykseen haetaan vastausta
esittelemällä aluksi leanin periaatteet ja hukan muodot yleisellä tasolla. Sen jälkeen
pohditaan kuinka lean soveltuu ohjelmistokehitykseen ottamalla leanin periaatteisiin
mukaan ohjelmistojen tuottamisen näkökulma. Lopuksi käsitellään ohjelmisto-
kehityksessä esiintyvää hukkaa ja sen poistamista. Työssä tullaan huomaamaan, että
leanin periaatteet ovat hyvin lähellä ketterän ohjelmistokehityksen periaatteita ja että
nimenomaan ketterät menetelmät tarjoavat paljon keinoja hukan poistamiseen.
2
Lean suomennetaan usein virtaviivaiseksi tai laihaksi, mutta vakiintunutta käännöstä ei
ole käytössä. Tässä seminaarityössä ohitamme suomennoksen ja käytämme termiä lean.
Alan englanninkielisessä kirjallisuudessa käytetään sanaa waste kuvaamaan toimintaa,
joka ei tuota lisäarvoa. Suomenkielisessä kirjallisuudessa tämä on suomennettu
vaihtelevin käytännöin esimerkiksi hukaksi, roskaksi tai jätteeksi. Tässä seminaari-
työssä englanninkielen sanasta waste käytetään suomen kielen sanaa hukka.
3
2 Lean-ajattelu ja hukka
Tässä luvussa kuvataan lean-ajattelua yleisellä tasolla sitomatta sitä mihinkään tiettyyn
toimialaan. Ensin käydään läpi leanin viisi periaatetta ja sen jälkeen esitellään erilaisia
hukan muotoja.
2.1 Lean-filosofian historiaa ja perusperiaatteet
Toyota Production System (TPS) on Toyota Motor Corporation:n käyttämä tapa ohjata
ja kehittää yrityksen toimintaa. TPS on kehitetty yrityksessä toisen maailmansodan
jälkeen. Sen kehittäjät Eiji Toyoda ja Taiichi Ohno totesivat, ettei Toyota pysty
toimimaan samoilla massatuotannon periaatteilla, joilla sen amerikkalaiset kilpailijat
toimivat. Toyotan tavoitteena oli valmistaa paljon erilaisia malleja pienissä erissä.
Keskeinen ajatus oli, että massatuotannossa syntyy paljon hukkaa, joka ei tuota arvoa.
Vaikka nopean talouskasvun aikaan tällä ei ollut suurta merkitystä, viimeistään 1970-
luvun öljykriisin yhteydessä paljastui Toyotan menetelmien vallankumouksellisuus.
[Ohn88, WJR90]
TPS koostuu viidestä perusperiaatteesta [WoJ96, Ram98]:
1. Määritellään mikä asiakkaan näkökulmasta lisää arvoa (value) ja mikä taas ei
lisää.
2. Tunnistetaan vaiheet, jotka lisäävät arvoa eli arvovirta (value stream). Arvo-
virrasta pyritään poistamaan kaikki se, mikä ei tuota arvoa eli on hukkaa
(waste).
3. Yritetään saada arvovirta virtaamaan (flow) tasaiseen tahtiin ilman keskey-
tyksiä, ylimääräisiä vaiheita ja varastoja, odottelua ja virheitä.
4. Tehdään vain sitä mitä asiakas pyytää ja vain silloin, kun asiakas pyytää (pull).
Ei siis tuoteta turhia ominaisuuksia, joilla ei ole asiakkaalle arvoa.
5. Pyritään täydellisyyteen (perfection) poistamalla hukkaa jatkuvasti.
Myöhemmin Womack ym. nimesivät TPS:n sen kantavan ajatuksen mukaan leaniksi
[WJR90].
4
Edellä mainitut periaatteet voidaan tiivistää seuraavalla tavalla. Yrityksen tuotantoketju
pyritään virtaviivaistamaan poistamalla siitä kaikki, mikä ei tuota asiakkaalle arvoa eli
on hukkaa. Tätä jatketaan tavoitellen koko ajan täydellisyyttä. Käytännössä jatkuva
kehittäminen johtaa siihen, että kun osa tuotantoketjusta saadaan tehokkaammaksi,
löytyy hukkaa ketjun toisesta osasta [HiT00].
Lean-ajattelussa on yksi erityisen mielenkiintoinen näkökulma verrattuna perinteiseen
massatuotantoon. Kun jälkimmäisessä pyritään olemaan riittävän hyviä, leanissa
pyritään täydellisyyteen. Massatuotannon tavoitteenasettelua perustellaan sillä, että
"liian hyvä" tulee liian kalliiksi tai se on inhimillisesti mahdotonta saavuttaa. Leanissa
taas uskotaan siihen, että aina voi tehdä paremmin; virheet voidaan saada kokonaan
pois, kustannuksia voidaan saada koko ajan pienemmiksi, tuotevariaatiota voidaan
jatkuvasti kasvattaa ja niin edelleen [WJR00].
Täydellisyyden tavoitteluun, arvovirran sujuvuuteen ja hukan eliminointiin liittyy käsite
jidoka. Se tarkoittaa laadun tarkkailua ja sisältää kaksi mekanismia, ongelmien
tunnistamisen ja tuotannon keskeyttämisen heti, kun jokin ongelma ilmenee [DJS08].
Esimerkiksi autoteollisuudessa tämä tarkoittaa sitä, että heti kun löytyy virhe, jota ei
pystytä välittömästi korjaamaan, koko tuotantolinja keskeytetään [WJR90]. Tavoitteena
on selvittää virheen syy välittömästi ennen kuin se alkaa kumuloitua prosessissa
eteenpäin. Jidoka-ajattelussa hyväksytään siis tuotannon keskeytykset ja tilapäiset
tehottomuudet, jotta saavutetaan laajemmassa mittakaavassa tehokkaampi prosessi
[Ohn88].
2.2 Hukan kolme muotoa – mura, muri ja muda
Leanissa pyritään siis tehostamaan tuotantoprosessia poistamalla siitä kaikki hukka eli
ne toiminnot, jotka eivät lisää asiakkaalle arvoa. Hukka jaetaan kolmeen kategoriaan,
jotka ovat mura, muri ja muda [Smi06]. Termit tulevat japanin kielestä ja niitä käytetään
alan kirjallisuudessa pääsääntöisesti sellaisenaan. Näistä yleisimmin käytetty muda
tarkoittaa tuhlaavaisuutta tai kaikkea arvoa lisäämätöntä toimintaa, mura työn
epätasaisuutta ja muri ihmisten tai koneiden ylikuormitusta [Smi06].
5
Käsitteitä on hyvä selventää esimerkin avulla. Mura eli työn epätasaisuus voi ilmetä
esimerkiksi siten, että työlinjalla kolmesta peräkkäisestä koneesta vain ensimmäinen
tekee kerrallaan työtä ja kaksi muuta ovat lepotilassa. Sama esimerkki toimii myös
murin eli ihmisten tai koneiden ylikuormituksen suhteen, näkökulma vain on hieman
erilainen. Kyseisessä tapauksessa luonnollisestikin työtä tekevä kone ylikuormittuu.
Kolmas käsite muda eli arvoa tuottamattomuus esiintyy esimerkissä ainakin turhan
odottelun muodossa, sillä kaksi jälkimmäistä konetta joutuvat odottamaan ensimmäisen
suoritusta, eivätkä siten pysty tuottamaan arvoa.
Esimerkin avulla on helppo havaita, kuinka kaikki kolme hukan muotoa ovat suhteessa
toisiinsa. Työn epätasaisuus (mura) johtaa joidenkin tuotantotekijöiden yli-
kuormittumiseen (muri), mikä taas aiheuttaa arvoa tuottamatonta toimintaa (muda),
yleensä monessakin eri muodossa [Wom06]. Toisaalta yhtä hyvin voidaan ajatella, että
muri johtaa muraan ja mudaan. Jos nimittäin esimerkiksi työntekijät ovat hyvin
ylikuormittuneita, he tekevät helpommin epätasalaatuisia tuotteita (mura) ja enemmän
virheitä (muda).
Kuva 2.1 havainnollistaa näiden kolmen hukkakäsitteen suhteita toisiinsa. Oleellista
kuvassa on huomata, että jos muda halutaan poistaa pysyvästi, täytyy ensin poistaa
mura ja muri.
Kuva 2.1: Muran, murin ja mudan suhde toisiinsa.
Muda
Mura
Muri
6
2.3 Muda ja sen alakäsitteet
Alan kirjallisuudessa eniten näkyvyyttä saanut hukan muoto on muda. Taiichi Ohno on
jakanut mudan seitsemään kategoriaan [Pop02]: ylituotanto, varastot, tarpeeton
käsittely, tarpeeton liike, virheet, odottelu ja kuljettaminen. Seuraavaksi kuvaillaan
tarkemmin, mitä nämä tarkoittavat.
Ylituotanto on joko liikaa tai liian aikaisin tuottamista. Lean-ajattelussa tuotetaan pull-
periaatteen mukaisesti vain asiakkaan tarpeen mukaan. Kaikki tarpeen yli tuottaminen
sitoo arvokkaita resursseja, joita voitaisiin muuten käyttää paremmin hyödyksi [HiT00].
Tarpeettomat varastot taas liittyvät ylituottamiseen. Asiakkaan tarvetta pyritään
mukailemaan rakentamalla tuotantolinja mieluummin vetäväksi (pull) kuin työntäväksi
(push) [HiT00]. Vetävä tarkoittaa esimerkiksi tietokonevalmistaja Dell:n tuotanto-
linjalla sitä, että tietokoneen valmistus aloitetaan vasta asiakkaan tilattua sen [PoP03].
Tilauksen tultua Dell valmistaa ja lähettää tietokoneen alle viikossa. Näin Dell ei joudu
pitämään valmistamiaan koneita varastossa ja esimerkiksi uuden näytönohjaimen tai
isomman kovalevyn tultua markkinoille, Dell voi tarjota sen asiakkailleen nopeammin
kuin kilpailijansa.
Tarpeetonta käsittelyä on esimerkiksi tuotteen uudelleen työstäminen tai tarkastaminen.
Tuote tulisi tehdä kerralla riittävän laadukkaaksi. Tuotteen korjaaminen laatuongelmien
takia tai välituotteen laadun tarkkailun tarve ovatkin oireita tuotantoketjun ongelmista.
Tarpeeton käsittely voi johtua esimerkiksi väärästä työkalusta, menetelmästä tai
järjestelmästä [HiT00].
Resurssit tulisi toimittaa käyttöön, ei varastoon. Lean-ajattelussa kuljettaminen
varastoon on esimerkki tarpeettomasta liikkeestä. Kaikki toimitukset pitäisi tehdä just-
in-time-periaatteen (JIT) mukaisesti suoraan toimittajalta tuotantoketjulle. Ylimitoitettu
kuljettaminen johtaa lisäksi tarpeettomaan varastoon [HiT00].
7
Virheellisten tuotteiden ja palveluiden alkuperäisen tuottamisen lisäksi virheiden
korjaaminen haaskaa resursseja. Lisäksi virheiden synnyttämien asiakaspalautteiden
käsittely ja hyvittäminen asiakkaalle kuluttavat resursseja [HiT00].
Myös odottaminen on lean-ajattelussa hukkaa, sillä silloin resurssit eivät ole parhaassa
mahdollisessa käytössä. Tuotantoketjun tulisi toimia edellä mainitun JIT-periaatteen
mukaisesti, eli tuotanto pitäisi saada virtaamaan tasaisesti [HiT00].
Tarpeeton kuljettaminen johtuu muun muassa vääränlaisesta työvuosta, huonosti
suunnitellusta tai epäsiististä työympäristöstä ja epäjohdonmukaisista tai dokumen-
toimattomista työskentelymenetelmistä [HiT00].
8
3 Lean-ajattelu ohjelmistokehityksessä
Tässä luvussa käsitellään lean-filosofiaa ohjelmistokehityksen näkökulmasta. Aluksi
pohditaan, kuinka lean ja sen periaatteet ylipäätään soveltuvat ohjelmistoteollisuuteen.
Tullaan huomaamaan, että samoja periaatteita voidaan hyödyntää myös
ohjelmistotuotannossa. Sen jälkeen pohditaan, minkälaista hukkaa ohjelmisto-
kehitykseen liittyy ja lopuksi esitetään, kuinka tätä hukkaa voidaan poistaa.
3.1 Lean-periaatteiden soveltuvuus ohjelmistokehitykseen
Lean-filosofiaa on alettu soveltaa valmistavan teollisuuden lisäksi myös ohjelmisto-
teollisuuteen [Mid01]. Ajatusmalli on se, että lean-ajattelu sopii kaikkiin prosesseihin ja
siten myös ohjelmistonkehitykseen [Ram98]. Luvussa 2 esiteltiin leanin viisi
periaatetta. Seuraavaksi pohditaan tarkemmin, kuinka hyvin ne soveltuvat ohjelmisto-
kehitykseen.
Leanin ensimmäinen periaate on määritellä, minkä asiakas kokee arvokkaaksi. Kyse on
niin yleisellä tasolla olevasta asiasta, että sen voidaan sanoa soveltuvan mihin tahansa
liiketoimintaan, siten myös ohjelmistokehitykseen. Voidaan kuitenkin pohtia, onko
ohjelmistotuotannossa jotain erityisiä keinoja tämän saavuttamiseen. Yksi menetelmä
on nopea protoilu [Ram98]. Lisäksi ketterän ohjelmistokehityksen periaatteet [Agi01]
tarjoavat tähän keinoja. Tällaisia ovat ainakin lyhyet iteraatiot ja tiivis yhteistoiminta
asiakkaan kanssa.
Toinen periaate eli arvovirran tunnistaminen soveltuu myös ohjelmistonkehitykseen
[Ram98]. Oleellista on, että ohjelmistokehitykseen kuuluu aina jonkinlainen vaiheit-
tainen prosessi. Tämän prosessin vaiheet muodostavat siis arvovirran, josta voidaan
lean-ajattelun mukaisesti alkaa poistaa hukkaa. Tarkemmin ohjelmistokehityksessä
esiintyvää hukkaa ja sen poistamista käsitellään seuraavassa luvussa.
Leanin kolmannessa periaatteessa arvovirrasta halutaan saada tasaisesti virtaava ilman
työn epätasaista jakautumista (mura) ja joidenkin osa-alueiden ylikuormittumista
9
(muri). Ohjelmistokehityksessä tämä voisi tarkoittaa sitä, että eri työvaiheissa kuten
määrittelyssä, kehityksessä ja testauksessa olisi koko ajan sopivasti ominaisuuksia työn
alla. Tärkeää on myös se, ettei työvaiheiden välille synny ylimääräisiä varastoja, joita
ovat muun muassa etukäteen tehdyt määritykset [Pop02] ja testaamaton koodi [Mid01].
Neljäs periaate (pull) sisältää ajatuksen siitä, että asiakkaalle tuotetaan vain sitä, mitä
hän tarvitsee ja vain silloin, kun hän sitä tarvitsee. Tämänkin voidaan ajatella
soveltuvan hyvin ohjelmistotuotantoon [Ram98]. Etenkin se, että tehdään vain
asiakkaan tarvitsemia ominaisuuksia, on hyvin oleellista. Kuten seuraavassa luvussa
tullaan huomaamaan, tämän vastakohta on yksi merkittävä hukan muoto.
Pull-toimintavan vastakohta on push. Janes ja Succi [JaS09] esittelevät kaksi tapaa
rakentaa ohjelmistoja push-menetelmällä sekä niille vaihtoehtoiset pull-menetelmät.
Vaatimukset ensin (requirements-first) on push-mallin mukainen menettely, jossa
vaatimuksia kerätään mahdollisimman paljon etukäteen tai vähintäänkin iteratiivisesti.
Tämän menetelmän kustannukset tulevat muun muassa niistä riskeistä, että vaatimukset
eivät täsmää liiketoiminnan tavoitteiden kanssa tai että vaatimukset muuttuvat.
Vaihtoehtoinen pull-menettely on tavoiteperustainen ohjelmistokehitys (goal-driven
software development), jossa ensin asetetaan tavoitteet, joiden perusteella luodaan
vaatimuksia. Yksi hyvä puoli tässä vaihtoehdossa on muun muassa se, että kehittäjät
pystyvät paremmin esittämään eri toteutusvaihtoehtoja, kun he ymmärtävät liike-
toiminnan tavoitteet.
Toinen push-esimerkki on alhaalta-ylös (bottom-up) ja sen pull-vastakohta ylhäältä-alas
(top-down) [JaS09]. Alhaalta-ylös-kehityksessä luodaan aluksi ne pohjakomponentit,
joita myöhemmin tullaan käyttämään niissä osissa, joita loppukäyttäjä tarvitsee.
Menetelmän kustannus tulee siitä, että pohjakomponentit ovat varastoa, joka saattaa
sisältää vääriä valintoja esimerkiksi arkkitehtuurin suhteen. Ylhäältä-alas-menetelmässä
taas lähdetään käyttäjän tarvitsemista komponenteista liikkeelle, määritetään niille
testitapaukset ja alempia kerroksia simuloidaan tynkien (stub) avulla. Näin pystytään
tuottamaan minimimäärä koodia, joka samalla tulee myös testatuksi.
10
Viides periaate eli pyrkimys täydellisyyteen on luonteeltaan samanlainen kuin
ensimmäinen eli se sopii mihin liiketoimintaan tahansa. Laatua voidaan siis parantaa
jatkuvasti myös ohjelmistokehityksessä [Mid01].
Voidaan siis todeta, että lean-periaatteet soveltuvat hyvin myös ohjelmistotuotantoon.
Seuraavaksi käsitellään tarkemmin, mitä hukan muotoja ohjelmistokehityksestä voi
löytää.
3.2 Hukka ohjelmistokehityksessä
Leanin tärkein ajatus on tunnistaa, mikä lisää asiakkaalle arvoa, ja poistaa sen jälkeen
tuotantoprosessista kaikki se hukka, mikä ei lisää arvoa. Näin ollen myös ohjelmisto-
tuotannossa täytyy ensin määrittää, mikä on arvoa. Arvon määrittäminen on jossain
määrin tapauskohtaista. Yleisellä tasolla voidaan kuitenkin ajatella, että ohjelmisto-
kehityksessä arvoa ovat kaikki ne toiminnallisuudet, joita asiakas todella tarvitsee.
Toisin sanoen esimerkiksi ne ominaisuudet, joita asiakas ei käytä, ovat hukkaa [Pop02].
Tässä luvussa esitellään, mitä muita hukan muotoja löytyy ohjelmistokehityksestä.
Hukkaa poistettaessa keskitytään usein pelkkään arvoa tuottamattomaan toimintaan
(muda) [Cal08]. Mutta kuten edellä todettiin, hukan päämuotoihin kuuluvat myös mura
(epätasaisuus) ja muri (ylikuormitus). Näiden tunnistaminen on tärkeää, sillä jotta arvoa
voidaan kestävästi tuottaa, täytyy ensin poistaa muri. Jos prosessista poistetaan
pelkästään muda, on todennäköisestä, että se palaa myöhemmin takaisin [Pic08]. Jos
esimerkiksi onnistutaan poistamaan virheitä mutta ihmisiä ylikuormitetaan liikaa,
virheet todennäköisesti palaavat ajan myötä takaisin. Ohjelmistokehityksessä juuri
ihmisten kuormittaminen onkin oleellisin esimerkki murista [Pic08].
Vastaavanlainen suhde on myös muralla ja mudalla. Ohjelmistokehityksessä muraa on
esimerkiksi se, ettei osa kehittäjistä noudata testilähtöistä kehitystapaa, käytetään
erilaisia kehitystyövälineitä tai ettei noudateta koodausstandardeja [Pic08]. Kaikki nämä
luovat prosessiin turhaa vaihtelua ja lisäävät siten riskiä siitä, että prosessiin tulee
mukaan arvoa tuottamatonta toimintaa eli mudaa. Siksi myös muran tunnistaminen on
tärkeää.
11
Kun mura ja muri on tunnistettu ja poistettu prosessista, on helpompi keskittyä
poistamaan mudaa. Kuten valmistavassa teollisuudessa, myös ohjelmistokehityksessä
näiden kaikkien tunnistamiseen voidaan hyödyntää arvovirta-analyysia [Ram98,
PoP03]. Yleisesti ottaen jos jokin toiminta sovelluskehitysprosessissa voidaan ohittaa
tai sen tavoite voidaan saavuttaa helpommin, toiminta on hukkaa.
Luvussa 2.3 esitellyt mudan muodot valmistavassa teollisuudessa voidaan yhdistää
ohjelmistoteollisuuteen seuraavasti [Pop03b]:
• ylituotanto = ylimääräiset toiminnot
• varasto = keskeneräinen työ
• tarpeeton käsittely = tarpeeton käsittely
• tarpeeton liike = tehtävien vaihtuminen
• virheet = testauksen läpäisseet virheet
• odottelu = odottelu, ml. asiakkaan odottaminen
• kuljettaminen = luovutukset
Ylituotanto on hukan muoto, joka ohjelmistokehityksessä tarkoittaa erityisesti
ylimääräisiä vaatimuksia [McC97] ja niiden perusteella rakennettuja ylimääräisiä
toiminnallisuuksia, joita asiakas ei käytä [Pop02]. Samoin sellaiset toiminnallisuudet,
jotka on rakennettu asiakkaan toivomuksesta mutta jotka eivät kuitenkaan täytä
asiakkaan tarpeita, voidaan ajatella olevan ylituotantoa. Edelleen jos rakennetaan
toiminnallisuus, jota asiakkaan oletetaan jossain vaiheessa tarvitsevan mutta ei
kuitenkaan juuri nyt, sitä pidetään myös hukkana [Pop03b].
Varastot ovat hukan muoto, joka ei välttämättä ensi alkuun tunnu kuuluvan
ohjelmistokehitykseen. Yleisesti voidaan kuitenkin ajatella, että kaikki sellaiset kesken-
eräiset tuotokset, jotka odottavat siirtymistä eteenpäin, ovat varastoa. Tämä sisältää
muun muassa sellaiset määrittelyt, joita ei vielä tarvita [Pop02]. Edellä mainittiin myös
alhaalta-ylös-tuotantotavassa syntyvät pohjakomponentit, joita voidaan pitää varastoina
[JaS09]. Laajempi näkökulma varastoihin on, että kaikki keskeneräinen työ kuten
testaamaton koodi on varastoa [Mid01, Pop03b]. Tässä on toisaalta pieni ristiriita lean-
12
periaatteiden kanssa. Niin kauan kuin työhön lisätään arvoa esimerkiksi koodaamalla
jotain ominaisuutta, työ ei ole hukkaa, vaikka se keskeneräistä onkin.
Tarpeeton käsittely tarkoittaa yleisesti ottaen sitä, että sama asia joudutaan tekemään
useaan kertaan tai siihen joudutaan käyttämään tarpeettomasti aikaa. Jos esimerkiksi
kehittäjällä menee kauan selvittää, mitä jokin koodi tekee, on kyse tarpeettomasta
käsittelystä [Mil09a]. Tällöin kyse voi olla esimerkiksi huonosta dokumentoinnista tai
epäselvästi kirjoitetusta koodista. Samoin tarpeetonta käsittelyä on se, jos heikosta
viestinnästä johtuen työntekijä ei saa jotain oleellista tietoa ja joutuu selvittelemään sitä
itse [Mil09a].
Neljäs mudan muoto eli jatkuva tehtävien vaihtuminen voi häiritä merkittävästi
henkilön keskittymistä. Parhaimmillaan jokaisen tulisi keskittyä yhteen asiaan
kerrallaan [Pop03b]. Toisaalta tehtävien vaihtuminen aiheuttaa myös tarpeetonta
käsittelyä, koska tekijä voi joutua käymään saman asian läpi moneen kertaan [Mil09a].
On hyvä huomata, että tehtävien vaihtelu voi liittyä henkilöiden ylikuormitukseen
(muri), jolloin hukan poistamiseksi täytyy ratkaista ensin ylikuormitusongelma.
Virheet ovat hukan muoto, jota voi luonnollisesti esiintyä minkä tahansa tuotteen tai
palvelun tuottamisessa. Ohjelmistotuotannossa virheet tarkoittavat sitä, ettei ohjelmisto
toimi määritystensä mukaisesti. On syytä huomata, että virheet ja varastot liittyvät
toisiinsa. Jos varastot (määrittelyt, suunnitelmat, testaamaton koodi) kasvavat liian
suuriksi, ne piilottavat samalla myös virheitä [Mid01]. Samoin virheet ja tarpeeton
käsittely liittyvät toisiinsa. Kun kehittäjä joutuu palaamaan virheen vuoksi uudelleen jo
kerran kirjoitetun koodin pariin, kyse on tarpeettomasta käsittelystä [Mil09a].
Leanin periaatteisiin kuuluu, että prosessi pyritään saamaan virtaavaksi. Jos tekijät
joutuvat kuitenkin odottelemaan esimerkiksi projektin hyväksyntää, määrittelyitä tai
priorisointeja, kyse on hukasta [Mil09b]. Yhtä lailla hukka on se, että joudutaan
odottamaan toimenpiteitä tai tietoa asiakkaalta [Pop02].
Turhaa kuljettamista vastaa ohjelmistokehityksessä luovutukset (handoffs). Luovu-
tuksilla tarkoitetaan erilaisten tuotosten kuten dokumenttien ja koodin siirtämistä
henkilöltä toiselle. Hukka syntyy siitä, että jokaisessa luovutuksessa katoaa tietoa
13
[Mil09b]. Mitä enemmän kehitysprosessi luovutuksia sisältää, sitä enemmän hukkaa
syntyy. Jos siis esimerkiksi yksi henkilö tekee vaatimusanalyysia, toinen vaatimus-
määrittelyä, kolmas kirjoittaa koodia ja neljäs testaa sen, jokaisessa vaiheessa tapahtuu
luovutus, joka sisältää hukkaa.
3.3 Hukan poistaminen ohjelmistokehityksessä
Tässä luvussa esitellään menetelmiä, joilla edellisessä luvussa kuvattua ohjelmisto-
kehityksen hukkaa voidaan poistaa. On mielenkiintoista huomata, että useat keinot
nojautuvat vahvasti ketterän ohjelmistokehityksen periaatteisiin, kuten Extreme
Programming (XP) -kehityskäytäntöön [Pop02]. Toisaalta nimenomaan leanin avulla
voidaan ymmärtää, miksi monet ketterät menetelmät ovat olleet menestyksekkäitä
[Pop07]. Ketteryys ja virtaviivaisuus liittyvät siis toisiinsa hyvin vahvasti.
Kuten edellisessä luvussa todettiin, hukan poistaminen on syytä aloittaa muran ja murin
poistamisesta. Muuten on vaarana, että poistettu muda palaa prosessiin takaisin. Scrum-
prosessimalli tarjoaa murin eli ylikuormituksen poistamiseen hyvän ratkaisun, sillä siinä
annetaan työntekijöille mahdollisuus itse valita realistinen määrä työtä tehtäväksi
[Pic08]. Mura eli epätasaisuus saadaan poistumaan taas siten, että kaikki noudattavat
tiettyjä yhteisesti sovittuja menetelmiä, kuten koodauskäytäntöjä ja testilähtöistä
sovelluskehitystä [Pic08].
Ylimääräiset toiminnot ovat siinä mielessä kiinnostava hukan muoto, että niitä
poistamalla voidaan saavuttaa isot säästöt. Jos jokin toiminnallisuus voidaan jättää
kokonaan tekemättä, säästyy helposti paljon aikaa ja työtä [McC97]. Käytännössä tämä
tarkoittaa sitä, että kerralla kannattaa suunnitella ja toteuttaa vain seuraavassa
iteraatiossa tehtäviä ominaisuuksia [Pop02].
Edellinen kohta liittyy myös varastoihin. Jos määrityksiä tai toiminnallisuuksia tehdään
liikaa etukäteen, se kasvattaa ohjelmistovarastoja. Tämä hukan muoto saadaan
poistumaan siten, että yksityiskohtaisia käyttäjätarinoita tehdään vain seuraavaa
iteraatiota varten [Pop02]. Toisekseen määrittelyt eivät saa olla liian laajoja [Mid01].
Kolmas asia on olla arvailematta liikaa etukäteen, mitä asiakas tarvitsee. Toisaalta tässä
14
pitää olla myös erityisen tarkkana, ettei ohjetta ymmärretä väärin. Menestyvään liike-
toimintaan nimittäin kuuluu se, että osataan ennakoida asiakkaiden tarpeita ja pystytään
tarjoamaan heille kilpailijoita parempia tuotteita.
Tarpeettoman käsittelyn poistaminen liittyy osittain muran poistamiseen. Jos kehittäjät
noudattavat samoja kehitysmenetelmiä ja standardeja, ei heidän tarvitse käyttää aikaa
tiedon tulkitsemiseen. Tärkeää on myös, että oleellinen tieto on saatavilla helposti.
Tähän yksi ratkaisu on se, että kehittäjät ovat lähellä asiakasta [Pop02]. Lisäksi täytyy
huolehtia siitä, ettei kerran löydettyä tietoa hukata, vaikka tiedon kannalta tärkeät
henkilöt eivät olisikaan enää tavoitettavissa. Tähän auttaa oleellisen tiedon dokumen-
toiminen [Mil09a].
Turhat tehtävien vaihdot poistuvat ennen kaikkea sillä, että tekijöiden annetaan
keskittyä omaan työhönsä. Scrum-prosessimallissa scrum masterin yksi tehtävä onkin
nimenomaan suojata tiimiä turhilta häiriöiltä. Myös se auttaa, jos kerrallaan työssä
olevien tehtävien määrä saadaan pidettyä alhaisena.
Virheiden poistamiseen liittyy periaate laadun rakentamisesta ohjelmiston sisään (build
quality in) [Pop03]. Käytännössä tämä tarkoittaa esimerkiksi testilähtöistä kehitystä,
automatisoituja testejä, refaktorointia ja jatkuvaa integraatiota [PoP03, DJS08].
Toisaalta laatua ei voi lähestyä pelkästään teknisestä näkökulmasta. Tuotteen laatuun
vaikuttaa keskeisesti myös kehitysprosessissa käytetyt menetelmät, esimerkiksi viestintä
kasvotusten on tehokkaampaa kuin kirjoittaen. Tehokas viestintä vähentää väärin
ymmärrysten määrää parantaen siten myös laatua [PoP03].
Turhaa odottelua voidaan vähentää siten, että tehdään asioita pienissä erissä [Pop02].
Tämä myös edesauttaa nopean palautteen saamista, jolloin tuotokset saadaan nopeasti
eteenpäin, eivätkä ne kerry varastoihin [Mid01]. Asiakasta lähellä oleminen on hyvä
tapa vähentää odottelua asiakkaan suuntaan. Esimerkiksi sen sijaan että odotettaisiin
asiakkaan vastausta sähköpostiin, on nopeampaa ja tehokkaampaa saada suullinen
varmistus asiaan suoraan asiakkaalta [Pop02].
Viimeinen hukan muoto ohjelmistokehityksessä eli luovutukset vähenevät erityisesti
mahdollistamalla avoin keskustelu [Mil09b]. Tarkoitus on siis minimoida dokumenttien
15
välityksellä tapahtuvaa keskustelua. Jälleen yksi käytännön keino on mennä lähelle
asiakasta [Pop02].
Hukan poiston suhteen on syytä ottaa huomioon vielä yksi tärkeä asia hukan muodosta
riippumatta. Jotta tiimit voisivat poistaa prosessista hukkaa ja turhaa vaihtelua, heille
pitää antaa siihen valta ja heitä pitää myös kannustaa siihen [Mid01]. Virtaviivaisuutta
ja ketteryyttä ei saavuteta käskemällä vaan tiimien itseohjautuvuudella.
16
4 Yhteenveto
Tässä seminaarityössä on tutkittu alan kirjallisuuteen perustuen, mitä lean-filosofian
hukkakäsitteet mura, muri ja muda tarkoittavat ohjelmistokehityksessä. Työn aluksi
käsiteltiin lean-ajattelua ja sen periaatteita yleisellä tasolla perehtyen erityisesti hukan
muotoihin. Sen jälkeen pohdittiin, miten lean ylipäätään soveltuu ohjelmisto-
kehitykseen. Työn lopuksi esiteltiin, miten hukka ilmenee ohjelmistokehityksessä ja
miten sitä voidaan poistaa.
Taulukossa 4.1 esitetään yhteenveto ohjelmistokehityksessä esiintyvästä hukasta ja sen
poistamisesta. Taulukon kaksi ensimmäistä riviä sisältävät murin ja muran, ja viimeiset
ovat mudaa. Taulukko vastaa seminaarityön tutkimuskysymykseen siitä, mitä hukka on
ohjelmistokehityksessä ja miten sitä voidaan poistaa.
Hukka yleisessä lean-ajattelussa
Hukka ohjelmisto-kehityksessä
Esimerkkejä ohjelmistokehityksen hukasta
Menetelmiä hukan poistamiseen
Ihmisten ja koneiden ylikuormitus (muri)
Ihmisten ylikuormitus
Jatkuvat ylityöt, jatkuvan stressin alla työskentely
Tiimille valta omien tehtävien arvioimisessa (Scrum-prosessi)
Epätasaisuus (mura)
Turha vaihtelu työmenetelmissä
Testaa lopuksi -menetelmän noudattaminen yhtä aikaa testaa ensin -menetelmän kanssa, vaihtelevat koodaus- ja kehityskäytännöt
Yhteisesti sovittujen menetelmien noudattaminen
Ylituotanto Ylimääräiset toiminnot
Toiminnot joita asiakas ei käytä ollenkaan tai vielä, toiminnot jotka eivät täytä asiakkaan tarpeita
Vähennetään etukäteen tekemistä, tehdään vain asiakkaan pyynnöstä, iteroidaan molemminpuolista ymmärrystä paremmaksi
Varastot Keskeneräinen / odottava työ
Määritykset, testaamaton koodi, etukäteen rakennetut komponentit (alhaalta-ylös-menetelmä)
Tekeminen tarpeeksi pienissä erissä (vain yksi iteraatio kerrallaan), etukäteen tekemisen minimointi
Tarpeeton käsittely
Tarpeeton käsittely
Vanhan koodin tutkiminen, kerran löydetyn tiedon etsiminen, kerran korjatun koodin uudelleen-korjaaminen
Lähellä asiakasta oleminen, yhteisten menetelmien noudattaminen, järkevä dokumentointi
Tarpeeton liike Tehtävien vaihtuminen
Jatkuva työtehtävien vaihtuminen
Scrum-prosessi ja siinä erityisesti scrum masterin rooli, alhainen yhtäaikaisten tehtävien määrä
Virheet Testauksen läpäisseet virheet
Tuotantoon menneet virheet Testilähtöinen kehitys, automatisoidut testit, refaktorointi, jatkuva integraatio, tehokas ja avoin viestintä
Odottelu Odottelu Projektin tai muutoksen hyväksymisen, määrittelyiden, prioriteettien
Asioiden tekeminen pienissä erissä, avoin ja suullinen keskustelu
17
ja asiakkaan vastausten odottelu
Kuljettaminen Luovutukset Määrittelyiden, suunnitelmien ja koodin luovuttaminen seuraavalle tekijälle ilman suullista keskustelua
Avoin keskustelu, lähellä asiakasta oleminen, turhien dokumenttien välttäminen
Taulukko 4.1. Yhteenveto ohjelmistokehityksessä esiintyvästä hukasta ja sen
poistamisesta.
Kuten taulukosta 4.1 voidaan havaita, lean ja sen periaate hukan poistamisesta soveltuu
myös ohjelmistokehitykseen. Lisäksi on merkille pantavaa, että useat hukan
poistamiseen soveltuvat menetelmät ovat löydettävissä ketteristä sovelluskehityksen
menetelmistä kuten extreme programming -kehityskäytännöistä sekä Scrum-prosessi-
mallista.
18
Lähteet
Agi01 Principles behind agile manifesto.
http://www.agilemanifesto.org/principles.html. [28.11.2009]
Cal08 Caldwell Kevin. Managing outcomes in a lean enterprise. Quality
Magazine. November 2008.
DJS08 Danovaro Emanuele, Janes Andrea, Succi Giancarlo. Jidoka in Software
Development. In OOPSLA’08, October 19-23, 2008, pages 827-830.
HiT00 Hines Peter, Taylor David. Going lean. Lean Enterprise Research Center.
2000.
JaS09 Janes Andrea, Succi Giancarlo. To Pull or Not to Pull. In OOPSLA’09,
October 25-29, 2009, pages 889-894.
McC97 McConnell Steve. Achieving Leaner Software. In Software, IEEE,
November/December 1997, pages 127-128. IEEE Computer Society.
Mid01 Middleton Peter. Lean Software Development: Two Case Studies. In
Software Quality Journal, 9, 2001, pages 241-252. Kluwer Academic
Publishers.
Mil09a Milunsky Jack. The 7 Software Development Wastes - Lean series Part 3 -
Extra Processing. The agilebuddy blog. August 4, 2009.
http://blog.agilebuddy.com/2009/08/the-7-software-development-wastes-
lean-series-part-3-extra-processing.html. [30.11.2009]
Mil09b Milunsky Jack. The 7 Software Development Wastes - Lean series Part 4 -
Transportation. The agilebuddy blog. August 6, 2009.
http://blog.agilebuddy.com/2009/08/the-7-software-development-wastes-
lean-series-part-4-transportation-.html. [30.11.2009]
19
Mil09c Milunsky Jack. The 7 Software Development Wastes - Lean series Part 6 -
Delays. The agilebuddy blog. September 23, 2009.
http://blog.agilebuddy.com/2009/09/the-7-software-development-wastes-
lean-series-part-6-delays.html. [30.11.2009]
Ohn88 Ohno Taiichi. Toyota Production System, Beyond Large-Scale Production.
Productivity Inc, 1988 (alkuperäisteos 1978).
Pic08 Pichler Roman. The Three M’s – The Lean Triad. InfoQ web site. Feb 27,
2008. http://www.infoq.com/articles/lean-muda-muri-mura. [27.11.2009]
Pop02 Poppendieck Mary. Principles of Lean Thinking. Poppendieck.LLC, 2002.
[Myös: http://www.poppendieck.com/papers/LeanThinking.pdf]
PoP03 Poppendieck Mary, Poppendieck Tom. Lean software development: an
agile toolkit. Addison-Wesley, 2003.
Pop03b Poppendieck Mary. Lean Software Development. C++ Magazine, 2003.
[Myös:
http://www.poppendieck.com/pdfs/Lean_Software_Development.pdf]
Pop07 Poppendieck Mary. Lean Software Development. In 29th International
Conference on Software Engineering (ICSE'07 Companion), 2007.
Ram98 Raman Sowmyan. Lean software development: is it feasible? In Digital
Avionics Systems Conference, 1998. Proceedings., 17th DASC. The
AIAA/IEEE/SAE, Oct 31 – Nov 7, 1998, pages C13/1-C13/8, vol. 1.
Smi06 Smits Hubert. 5 Levels of Agile Planning: From Enterprise Product Vision
to Team Stand-up. Whitepaper. Rally Software Development Corp, 2006.
WJR90 Womack James P., Jones Daniel T., Roos Daniel. The Machine that
Changed the World. Rawson Associates, 1990.
20
WoJ96 Womack James P., Jones Daniel T. Beyond Toyota: How to Root Out
Waste and Pursue Perfection. Harvard Business Review, September-
October, 1996.
Wom96 Womack Jim. Mura, muri, muda?. E-letter. Lean Enterprise Academy.
July 7, 2006. http://www.leanuk.org/downloads/jim/mura_muri_muda.pdf
Top Related