Kanban az irodában. Amikor azonban ő és Anderson elkezdték elemezni az XIT teljesítményét, gyorsan azonosította azokat a kulcsfontosságú tényezőket, amelyek negatívan befolyásolták az osztály sebességét.

KANBAN

Kanban rendszer- húzórendszer a termelés és ellátás szervezésére, lehetővé téve a Just-In-Time elv megvalósítását.

A Toyota fejlesztette és vezette be először a világon. 1959-ben ez a vállalat kísérletezni kezdett a Kanban rendszerrel, és 1962-ben megkezdte az egész termelés Kanban elvekre való átállását. A Kanban F. Taylor (1856-1915) elméleti konstrukcióin alapul; G. Ford (1863-1947), valamint a zen buddhizmus és a konfucianizmus filozófiájának néhány rendelkezése.

A Toyota cég gyártásának megszervezése az autók gyártásának és értékesítésének éves tervén alapul, amely alapján az egyes telephelyeken az átlagos napi termelés havi és üzemi tervei készülnek, a fogyasztói kereslet előrejelzése alapján (átfutási idő). - 1 és 3 hónap). A napi gyártási ütemtervek csak a fő összeszerelő sorra készülnek. A műhelyekre és a fő szállítószalagot kiszolgáló területekre nem készítenek gyártási ütemtervet (csak hozzávetőleges havi termelési mennyiségeket állapítanak meg).

A just-in-time filozófia folyamatos alkalmazása lehetővé teszi az eddig fel nem fedezett hibák feltárását. A készlet kiválóan alkalmas a hibák elrejtésére. Csak ha a készlet csökken, akkor láthatók a problémák. Nagyon hasonlít a hogyan magas szintű a víz víz alatti zátonyokat rejt.

A "Kanban" japánul kártyát jelent.

Kétféle Kanban rendszer létezik:

- „Kanban” konténer;

- "Kanban" kártya.

A „Kanban” konténer egy olyan tárolóegység, amelyen a „Kanban” címke található. A tárolón lévő Kanban címke mereven rögzítve van, és a következő tartalommal rendelkezik:

Alkatrész neve;

cikkszám;

Alkatrészek száma;

Az alkatrész címzettjének címe;

Alkatrész feladó címe.

A „Kanban” konténer szerinti alkatrészek és szerelvények rendelési rendszere történik alábbiak szerint: amint az első „Kanban” konténerben az alkatrészek elkészültek, a kezelő a munkahelyről a rack alsó szintjére szállítja (az állvány alsó szintje az üzemeltetői rendelések tárolásának és a szállító általi fogadásnak a helye) és a másodiktól működik. A szállító felveszi az üres konténert, és mivel „Kanban” van a konténerhez rögzítve, visszacsatolás az üzemeltető és a raktáros között a szállítón keresztül az anyagrendeléshez.

A Kanban konténernek van egy hátránya - a raktár létrehozásakor további mennyiségű konténerre van szükség minden egyes alkatrész vagy CI egységhez.

A Kanban kártya négy részre osztott kártya:

Kártya színe;

Alkatrész feladó címe;

A címzett címére történő kézbesítéshez szükséges alkatrész neve, cikkszáma, alkatrészek vagy szerelvények száma;

Az alkatrész címzettjének címe.

Az egyik színválaszték:

Kék - „Kanban” gyártás (a gyártósor és a szállítási terület között);

Piros - „Kanban” raktár (a raktár és a szállítási terület között);

Zöld - „Kanban” üzletek közötti (műhelyek, gyártóüzemek stb. között).

Az alkatrészek szállítását szállítókocsin kell végrehajtani. A műhelyen belül az elektromos szállítást ki kell zárni, mivel ez többletköltséget igényel a karbantartáshoz, javításokhoz, több dolgozót igényel és befolyásolja mások biztonságát. A szállítókocsi négy rekesszel rendelkezik: nagy alkatrészek számára; közepes alkatrészekhez; kis alkatrészekhez; üres konténerekhez.

A nagyméretű alkatrészeket mind a raktárban, mind a kezelő munkahelyén kézzel kell áthelyezni a szállítókocsira; munkahelyen, vagy fordítva. Az alkatrészek munkahelyre történő szállítását úgy kell végrehajtani, hogy a szállító ne lépjen be a kezelő munkaterületére. Ehhez az üzemeltetők munkahelyén fel kell tüntetni az alkatrészek összes címét az elrendezésnek megfelelően, hátoldal kezelő asztala.

A Kanban rendszer első elve- a Kanban címkének az alkatrészekkel együtt kell lennie, vagy azokhoz rögzítve kell lennie.

A Kanban rendszer második elve- két „Kanban” a munkahelyen, i.e. Egy munkahelyen megengedett két szabványos alkatrész. Ez az elv csak a kis és közepes méretű alkatrészekre vonatkozik, amelyek szállítása speciális konténerekben történik - ez az elv határozza meg az alkatrészek szállításának idejét.

A Kanban rendszer harmadik alapelve- hibás alkatrészek hiánya a gyártósoron (szállítószalagon), mivel ha hibás alkatrészek kerülnek a szállítószalagra, nem lesz stabil a szállító és a szállítószalag működése.

A Kanban rendszer negyedik elve- formáció új rendszer raktári létesítmények:

Egy raktárnak kell lennie, a lehető legközelebb a szállítószalaghoz;

A raktár az önkiszolgáló üzlet elve szerint van kialakítva - a szállító mozog a raktárban, és maga gyűjti össze a szükséges alkatrészeket és összeszerelési egységeket egy kocsiba;

A szükséges mennyiségben alkatrészeket és CI-ket raktári dolgozóknak kell elkészíteniük a szállítónak, az egyik legtöbbet fontos tényezők az újraszámítás hiánya, vagy gyors újraszámítás (mért, cellás konténerek). Az áruk és anyagok átadását a szállítótól az üzemeltetőhöz szintén újraszámítás nélkül kell végrehajtani - az emberek egymás iránti bizalma előtérbe kerül.

