Kanban modell a szoftverfejlesztésben

Mi az a Kanban?

Kanban egy nagyon népszerű fejlesztési keret az agilis szoftverfejlesztési módszertanban. Átlátható módon szemlélteti a csapat feladatait és munkaképességét. Főleg fizikai és digitális táblákat használ, amelyek lehetővé teszik a csapattagok számára, hogy megjelenítsék a projekt jelenlegi állapotát, amelyen dolgoznak.

A Kanban a Toyotától származik az 1940-es években. A Kanban japán jelentése „óriásplakát”. A Kanban táblán oszlopok és történetkártyák vannak. Az oszlopok semmiek, de a munkafolyamat-állapotok és a kártyák nem más, mint a csapattag által végzett tényleges feladat bemutatása.

Mikor kell használni a Kanbant?

Íme a Kanban fejlesztési módszer használatának okai:

  • A Kanban bármely területen használható, és nagyon hatékonyan használható szoftverfejlesztésben. A Kanban projektmenedzsment segít a csapat hatékonyságának javításában.
  • Ez egy pull-alapú rendszer. A feladatokat amint egy személy felszabadul, kihúzzuk.
  • A Kanbant akkor kell használni, ha bármikor ki akarja adni a munkáját. Git elágazást igényel, de kivitelezhető.
  • A Kanbant akkor kell használni, ha menet közben szeretné módosítani a prioritásokat. Ehhez mindössze annyit kell tennie, hogy ezt a történetet a teendők sorának tetejére helyezi.
  • Akkor kell használni, ha vizuálisan szeretné megjeleníteni a munkáját, és vizuálisan szeretné látni a feladatok előrehaladását.

Kanban kártyák

A Kanban rendszer a munka vizualizálását javasolja. A fizikai és a digitális tábla használatát javasolja.

Kanban kártyák
Kanban kártyák

A Kanban kártyák nélkülözhetetlen elemei a Kanban táblának, mivel azt a munkát jelzik, amelyen a csapat dolgozik. Ezek a kártyák lesznek

  1. Prioritás
  2. Tulajdonos
  3. típus
  4. Határidő

A Kanban táblán egy oszlop jelzi a munkaszakaszt, és az oszlopra WIP (Work in Progress) korlátot helyezhet el. A WIP-korlát az adott oszlopban maradó kártyák maximális számát jelenti.

Mivel a Kanban projektmenedzsment lehívásalapú rendszert használ, a fejlesztő szabaddá válása esetén áthúzhat egy kártyát a teendők oszlopból a fejlesztői oszlopba.

Kanban tábla

Kanban tábla egy agilis projektmenedzsment eszköz, amely segít a Kanban bevezetésében személyes és üzleti célú projektek kezelésében. Ez egy fizikai vagy digitális (JIRA) tábla, amelyet arra terveztek, hogy segítse a csapatokat, hogy megjelenítsék munkájukat a különböző szakaszokban és folyamatokban. Segít abban is, hogy kártyákkal ábrázolja az oszlopokkal végzett munka szakaszait.

Olyan oszlopokkal rendelkezik, amelyek a munka állapotát jelzik, mint például

  1. Csinálni,
  2. Dev
  3. Tesztelés
  4. Kész.

Ezen oszlopok mindegyike tartalmazhat kártyákat a WIP-korlát alatt. A kártyák a tényleges munkát ábrázolják.

Pozitív számokkal korlátozhatja a folyamatban lévő munkát, és ez a határérték elhelyezhető az oszlopok tetején mind a fizikai, mind a digitális Kanban táblákon. A csapat bármely tagja kezelheti kártyája állapotát, és az egész csapat vizualizálhatja a munkafolyamatot. A következő Kanban-oktatóanyagban a Kanban-munkafolyamattal fogunk megismerkedni.

Kanban munkafolyamat

Kanban munkafolyamat egy olyan lépéskészlet, amely segít a csapatoknak kifejezett irányelvek és elvek meghatározásában a Kanbanban. A szabályokat és eljárásokat képviseli, miközben a munka a fejlesztés és a szállítási ciklusok különböző szakaszaiban folyik. A Kanban munkafolyamat lépésenkénti folyamatokból áll egy adott feladat indítása és teljesítése között.

