Mikä ihmeen Kanban?

Kanban Board Example

Japaninkielinen sana kanban tarkoittaa suomeksi näkyvää taulua.

Kanban-menetelmä sisältää vain kolme sääntöä, jotka voi joskus mieltää Scrumin laajennuksena samaan tapaan kuin eXtreme Programming (XP) ja Test-Driven Development (TDD). Kanbania voi myös hyödyntää sellaisenaan minkä tahansa prosessin visualisointiin ja kehittämiseen.

Kanbanin kolme perussääntöä:

1. Näkyvöitä työnkulku

  • Pilko työt sopivankokoisiin tehtäviin
  • Kirjaa kukin tehtävä paperilapulle ja kiinnitä laput kanban (tai scrum) -tauluun
  • Kuvaa taulun sarakkeilla missä työvaiheessa kukin tehtävä on

2. Määritä WIP taulun jokaiselle sarakkeelle

WIP (Work in Progress) tarkoittaa suurinta määrää tehtäviä, joita kyseisessä sarakkeessa saa kerrallaan olla, jottei sarakkeeseen kasaantuva työ hidasta muita työvaiheita.

3. Kirjaa ylös tehtävien läpimenoajat

Läpimenoaika (Lead Time) tarkoittaa keskimääräistä aikaa yhden tehtävän valmistumiseen. Kun olet mitannut läpimenoajan, optimoi pikkuhiljaa prosessia ja kokeile erilaisia WIP-arvoja läpimenoajan lyhentämiseksi ja ennustettavuuden parantamiseksi.

Scrumin ja Kanbanin ero on siinä, ettei Kanban sisällä kehitysjaksoja (sprintejä), vaan määrittely- ja suunnittelupalavereita pidetään aina tarvittaessa ja ohjelmistosta julkaistaan uusi versio heti, kun pienin markkinoitava ominaisuusjoukko (Minimum Viable Product, MVP) valmistuu. Näin Kanban-taulu ei koskaan tyhjene vaan pysähtyy viikonlopuksi kuin liukuhihna.

Kanban sopii luontevimmin tilanteisiin, joissa työn sisältöä on mahdotonta lukita edes yhdeksi viikoksi. Esimerkiksi ohjelmiston ylläpidossa voidaan Kanbania käyttää reagoimaan lähes välittömästi käyttäjien bugiraportteihin. Esimerkistä tosin herää kysymys kannattaisiko laatuun kiinnittää huomiota jo kehitysvaiheessa vaikkapa tarkistamalla valmiin määritelmää ja testausprosessia.

Ennen Kanbanin toteuttamista kannattaa arvioida, tarvitseeko muutoksiin todella reagoida päivittäin tai tehdä useampia projekteja samaan aikaan, ja mitä vaikutuksia näillä on. Jos samalla luovutaan Scrumin tasapitkistä kehitysjaksoista, saatetaan kadottaa osa työn tavoitteellisuudesta, kun sprintille määriteltävä tavoite ja ajan loppumisen tunne jäävät pois. Suunnittelu- ja katselmointikokouksiin on myös vaikeampaa osallistua, kun kokousaikaa ei etukäteen voida sopia, ja julkaisuaikoja voi olla hankalaa ennustaa suuremmalle projektille. Tuoteomistajan tulee lisäksi olla ketterä kuin gaselli sopeutuakseen töiden jatkuvaan ”syöttämiseen”, ellei Selected-sarakkeeseen (kts. kuva) aseteta niin korkeaa WIP-arvoa, että tuoteomistaja ehtii välillä tehdä muutakin. Oheinen kuva on Henrik Knibergin kirjasta Kanban vs Scrum.

Haasteista huolimatta Kanbanille löytyy käyttökohteita varsinkin ohjelmistojen ylläpitotiimeistä sekä tilanteista, jolloin työnkuva on vahvasti reaktiivinen (esim. ohjelmistovirheiden korjaaminen, assistentit, mainostoimistot, jne.) tai sama tiimi joutuu tekemään useampia projekteja samaan aikaan. Hopealuoti Kanban ei kuitenkaan ole ja ennen sen toteutusta kannattaa ketteryyttä mahdollisuuksien mukaan harjoitella vaikkapa Scrumilla.

Scrumia ja Kanbania yhdistelevä kehitysmalli, jossa ei ole sprintejä, tunnetaan nimellä Scrumban. Siinä Kanbanin keveyttä voidaan tukea valitsemalla Scrumista sopivaksi katsottuja elementtejä, kuten rooleja, kokouskäytäntöjä tai kehitysjonoja.

Lue lisää Scrumista ja KanbanistaScrumista ja Leanista tai tutustu Agile & Lean Intro -koulutukseen.

Kommentoi

Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out / Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out / Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out / Muuta )

Google+ photo

Olet kommentoimassa Google+ -tilin nimissä. Log Out / Muuta )

Muodostetaan yhteyttä palveluun %s