Mert racionális használat raktáros, fuvarozó stb. munkaideje, szükséges alkalmazni - az iratkezelési rendszer egyszerűsítése (vonalkód használata).

Wikimédia Alapítvány.

2010.:

Szinonimák

• Könyvek

Kanban és éppen időben a Toyotánál. A menedzsment a munkahelyen kezdődik. A fejlődésre való törekvésről, a szamuráj hagyományig visszanyúlóan, mely szerint a harcos soha nem szűnik meg fejleszteni tudását és élesíteni a kardját. A kanban rendszerről és a just-in-time...
Több cikket fogok írni az új Kanban (Kanban Development) agilis fejlesztési módszertanról, hogy felkészüljek a 2009-es Skandináv Agilis Konferenciára, ahol az egyik beszámolót fogom tartani (egyébként meghívok mindenkit a konferencia).
Ma közzéteszem az első cikket.
Az első cikk fő célja, hogy a lehető legegyszerűbben leírja a Kanban alapjait: mi az, miben különbözik a többi rugalmas módszertől, és miért van rá szükség.
Szeretnék minél több kérdést és kételyt összegyűjteni a megjegyzésekben, hogy válaszolhassak rájuk a következő cikkekben, ezért írjon bármit, amit nem ért, vagy bármi mást, amit tudni szeretne a Kanbanról.

Nem vagyok éppen nagy szakértő ebben az új módszertanban, de a csapaton belül egyedül jutottunk el a Kanbanhoz, és következetesen végigmentünk a mutáció minden szakaszán a SCRUM-tól a Kanbanig, tehát gyakorlati tapasztalataink vannak. Először a kifejezés eredetéről írok.

Ez a kifejezés Japánból került hozzánk a szűk körökben széles körben ismert Toyota gyártási rendszernek köszönhetően. Szeretném, ha minél többen olvasnának erről a rendszerről és a benne foglalt alapelvekről - lean termelés, folyamatos fejlesztés, ügyfélközpontúság stb. Mindezeket az alapelveket Taiichi Ohno A Toyota gyártási rendszer című könyve írja le, amelyet orosz nyelvre fordítottak le.

A Kanban kifejezésnek szó szerinti fordítása van: „Kan” azt jelenti, hogy látható, látható, a „ban” pedig kártyát vagy táblát jelent.
A Toyota gyáraiban mindenhol Kanban kártyákat használnak, hogy elkerüljék a raktárak és a munkaterületek zsúfoltságát az előre elkészített alkatrészekkel. Képzelje el például, hogy ajtókat szerel fel egy Toyota Corollára. Van egy 10 ajtós csomagja a munkahelye közelében. Egymás után rakja fel őket az új autókra, és amikor 5 ajtó maradt a csomagban, akkor tudja, hogy ideje új ajtókat rendelni. Fogsz egy Kanban kártyát, írsz rá egy rendelést 10 ajtóra és elviszed az ajtógyártóhoz. Tudod, hogy éppen akkor készíti el őket, amikor kifogysz a maradék 5 ajtóból. És pontosan ez történik – az utolsó ajtó beszerelésekor egy 10 új ajtót tartalmazó csomag érkezik. És ez mindig megtörténik – csak akkor rendel új ajtót, amikor szüksége van rájuk.
Most képzelje el, hogy egy ilyen rendszer az egész üzemben működik. Sehol nincs olyan raktár, ahol hetekig-hónapokig hevernek az alkatrészek. Mindenki csak kérésre dolgozik, és pontosan annyi alkatrészt gyárt, amennyit kér. Ha hirtelen több vagy kevesebb megrendelés érkezik, a rendszer maga is könnyen alkalmazkodik a változásokhoz.

A Kanban kártyák fő célja ebben a rendszerben az elvégzett munka mennyiségének csökkentése pillanatnyilag munka" (folyamatban lévő munka).
Például egy teljes gyártósorhoz pontosan 10 ajtókártya tartozik. Ez azt jelenti, hogy egy adott időpontban legfeljebb 10 kész ajtó lesz a vonalon. Mikor kell új ajtót rendelni és mennyi dolga a beszerelőnek. Csak ő ismeri az igényeit, és csak ő tud rendelést leadni az ajtógyártónál, de ő mindig 10-re korlátozódik.
Ezt a Lean gyártási módszert a Toyota találta fel, és ma már sokan gyártó cégek Bevezetés alatt áll, vagy már bevezették az egész világon.

De ez mind a termeléshez kapcsolódik, nem a szoftverfejlesztéshez.
Mi a Kanban fejlesztés a szoftverrel kapcsolatban, és miben különbözik a többi rugalmas módszertől, legyen az SCRUM vagy XP?

Először is azonnal meg kell értenie, hogy a Kanban nem konkrét folyamat, hanem értékrend. Pont mint a SCRUM XP-vel. Ez azt jelenti, hogy senki nem fogja megmondani, mit és hogyan kell csinálni lépésről lépésre.
Másodszor, az egész Kanban egyetlen egyszerű mondattal leírható - „A jelenleg folyamatban lévő munka csökkentése (folyamatban lévő munka)”.
Harmadszor, a Kanban még „rugalmasabb” módszertan, mint a SCRUM és az XP. Ez azt jelenti, hogy nem fog megfelelni minden csapatnak vagy minden projektnek. Ez azt is jelenti, hogy a csapatnak még jobban készen kell állnia az agilis munkára, mint a SCRUM-ot és XP-t használó csapatoknak.

A Kanban és a SCRUM közötti különbség:
- A Kanbanban nincs idődoboz semmire (se feladatokra, se sprintekre)
- A Kanbanban több a feladat és kevesebb
- A Kanbanban a feladatok határidejének becslése nem kötelező, vagy egyáltalán nem kötelező
- A Kanbanban nincs „csapatsebesség”, és csak a feladat elvégzésének átlagos idejét veszik figyelembe

