Kanban HY:ssä

1         Kanbanin määritelmä HY:ssä

Kanban on Lean-periaatteisiin ja just-in-time –tuotantostrategiaan perustuva, evolutiivinen menettelytapa, joka tekee näkyväksi prosessin ja sen pullonkaulat. Lean-ajattelun mukaisesti kanban-työskentelyssä pyritään optimoimaan arvoketjua, ts. minimoimaan läpimenoaikaa, jonka lisäarvon tuottaminen kestää.

Ei ole olemassa virallista ”kanban-ohjelmistoprosessia”. Kanban on hyvin minimalistisesti määritelty ja jättää runsaasti liikkumavaraa tiimin omille tulkinnoille ja sovelluksille. Tässä on määritelty vain kanbanin perusmekanismi, jota voidaan – ja kuuluukin! – optimoida projektikohtaisesti. Lähtökohtana on tiimin kulloinenkin prosessi, jota aletaan hienosäätää.

Kanban-malli perustuu kolmeen perussääntöön:

1. Visualisoi: Työnkulku on ehdottomasti tehtävä näkyväksi, jotta prosessia voi ymmärtää ja kehittää. Toteutustapana HY:ssä on seinätaulu / task board sarakkeineen (työvaiheet) ja siinä liikkuvine paperilappuineen (työtehtävät).
2. Rajoita: Työn alla olevien tehtävien määrää rajoitetaan voimakkaasti, jotta tiimi keskittyy saamaan tehtäviä valmiiksi mahdollisimman tehokkaasti. Nyrkkisääntö on, että työn alla on korkeintaan (tiimin koko / 2) tehtävää, esim. 6 hengen tiimille 3 tehtävää. Limiittejä hienosäädetään ajan myötä vastaamaan prosessin kipupisteisiin.
3. Mittaa: Tehtävien läpimenoaikoja mitataan, ja mittaustietoa hyödynnetään prosessin hienosäädössä ja arvoketjun näkyväksi tekemisessä.

Kanban organisoi työnkulun tavalla, joka poistaa tarpeen aikarajatuille iteraatioille (sprinteille) ja työmääräarvioille. Erona scrumiin on myös, että sprintin tehtävälistan kaltaista tuotosta ei ole. Tuoteversio on kanbanissa summa kaikista kehitysjonon kohdista, jotka ovat valmistuneet kuluvaan ajanhetkeen mennessä.

2          Rytmitys (kadenssit)

Kadenssi (cadence) tarkoittaa ohjelmistokehityksessä erilaisten työvaiheiden ja toimenpiteiden rytmitystä säännöllisesti toistuvaksi ”sykkeeksi”. Kadenssien välillä on havaittava hengähdystauko tai virstanpylväs. Kadenssien avulla jaksotetaan työtä helpommin hallittaviksi kokonaisuuksiksi. Kadensseja tarvitaan myös mittauspisteinä, kun mitataan tiimin kykyä tuottaa arvoa (tässä: toimivaa ohjelmistoa) ennustettavalla nopeudella.

Scrumissa työ tehdään aikarajatuissa iteraatioissa (sprintit). Sprintti sitoo suunnitteluun, katselmointiin ja julkaisuun liittyvät toimenpiteet yhdeksi paketiksi: kaikkien kadenssi on esim. 2 viikkoa. Kanban-mallissa em. toimien aikataulutus on irrotettu toisistaan itsenäisiksi, eli suunnittelu, katselmointi ja julkaisu voivat tapahtua keskenään eri rytmityksellä.

Scrumissa tiimin kykyä tuottaa arvoa mitataan suhteuttamalla tuotosten määrä iteraation kestoon (nopeus l. velocity). Kanbanissa tiimin kykyä tuottaa arvoa mitataan ensisijaisesti yksittäisen tuotoksen läpimenoajalla.

3          Virtaus (flow)

Kanbanissa pyritään edistämään ja optimoimaan työalkioiden etenemistä prosessin läpi. Tätä kutsutaan virtaukseksi. Ihanteellisesti työ (esim. toteutettava feature) pilkotaan vakiokokoisiksi alkioiksi, jolloin niiden virtausta on helpompi edistää ja kontrolloida. 

Projektikohtaisesti voidaan sopia, että kiireellisille tehtäville varataan muun flow’n ja sarakelimiitit ohittava yhden työalkion kokoinen ”ohituskaista”, jos tämä on tarpeen arvoketjun optimoinnin kannalta. Tyypillisesti esim. tuotantojärjestelmissä olevien kriittisten bugien korjaus voi arvoketjussa ohittaa saman järjestelmän jatkokehityksen. Ohituskaistalla voi siis taata maksimaalisen virtausnopeuden yksittäiselle kriittiselle palaselle, kun taas normaaleille työalkioille pyritään optimoimaan keskimääräistä läpimenoaikaa.

4          Edistymisen mittarit Kanbanissa

