Technology

20_leankitkanbantouchscreen3_420px
Forrás: -

Módszeresen, hatékonyan

Japánból számos, hatékonyságnövelő módszertan, irányelv került a világ termelési vérkeringésébe, ilyen a kanban is, amelyet a szoftverfejlesztésben is lehet alkalmazni.

A kanban-rendszert az 1950-es években kezdték alkalmazni a Toyotánál, s csakhamar alapvető része lett a just in time (jit) gyártási rendszereknek. Kifejlesztésének ötletét egy szupermarketben alkalmazott kártyarendszer adta (kan: kártya, ban: jel). Az áruházban a termékeket, mondjuk, sárga színű azonosító kártyákkal látták el. A pénztáros a termékek eladásakor levette a kártyákat és a raktárba küldte. A raktáros a beérkezett kártyák alapján előkészítette az eladótérbe kiszállítandó árukat, feltette rá a sárga kártyákat és kivitte a termékeket. A sárga kártyák felrakásakor a raktárban levették a termékekről a gyártói kártyákat, s ezeket eljuttatták a gyártóhoz.

A termékgyártó a beérkezett kártyák száma és adatai alapján legyártotta a szükséges mennyiséget. Az áruk feltöltése, a készletek figyelése, az utánrendelés, a gyártás és a kiszállítás a kártyák alapján történt.

 

Éppen időben

Sok vállalat ezzel szemben veszteséges folyamatokat alkalmaz, mert az első lépés nagy tételben állítja elő a cikkeket, mielőtt a második lépésnek szüksége lenne rájuk. A készleteket tárolni, regisztrálni és kezelni kell, amíg a következő lépés fel nem használja, és ezek a lépések sok erőforrást emésztenek fel.


Ezzel szemben a jit-elgondolás az, hogy akkor kell termelni és kiszállítani a terméket, amikor arra szükség van, és akkor kell beszerezni, amikor adott egység megmunkálására szükség van. A nulla készletszint ugyan nem mindig valósítható meg, ám a folyamatok megfelelő szervezése esetén be lehet állítani olyan optimális (minimum) értékre, amelynek segítségével a vállalati folyamatok zavartalan lebonyolítása biztosítható.

A kanban irányelvein alapuló szoftverfejlesztés a fejlesztési folyamat gördülékeny, rugalmas, ellenőrzött kivitelezésére fekteti a hangsúlyt, és nagy figyelmet fordít a megvalósítás fázisainak mérésére.

 

Munkafázisok

A kanban rendszerű fejlesztési projektek menedzselését néhány egyszerű, világos alapelv vezérli – magyarázza Fabók Zsolt, a téma szakértője.

A kanban-rendszer kialakításának első lépése a fejlesztés munkafázisainak meghatározása. A fejlesztendő funkciók ezeken a fázisokon keresztülhaladva valósulnak meg, a felméréstől az éles üzembe állításig. Ezeket a fázisokat a csapat számára jól látható helyen kell megjeleníteni. Ehhez a gyakorlatban legtöbbször státuszoszlopokat tartalmazó táblát használnak.

A kanban-rendszer legfontosabb szabálya az egyes munkafázisokban feldolgozás alatt lévő elemek számának korlátozása. Ez a korlát határozza meg, hogy a csapat egyszerre mennyi feladaton dolgozhat egy adott munkafázisban. Ezt a korlátot wip- (work in progress) limitnek nevezik, és azt biztosítja, hogy a csapat ne halmozzon fel „készleteket” előkészített, de el nem végzett feladatokból. A gyakorlatban ez azt jelenti, hogy a fejlesztést a folyamat végén álló elemek állapota határozza meg, azaz például egy új funkció tesztelése csak akkor kezdődhet meg, ha egy már tesztelés alatt lévő elem tesztelése sikeresen lezáródott és a következő (például telepítés) fázisba lépett, felszabadítva ezzel egy helyet a tesztelés státuszában.

A feldolgozás alatt lévő elemek számának korlátozása végső soron a legfontosabb alapelvek, az áramlás és a húzórendszer betartását szolgálja. Ezek az elvek biztosítják azt, hogy a fejlesztési folyamat során egyenletes ütemben készüljenek el az élesbe állítható funkciók.

 

Azonnali probléma-elhárítás

A húzórendszer azt jelenti, hogy a fejlesztési tevékenységet az ügyféligények megjelenése vezérli. Amikor a csapat egy új igényt azonosít, annak a megvalósítása csak akkor kezdődhet el, ha van szabad kapacitás az első munkafázisra, azaz a felmérés státuszban a wip-korlátnál kevesebb elem vár feldolgozásra.

A kanban-rendszer kifejezetten intoleráns a hibákkal szemben. Ez egyrészt abban jelentkezik, hogy egy funkció csak megfelelő tesztelés után állítható élesbe. Ha egy funkciót hibásan dolgoztak ki, akkor a tesztelés, hibajavítás státuszban várakozik a hiba kijavításáig. A wip-korlát miatt ugyanakkor ez a várakozás meggátolja, hogy más, időközben implementált funkciók a tesztelés státuszba kerülhessenek át, ami az azt megelőző fázisokban lévő elemek továbbítását akadályozza. Ennek következtében egy idő után a teljes fejlesztési folyamat blokkolt állapotba kerülhet. Ez a mechanizmus felszínre hozza a hibákat és rákényszeríti a fejlesztő teamet azok azonnali elhárítására s ezzel a folyamat állandó tökéletesítésére.

 

Előnyök

Egy vezető sok mindent nyerhet, ha kanbanban dolgozik, vagy olyan beszállítója van, aki e szerint működik.

A kanban bevezetése, használata többek között nem igényel olyan szintű változáskezelést, mint például az agilis módszerek bevezetése, mert tetszőleges rendszerrel tud együtt dolgozni. A bevezetés után továbbá a vezetésnek egyértelmű képe lesz arról, hogy éppen mi folyik a szervezeten belül, mik az aktuális problémák.

Mivel a kanban folyamatosságot feltételez, és ezt nagymértékben támogatja, a szervezet könnyebben tud a külső változásokra reagálni. Például a munka rangsorolása bármikor és bármelyik fázisban megtörténhet – ellenben fontos, hogy ami elkezdődött, azt be is kell fejezni.

A rendszer nagymértékben épít a visszacsatolásra: az igazi kanban-csapatok folyamatosan szállítanak, és a felhasználóktól kapott visszajelzések alapján finomhangolják rendszerüket. Ha egy igazi kanban-csapat olyan visszajelzést kap, hogy a termékkel más irányba kell haladni, akkor a következő szállításon már érezhető lesz ez az irány, nem kell heteket, hónapokat várni, hacsak nem éppen ennyi időre van szüksége a csapatnak egy szállításhoz.

A rendszer adatai le vannak fektetve, a mérési módszerek is ugyanazok, de továbbra sem adja meg a rendszer a lehetőséget – más rendszerekhez hasonlóan – a csapatok összehasonlítására.