Most nézze meg ezt a listát, és gondolja át, mi maradt meg agilis módszertan, ha eltávolítjuk a sprinteket, növeljük a feladatok méretét és leállítjuk a csapat sebességének mérését? Semmi?
Hogyan is beszélhetünk fejlesztésirányításról, ha eltávolítjuk a főbb vezérlőeszközöket - a határidőket, a munka sebességét és a sprinteket? Számomra ez a kérdés szinte a legfontosabb.
a menedzserek mindig az irányításra gondolnak, és megpróbálják megszerezni azt, bár a valóságban soha nem rendelkeznek vele. A fejlesztés menedzser általi ellenőrzése kitaláció. Ha a csapat nem akar dolgozni, akkor hiába irányítod, megbukik a projekt.
Ha a csapat élvezi a munkát és teljes odaadással dolgozik, akkor nincs szükség kontrollra, csak beavatkozik és növeli a költségeket.
Például a SCRUM jól ismert problémája a megbeszélések, értekezletek és a nagy időveszteség a sprintek csomópontjain (amikor legalább egy napot az egyik sprint lezárásával, majd egy napot egy új nyitásával töltenek). ha a sprint 2 hetes, akkor 2 hétből 2 nap 20%, rohadt sok). Ennek eredményeként a SCRUM használata során az idő közel 30-40%-át magának a folyamatnak a karbantartására fordítják - napi megbeszélésekre, 5%-ban workshopokra, sprint retrospektívákra stb. 30%!

A Kanban fejlesztés elsősorban a feladatokra való összpontosításában tér el a SCRUM-tól. Ha a SCRUM-ban a sprintek sikeres teljesítése a fő hangsúly a csapatnak (el kell ismernünk, hogy ez igaz), akkor a Kanbanban a feladatok állnak az első helyen.
Nincsenek sprintek, a csapat az elejétől a befejezésig egy feladaton dolgozik. A feladat telepítése akkor történik meg, amikor az készen áll. Az elkészült munkák bemutatása - is. A csapat ne becsülje meg a feladat elvégzésének idejét, mert ennek nincs sok értelme, és az elején szinte mindig rossz.
Ha a menedzser bízik a csapatban, akkor miért kell időbecslést készíteni? A menedzser feladata priorizált feladatkészlet létrehozása, a csapaté pedig az, hogy ebből a készletből minél több feladatot teljesítsen. Minden. Nincs szükség vezérlésre. A menedzsertől csak feladatokat kell hozzáadnia ehhez a készlethez, vagy módosítania kell a prioritásukat. Így irányítja a projektet.

A csapat Kanban táblát használ a munkához. Például így nézhet ki (kivéve):

Oszlopok balról jobbra:

A projekt céljai:
Nem kötelező, de hasznos oszlop. Magas szintű projektcélokat helyezhet el ide, hogy a csapat láthassa azokat, és mindenki tudjon róluk. Például: „Növelje a sebességet 20%-kal” vagy „Támogatás hozzáadása a Windows 7 rendszerhez”.

Feladatsor:
Itt tárolják a feladatokat, és készen állnak a kezdésre. A legfelső, legmagasabb prioritású feladat mindig végrehajtásra kerül, és a kártyája a következő oszlopba kerül.

Tervezésfejlesztés:
Ez és a többi oszlop a „Befejezve”-ig változhat, mert a csapat dönti el, hogy a feladat milyen lépéseken keresztül éri el a „Befejezett” állapotot.
Ez az oszlop például olyan feladatokat tartalmazhat, amelyeknél a kód vagy az interfész kialakítása még nem világos, és amelyek megvitatása folyamatban van. A beszélgetések befejeztével a feladat a következő oszlopba lép.

Fejlesztés:
Itt a feladat lefagy, amíg a funkció fejlesztése be nem fejeződik. Ha elkészült, a következő oszlopba lép.
Vagy ha az architektúra nem megfelelő vagy pontos, a feladat visszakerülhet az előző oszlopba.

Tesztelés:
A feladat ebben az oszlopban van a tesztelés alatt. Ha hibákat talál, akkor visszakerül a Fejlesztésbe. Ha nem, akkor továbbmegy.

Telepítés:
Minden projektnek megvan a saját telepítése. Valakinek ez azt jelenti, hogy posztol új verzió terméket a kiszolgálóra, míg mások egyszerűen véglegesítik a kódot a tárolóban.

Befejezett:
A matrica csak akkor kerül ide, ha a feladattal kapcsolatos összes munka befejeződött.

Minden munkában vannak sürgős feladatok. Tervezett vagy nem, de azokat, amelyeket most azonnal meg kell tenni. Ezekre kiemelhetjük különleges hely(a képen „Expedite” jelzéssel). Egy sürgős feladatot behelyezhet az Expedite programba, és a csapatnak azonnal el kell kezdenie a végrehajtását, és a lehető leggyorsabban végre kell hajtania. De ilyen feladat csak egy lehet! Ha megjelenik egy másik, azt hozzá kell adni a „Feladatsorhoz”.

És most a legfontosabb. Látod a számokat az egyes oszlopok alatt? Ennyi feladat lehet egyszerre ezekben az oszlopokban. A számokat kísérletileg választják ki, de úgy gondolják, hogy a csapatban lévő fejlesztők számától függenek.
Például, ha egy csapatban 8 programozó van, akkor a „Fejlesztés” sorba beírhatja a 4-es számot. Ez azt jelenti, hogy a programozók legfeljebb 4 feladatot hajtanak végre egyszerre, ami azt jelenti, hogy sok oka van rá kommunikálni és tapasztalatokat cserélni. Ha odaírja a 2-es számot, akkor 8 két feladatot végző programozó megunhatja, vagy túl sok időt veszíthet a megbeszélésekre. Ha 8-at állítasz be, akkor mindenki elvégzi a saját feladatát, és néhány feladat sokáig ott marad a táblán, de fő feladata A Kanban annak az időnek a lerövidítése, amely alatt a feladatnak az elejétől a kész állapotba kerüléséhez szükséges.
Senki nem fog pontos választ adni arra, hogy mik legyenek ezek a korlátok, de először próbáld meg elosztani a fejlesztők számát 2-vel, és nézd meg, hogyan működik ez a csapatodban. Ezek a számok azután a csapatának megfelelően módosíthatók.
A „fejlesztők” alatt nem csak a programozókat értem, hanem más szakembereket is. Például a „Tesztelés” oszlop esetében a fejlesztők tesztelők, mert a tesztelés az ő felelősségük.

