Scrum, Kanban ja Scrumban

Ohjelmistotuotanto on ohjelmistotuotteiden systemaattista suunnittelua ja toteuttamista sekä ohjelmistoprosessin hallintaa. Ohjelmistotuotantomenetelmä on tapa jakaa tuotanto selkeisiin vaiheisiin, joihin liittyvät toiminnot tähtäävät parempaan suunnitteluun ja projektinhallintaan. Menetelmät tarjoavat keinoja suunnitella, koordinoida, kommunikoida ja mitata työtä. Menetelmät voivat ottaa kantaa ohjelmiston vaatimustenhallintaan, testaamiseen, ylläpitoon, konfiguraationhallintaan sekä laadunhallintaan. Ohjelmistotuotantomenetelmän kanssa jokseenkin rinnastettavia nimityksiä on lukuisia, esimerkiksi projektinhallinnan viitekehys, ohjelmistotuotannon elinkaari (engl. software development life cycle) ja ohjelmistotuotantoprosessi (engl. software development process).

Ohjelmistotuotantomenetelmät voidaan jakaa karkeasti kolmeen kategoriaan: lineaarisiin menetelmiin, iteratiivisiin menetelmiin sekä ketteriin menetelmiin. Lineaarisissa malleissa tuotannon eri vaiheet toteutetaan peräkkäin, joista palaute saadaan aina vaiheen päätteksi. Iteratiivisissa malleissa ohjelmistoon kehitetään uutta toiminnallisuutta pienin lisäyksin. Ketterät menetelmät tuottavat taajaan asiakkaalle tai asiakkaan edustajalle tarkasteltavaksi toimivaa ohjelmistoa. Uutta toiminnallisuutta lisätään lyhyissä iteratiivisissa sykleissä pienin lisäyksin, ja asiakas ohjaa kehitystyötä.

Lineaariset mallit ovat niin sanottuja ennustavia malleja, kun taas iteratiiviset ja ketterät mallit sopeutuvia. Lineaariset mallit toteuttavat kaikki projektin aloitus- ja suunnitteluvaiheessa täysin määritellyt vaatimukset – mahdollisuuksien rajoissa. Vaatimukset ovat tiukasti määriteltyjä, ja projektissa luotetaan siihen, että tiedetään jo alkuvaiheessa, mitä lopputuotteelta halutaan tulevaisuudessa.

Vesiputousmalli

Esimerkki lineaarisesta mallista on vesiputousmalli, jossa tuotannon vaiheet – vaatimusmäärittely, suunnittelu, toteutus, integrointi, testaus, asennus ja ylläpito – toteutetaan peräkkäin järjestyksessä ja visualisoidaan usein alaspäin suuntautuvana virtana vesiputouksen tapaan. Mallia voidaan pitää ensimmäisen ohjelmistotuotantomenetelmänä, ja ensimmäinen kuvaus sen kaltaisten vaiheiden käytöstä ohjelmistotuotannossa on vuodelta 1956. Ensimmäinen formaali kuvaus vesiputousmallista on vuodelta 1970, jossa mallia käytettiin esimerkkinä viallisesta ja toimimattomasta ohjelmistokehitysmallista. Silti vesiputousmallia käytetään edelleen laajasti myös ohjelmistokehityksessä, eikä sen käytölle ole näkyvissä loppua siihen kohdistuvasta kritiikistä huolimatta.

Vesiputousmallin ongelmat liittyvät siihen, että projektin alussa on usein hyvin vaikeaa tietää, ovatko suunnitellut ominaisuudet relevantteja projektin lopussa. Suunnitteluvaiheessa tuotetaan paljon dokumentaatiota, joka sisältää päällekkäistä tietoa, eikä ole aina selvää, mikä versio on ajantasaista. Mitä pidempi projekti, sitä suuremmalla todennäköisyydellä vaatimukset muuttuvat. Testauksen lykkääminen aivan projektin loppupuolelle aiheuttaa ongelmia: testattavaa on paljon, on vaikeaa palata kehitysvaiheeseen, ja muuttaa asioita, jotka olivat huonosti suunniteltuja, ja korjaaminen viivästyttää projektia. Mitä myöhemmin virhe löydetään, sitä kalliimpaa on sen korjaaminen. Toimivaa ohjelmistoa toimitetaan vasta projektin lopussa. Vesiputousmalli ei sovellu epävarmoihin, pitkiin, jatkuviin tai monimutkaisiin projekteihin. Sellaisten projektien tarpeisiin on kehitelty iteratiivisia ja ketteriä menetelmiä.

