Kanban
A Kanban eredete
A kanban-t (jelentése: kártya, tábla, bizonylat) Taiichi Ohno fejlesztette ki a Toyota mérnökeként, 1947-ben, a gyártás optimalizálás céljából. A módszer a szintén Ohno által összeállított 7 veszteség (japánul muda) egyes elemeit csökkenti. Később Mary Poppendieck a gyártás 7 veszteségét a szoftverfejlesztésre “átfordította”: átadások (információ), kontextusváltás, várakozás, félkész termékek, felesleges funkciók, felesleges tevékenységek (pl újratanulás), hibák.A Kanban módszert is át tudjuk ilyen módon fordítani és alkalmazni a termék / szofverfejlesztésre.
A Kanban tábla
A Kanban-táblával kezdődik a folyamat, ami egy vizualizációs eszköz. Az oszlopok a folyamatunk főbb fázisait jelenítik meg, a bennük lévő kártyák pedig az éppen abban a folyamatban lévő feladatokat szimbolizálják. A vizualizáció valós idejű, mindig az aktuális státuszt mutatja. A kártyák mozgatása pull-rendszert követ, ami azt jelenti, a kártya az adott oszlopban marad, amíg a következő oszlopba behúzzák. Ezt a szabályt fogadjuk el, ne gondolkozzunk egyelőre azon, miért is ne tolhatnánk tovább, ha készen vagyunk, ennek a későbbiekben lesz jelentősége. Tehát az adott folyamatban elkészült kártyák ottmaradnak, és az adott oszlop sorát növelik, amíg a következő oszlopban alakul szabad kapacitás, és áthúzzák. A tábla tehát egy egyszerű vizualizációs eszköz, ebben még nincsen különösebb optimalizáció vagy veszteség minimalizálás. Hány oszlop a megfelelő? Kezdve a legegyszerűbbtől, ami 3 oszlop (el nem kezdett, folyamatban lévő, elkészült) az egészen sok oszlopos táblákig lehet nagyon bonyolult is. A lényeg: csak annyi legyen, aminek a vizualizálásából érdemi információt nyerünk, és nem csak adminisztrációs terhet teszünk a csapat nyakába.
A kártyák mérete
A Kanban folyamat akkor működik jól, ha a kártyák illetve a kártyákon lévő feladatok mérete közel azonos. Itt nem becslünk, story pontokat mint a scrumnál, hanem arra törekszünk, hogy azonos méretűre bontsuk a feladatokat. Az a következő pont szempontjából fontos.
A Kanban módszer, mint folyamatjavító módszer
A kanban táblán szemléltetett folyamatot, annak teljesítményét a leginkább annak áteresztő képességével (throughput) tudjuk jellemezni. Ez jelentheti az egy kártya átlagos folyamatban töltött idejét – amikor elkezdünk dolgozni rajta addig, amíg befejezzük. Illetve más megközelítésből a napi / heti elkészült kártyák számát. Mivel mindkettő a kártyák átlagos folyamatban lévő idején alapszik, tulajdonképpen ugyanarról beszélünk. A cél nyilvánvalóan az áteresztőképesség növelése lesz, minél hatékonyabban dolgozzuk fel a feladatokat, kártyákat. Ez a mérési módszer csak akkor célravezető, ha egyforma méretűek a kártyák, nem fog kijönni a heti átlag ha az egyik héten csupa kis feladat a másikon csupa nagy feladat készül. Ezért fontos tehát a lehető leghasonlóbb méretűre bontani a feladatokat. Sziantén ide tartozó fogalom a Flow, ami a kártyák akadálymentes továbbjutását jelenti, érthető okokból a flow biztosítása is az áteresztő képesség javulását eredményezi.
A veszteségek
Amennyiben a kártyák rendre egyenlőtlenül oszlanak el, például a 2-es oszlopban folyamatosan növekszik a darabszám, a 4esban alig van 2-3 darab akkor láthatjuk, hogy van helye a javulásnak. Ahol folyamatosan sok illetve növekvő számú kártya van, ott többletkapacitásunk van. Miért gond ez? Félkész termékek keletkeznek. A félkész termék azért veszteség, mert belefektettünk már munkát, de egészen addig nem látjuk hasznát, míg el nem készül. Minél több a félkész termék, annál több veszteséget generálunk. Továbbá ezek a kártyák, amennyiben túl sokára kerülnek tovább, okafogyottá válhatnak. Kontextusváltás okozhatnak, ahogy az oszlopban dolgozó csapat újra és újra átnézi a régebbi elemeket, esetleg egy több napos/hetes elemet folytatnak később egy következő oszlopban, és visszakérdeznek (felesleges tevékenység/újratanulás). Valamint amíg nem kerülnek tovább az oszlopból, várakozni fognak. Amíg várakoznak, az óra ketyeg, a várakozási idő is beleszámolódik az áteresztő képességbe. Azok az oszlopok, ahol folyamatosan kevés kártya van, szűk keresztmetszetet jelentenek. A táblán nyomon követve láthatjuk, hol a probléma. A folyamat csak annyira lehet gyors, mint a legszűkebb keresztmetszete.A folyamat javítása
Láthattuk a nagy illetve folyamatosan növekvő elemszámú oszlopok mennyi veszteséget okoznak. Itt kezdjük a folyamat javítást, WIP (Work In Progress – folyamatban lévő munka) limit beállításával. Oszloponként megfogalmazhatunk limiteket, amit nem haladhat meg a benne lévő elemek száma. (alapvetően érdemes ugyanazt a limitet alkalmazni minden oszlopra, de eltérő is lehet, ha az értelmezhető valami speciális sajátosság miatt). A limit hatására, ha az adott oszlop elérte a korlátot, nem húzhat magára újabb kártyát. Az ahhoz az oszlophoz tartozó emberek hirtelen feladat nélkül maradnak. Egészen addig, amíg nem fogy a limit alá az oszlopukban lévő kártyák száma. Ezalatt az idő alatt besegítenek a többi oszlopban dolgozó társaiknak, ami nem feltétlenül a legoptimálisabb használata a tudásuknak, nem biztos, hogy egyénileg a leghatékonyabb, de folyamat szempontjából mindenképpen. Amint az ő segítségükkel felzárkózik a szűk keresztmetszetet okozó csapat, lefogy a saját oszlopukban lévő elkészült kártyák száma a limit alá, ’hazamehetnek’ és a munka folytatódik. Amennyiben mindig ugyanaz, és folyamatos a szűk keresztmetszetet okozó oszlop, ott nyilván kapacitásbővítésre van szükség, és nem hatékony, ha a másik oszlopból a társaiknak a fele idejében mást kénytelenek csinálni, mint a saját dolguk.
Keresztfunkcionalitás, explicit folyamatok
A WIP limites szabályozás feltételezi, hogy a csapattagok nem csak a saját szakterületükhöz értenek (ahhoz a legjobban), hanem társaik szakterületeihez is valamilyen szinten tudnak segíteni. Például egy üzleti elemző tud segíteni a tesztelésben, egy ügyes automata tesztelő, akinek nem idegen a kódolás be tud segíteni, egy gyakorlott manuális tesztelő, aki szinte a legjobban ismeri a rendszert és az üzleti folyamatot, be tud segíteni az elemzőknek. Ez a kereszt-funkcionalitás, amit az agilis csapatokban segítünk kialakítani, a csapat tagok aspirációját figyelembe véve. Szükséges ehhez a jól definiált folyamatok ismerete mindenki által, és a csapat részéről is a tanulási vágy, a közös csapat célok. Ez a módszer nem az egyén leghatékonyabb felhasználását, hanem a folyamat optimalizálását tűzi ki célul (csapat cél), és az esetenként alakuló csúcsokat tudja jól kisimítani.
Mikor jó a Kanban?
Ha például a csapat nem csupán egy termék fejlesztésén dolgozik. Ha a két hetes iterációk nem értelmezhetőek. Ha folyamatos leszállításra van szükség, néha rövid határidővel.
Példa: Szoftverfejlesztő csapat, szupermarketek pénztárgép/raktárkészlethez fejlesztenek saját terméket. A jelenlegi éles rendszert több áruházban használják évek óta. Ezeket a rendszereket kell támogatni, ad hoc hibák súlyosságtól függően SLA-n belül megoldani (#1). Néha kisebb fejlesztések promóciók okán, 2-t fizet 3-at vihet, de akár a hatósági árak alkalmazását is említhetem, szintén rövid határidővel. Ezek nem hibák, inkább mikro projektek (#2). Végül a jövő rendszerének a fejlesztése, teljesen új, korszerű platformon, termékfejlesztés (#3). Amíg az utóbbi teljesen jól illeszkedne egy scrum-ba, a folyamatos megszakítások a mikro projektek, vagy support problémák miatt tönkretennék a velocity-t, a csapat morált, illetve sprint közbeni kiadásokra is szükség lenne az SLA miatt.
Itt a kanban módszer lehet a megoldás, WIP optimalizálással, a csapat is motivált maradhat, a leszállítási idő is ideális lehet mindhárom témakörben.