Az ilyen táblán lévő feladatok nem csak feladatok, hanem az úgynevezett Minimum Marketing Feature, azaz egy olyan szolgáltatás, amely „eladható” az ügyfeleknek.
Egy jó teszt az MMF számára, ha felteszi magának a kérdést: „Írjak erről a funkcióról a vállalati blogon?” Ha nem, akkor nem MMF.

Milyen újat és hasznosat nyújt egy ilyen limitekkel ellátott tábla?

Először, A párhuzamos feladatok számának csökkentése nagymértékben csökkenti az egyes feladatok végrehajtási idejét. Nincs szükség kontextusváltásra a feladatok között, a különböző entitások nyomon követésére, ütemezésére stb. - csak az történik, ami szükséges. Nem kell sprint tervezést és 5%-os workshopokat szervezni, mert a tervezés már megtörtént a „feladatsor” oszlopban, és a feladattal kapcsolatos részletes munka CSAK akkor kezdődik, amikor megkezdődik a feladat végrehajtása.

Másodszor, a dugók azonnal láthatóak. Például, ha a tesztelők nem tudnak megbirkózni a teszteléssel, akkor nagyon hamar kitöltik a teljes oszlopukat, és az új feladatot végrehajtó programozók már nem tudják áthelyezni azt a tesztelési oszlopba, mert tele van. Mit tegyek? Itt az ideje, hogy emlékezzünk arra, hogy „egy csapat vagyunk”, és megoldjuk ezt a problémát. Például a programozók segíthetnek a tesztelőknek elvégezni az egyik tesztelési feladatot, és csak ezután helyeznek át egy új feladatot a szabad helyre. Ez mindkét feladatot gyorsabban elvégzi.

Harmadszor, kiszámíthatja egy átlagos feladat elvégzéséhez szükséges időt. A kártyán megjelölhetjük a feladatsorba való felvétel dátumát, majd az indítás dátumát és a befejezés dátumát. Ezt a három pontot felhasználva legalább 10 feladatnál már kiszámolható az átlagos várakozási idő a feladatsorban és az átlagos feladatvégzési idő. És ezekből a számokból a menedzser vagy a terméktulajdonos már kiszámolhat, amit akar.

Az összes Kanban három alapvető szabállyal írható le:
1. Vizualizálja a termelést
- Oszd fel feladatokra a munkát, írj fel minden feladatot egy kártyára, és helyezd ki a falra vagy a táblára.
- Használjon elnevezett oszlopokat egy feladat állapotának megjelenítésére a termelésben.
2. WIP korlátozása(folyamatban lévő vagy egyidejűleg végzett munka) mindegyiken gyártási szakaszban.
3. Mérje meg a ciklusidőt(átlagos idő egy feladat elvégzésére) és folyamatosan optimalizálja a folyamatot csökkenteni ezt az időt.

Csak 3 szabály!
Például a SCRUM-ban 9 alapszabály van. XP-ben - 13, és a klasszikus RUP-ban - akár 120. Érezd a különbséget.

Itt fejezem be az első cikket a Kanbanról.
Várom visszajelzéseiket és észrevételeiket, valamint javaslataikat a jövőbeni cikkekhez.

A munkában való felhasználásukhoz szabályokat találtak ki.

A Kanban a munka irányításának agilis módja. Mindössze hat szabályt tartalmaz, és evolúciós átmenetet javasol a hagyományos gondolkodásmódról az agilisra. Az agilis edzők gyakran hasonlítják össze a Kanbant a vízzel – körbejárja a vállalat szerkezetét és hierarchiáját, és lassan elkezdi megváltoztatni azokat. Ahogy a víz koptatja a köveket, a Kanban megváltoztatja a gondolkodásmódot.

Nem kell nagy erőfeszítéseket tennie ahhoz, hogy agilis legyen – az átállás során nincs átszervezés, és eleinte megmaradnak a megszokott szerepek. Minden fokozatosan változik, és nem okoz gondot a Csapatnak.

Kinek alkalmas a Kanban?

A Kanbannak nincsenek korlátozásai. Segítségével az ifjú házasok megtervezik családi költségvetésüket, a Microsoft kis részlegei új programokat fejlesztenek ki, a Toyota pedig a teljes termelést irányítja.

A Kanbannak külön ágai vannak: gyártás, szoftver és személyi. Annyira különböznek egymástól, hogy a vizualizációk teljesen különböznek egymástól. A gyártásnak számos szakasza van, mindegyiknek megvan a saját táblája, és mindegyik szétszórva van a műhelyekben. A kártyák az összeszerelés szakaszait jelzik, a vizualizáció pedig a műhelyek ellátását célozza a szükséges alkatrészekkel. Az informatikusoknak általában van egy közös táblájuk; csapatmunkaés segíti a közös munka irányítását.

Hogyan használjuk, hogy mozgékonyak legyünk

A Kanbanban csak hat szabály van, ezeket fokozatosan vezetik be. Addig nem adnak hozzá újakat, amíg a korábbi változtatások a legtöbb alkalmazott számára ismertté nem válnak.

A Kanban eleinte a régi struktúra és hierarchia megkímélését javasolja, így a változások evolúciós jellegűek lesznek. Nem kell más, mint egy erős indulási vágy és a kezdeményezés ösztönzése a cégben.

1. szabály: Vizualizálja a feladatfolyamát