Vaihtoehtona iteraatiot

Iteratiiviset mallit tuottavat ennalta jaotellun osan – inkrementin – vaatimuksista toimivan ohjelmiston muodossa lyhyiden syklien – iteraatioiden – välein. Vaatimukset voivat olla tiukasti määriteltyjä tai niitä voidaan uudelleentarkastella joustavasti. Ketterissä menetelmissä määritellään alkuvaiheessa korkean tason ominaisuuksia, mutta tarkempi suunnittelu jätetään myöhemmäksi, toteutusvaiheen yhteyteen. Ketterät menetelmät on suunniteltu siten, että vaatimuksia voidaan muuttaa projektin edetessä.

Scrum

Scrum on Jeff Stuherlandin ja Ken Schwaberin 1990-luvun puolivälissä kehittämä iteratiivinen ketterä ohjelmistotuotantomenetelmä, jota käytetään nykyään myös muilla aloilla, erityisesti kompleksisten ja innovatiivisten projektien kehittämiseen ja ylläpitoon. Scrum on johtava ketterä tuotantomenetelmä, jota käytetään Fortune 500-yrityksissä ympäri maailman. Scrumin kehittäjät kuvailevat sitä kevyeksi, yksinkertaiseksi ymmärtää, mutta vaikeaksi hallita hyvin. Scrum koostuu erilaisista rooleista, tapahtumista, tuotoksista ja säännöistä, jotka on kuvattu kuvassa 1.

Kuva Scrum yleiskuva
Kuva 1 Yleiskuva Scrumista.

Scrumin perusideana on, että tuoteomistaja luo priorisoidun toivelistan ominaisuuksista ja vaatimuksista, jota kutsutaan tuotteen kehitysjonoksi. Tuoteomistaja työskentelee yhteistyössä asiakkaan kanssa, joka määrittelee halutut ominaisuudet. Niin sanotun sprintin suunnittelupalaverissa kehittäjätiimi valitsee tuotteen kehitysjonon yläpäästä pienen osan ominaisuuksia, jota kutsutaan sprintin kehitysjonoksi. Kehitystiimi on pieni, noin 3-9 henkilön poikkitoiminnallinen, itseorganisoituva ryhmä, joka päättää, miten valitut ominaisuudet toteutetaan. Tiimin pitää toteuttaa valitut ominaisuudet tietyn aikaikkunan – sprintin, jonka kesto on tyypillisesti 2-4 viikkoa – aikana.

Tiimi tapaa kasvotusten päivittäin arvioidakseen työn etenemistä päiväpalavereissa. Sprintin aikana Scrum Master pyrkii pitämään tiimin keskittymisen sprintin tavoitteissa, ja poistamaan työskentelyn esteenä olevat asiat. Sprintin päätteeksi on valmistunut käyttökelpoinen toimiva tuoteversio, jonka julkaisemisesta päättää tuoteomistaja. Tuoteomistaja optimoi julkaisusuunnitelmaa ja päivittää tuotteen kehitysjonoa perustuen havantoihin, jotka on todettu tutkittaessa tuoteversiota yhteistyössä asiakkaan kanssa. Sprintti päättyy sprinttikatselmointiin ja retrospektiiviin, joiden avulla optimoidaan tuotantoprosessia jatkossa. Seuraavan sprintin alkaessa tiimi järjestää jälleen sprintin suunnittelupalaverin, jossa valitaan uudet toteutettavat ominaisuudet tuotteen kehitysjonosta, jonka jälkeen se aloittaa työskentelemään uudelleen.

Lean ohjelmistotuotannossa

Lean-ajattelutapa on peräisin 1900-luvun puolivälistä autovalmistaja Toyotan kehittämästä tavasta valmistaa ja kehittää autoja. Toyotan tuotantojärjestelmä pohjautuu juuri-oikeaan-aikaan -tuotantoon (engl. Just-in-time), jonka keskiössä ovat imuohjaus ja niin sanottu Kanban-prosessi.

