Kanban - kortti on yksi työkaluista , joita voidaan käyttää Kanban - kehitysjohtamismenetelmän toteuttamisessa .
Näitä tauluja voidaan pitää muunnelmina perinteisistä kanban-korteista. Signaalikorttien sijaan, jotka yleensä osoittavat kysyntää tai suorituskykyä, taulun mukana käytetään magneetteja, muovisia rahakkeita, värillisiä kiekkoja tai tarroja kuvaamaan työkohteita ja prosesseja. [1] Jokainen näistä esineistä edustaa tuotantoprosessin vaihetta ja liikkuu sen edetessä. Tämä liike vastaa tuotantoprosessin liikettä. [2] Taulu on yleensä jaettu kolmeen loogiseen osaan: "odottaa", "työ kesken" ja "valmis työ". Työntekijät siirtävät muistiinpanoja taulun osaan, joka vastaa tehtävän tilaa. [3]
Kanban-metodologiaa voidaan käyttää monien elämänalueiden organisointiin. Kanban-levystä on monia muunnelmia.
Yksinkertaisimmat taulut koostuvat kolmesta sarakkeesta: "to do" ( englanniksi to-do ), "in progress" ( käynnissä ), "done" ( done ). [neljä]
Kanban-levyn suosituin tulkinta ketterään kehitykseen tai ns. lean-kehitykseen sisältää seuraavat sarakkeet tehtävien tilan mukaan: keskusteltu ( backlog ), sovittu ( valmis ), koodi kirjoitettu ( koodaus ), testattu ( testattu ), vahvistettu ( hyväksyntä ) ja tehty ( tehty ). On myös yleinen käytäntö nimetä sarakkeet eri tavalla, esimerkiksi: seuraava, kehitys, tehty, asiakkaan hyväksyntä, push muutokset tuotantopalvelimelle [5] .
Sen lisäksi, että pystyt nimeämään uudelleen sarakkeita / tiloja Kanban-levyllä, on myös mahdollista lisätä sarakkeiden määrää, mutta tämä tapahtuu, jos olemassa olevat jaetaan.
Vaikka kanban-taulu toteutettiin alun perin fyysisessä muodossa, monet tiimit, erityisesti hajautetut, ovat oppineet ymmärtämään verkkotaulujen käytettävyyden [12] .
Kanban-tyylisten verkkotaulujen kehitys on saanut viime aikoina uutta vauhtia. Tämä johtuu tarpeesta tehdä etätyötä Kanban-metodologialla .
Kehitysprosesseissa, kuten muillakin toiminta-alueilla, ei aina ole mahdollista heti ”tuntea” oikeaa polkua, usein joutuu kokemaan paljon piikkejä. Tuotteen tai palvelun tuleva elinikä riippuu sopivan kehitysmetodologian valinnasta. Olemme koonneet yhteen 13 etua Kanbanin käyttöönotosta ohjelmistokehitykseen.
Analysoidaan seuraavaa esimerkkiä ottaen huomioon kaksi tilannetta.
Ensimmäinen tilanne - kuvitellaan kuljetintehdas Neuvostoliiton aikana, jonka toiminta riippui suoraan valtion suunnitelmasta. Tässä suunnitelmassa määriteltiin selkeästi tuotantoon tarkoitettujen tuotteiden määrä. Tuloksena varastot ylikuormitettuja, koska Valtion suunnittelulautakunnan laatijat saattoivat usein tehdä virheitä kysynnän kanssa. Tuote ei ehtinyt myydä.
Toinen tilanne on Toyotan näyttelytila näinä päivinä. Ostaja valitsee mallin ja maksaa. Toyotalla ei kuitenkaan ole autosi väriä varastossa tällä hetkellä. Tilaus lähetetään Toyotan pääkonttoriin. Saat tiedon kun auto toimitetaan. Vasta siitä hetkestä lähtien autoa alettiin valmistaa. Erityisesti sinulle. On olemassa periaate: ensin myynti, sitten tuotanto. Toisin sanoen juuri ajoissa (JIT) toimii. Ensin tavoitteet ja määräajat, sitten suunnitelma ja työ.
Toyotan varasto ei ole liian täynnä, sillä ensimmäisessä tilanteessa niiden ei tarvitse säilyttää esivalmistettuja osia pitkiä aikoja. Tämä johtuu siitä, että se, mitä tällä hetkellä tuotetaan linjalla, on vaadittu määrä joillekin äskettäin myydyille koneille.
Yksi JIT-periaatteen avainkomponenteista on Kanban. Kanban-taulut ja kortit ovat eräänlaisia liikennevaloja just in time -järjestelmässä. Kanban antaa yrityksille mahdollisuuden reagoida asiakkaiden tarpeisiin sen sijaan, että ne ennakoivat tarpeita, kuten ensimmäisessä kuvatussa tilanteessa.
Voit heijastaa samanlaisen esimerkin ohjelmistokehitysalueelle:
Varaosien sijaan - kehitystehtävät tai bugit. Testaaja saa useita tehtäviä tarkistettavaksi. Kun laadunvarmistajalta loppuu tarkastettavat tehtävät, hänen on ilmoitettava ohjelmoijille saadakseen heiltä uusia tehtäviä. Jos ohjelmoijat eivät ehdi suorittaa uusia tehtäviä, testaaja jää yksinkertaisesti ilman työtä jonkin aikaa.
Tilanne on myös päinvastainen: QA:lla on paljon tehtäviä, eikä hänellä ole aikaa tarkistaa kaikkea ajoissa. Tällöin myös tuotteen julkaisupäivä viivästyy.
Ohjelmistokehityksessä Kanbanin tasapainottaminen on paljon vaikeampaa kuin tuotannossa. Se vaikuttaa työn erityispiirteisiin: jos koneet tuottavat samantyyppisiä osia, ohjelmoijat työskentelevät koodin kanssa omin voimin aivoissa, joissa on noin 100 miljardia neuronia ja yksi, mutta merkittävä inhimillinen tekijä.
Löysin Kanbanin edut täysillä vuonna 2008, minkä jälkeen käytän Kanban-levyjä kaikkialla: henkilökohtaisesta suunnittelusta, kehityksestä ja jopa Kanbanin toteutuksesta keramiikkapajassa.
Tässä on 13 syytä, miksi Kanban kannattaa ottaa käyttöön ohjelmistokehitystä harjoittavissa IT-yrityksissä:
Kanban-tauluille siirtyminen tavallisista tehtävälistoista osoitti heti pullonkaulan: Testaus-sarakkeeseen kertyi suuri jono tehtäviä. Laadunvalvojamme ei selvinnyt tarkastustehtävistä. Hän otti tehtävät todennettavaksi pitkällä viiveellä. Kun testaaja palautti tehtävän tarkistettavaksi, ohjelmoija oli jo onnistunut unohtamaan sen. Minun piti katsoa koodia uudelleen ja muistaa yksityiskohdat. Kuten voit kuvitella, tämä on arvokasta aikaa. Joukkue tarvitsi toisen testaajan.
Kanban-taulun avulla voit nähdä prosessisi pullonkaulat, joissa jonoja muodostuu. Hygger.io:ssa WIP-rajoitukset auttavat tässä tehtävässä. Jos sinulla on enemmän tai vähemmän tehtäviä kuin tarvitset, sarake on korostettu punaisella tai keltaisella.
Ominaisuuksien julkaisujärjestys on usein tärkeä. Priorisoiduissa listoissa järjestystä on vaikea hallita tarkasti. Jos ohjelmoijalla on samanaikaisesti viisi pääasiallista tehtävää, hänen on vaikea selvittää, mikä näistä tehtävistä ottaa ensin.
Kanban Board tarjoaa vain tien ulos tilanteesta, jossa järjestyksellä on väliä. Tämä visuaalinen ratkaisu on pystysuora sarake, jossa on tehtäviä. Mitä korkeampi tehtävä, sitä tärkeämpi se on. Kanban, muuten, sisältää prioriteettien asettamisen yhdeksi metodologian tärkeistä näkökohdista. Vaatimukset muuttuvat jatkuvasti, monet tehtävät voivat menettää merkityksensä ja "laskeutua" alas. Jotkut tehtävät voivat päinvastoin "nousta jyrkästi". Esimiehen on jatkuvasti "pitettävä sormea pulssissa", jotta ohjelmoijat tekevät tarpeellisimman.
Kanban opettaa sinua keskittymään tärkeimpiin asioihin. Jotain, joka todella lisää tuotteen arvoa. Pystyimme "laskemaan" paljon turhia bugeja ja parannuksia. Tämä antoi tuloksen.
Tärkeiden bugien erottaminen pienemmistä ei ole helppo tehtävä tuotepäällikölle, mutta tässä Swimlanes-ominaisuus tulee apuun. Nämä ovat Kanban-taulun vaakasuorat sarakkeet. Yleensä ohjelmoijilla on laudalla seuraavat uimarajat:
Järjestelmä on samanlainen kuin Eisenhower-kvadrantti. Tärkeitä ja kiireellisiä asioita ovat estäjät. Tärkeää, mutta ei kiireellistä - Tehtävät ja bugit. Tärkeää ja kiireellistä, samoin kuin merkityksetöntä ja ei-kiireellistä - tämä on joku päivä. Muuten, vaakasuuntaisten sarakkeiden puute on yksi tekijöistä, jotka vahvistavat sen, mitä Trellolta puuttuu ketterässä kehityksessä.
Ohjelmoijan tulee keskittyä työhönsä. Siksi on hyvä, kun hän saa jonon tehtäviä eikä hänen tarvitse miettiä, mitä tehdä seuraavaksi, johtaja on jo miettinyt tätä. Sinun tarvitsee vain ottaa seuraava tehtävä tai vika.
Joskus Kanban sisältää ohjelmoijien itsenäisen tehtävien valinnan ylhäältä. Silloin kaikkien ihmisten ammatillisen tason tulee olla tasa-arvoinen, jotta ei tapahdu niin, että vaikein tehtävä "pääsee" nuoremmalle asiantuntijalle.
Omat tehtävät -suodatin auttaa sinua keskittymään tehtäviisi. Sen avulla näet nopeasti tehtäväsi taululla.
Silmiesi edessä - koko kuva projektista. Avaamalla taulun saat nopeasti vastauksia tärkeisiin kysymyksiin:
Kanban auttaa sinua tulemaan joustavammaksi. Tämä on erityisen välttämätöntä, kun tuote julkaistaan ja se saa paljon hyödyllistä palautetta. Näitä ovat tukiviestit, käyttäytymisanalytiikka, a/b-testitulokset, arvostelut jne. Heti kun "lataamme" uuden ominaisuuden tuotantoon, alamme välittömästi muuttaa sitä palautteen perusteella. Aiemmin ohjelmoija ei halunnut tehdä "vasenta" tehtäviä peläten "täyttää" sprintin määräajat. Kanbanin mukaan ohjelmoija toimii kuin prosessori: yksi sykli - yksi tehtävä.
Mitä useammin syklit ovat, sitä joustavammaksi kehitystiimi tulee. Meidän tiimille ihanteellinen taktisuus on 8-12 tuntia. Suuret tehtävät on hajotettava.
Scrum vei paljon aikaa ominaisuuksien arvioimiseen ennen sprintin alkua. Kanbanin kanssa arviointia ei tarvita. Kun teemme sen, niin se tehdään.
Scrum sisältää paljon viestintää. Sprintin alkuun liittyy suunnittelu: tehtävien analysointi ja arviointi. Stand-uppeja vaaditaan joka viikko. Sprintin päätyttyä pidetään retrospektiivi. Tämän seurauksena kaikki viestintä vie noin 30 % ajasta. Mutta tällä kertaa joukkue saattoi viettää aikaa työhön.
Kanbanin avulla tiimi alkaa työskennellä johdonmukaisemmin. Nyt testaaja tarkistaa ominaisuuden lähes välittömästi ohjelmoijan tehtyä sen. Samoin muilla aloilla: suunnittelijat, UX, toimittajat, myynti.
Aiemmin QA ei tarkistanut ominaisuutta ohjelmoijan tehdessä, vaan pitkän ajan kuluttua. Tänä aikana ohjelmoija onnistui unohtamaan kaiken maailmassa, mukaan lukien tämän tehtävän yksityiskohdat.
Scrumissa "lataamme" ominaisuuksia tuotantoon vasta sprintin lopussa. Noin kerran 3 viikossa. Kanbanissa melkein heti testaajan hyväksymisen jälkeen. Kerran muutaman päivän välein.
Joten saamme nopeasti selville, onko ominaisuus tullut käyttäjiin vai ei. Jos ei, jossain on tapahtunut virhe. Ja meille on tärkeää olla ensimmäinen, joka tekee virheitä. Tämä ei tarkoita, että rakastamme virheiden tekemistä. Mutta jos tiedämme virheestä ensimmäisenä, tiedämme ensimmäisinä ja päätämme, mitä tehdä.
Ei tarvitse jatkuvasti "vetää" ohjelmoijia. Avasimme Kanban-taulun, katsoimme nopeasti kuka ja mitä tekee, kaikki tilat, ja voit turvallisesti palata hallintaan. Ja ohjelmoija on edelleen muuttuvassa tilassa ja odottaa uusia korkeuksia.
Aikaisemmin ohjelmoijat eivät tienneet, mitä heidän kollegansa tekivät. Nyt Kanbanin avulla ohjelmoija voi johtajan tavoin mennä johtoon katsomaan, mitä kollegat tekevät. He tarvitsevat tällaisia tietoja koordinoidakseen yhteisiä ponnisteluja hankkeessa.
Aikaisemmin ohjelmoija oli mukana useissa tehtävissä samanaikaisesti. Voisin valita tehtävän mielialani mukaan tai unohtaa kokonaan sen mitä tein perjantaina maanantaina.
Nyt WIP-rajat ja panoraamanäkymä rajoittavat ohjelmoijaa oikein: hän ei voi tehdä useampaa kuin yhtä tehtävää kerralla.
JohtopäätöksenäSaattaa tuntua siltä, että vaadimme Kanbanin olevan parempi kuin Scrum. Mutta se ei ole. Kaikella on aikansa. Hyggerin kokemuksen mukaan Scrum sopii hyvin tuotekehityksen alkuun ja Kanban, kun tuote on jo tullut areenalle.
Kanban ei ole ihmelääke jokaiselle yritykselle. Jos asetat tikkaat väärää seinää vasten, vaikka kuinka jyrkästi kiipeäisit niitä, päädyt silti väärään paikkaan. Siksi Kanban on välttämätön, mutta ei riittävä edellytys tuotteen tai projektin onnistumiselle.