A Kanban a vizualizációra támaszkodik. Minden feladat jól látható helyre van írva, így bármikor tudhatja, hogyan mennek a dolgok.

A vizualizáció különböző lehet: cetlivel ellátott tábla, kártyákkal ellátott asztal, Excel táblázat vagy olyan programok, mint a Trello és a Jira. Nincs jó vagy rossz vizualizáció – az a jó, ami neked megfelel:

Kezdőknek cetlivel ellátott tábla vagy fal használatát javasoljuk. Fizikai tábla kényelmesebb, mint a programok, mert mindig a szemed előtt van. Nem kell bekapcsolnia számítógépét, meg kell nyitnia a böngészőt, és fel kell keresnie a webhelyet, hogy megtudja, hogyan halad a munka. A csapat azonnal látja az aktuális képet.

A fizikai tábla érzelmileg is meleg. Képzeld csak el, hogy befejezted a feladatot, odamentél a táblához, és áthelyezted a kártyát egy másik oszlopba. Szuper vagy, és ezt mindenki tudja. Ez nem fog megtörténni a Trellóban és a Jirában; a kártya egyszerűen egy másik oszlopban jelenik meg.

Írja le az összes feladatot. A vizualizáció létrehozásához fel kell írnia az összes olyan feladatot, amelyet most végez, és a következő napokban fog elvégezni. Ezek után kiderül, hogy mennyi van igazi munka, és hány van a tervekben.

Határozza meg a feladatok állapotát. A feladatállapotok a tábla oszlopaiban láthatók. Különféle oszlopokat használhat, nincsenek konkrét szabályok. Kezdésként hármat kínálunk: „Teendő”, „Munka” és „Kész”. Ezután szükség esetén kisebbre bonthatja őket, vagy új állapotokat találhat ki.

Fontos: minden feladatnak a táblán kell lennie. Nem lehet azon dolgozni, ami nem szerepel a vizualizációban.

2. szabály. Korlátozza az egyidejű munka mennyiségét

Miután elkészült a vizualizáció, meg fog lepődni, mennyi munkát végez párhuzamosan a Csapat. Többek között ez az egyik oka annak, hogy a projektek elhúzódnak: az energiát nem a feladatokra, hanem a köztük való váltásra fordítják.

A Kanban az egyidejű munka mennyiségének korlátozását javasolja. Ez növeli a hatékonyságot, és felgyorsítja a kártyák előrehaladását a „Teendő” állapotból a „Kész” állapotba. Javasoljuk, hogy rögzítse az aktuális feladatok számát, és ezt a számot használja kezdeti korlátként. Ezután a határt fokozatosan csökkenteni kell:

Rögzítse a határt. Egyezzen meg kollégáival, hogy az egyes oszlopokból hány feladatot tud egyszerre elvégezni. Írja ezeket a korlátozásokat számokkal az oszlopok fölé, vagy korlátozza a helyet a táblán, hogy új kártyák ne férhessenek rá.

A feladatok rangsorolása. Az egyidejű munkák számának korlátozása után sok kártya lesz a „Teendő” oszlopban. Ezek megszervezéséhez fontossági sorrendet kell felállítani. A kártyákat színnel jelölheti, meghatározott sorrendbe rendezheti, vagy pontozást készíthet. A lényeg az, hogy mindenki világosan megértse, mely feladatokat kell most elvégezni, és melyeket lehet elhalasztani pár nappal.

Fontos: fejezze be a megkezdett dolgokat, ahelyett, hogy egyszerre több újat is vállalna.

3. szabály: Irányítsd a feladatok menetét

A vizualizáció segít nyomon követni a kártya előrehaladásának sebességét és az alkalmazottak egységes leterheltségét. Ha valami nem stimmel, az azonnal látható a táblán:

Amikor megjelenik egy forgalmi dugó, az elv érvényesül: egy mindenkiért, és mindenki egyért. A tétlenül hagyott alkalmazottak nem ülnek a sarokba, hanem segítenek eltakarítani a romokat. Például a tervezők akkor vesznek részt dokumentumok tesztelésében vagy megfogalmazásában, amikor nincs saját munkájuk.

Ez nem jelenti azt, hogy minden munkát másokért kell elvégeznie. Minden alkalmazott maga határozza meg, hogy mennyivel bővíti felelősségi körét. De ne feledje, hogy a kapcsolódó területek megértésének képessége professzionálisabbá tesz.

Irányítsd a terhelést. A munka legyen ritmikus. Ha zuhanást érzel, menj a táblához. Lehet, hogy kollégái túlterheltek, és segítségre van szükségük.

Kérjen magának segítséget. Ha forgalmi dugó alakult ki a környéken, nem kell csendben maradnia. Az Ön általános sikere a munkájától függ, így kollégái biztosan segítenek. Nézze meg a táblán, hogy ki a legkevésbé elfoglalt, és kérjen tőle segítséget.

Fontos: A tábla megmutatja, hogyan halad a munka. Segíts a csapatnak a lehető leggyorsabban befejezni.

4. szabály: Tegye egyértelművé a megállapodásokat és az elvárásokat.

A Csapat működésének szabályait mindenkinek ismernie kell, ugyanakkor rendszeresen változnia kell. Leginkább akasztani javasoljuk fontos szabályokat a táblánál vagy az oszlopokon belül. Így néz ki:

Írja le a táblával való munka szabályait. Egyezzen meg kollégáival, és írja le, hogy milyen feltételekkel vállalhat új feladatot, hogyan helyezheti át egy másik rovatba, és mikor tekintheti késznek. Tegye nyilvánvalóvá a kártyák reklámozásának szabályait.

A szabályokat jól látható helyen tedd ki. A kollégákkal való könnyebb kapcsolattartás érdekében tegye közzé a szabályokat a tábla közelében vagy a hangszórókon belül.

Fontos: megállapodások segítik a Csapat harmonikus munkáját. Tedd egyértelművé őket.

5. szabály. Elemezze a munkát