Toyotan tuotantojärjestelmä ja niin sanottu Toyotan tapa – johtamistapa, joka perustuu ihmisten kunnioittamiseen ja jatkuvaan parantamiseen – herättivät kiinnostusta vuoden 1973 öljykriisin jälkeen, kun japanilaiset yritykset – joissa oli myös opiskeltu Toyotan toimintatapaa – toipuivat kriisistä muuta maailmaa nopeammin ja nousivat eurooppalaisten ja amerikkalaisten todellisiksi kilpailijoiksi laadukkailla ja edullisilla tuotteilla. Termi Lean esiteltiin vuonna 1990 James P. Womackin kirjassa ”The Machine That Changed the World”, ja vuonna 1996 Womack jalosti Daniel T. Jonesin kanssa Lean-ajattelun viisi periaatetta seuraavasti:

  1. Arvon määrittäminen asiakkaan näkemänä arvona
  2. Arvovirran määrittäminen ja arvoa tuottamattomien toimintojen poistaminen
  3. Arvovirran luominen, eli prosessin jatkuvan virtauksen mahdollistaminen askel kerrallaan
  4. Asiakasvetoisen prosessin eli imuohjauksen käyttö siellä missä jatkuva virtaus on mahdollista
  5. Jatkuva parantaminen ja täydellisyyden tavoittelu
Lean-tuotanto

Lean-termin ilmestymisen jälkeen Toyotan valmistustapaa alettiin kutsua Lean- tuotannoksi. Toyotan myötä Lean-ajattelu on laajentunut myös tuotekehitykseen, ja myös perinteisen valmistuksen lisäksi muille aloille.
Lean on noussut myös ohjelmistotuotannon uudeksi trendiksi. Lean kumpuaa ketterien menetelmien käyttäjäkunnasta ja sitä voidaan pitää joko ketterien menetelmien suuntauksena tai kokonaan uutena itsenäisenä ohjelmistotuotannon lähestymistapana. Leania pidetään ohjelmistokehityksen seuraavana aaltona.

Lean-ajattelu ohjelmistotuotannossa on saanut alkunsa Mary ja Tom Poppendieckin kirjasta ”Lean Software Development”, ja heidän esittelemänsä lean-mallin periaatteet ovat hieman muokattu versio perinteisistä lean-periaatteista. Alkuperäiset periaatteet ovat vuodelta 2003, ja ne ovat luultavasti laajiten siteeratut. Poppendieckit ovat kuitenkin päivittäneet periaatteitaan vuosien varrella. Taulukossa 1 on listattuna sekä alkuperäiset että nykyiset periaatteet.

Taulukko 1 Lean-ohjelmistotuotannon periaatteet Poppendieckien mukaan.

Alkuperäiset, 2003 Nykyiset, 2016
Eliminoi hukka Vähennä kitkaa
Rakenna laatu edellä Rakenna laatu edellä
Luo tietoa Paranna oppimista
Viivästytä sitoutumista Paranna jatkuvasti
Toimita nopeasti Keskity asiakkaisiin
Kunnioita ihmisiä Energisoi ihmiset
Optimoi kokonaisuus Optimoi kokonaisuus
Lisää virtausta

Esimerkkejä hukasta ohjelmistotuotantotyössä ovat muun muassa osittain tehty työ, ylimääräiset prosessit, ylimääräiset ominaisuudet, tehtävien vaihtaminen kesken, odottaminen, tuotteen luovutukset, virheet ja ylimääräinen johtaminen. Jotta hukkaa voi karsia, on se tunnistettava. Hukan tunnistamiseen käytetään työn kulun ja niin sanotun arvovirran visualisointia. Käytännössä tämä tehdään Kanbanin avulla.

Kanban

Kanban on lean-lähestymistapa ketterään ohjelmistokehitykseen. Kanban on japania, ja tarkoittaa ”näkyvää korttia”. Toyotan tuotantojärjestelmässä Kanban on termi, joka tarkoittaa visuaalista ja fyysistä signalointijärjestelmää, joka sitoo koko tuotantoketjun vaiheet yhteen. Vaikka Kanban on kehitetty jo yli puoli vuosisataa sitten, on sen käyttäminen ohjelmistotuotannossa varsin tuore ilmiö. Ensimmäisenä kanbanin toi ohjelmistotuotantoon David Anderson vuoden 2010 kirjassaan Kanban.