Kaksi tärkeää edistymisen mittaria ovat läpimenoaika (cycle time) ja suoritusteho (throughput).

Läpimenoaika ilmaisee ajan, joka yhdeltä työlistan alkiolta on mennyt toteutusputken läpäisemiseen jonon kärjestä valmiiksi. Tuoteomistaja käyttää läpimenoaikaa tuoteversioiden julkaisujen suunnittelussa vastaamaan samaan kysymykseen kuin Scrumissa tiimin nopeutta (velocity): ”milloin tämä tuoteversio on valmis?”

Suoritusteho lasketaan kaavalla (WIP/läpimenoaika), missä WIP = Work In Progress, työn alla olevien työalkioiden määrä. Tiimi, jolla on työn alla kerrallaan 3 työalkiota ja läpimenoaika 6 työpäivää, laskee suoritustehokseen 3/6 = 0,5 työalkiota/päivä.

Tiimin on kirjattava taskien aloitus- ja valmistumisajat, jos tuoteomistaja haluaa seurata läpimenoaikoja.

5          Tiimin kokoonpano ja roolit

Kanban-tiimi on itseorganisoituva ja muodostetaan kuten scrumtiimi. Prosessimallin mahdollisesti vaihdellessa scrumin ja kanbanin välillä tiimi voi luonnollisesti pysyä samana tai myös vaihtua osittain.

6          Aktiviteetit ja niiden rytmitys

Kuten edellä on kuvattu luvussa Rytmitys, kanban-prosessissa syötteisiin (refining, tehtäviksi pilkkominen jne.), tuotoksiin (katselmointi) ja reflektioon (retrospektiivit) liittyvät tilaisuudet voivat noudattaa kukin omia kadenssejaan.

Kanban suosii lyhyitä kadensseja. Tyypillisesti tilaisuuksia kutsutaan koolle tarpeen mukaan (pull-periaate) ja juuri ajoissa (just-in-time), mikä osaltaan ohjaa lyhyisiin kadensseihin. Tilaisuuksien kesto suhteutetaan kadenssin kestoon; Scrum Guiden ohjeajat pätevät 2 viikon kadensseihin ja skaalataan niistä tarpeen mukaan.

Lähtökohdaksi kannattaa ottaa Scrum-mallin tilaisuudet ja noudattaa niistä useimpia hieman soveltaen:

Julkaisusuunnittelu – kadenssi <1 kk, vahvasti soveltaen
Tuoteomistajan on kanbanissa ylläpidettävä priorisoitua kehitysjonoa. Soveltuvin osin toimitaan luvussa Julkaisusuunnittelu kuvatulla tavalla. Työmääräarvioiden sijaan on pyrittävä vakioimaan kehitysjonon alkioiden kokoa, jotta läpimenoaika pysyisi riittävän ennustusvoimaisena mittarina. Kehitysjonon alkioita voidaan paketoida tuoteversioiksi Scrumin tapaan.

Kehitysjonon työstö – pull  / just-in-time TAI kadenssi <1 viikko
Kehitysjonon alkioita työstetään tarpeen mukaan ”juuri ajoissa” niiden noustessa lähemmäs työjonon kärkeä. Työstötilaisuuksia järjestetään kuten scrumissa (Kehitysjonon jalostaminen); tiimin työpanoksesta 5–10 % tulee käyttää työstämiseen.

Taskien suunnittelu – pull / just-in-time TAI kadenssi <1 viikko
Yksittäisten tehtävien osalta suunnittelu tehdään kuten sprintin suunnittelupalaverissa. Suunnittelusessioita järjestetään aina tarpeen mukaan, vähintään aina uuden kehitysjonon alkion päätyessä toteutusputkeen. Tiimi voi myös sopia jonkin lyhyen kadenssin, esim. 2 kertaa viikossa.

Päiväpalaveri – kadenssi 1 päivä
Päivittäinen statuskatsaus pidetään sivulla Scrum-kehitys HY:ssä kuvatulla tavalla.

Työkokonaisuuksien katselmus – kadenssi 1–2 viikkoa
Työkokonaisuuksien (kehitysjonon alkioiden) valmistuessa putkesta ne tulee katselmoida luvussa Sprinttikatselmus kuvatulla tavalla. Katselmuksia pidetään vähintään 2 viikon välein. Lyhyempi kadenssi (muutaman työkokonaisuuden välein) on suositeltava, jakson pituus riippuu tällöin tiimin suoritustehosta.

Retrospektiivi – kadenssi 1–2 viikkoa
Tiimin oman toiminnan parantaminen sekä mittareiden seuranta ja viritys on tärkeää, mutta ajan varaaminen sille unohtuu helposti, kun tilaisuutta ei ole paketoitu valmiiksi kahden viikon kadenssiin. Retrospektiivitilaisuudet pidetään luvun Sprintin retrospektiivi mukaisesti vähintään 2 viikon välein. Tiimi voi sopia lyhyemmästäkin kadenssista.