Rendszeres tervezési értekezletek és elemzések - kötelező követelmény Kanbana. Szükségük van rájuk, hogy megbizonyosodjanak arról, hogy a csapat a helyes irányba halad, és az ütemtervben és a költségvetésben marad.

Nincsenek formátumkorlátozások. Ezek lehetnek találkozók, hívások vagy egyszerűen csak kérdőívek. Az Agile előnyben részesíti az élő kommunikációt, ezért javasoljuk, hogy gyülekezzenek a tábla körül. Tervezési értekezletek - minden nap és hetente, elemzés - havonta egyszer. Mik ezek a találkozók:

Napi tervezési értekezletek kényelmesen kivitelezhető a vizualizáció mellett. A találkozó célja a feladatáramlás sebességének növelése. A csapat átvizsgálja a táblát jobbról balra, megtalálja a problémás területeket, és eldönti, hogyan kell gyorsan elvégezni az aktuális feladatokat. Bárki tehet javaslatot, és a Csapat meghallgatja.

A heti találkozókon az egész csapat találkozik a vezetőséggel. Együtt megvitatják a munka sebességét és a kockázatcsökkentést.

Havonta egyszer A cégben dolgozó összes csapat összegyűlik. A menedzsment beszél a pénzügyekről, és minden alkalmazott megérti, mennyit keresett az osztálya, mit csinál a vállalat egésze és milyen állapotban vannak a feladatok. A csapatok megosztják egymással, hogy milyen erőforrásokra van szükségük.

Fontos: Legyen proaktív, kommunikáljon kollégáival és kínáljon ötleteket.

6. szabály: Fejlődés együttműködésen alapuló kísérletezéssel

A Kanban csapata mindig a tökéletes rendszert keresi, ahol a kártyák a lehető leggyorsabban mozognak a táblán.

Ennek érdekében a Csapat kísérleteket végez: megváltoztatja az egyidejű munka mennyiségét, vagy másképp rangsorolja a feladatokat. A rendszer fejlődéséhez a kísérleteket meg kell osztani, nem pedig az egyes alkalmazottak között. Rendszeresen ki kell próbálnia új dolgokat:

Javasoljon fejlesztéseket. Ha a csapat nem tudja bizonyítani, hogy ez rossz hatással lesz a munka eredményére, kísérletet végeznek.

Próbáljon meg egy változtatást egyszerre. Annak érdekében, hogy pontosan megtudja, milyen hatással volt egy innováció, ne végezzen egyszerre több kísérletet. Jobb, ha egyik ötletet a másik után próbáljuk ki, és megtartjuk a legsikeresebbeket.

Fontos: a kísérletek segítik a Csapat fejlődését, ne félj új dolgokat kipróbálni.

Hogyan ne feledkezzünk meg a helyes gondolkodásmódról

Mind a hat Kanban-szabályt lefedtük. Nem adnak konkrét utasításokat, csak irányítják a Csapatot. Javasoljuk, hogy ellenőrizze magát:

Minden alkalmazott proaktív, és törődik az általános sikerrel;

Segít, ha a kollégák elakadnak;

Az alkalmazottak rendszeresen végeznek kísérleteket a munkafolyamat javítása érdekében;

A csapatok megvitatják a vállalat pénzügyeit és annak teljesítményéhez való hozzájárulásukat;

A cég evolúciós változásokon megy keresztül.

David Anderson, a MYTH kiadó által oroszul megjelent könyv szerzője arról beszél, mi az a kanban, és miért nem csak matricás táblák.

Anderson volt az első, aki a Kanbant használta a szoftverfejlesztésben (2005), ő vezetett be agilis menedzsment módszereket olyan cégeknél, mint a Motorola és a Microsoft, valamint megalapította a Lean Kanban Egyetemet és a David J Anderson School of Management-et.

Mi az a Kanban módszer?

2005 tavaszán volt szerencsém Tokióban nyaralni. Április eleje volt, amikor a cseresznyefák virágoznak. Hogy élvezzem ezt a látványt, életemben másodszor jöttem el a tokiói császári palota Keleti kertjébe. Itt jutott eszembe: A Kanban nem csak a gyártásról szól.

2005. április 9-én, szombaton az északi bejárat felől léptem be a parkba, átkelve a Takebashi metróállomás közelében lévő vizesárkon átívelő hídon. Sok tokiói lakos úgy döntött, hogy elmegy a parkba ezen a napsütéses vasárnap reggelen, és élvezi a nyugalmat és a japán cseresznyefák – sakura – virágzását.

Azt a szokást, hogy a cseresznyefák alatt piknikeznek, amikor a virágok lehullanak, "hanaminak" nevezik. virágünnep). Ez egy ősi japán hagyomány – lehetőség arra, hogy elmélkedjünk az élet szépségéről, törékenységéről és rövidségéről.

Miközben a családommal a parkban sétáltunk, egy idős japán férfi lépett hozzánk egy táskával a vállán. Benyúlt a táskájába, és elővett egy köteg műanyag kártyát. Mindannyiunknak felajánlott egyet, bár azon töprengett, hogy a három hónapos kislányomnak szüksége van-e kártyára. De végül nekem adta a kártyát és őt. Nem szólt semmit, én pedig, mivel rosszul tudok japánul, szintén nem szóltam semmit.

Miután a délelőtt a napon töltöttük, elindultunk a kijárat felé, ahol sor állt a kioszkhoz. Amikor egy kicsit előrelépett, rájöttem, hogy ezek az emberek visszaadták a plasztikkártyákat, amelyek belépőjegyek voltak. Benyúltam a zsebembe és elővettem a kártyáinkat. Egy japán nő volt egyenruhában a kioszkban. A pultnál egy félköríves kivágású üveg válaszfal volt közöttünk, mint egy moziban vagy vidámparkban. Átadtam a kártyáinkat. A hölgy fehér kesztyűs kezével fogta őket, és egy kupacba tette a többiekkel. Nem volt szükség pénzre. Arra nem adtak magyarázatot, miért hordtam magammal fehér plasztikkártyákat két órán keresztül attól a pillanattól kezdve, hogy beléptem a parkba.