A Kanban alapelve a következő: „Hagyd abba az indulást, kezdd el befejezni”. A WIP-korlátok segítségével több munkát végez. Bármely modern eszközben, például a JIRA-ban testreszabható Kanban-munkafolyamatok és állapotok állnak rendelkezésre.

Az alábbiakban bemutatjuk azokat az alapvető állapotokat, amelyeket sok szoftvercsapat követ a munkafolyamat-kezelés során.

Államok A feladatok megértése
Csinálni A feladatok ebben az állapotban először érkeznek ide.
Készen áll az elemzésre Elemezze a feladatot, és adja hozzá a követelményeket teljesen.
Fejlesztésre készen Elkészült az elemzés és kezdődhet a fejlesztés.
A fejlesztésben A feladatok kidolgozása folyamatban van.
Tesztelésre készen A fejlesztés befejeződött, és most indulhat a tesztelés.
A tesztelésben A feladatok tesztelése folyamatban van.
Kiadásra kész A tesztelés befejeződött; felszabadulás megtörténhet.
Megjelent/Kész Megjelent.

A Kanban négy alapelve

Az alábbiakban a Kanban négy fő alapelve található:

  1. Kezdje azzal, ami most van: A Kanban rendszer azt javasolja, hogy fokozatosan dolgozzon, és kezdje azzal, ami jelenleg van. Mivel az egyik gyakorlata a folyamatos fejlesztés, a rendszert fokozatosan kell fejleszteni.
  1. Fogadja el a fokozatos, evolúciós változást: A Kanban a folyamat fokozatos megváltoztatását javasolja, és nem szabad egyszerre nagy változtatást végrehajtani a folyamatban.
  1. Tartsa tiszteletben a jelenlegi folyamatot, szerepeket és felelősségeket: Még egyszer kezdje azzal, ami most van, és fokozatosan változtassa meg a folyamatot, a szerepet és a felelősségeket.
  1. Ösztönözze a vezetést minden szinten: Minden egyén vezető szerepet tölthet be, és ötleteket adhat az általános Kanban rendszer hatékonyságának javítására. Nem szabad azt gondolni, hogy ez egy vezetői szintű tevékenység, és a csapat legfiatalabb tagja is vezető szerepet tölthet be.

A hat Kanban alapgyakorlat

Íme a Kanban hat fő gyakorlata:

  1. Képzeld el a munkafolyamatot: Ez az elv azt javasolja, hogy legyen egy Kanban tábla (fizikai vagy digitális) a munkafolyamat megjelenítéséhez. A csapat minden egyes tagjának látnia kell a saját kártyáját és a csapat többi tagjának kártyáit. A fenti kép szerint a kártyákat különböző oszlopokba helyezheti. Ez nagy átláthatóságot hoz a csapaton belül, és megkönnyíti a blokkolók feloldását is
  1. A folyamatban lévő munka korlátozása: A Kanban egy pull-alapú rendszer, és a csapat hatékonyságát javítja, hogy korlátozza a folyamatban lévő munkát, és legyen olyan feladat, amelyet a csapat az adott időkeretben elvégezhet. Ez a WIP-korlát a munkafolyamat elejétől a végéig érvényes. A korlátot pozitív egész szám használatával alkalmazhatja az oszlop tetején.
  1. Összpontosítson az áramlásra: Ez az elv az áramlásra és az esetleges megszakításokra összpontosít. Ha vannak fennakadások vagy blokkolók, azokat véglegesen ki kell javítani.
  1. Kifejezett irányelvek: Csapatban is kialakíthatók irányelvek, amelyek csökkentik az utómunkálatokat, és azokra a területekre összpontosítanak, amelyek figyelmet igényelnek, vagy ahol hatékonyabb.
  1. Visszacsatolás: A visszacsatolási hurkok nagyon fontosak a Kanbanban. Nem csak a csapaton belül, hanem több csapat, edző stb. között is. Ez segít a Kanban rendszer általános állapotának javításában.
  1. Folyamatos Fejlesztés: Ez a Kanban rendszer alapelve. Azt állítja, hogy mindig javíthatja a folyamatot, és ez jobb hatékonyságot eredményez.

Húzás alapú rendszer

