A Kanban tábla a Kanban fejlesztésmenedzsment módszer megvalósítása során használható eszközök egyike .
Ezek a táblák a hagyományos kanban kártyák variációjának tekinthetők. Jelzőkártyák helyett, amelyek általában az igényt vagy az áteresztőképességet jelzik, mágneseket, műanyag jelzőket, színes korongokat vagy matricákat használnak a táblával együtt a munkadarabok és folyamatok ábrázolására. [1] Ezen objektumok mindegyike a gyártási folyamat egy szakaszát képviseli, és a folyamat előrehaladtával mozog a táblán. Ez a mozgás megfelel a gyártási folyamat mozgásának. [2] A tábla általában három logikai részre oszlik: „várakozás”, „folyamatban lévő munka” és „befejezett munka”. Az alkalmazottak jegyzeteket helyeznek át a tábla azon részébe, amely megfelel a feladat állapotának. [3]
A Kanban módszertan az élet számos területének megszervezésére használható. A Kanban táblának számos változata létezik.
A legegyszerűbb táblák három oszlopból állnak: „to do” ( angolul to-do ), „in progress” ( folyamatban ), „done” ( done ). [négy]
A kanban tábla legnépszerűbb értelmezése az agilis fejlesztéshez vagy az úgynevezett lean fejlesztéshez a következő oszlopokat tartalmazza a feladatok állapota szerint: megbeszélve ( lemaradás ), egyeztetve ( kész ), kód írva ( kódolás ), tesztelve ( tesztelés ), megerősítve ( jóváhagyás ) és kész ( kész ). Szintén bevett gyakorlat az oszlopok eltérő elnevezése, például: következő, fejlesztés, kész, kliens jóváhagyása, változtatások leküldése a termelési szerverre [5] .
A Kanban táblán az oszlopok / állapotok átnevezése mellett az oszlopok számának növelése is lehetséges, de ez a meglévők felosztása esetén történik.
Bár a kanban táblát eredetileg fizikai formában valósították meg, sok csapat, különösen az elosztottak, megértette az online táblák használhatóságát [12] .
Az online Kanban-stílusú táblák fejlesztése a közelmúltban új lendületet kapott. Ez annak köszönhető, hogy távolról kell dolgozni a Kanban módszertan használatával.
A fejlesztési folyamatokban, akárcsak más tevékenységi területeken, nem mindig lehet azonnal „ráérezni” a helyes utat, sokszor rengeteg tövist kell megtapasztalni. Egy termék vagy szolgáltatás jövőbeli élettartama a megfelelő fejlesztési módszertan megválasztásától függ. Összegyűjtöttük a Kanban szoftverfejlesztési alkalmazásának 13 előnyét.
Elemezzük a következő példát két helyzet figyelembevételével.
Az első helyzet - képzeljünk el egy szállítószalag-gyárat a szovjet időkben, amelynek tevékenysége közvetlenül az állami tervtől függött. Ez a terv egyértelműen meghatározta a termelésre szánt termékek mennyiségét. Emiatt túlzsúfolt raktárak alakultak ki, mivel az Állami Tervbizottság készítői gyakran hibázhattak az igényekkel. A terméknek nem volt ideje eladni.
A második helyzet manapság a Toyota bemutatóterme. A vevő kiválaszt egy modellt és fizet. A Toyotának azonban jelenleg nincs raktáron a járműve színe. A rendelés a Toyota központi irodájába kerül. Megmondják, mikor szállítják ki az autót. Csak attól a pillanattól kezdték el gyártani az autót. Különösen az Ön számára. Van egy alapelv: először értékesítés, majd gyártás. Más szóval, az éppen időben (JIT) működik. Először a célok és a határidők, majd a terv és a munka.
A Toyota raktárkészlete nem lesz túlzsúfolt, hiszen az első helyzetben nem kell hosszú ideig tartaniuk az előre gyártott alkatrészeket. Ennek az az oka, hogy amit most gyártanak a soron, az egy nemrégiben eladott gép esetében szükséges.
A JIT-elv egyik kulcseleme a Kanban. A Kanban táblák és kártyák amolyan közlekedési lámpák a just in time rendszerben. A Kanban lehetővé teszi a vállalkozások számára, hogy reagáljanak az ügyfelek igényeire, ahelyett, hogy előre jeleznék az igényeket, ahogy az az első leírt helyzetben történt.
Hasonló példát vetíthet a szoftverfejlesztési területre:
Alkatrészek helyett - fejlesztési feladatok vagy hibák. A tesztelő több ellenőrzési feladatot kap. Amikor a minőségellenőrző kifogy az áttekintendő feladatokból, értesítenie kell a programozókat, hogy új feladatokat kaphasson tőlük. Ha a programozóknak nincs idejük az új feladatok elvégzésére, a tesztelő egyszerűen munka nélkül marad egy ideig.
A fordított helyzet is megtörténik: a QA-nak sok feladata van, és nincs ideje mindent időben ellenőrizni. Ebben az esetben a termék megjelenési dátuma is késik.
A szoftverfejlesztésben a Kanban egyensúlyozása sokkal nehezebb, mint a termelésben. Befolyásolja a munka sajátosságait: ha a gépek azonos típusú alkatrészeket gyártanak, akkor a programozók saját erőből dolgoznak a kóddal az agyból, amelyben körülbelül 100 milliárd idegsejt és egy, de jelentős emberi tényező található.
A Kanban előnyeit 2008-ban fedeztem fel teljes mértékben, ezt követően mindenhol használom a Kanban táblákat: a személyes tervezéstől a fejlesztésen át egészen a Kanban kerámiaműhelyben történő megvalósításáig.
Íme 13 ok, amiért érdemes bevezetni a Kanbant a szoftverfejlesztéssel foglalkozó informatikai cégeknél:
A szokásos feladatlistákról a Kanban táblákra váltás azonnal megmutatott egy szűk keresztmetszetet: a Tesztelés oszlopban felhalmozódott feladatok nagy sora. A minőségellenőrzőnk nem tudott megbirkózni az ellenőrzési feladatokkal. Hosszú késéssel vette fel a feladatokat az igazolásra. Miután a tesztelő visszaküldte a feladatot felülvizsgálatra, a programozónak már sikerült elfelejtenie. Újra meg kellett néznem a kódot, és emlékeznem kellett a részletekre. Ahogy el tudja képzelni, ez értékes idő. A csapatnak szüksége volt még egy tesztelőre.
A Kanban tábla lehetővé teszi a folyamat szűk keresztmetszete megtekintését, ahol sorok alakulnak ki. A Hygger.io-ban a WIP-korlátok segítenek ebben a feladatban. Ha több vagy kevesebb feladata van, mint amennyire szüksége van, az oszlop piros, illetve sárga színnel van kiemelve.
A funkciók kiadásának sorrendje gyakran fontos. A rangsorolt listákban nehéz pontosan kezelni a sorrendet. Ha egy programozónak egyszerre öt fő prioritású feladata van, akkor nehéz lesz kitalálnia, hogy ezek közül melyiket vállalja el először.
A Kanban tábla csak egy kiutat kínál abból a helyzetből, amikor a sorrend számít. Ez a vizuális megoldás egy függőleges oszlop feladatokkal. Minél magasabb a feladat, annál fontosabb. A Kanban egyébként magában foglalja a prioritások meghatározását a módszertan egyik fontos szempontjaként. A követelmények folyamatosan változnak, sok feladat elveszítheti jelentőségét és „lemegy”. Egyes feladatok éppen ellenkezőleg, élesen „emelkedhetnek”. A menedzsernek folyamatosan „a pulzuson kell tartania az ujját”, hogy a programozók a legszükségesebbet megtegyék.
A Kanban megtanít a fő dolgokra összpontosítani. Valami, ami valóban hozzáadott értéket ad a termékhez. Sok haszontalan hibát és fejlesztést tudtunk "leereszteni". Ez eredményt hozott.
A fontos hibák megkülönböztetése a kisebbektől nem könnyű dolga egy termékmenedzsernek, de itt jön a segítség a Swimlanes funkció. Ezek a Kanban tábla vízszintes oszlopai. A programozóknak általában ilyen úszósávok vannak a táblán:
A rendszer hasonló az Eisenhower-kvadránshoz. Fontos és sürgős ügyek a blokkolók. Fontos, de nem sürgős – Feladatok és hibák. Fontos és sürgős, valamint lényegtelen és nem sürgős – ez egy nap. Mellesleg, a vízszintes oszlopok hiánya az egyik olyan tényező, amely megerősíti azt, amit a Trello hiányzik az Agile fejlesztéshez.
A programozónak a munkájára kell összpontosítania. Ezért jó, ha sorra kapja a feladatokat, és nem kell azon gondolkodnia, hogy mit tegyen, ezen már a vezető is gondolkodott. Csak el kell vállalnia a következő feladatot vagy hibát.
Néha a Kanban magában foglalja a feladatok független kiválasztását a programozók által felülről. Akkor minden ember szakmai színvonala egyenlő legyen, nehogy a legnehezebb feladat a junior szakemberre „essen”.
A Saját feladatok szűrő segít a feladatokra összpontosítani. Segít gyorsan látni a feladatait a táblán.
A szemed előtt - a projekt teljes képe. A tábla megnyitásával gyorsan választ kaphat fontos kérdésekre:
A Kanban segít rugalmasabbá válni. Erre különösen akkor van szükség, ha a terméket kiadják, és sok hasznos visszajelzést kap. Ezek támogatási üzenetek, viselkedéselemzések, a/b teszteredmények, áttekintések stb. Amint „feltöltünk” egy új funkciót a termelésbe, a visszajelzések alapján azonnal elkezdjük módosítani. Korábban a programozó nem akart „baloldali” feladatokat végezni, félt „betölteni” a sprint határidőket. Kanban szerint a programozó úgy működik, mint egy processzor: egy ciklus - egy feladat.
Minél gyakoribbak a ciklusok, annál rugalmasabbá válik a fejlesztőcsapat. Csapatunk számára az ideális tapintat 8-12 óra. A nagy feladatokat le kell bontani.
A Scrumnak sok időbe telt a funkciók értékelése a sprint kezdete előtt. A Kanban esetében nincs szükség értékelésre. Ha megcsináljuk, akkor kész lesz.
A Scrum sok kommunikációt foglal magában. A sprint kezdetét tervezés kíséri: feladatok elemzése, értékelése. Felállás minden héten szükséges. A sprint vége után visszatekintést tartanak. Ennek eredményeként az összes kommunikáció az idő körülbelül 30%-át teszi ki. De ezúttal a csapat munkára költhetett.
A Kanban segítségével a csapat következetesebben kezd dolgozni. Most a tesztelő szinte azonnal ellenőrzi a funkciót, miután a programozó elkészítette. Hasonlóan más területeken is: tervezők, UX, szerkesztők, értékesítés.
Korábban a QA nem akkor ellenőrizte a funkciót, amikor a programozó elkészítette, hanem hosszú idő után. Ezalatt a programozónak sikerült mindent elfelejtenie a világon, beleértve ennek a feladatnak a részleteit is.
A Scrumban csak a sprint végén „töltjük fel” a funkciókat a termelésbe. Körülbelül 3 hetente egyszer. Kanbanban szinte azonnal a tesztelő általi elfogadás után. Néhány naponta egyszer.
Így gyorsan megtudjuk, hogy a funkció bekerült-e a felhasználókba vagy sem. Ha nem, akkor valahol hiba történt. És fontos, hogy mi legyünk az elsők, akik hibáznak. Ez nem azt jelenti, hogy szeretünk hibázni. De ha mi vagyunk az elsők, akik értesülünk a hibáról, mi leszünk az elsők, akik megtudják és eldöntik, mit tegyünk.
Nem kell folyamatosan "húzni" a programozókat. Megnyitottuk a Kanban táblát, gyorsan megnéztük, hogy ki és mit csinál, az összes állapotot, és nyugodtan visszatérhet a menedzsmenthez. A programozó pedig továbbra is változó állapotban van, és új magasságok megszerzését várja.
Korábban a programozók nem tudták, mit csinálnak kollégáik. Most a Kanban segítségével egy programozó, akárcsak egy menedzser, odamehet a táblához, és megnézheti, mit csinálnak a kollégák. Ezekre az információkra szükségük van a projekttel kapcsolatos közös erőfeszítéseik összehangolásához.
Korábban a programozó egyszerre több feladattal foglalkozott. Választhattam a hangulatomnak megfelelő feladatot, vagy teljesen megfeledkezhetnék arról, amit pénteken csináltam hétfőn.
Most a WIP-korlátok és a panorámakép megfelelően korlátozza a programozót: nem tud egyszerre több feladatot elvégezni.
KonklúziókéntÚgy tűnhet, hogy ragaszkodunk ahhoz, hogy a Kanban jobb, mint a Scrum. De nem az. Mindennek megvan a maga ideje. A Hygger tapasztalatai azt mutatják, hogy a Scrum a termékfejlesztés kezdetén, a Kanban pedig akkor, amikor a termék már belépett az arénába.
A Kanban nem csodaszer minden vállalkozás számára. Ha rossz falhoz helyezi a létrát, bármilyen meredeken mászik is fel, akkor is rossz helyre kerül. Ezért a Kanban szükséges, de nem elégséges feltétele egy termék vagy projekt sikerének.