Milyen belépőjegyek ezek? Miért adjuk ki őket, ha ingyenesek? Először azt hittem, hogy ez biztonsági probléma. Az összes visszaküldött kártya megszámlálásával a vezetőség biztosítani tudta, hogy a park éjszakai bezárása után senki más ne maradjon bent. Ekkor azonban rájöttem, hogy ha arról beszélünk a biztonságról, akkor ez valami nagyon kétes séma. Honnan tudhatják, hogy nem egy kártyát kaptam, hanem kettőt? A három hónapos lányom látogató vagy poggyász? A rendszer túl változékonynak tűnt. Túl sok a hibalehetőség! Ha ez valóban biztonsági rendszer lenne, akkor kudarcra lenne ítélve, és naponta I. típusú hibákat produkálna.

(Mellesleg megjegyzem, egy ilyen rendszer nem tud második típusú hibákat produkálni, mert ehhez további belépőjegyek nyomtatására lenne szükség. Ez általános hasznos ingatlan kanban rendszerek)

Eközben a biztonságiak minden este átkutatták a parkot, hogy elveszett turistákat keressenek. Nem, ez valami más.

Rájöttem, hogy a császári palota kertjeiben kanban rendszert valósítanak meg! Ez a felismerés ráébredt arra, hogy a Kanban rendszerek nem csak a gyártásban hasznosak.

Úgy néz ki, mint a kanban tokenek különböző típusok segítséget nyújt minden típusú vezetési helyzetben.

Mi az a kanban rendszer?

A rendszer (megállapodott) kapacitásának megfelelő számú kanban token (esetünkben kártya) kerül forgalomba. Egy kártya egy munkaelemnek felel meg. Minden kártya egy jelzőmechanizmus. Új elem a munka csak akkor kezdődhet el, ha van hozzá kártya. Ez a rendelkezésre álló kártya a munkadarabhoz van csatolva, amikor áthalad a rendszeren. Ha már nincs több kártya, új feladat nem kezdhető el. Bármilyen új munkahely sorban kell maradnia, amíg a kártya fel nem szabadul. Amikor egy bizonyos mennyiségű munka elkészül, a kártyát elengedik és újra forgalomba helyezik. Most elkezdhet dolgozni egy új elemen a sorban.

Ezt a mechanizmust húzórendszernek nevezik, mivel az új munkát akkor vonják be a rendszerbe, amikor az elegendő kapacitással rendelkezik ehhez, nem pedig igény szerint. A sorsolási rendszer nem tud túlterhelni, ha a forgalomban lévő kártyák száma által meghatározott kapacitást helyesen határozzuk meg.

A császári palota kertjében maguk a kertek alkotják a rendszert, a látogatók folyamatban vannak, a kapacitást pedig a forgalomban lévő kártyák száma határozza meg. Az újonnan érkező látogatók csak akkor juthatnak hozzá, ha van jegyük.

IN szokásos időben nem merülnek fel problémák. A csúcsnapokon, például a cseresznyevirágzás hétvégéjén azonban a park nagyon népszerű. Az összes belépőjegy kiállítása után az új látogatóknak sorban kell állniuk a híd előtt, amíg a korábbi turisták a kártyáik visszaadása után el nem indulnak.

A Kanban rendszer egyszerű, olcsó és könnyen megvalósítható módszert kínál a látogatók számának szabályozására és korlátozására. Ez lehetővé teszi a park személyzetének, hogy jó állapotban tartsa a kerteket, és elkerülje a túlzsúfoltság okozta károkat.

A Kanban alkalmazása a szoftverfejlesztésben

A Kanban gyorsan azonosítja a termelékenységet befolyásoló problémákat, és arra kényszeríti a csapatot, hogy ezek megoldására összpontosítson a folyamatos munkafolyamat fenntartása érdekében.

A minőségi és folyamatproblémák láthatóvá tételével a Kanban lehetővé teszi a hibák, a korlátok, a változékonyság és a karbantartási költségek hatásának felmérését. termelési áramlásÉs áteresztőképesség alkalmazottak.

A befejezetlen feladatok egyszerű korlátozása a Kanban segítségével jobb munkaminőséget és termelékenységet eredményez. A munkafolyamat ésszerűsítésének és a minőség javításának kombinációja csökkenti az átfutási időt, valamint növeli a kiszámíthatóságot és a feladat időben történő elvégzésének valószínűségét.

A rendszeres megjelenési ütemek kialakításával és az ütemezések következetes betartásával a Kanban segít a bizalom kialakításában az ügyfelekkel és az értéklánc többi tagjával – más részlegekkel, beszállítókkal és függő partnerekkel.

Mindezzel a Kanban hozzájárul a szervezetek kulturális fejlődéséhez. A problémák leleplezésével és a szervezeti erőfeszítések megoldásukra való összpontosításával, a jövőbeni hatások kiküszöbölésével a Kanban megkönnyíti egy erősen együttműködő, bizalommal, erővel és folyamatosan fejlődő csapat létrehozását.

A Kanban bizonyítottan növeli a felhasználói elégedettséget az értékes funkciók rendszeres, megbízható, jó minőségű kiadása révén. Bizonyítottan javítja a termelékenységet, a minőséget és csökkenti az átfutási időt. Emellett bizonyítékok vannak arra, hogy a Kanban katalizátora lehet egy agilisabb szervezet kialakulásának az evolúciós kulturális változások révén.

10 tézis Kanbanról

A Kanban rendszerek bármilyen helyzetben használhatók, korlátozva a munkaelemek elérhetőségét a rendszeren belül.