A Kanban egy húzáson alapuló módszer, ahol a feladatokat húzzák, nem pedig tolják. Amint kitöltötte az aktuális kártyát, húzhat egy új kártyát a Kanban tábla előző oszlopából.

A WIP korláttal a Kanban segít az átfutási idő és a ciklusidő javításában. E két időzítés között a lehető legkisebb távolságnak kell lennie. Például 5 fejlesztőnk és csak 1 tesztelőnk van; mi lesz ebben az esetben? Mindig sok olyan kártya lesz, amelyet tesztelni kell, és tétlenül fognak várni.

A fent említett problémák leküzdése és a hatékonyság javítása érdekében a Kanban a pull-alapú megközelítést követi WIP-limitekkel, ahol korlátozott számú kártyát kell kihúzni.

Tehát a tesztelő kihúz egy feladatot a „tesztelésre kész” szakaszból, amikor befejezte az aktuális feladatát. A Kanban oszlopokban (a fejlesztési szakaszokban) lévő WIP-korláttal nem lesz sok felügyelet nélküli kártya a Kanban munkafolyamatban.

A húzás alapú rendszer segít megtalálni a megfelelő sebességet a csapat számára. A megfelelő sebesség mellett a csapat jobban teljesít.

Átfutási idő és ciklusidő

A Kanban módszerben az átfutási időt és a ciklusidőt széles körben használják, van különbség a kettő között, és ezt fontos megérteni, hogy elkerüljük a félreértést.

átfutási idő Ciklusidő
Az átfutási időt a feladatnak a munkafolyamatba érkezése és a munkafolyamatból való távozása között eltelt időként mérjük, vagyis feloldásra került. A ciklusidőt a feladat „folyamatban” állapotba érkezése és a „felszabadításra kész” állapotba érkezés közötti időként mérjük.

Itt azt is fontos megérteni, hogy ne számítsuk bele a kiadásra való készenlét és a tényleges kiadás között eltelt időt.

Cycle Time = Work in Progress/Throughput

Az ideális forgatókönyvben az átfutási idő és a ciklusidő közötti különbségnek minimálisnak kell lennie, és a Kanban kumulatív folyamatdiagramot (CFD) használ az átfutási és ciklusidő-előzményadatok mérésére.

Kumulatív áramlási diagram (CFD)

A CFD egy grafikon, amely minden vezető oldalon elérhető munkafolyamat-kezelő eszközök mint JIRA. Ez a diagram a munkafolyamatba belépő és a befejezett kártyák/feladatok teljes mennyiségét méri az idő múlásával.

Segít az átlagos átfutási idő és ciklusidő becslésében az előre meghatározott időre vonatkozóan.

A CFD diagram mutatókat vagy javítandó problémás területeket ad. Tiszta képet fog adni, és ennek a diagramnak az alapján. Kijavíthatja csapata átfutási idejét és ciklusidejét.

Kanban kumulatív áramlási diagram
Kanban kumulatív áramlási diagram
  1. átfutási idő: Ez az időtartam az új kártya munkafolyamatba érkezése és a munkafolyamatból való végső távozása között.
  2. Ciklusidő: Ez egy időtartam a kártya működőképes állapotba érkezése és a kártya kibocsátásra kész állapota között.
  3. WIP: A folyamatban lévő munka (WIP) korlátozza a munkaelemek maximális számát a munkafolyamat különböző szakaszaiban.
  4. áteresztőképesség: Ez a tényleges teljesítmény, és megmutatja az adott időkereten belül kiadott kártyák tényleges számát.
  5. Átmenőképesség = WIP/Ciklusidő

A WIP korlátozása (Folyamatban lévő munka)

A Kanban fejlesztési módszertanban a WIP korlátozza azoknak a feladatoknak/kártyáknak a számát, amelyeken egy csapattag vagy egész egyszerre dolgozhat.

A WIP-korlátok biztosítják, hogy a csapat stabilizálja munkáját, és növelje a prediktív jelleget, ami elengedhetetlen a pull-alapú rendszerben. Általában a WIP limit döntését maga a csapat hozza meg.

A WIP-korlátok beállításának oka