Kanban perustuu kolmeen kulmakiveen. Ensimmäisenä on visualisoitava työn kulku. Tehtävä työ jaetaan pieniin osiin, kukin osa kirjoitetaan kortille, joka laitetaan näkyville seinälle tai muuhun vastaavaan paikkaan niin sanotulle Kanban-taululle, josta on esimerkki kuvassa 2. Taulussa käytetään nimettyjä sarakkeita, jotka kuvaavat kunkin työtehtävän vaihetta. Toiseksi on rajoitettava käynnissä olevien työtehtävien määrää. Kanban-tauluun merkitään kappalemäärärajoituksia kuhunkin työnkulun vaiheeseen. Kolmanneksi on mitattava työn virtausta, eli kuinka paljon aikaa kuluu yhden tehtävän täydelliseen suorittamiseen. Prosessia optimoidaan pienentämällä läpivirtausaikaa ja tekemällä siitä mahdollisimman ennustettava.

Kanban-taulu

Kuva kanban taulusta
Kuva 2 Esimerkki Kanban-taulusta. Tehtävät on merkitty sinisille korteille. Sarakkeisiin on asetettu rajoitukset tehtävien määrille.

Kanban-taulu toimii siten, että kun johonkin sarakkeeseen syntyy tyhjä paikka, se täytetään kyseisen sarakkeen vasemmalla puolella olevasta sarakkeesta. Työtä siis imetään työnkulun loppupäästä, siitä johtuu nimitys imuohjaus. Työtehtävien määrän rajoitus ja imuohjaus estävät työtehtävien kasautumisen ja prosessin tukkeutumisen. Läpivirtausaikaa mittaamalla voidaan säätää tehtävien määrän rajoituksia, ja siten saada tehtävät virtaamaan prosessin läpi mahdollisimman nopeasti.

Kanban on todella salliva menetelmä. Siinä on oletuksena vain kolme rajoitetta, kun taas Scrum määrittelee yhdeksän rajoitetta, eXtreme Programming – eräs ketterä menetelmä – 13 ja Rational Unified Process – eräs iteratiivinen menetelmä – yli 120. Kanban on sallivampi ja joustavampi kuin Scrum. Scrumin ja Kanbanin eroavaisuuksia on koottu taulukkoon 2.

Taulukko 2 Scrumin ja Kanbanin eroavaisuuksia.

Ominaisuus Scrum Kanban
Aikaikkunoidut iteraatiot Pakollisia Valinnaisia
Tiimi sitoutuu toteuttamaan tietyn määrän työtä iteraation aikana Pakollista Valinnaista
Suunnittelun ja prosessin parantamisen mittari Nopeus (iteraation aikana asiakkaalle toteutetun arvon määrä) Tehtäväkortin läpivirtausaika
Poikkitoiminnalliset tiimit Pakollisia Valinnaisia, erityisosaajatiimit sallittuja
Toteutettavien ominaisuuksien ositus Jaettava osiin, jotka mahdollista toteuttaa sprintin aikana Ei vaadita
Kuvaajat Jäljellä olevan työn määrän kuvaaja (engl. burn-down chart) pakollinen Ei pakollisia kuvaajia
Käynnissä olevan työn määrän rajoitus Epäsuorasti (iteraatioittain) Suoraan (työvaiheittain)
Tehtävän työmäärän arviointi Pakollista (effort estimation) Valinnaista
Uusien tehtävien lisääminen Ei mahdollista käynnissä olevaan iteraatioon Mahdollista, mikäli tilaa on
Tehtäväjono Yhden tiimin omaisuutta Voidaan jakaa useiden tiimien tai henkilöiden kesken
Roolit Kolme pakollista Ei pakollisia
Taulun tyhjennys Iteraatioiden päätteeksi Taulu jatkuvasti käytössä
Kehitysjonon priorisointi Ennalta priorisoitu Valinnaista

Scrum ja Kanban, kuten mikä tahansa työkalu, eivät ole täydellisiä. Ne eivät ole vastaus kaikkeen, vaan tarjoavat vain tiettyjä suuntaviivoja. Koska kummatkin ovat suhteellisen mukautuvaisia ja sallivia työkaluja, voidaan eri työkalujen ominaisuuksia yhdistellä, esimerkiksi yhdistelemällä taulukon 2 ominaisuuksia. Monet Kanban- tiimit käyttävät Scrumin päiväpalavereita. Scrumissa voidaan visualisoida työn kulku eri tavoin. Eräs tapa yhdistellä Scrum ja Kanban on Scrumban.