1. A tokiói Imperial Palace Gardens kanban rendszert használ a park látogatóinak számának szabályozására.
2. A forgalomban lévő Kanban kártyák száma korlátozza a befejezetlen feladatok mennyiségét.
3. Új feladatot vonnak be a folyamatba, miután a jelzőkártya visszakerült a forgalomba, amikor az előző feladat befejeződött.
4. Az IT-iparban jellemzően virtuális kanban rendszert használunk, mivel a fizikailag meglévő kártyákat nem adják át a befejezetlen feladatok számának korlátozására.

Az agilis szoftverfejlesztésben gyakran látható post-it táblák nem Kanban rendszerek.

A Kanban különböző szakterületekről származó eszközöket használ a problémák elemzésére és megoldások megtalálására.

A Kanban magában foglalja a folyamatok fokozatos fejlesztését a termelékenységet befolyásoló problémák folyamatos azonosításával.

A Kanban módszer modern meghatározása megtalálható online a Limited WIP Society honlapján.

A Kanban engedélyezi az eltérést a szoftverfejlesztésben, ösztönözve a kontextustól függő konkrét megoldások keresését, nem pedig a folyamatdefiníciókhoz való dogmatikus ragaszkodást. életciklus szoftverfejlesztés vagy sablon.

Kanban (kanban, kanban rendszer) egy karcsú gyártósor-menedzsment módszer (japán szó: "jel" vagy "kártya"), amely információs kártyák segítségével továbbítja a gyártási rendelést egy későbbi folyamatból az előzőhöz.

Lehúzó rendszer eszköz, amely utasítja az elemek gyártását vagy eltávolítását (áthelyezését) egyik folyamatból a másikba. ben alkalmazható Termelési Rendszer A Toyota úgy szervezze meg a húzást, hogy értesíti az előző gyártási szakaszt a munka megkezdéséről. A Kanban rendszer lehetővé teszi a termelési kapacitás tervezési láncának optimalizálását, kezdve a kereslet előrejelzésétől, a termelési feladatok tervezésén és ezeknek a feladatoknak a kiegyensúlyozásán/elosztásán keresztül. termelési kapacitás rakodásuk optimalizálásával.

Is szerves része ezt a termelési rendszert Just-in-Time-Production (JIT), amely a gyártásban szükséges anyag szinkron ellátását foglalja magában: a munkahelyen közvetlenül a gyártásba az előírt időpontban, az előírt mennyiségben, az előírt minőségben és fogyasztásnak megfelelő csomagolásban. Az információtovábbítás eszközeként címkéket, kártyákat, konténereket és elektronikus üzenetkártyákat (japánul „kanban”) használnak, amelyek a szupermarket elve szerint mozognak a fogyasztók és a termelők között (lásd 1. ábra).

1. ábra: Termelésirányítás Kanban használatával a szupermarket elve szerint

A módszer célja, hogy egyáltalán megvalósuljon a just-in-time (JIT) termelés gyártósorok a raktári készletek méretének csökkentésére és ennek ellenére garanciára magas fokú a rendelések időben történő teljesítése.

A kommunikáció egyszerűsítésének előfeltétele, hogy egy adott médiumon egyértelműen beazonosítható legyen az információ, hogy mire van szüksége a fogyasztóknak és milyen mennyiségben. Ha az anyag elfogy (vagy például a készlet elérte a minimális szintet), a szállító csak akkor kéri a szállítást új anyag. Ezt a kérést egy kanban kártyán keresztül adják ki, amelyet szükségszerűen minden egyes anyagszállítással szállítanak, és új szállítás céljából visszaküldik az elejére. Ha a gyártó megkapja a kártyát, elkezdi gyártani a szükséges alkatrészeket. A kért alkatrészmennyiség legyártása után a Kanban kártyát a szállítóeszköz tartójához csatolják és továbbítják bizonyos szabályokat az eredeti helyére (lásd a 2. ábrát). Egyébként ha konkrétan érdekel Orosz tapasztalat A kanban rendszer megvalósítása és használata, az itt található Almanach "Production Management" .

2. séma Kanban kártya szállítása a teljesített megrendeléssel együtt.

Egy kártya példája a 3. ábrán látható.

3. séma. Példa egy kártyára a használt szimbólumokkal.

A Kanban rendszer hatékony használatának szabályai

A Toyota Motor Corporation elnöke, Taiichi Ono a következő szabályokat javasolta a kanban kártyák hatékony használatához:

• Minden további munkafolyamat eltávolítja a kanban-kártya által megadott számú részt az előző munkafolyamatból.
• Az elülső munkafolyamat mennyiségben és sorrendben gyártja az alkatrészeket a megadott kártya szerint.
• Kártya nélkül nem szabad alkatrészt gyártani. Ez biztosítja a túltermelés és az áruk túlzott mozgásának csökkentését. A forgalomban lévő kanban kártyák száma a maximális készlet mennyiségét jelenti.
• A termék mindig a kártyához van csatolva. A kártya egyfajta megrendelés az áruk előállítására.
• A hibás alkatrészek nem kerülnek át a későbbi munkafolyamatba. Az eredmény teljesen hibamentes termékek gyártása.
• A kártyák számának csökkentése növeli az érzékenységüket. Felfedik a meglévő problémákat, és lehetővé teszik a készlet ellenőrzését.

A Kanban kártyák használatakor garantálni kell a rendszer láthatóságát és biztonságát. A kártyákat nem szabad elveszíteni, és nem szabad összekeverni. Mivel a munkahelyeken gyakran több különböző kártyát használnak, célszerű egy Kanban táblát megvalósítani, amelyen a kártyákat gyűjtik. A gyártóhoz érkező kártyák egy vezérlőpanelbe kerülnek. Amikor az újonnan érkezett kanban kártyák elérték a „start” mezőt, a megfelelő cikkszámú összes összegyűjtött kártyát elfogadjuk és együtt használják fel a gyártáshoz (lásd 4. ábra).

4. séma. Példa egy kártyára a használt szimbólumokkal.

További elemző és gyakorlati anyagok ebben a témában megtalálható Kanban szakasz portálkönyvtárak.