A WIP-korlátok beállításának okai:

  • Áthelyezi a hangsúlyt a dolgok elvégzésére, mivel az egyén egyszerre egyetlen feladatra összpontosít.
  • Segít a csapatoknak megérteni képességeiket.
  • Javítja a termelékenységet, az átfutási időt és a ciklusidőt.
  • Segít elkerülni a felhalmozódó feladatokat (várakozó üzemmódban).
  • Segíti a munkafolyamat mozgását és a feladatok mozgását.
  • Segít a blokkolók feloldásában is, mivel az egyén nem vált a különböző feladatok között.

Scrum vs. Kanban

Itt vannak a lényeges különbségek között Scrum vs. Kanban

Scrum Kanban
Scrum a tervezésre helyezi a hangsúlyt. A sprint tervezésével kezdődik, és a sprint retrospektívával végződik. Sok találkozót tartanak, amelyek segítenek abban, hogy a csapat igazodjon a következő lépésekhez, prioritásokhoz és a korábbi sprintek tanulságaihoz. A Kanban kész a változtatásokra útközben. Ez azt jelenti, hogy kisebb a merevség és a dolgok gyakran változhatnak.
Gyűjtését javasolja időmérések sprintek során készült Kanban grafikonokat ajánl hogy áttekintést kapjon a csapat időbeli fejlődéséről.
Scrum már nem elkötelezettséget kér a csapatoktól. Ehelyett a sprint céljairól és előrejelzéseiről van szó. Kanban támaszkodik időbeosztás és előrejelzések.
Hangsúlyozza a tervezést, és így tovább a becslésnek nagyon fontos szerepe van a Scrumban Kanbannak van nincsenek kötelező követelmények becsléshez.
Minden az egyénnek megvan a maga szerepe és felelősségek. Nem beállítani a szerepeket olyan rugalmasan az egyéni felelősségek tekintetében.
Az iterációk/Sprints időtartama rögzített. Ez az időtartam 2 héttől 1 hónapig terjed. Kanban az nem az időtartam alapján. Ez a dolog a ciklusidővel mérve.
A csapatok kötelezni kell meghatározott mennyiségű munka. Elkötelezettség nem szükséges csapatok számára nem kötelező.
Ebben a módszerben többfunkciós csapatok fontosak, mivel képesek kezelni minden olyan zavart, amely szűk keresztmetszetet okozhat a szoftverfejlesztésben. Miután szakosodott csapat fontos.
Ez nem lehetséges elemeket hozzáadni a folyamatban lévő iterációkhoz. Újszerű elemek könnyen hozzáadhatók ha rendelkezésre áll a további kapacitás.
A sprint lemaradás tulajdonosa csak a egyetlen csapat. Több csapats megoszthatja a Kanban táblát.
Szállítandók sprintek határozzák meg, amelyet egy munkacsoportnak el kell végeznie és készen kell állnia az áttekintésre. A termékek és folyamatok folyamatosan szállítjuk szükséges alapon. Tehát a tesztelési és felülvizsgálati folyamat egyszerre megy végbe.
Scrum szoftverfejlesztési módszer a lemaradásra összpontosít. Kanban módszer teljesen a folyamat irányítópultjára összpontosít.
Minden a csapattagnak meghatározott szerepe van A Scrum masterben határozzák meg az ütemezést, a terméktulajdonosok kitűznek célokat és célkitűzéseket, a csapattagok pedig a fejlesztési munkát végzik. Egy csapatnak nincsenek előre meghatározott szerepei. Azonban továbbra is lehet projektmenedzser; a csapatot az együttműködésre és a közös munkára ösztönzik.
A legjobb projektekhez változó prioritások. Ideális csapatoknak stabil prioritások ami nem valószínű, hogy idővel megváltozik.
Méri a termelést sebesség segítségével sprinteken keresztül. A termelést a segítségével méri ciklusidő vagy a projekt egy teljes darabjának befejezéséhez szükséges pontos idő.
A Scrum megköveteli a teljes elmozdulás a hagyományos modelltől a projektet megvalósító Agile Scrum modellre. Kanban nem enged drasztikus változtatásokat a projektben.
Ideális módszer a projektekhez igen változó prioritások. A legalkalmasabb stabil prioritású csapatok.
Scrumban a teljes tAz eam az együttműködésre és a feladat elvégzésére összpontosít minőségi fejlesztési munkát biztosítani. A csapatok a célok elérése érdekében dolgoznak és csökkentse a teljes folyamat befejezéséhez szükséges időt. Így az időciklus csökkentése itt a siker legnagyobb mutatója.
Scrum ütemtervére helyezi a hangsúlyt; új elemek nem adhatók hozzá a folyamatban lévő iterációkhoz. A Kanban természeténél fogva iteratívabb nincs konkrét időkerete. Így folyamatosan új elemeket lehet hozzáadni, amikor további kapacitás áll rendelkezésre.
A teljes munka be van fejezve tételek/Sprints. A teljes projektet a mozgáson hajtják végre egyszálú munkadarab áramlik.
Scrum mester problémamegoldóként működik. Kanban biztat minden csapattag vezető és megosztani a felelősséget mindannyiuk között.
Scrum előírja időkeretes iterációk. Kanban arra összpontosít eltérő időtartam tervezése egyéni iterációhoz.
A Scrum segít a cégeknek időt és pénzt takarít meg. Kanban módszer a folyamatos fejlesztésre összpontosít, termelékenység és hatékonyság.
Elérése stabil és következetes kommunikáció minden szinten. A csapat tagjai nagyobb valószínűséggel sokkal könnyebben érik el céljaikat a Kanban táblák vizuális jellege miatt.
Projektek kódolták és tesztelték a sprint során Kritika A csapat tagjai nagyobb valószínűséggel sokkal könnyebben érik el céljaikat a Kanban táblák vizuális jellege miatt.
Ez könnyebb alkalmazkodni az állandó változásokhoz a rövid sprintek és a rendszeres visszajelzések miatt. Ez rendszeres, egyenletes teljesítményre tervezték, a vásárlói igények jelentős változásai miatt a Kanban megbukhat.
A projekt összköltsége minimális, amihez vezethet gyorsabb és olcsóbb eredmény. Ha egy feladat nincs megfelelően megbecsülve, a A projekt teljes költsége soha nem lesz pontos. Ilyen esetekben a feladat több sprintre is szétosztható.
Ez a módszertan tapasztalt csapattagokat igényel csak. Tehát, ha a csapat olyan emberekből áll, akik nem szakértők, a projektet nem lehet időben befejezni. Nem konkrét időkeretek minden fázishoz hozzá vannak rendelve, így a csapat tagjai soha nem gondolják, mennyi időt vehetnek igénybe minden fázisban.
Ebben az Agile Scrum módszerben ez az egyszerűbb minőségi terméket szállítani megbeszélt időpontban. Úgy tervezték, a rendszeres, egyenletes teljesítmény, Az ügyfelek keresletében bekövetkezett jelentős változások a Kanbant bukását idézhetik elő.
A a projektterv soha nem fog zavarni még akkor is, ha egy csapattag elhagyja a csapatot. Ha valamelyik csapattag kilép a fejlesztés során, megteheti ártott a projektfejlesztésnek.
Néha napi találkozók frusztrál csapattagok. Elavult Kanban tábla problémákhoz vezethet a fejlesztési folyamatban.
A nagy projektek könnyen feloszthatók könnyen kezelhető sprintekbe.

Összegzésként

  • Kanban definíció: A Kanban agilis fejlesztési módszertanként definiálható szoftverek, autók, áruk, gyógyszerek, cipők vagy bármilyen más gyártási munka fejlesztésére.
  • A Kanban a Kanban táblát használja a munka vizualizálására. Oszlopokat használ szakaszként (teendő, fejlesztés, tesztelés stb.), a kártyákat pedig munkaelemként.
  • A Kanban módszertana támogatja a fizikai és digitális táblát a vizualizációhoz.
  • A Kanban egy pull-alapú rendszer, és a kártyákat a csapat tagjai az előző szakaszból az aktuális szakaszba húzzák.
  • A Kanban módszer a CFD diagramot használja a csapat átfutási idejének és ciklusidejének megértéséhez. Ez a diagram segít a csapatoknak a két időzítés közötti különbség kijavításában és a hatékonyság javításában.
  • A Kanban fejlesztési módszertan, a WIP korlátozza azoknak a feladatoknak/kártyáknak a számát, amelyeken egy csapattag vagy egész egyszerre dolgozhat.
  • A WIP korlátozza a fókusz eltolódását a dolgok elvégzésére, mivel az egyén egyszerre egyetlen feladatra összpontosít.