Scrumban

Scrumban on menetelmä, joka alunperin suunniteltiin auttamaan siirtymisessä Scrumista Kanbaniin. Nykyään se on ohjelmistotuotantomenetelmä, jossa tiimit käyttävät Scrumia soveltavin osin työtapanaan, ja Kanbania näkökulmana, miten työtä lähestytään ja parannetaan. Scrumban pyrkii luomaan saumattoman joustavan prosessin, joka kykenee hallitsemaan jatkuvan työn virtausta sekä yllättäviä muutoksia ja vaatimuksia. Scrumbanissa voidaan hyödyntää Scrumin käytäntöjä tiimistä ja tarpeesta riippuen. Taulukossa 3 on listattuna Scrumin ja Kanbanin ominaisuudet, jotka yhdistyvät tässä työssä käytetyn Scrumbanin versiossa.

Taulukko 3 Scrumbanin anatomia.

Scrumista lainatut ominaisuudet Kanbanista lainatut ominaisuudet
Tuoteomistaja Imuohjaus
Scrum Master Käynnissä olevan työn rajoittaminen
Kehittäjätiimi Työn vaiheistus
Päiväpalaverit Kanban-taulu
Tuoteversion esittelyt Korkean prioriteetin työ etusijalle
Arvon toimittaminen Prosessin analysointi ja optimointi
Valmiin määritelmä

Scrumbanin tärkeimpiä termejä on työjono, työtehtävä, työvirta ja vaiheet. Työjono on tuoteomistajan asiakkaan kanssa yhteistyössä priorisoima listaus toteutettavia työtehtäviä, jossa tärkeimmät ovat ylimpänä. Työtehtävät virtaavat työjonosta ennalta määrättyjen vaiheiden läpi valmiiksi ominaisuudeksi. Vaiheet voivat olla esimerkiksi suunnittelu, ohjelmointi, testaus ja valmis. Kehittäjätiimi valitsee jonosta aina ylimmän työtehtävän siirrettäväksi prosessiin. Virtaus visualisoidaan fyysisesti Kanban-taululle, jossa työtehtävät liikkuvat imuohjausperiaatteella. Kaikki työvaiheet on tarkoitus pitää mahdollisimman täynnä, ja työtehtävien kuuluu virrata jatkuvasti. Taulussa on rajoitukset kussakin vaiheessa olevien työtehtävien määrälle. Taulu on kaikkien nähtävillä, ja sitä käytetään koko poikkitoiminallisten tai erityisosaajatiimien työkaluna arvon toimittamiseksi asiakkaalle yhdessä toteutettujen työtehtävien muodossa.

Tiimi koordinoi työskentelyään lyhyissä päiväpalavereissa, ja Scrum Master pyrkii poistamaan työskentelyn esteenä olevat asiat. Prosessia voidaan optimoida esimerkiksi sekä Scrumista tutuilla retrospektiiveillä että Kanbanin läpivirtausaikaa parantamalla. Retrospektiivejä voidaan järjestää esimerkiksi viikottain, ja niissä voidaan myös esitellä valmiit tuoteversiot tuoteomistajalle, joka päättää julkaisusta. Retrospektiiveissä voidaan myös tutustua työjonossa oleviin tuleviin työtehtäviin, ja tiimi voi esittää tarkentavia kysymyksiä tuoteomistajalle. Tiimi voi antaa palautetta tuoteomistajalle tuotejonon koosta, rakenteesta ja optimaalisesta suoritusjärjestyksestä, ja tuoteomistaja voi tehdä parannuksia sen pohjalta.

Mitä mieltä sinä olet?

Minkälaisia kokemuksia sinulla on Scrumista, Kanbanista ja Scrumbanista? Voisitko harkita vaihtavasti esimerkiksi Scrumin Scrumbaniin? Herättikö artikkeli muita ajatuksia? Osallistu keskusteluun kommenteissa ja jaa artikkeli tuttavillesi, joille voisi olla siitä hyötyä. Lue myös artikkelisarjan neljäs ja viimeinen osa Scrum, Kanban ja Scrumban vastaan erityspiirteet.

Kommentoi

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *