Kanban (szoftverfejlesztés)

A Wikipédiából, a szabad enciklopédiából
Ugrás a navigációhoz Ugrás a kereséshez
Egy Kanban tábla

A Kanban (japán szó, jelentése jelzőtábla vagy hirdetőtábla) egy lean módszer emberek csoportos munkájának menedzselésére és fejlesztésére. A Kanban kiegyensúlyozza az igényeket és az elérhető munkakapacitást.

A munkaeszközök úgy vannak megjelenítve, hogy a munka készültségi szintjét az elejétől a végéig egyértelműen kifejezzék. A munkafolyamat megjelenítésére általában egy Kanban táblát használnak. A munkafolyamatok elvégzését úgy ütemezik, ahogy a dolgozók kapacitása megengedi, és nem engedik, hogy a munkafolyamatok sürgőssége határozza meg a munka időbeosztását.

Az a cél, hogy létrejöjjön egy olyan vizuális folyamatmenedzsment rendszer, amely segít meghozni azokat a döntéseket, hogy mit, mikor és hogyan gyártsanak. A Kanban módszer a lean gyártás módszerból származik,[1] amelynek a Toyota Gyártási Rendszer volt az alapötlete.[2] A Toyota autóipari vállalat az 1940-es évek végén létrehozta a "just in time" gyártási rendszert, aminek az volt a célja, hogy a gyártáshoz szükséges alapanyagok pont a megfelelő időben érkezzenek be a gyárba, hogy raktározás nélkül le tudják gyártani az adott vevői igényt kielégítő termékeket. David J Anderson, a Microsoft mérnöke dolgozta ki a módszert arra, hogy a Toyota gyártási rendszerét hogyan lehet úgy implementálni, hogy bármilyen más típusú cégnél használni lehessen.[2]

A Kanban módszert általában a szoftverfejlesztésben használják, ahol olyan módszerekkel kombinálják, mint például a Scrum.[3]

A módszer fejlődése és dokumentálása[szerkesztés]

A Kanban fejlődését David Anderson írta le a 2010-ben megjelent, Kanban című könyvében.[4] A fejlődéstörténet leírása egy 2004-es Microsoft projekttel kezdődött,[5] és egy 2006-2007-es Corbis projekttel fejeződött be. Ez utóbbi projekt esetén azonosították először a Kanban módszert. 2009-ben Don Reinertsen publikált egy könyvet a második generációs lean termékfejlesztésről,[6] amiben leírja a Kanban rendszer adaptálását, és meghatározott egy gazdasági modellt a menedzsment döntéseinek támogatására. Corey Ladas 2008-as Scrumban című könyvében azt állította,[3] hogy a Kanban képes tökéletesíteni a Scrum módszert a szoftverfejlesztés területén. Ladas szerint a Scrumban átmenetet jelent a Scrum és a Kanban között. Jim Benson és Tonianne DeMaria Barry 2011-ben megjelent, „Personal Kanban” könyvében a Kanbant egyedi fejlesztőkre és kis csapatokra alkalmazták.[7] Mike Burrows 2014-ben megjelent, „Kanban from the Inside” című könyvében elmagyarázta a Kanban elveit, gyakorlatát és mögöttes értékeit, és összehasonlította ezeket korábbi módszerek jellemzőivel.[8] Eric Brechner 2015-ben megjelent, „Agile Project Management with Kanban” című könyvében áttekintést nyújtott a Kanbanról a Microsoft és az Xbox gyakorlatát vizsgálva ,[9] Klaus Leopold és Siegfried Kaltenecker 2015-ben megjelent, „Kanban Change Leadership” című könyvükben a menedzsment szempontjából magyarázták el a Kanban módszert, illetve leírtak egy útmutatást a szükséges változtatások elkezdéséhez.[10] 2016-ban megjelent egy komplex útmutató a kanban módszerről, amibe már beépítették a korábbi Kanban projektek fejlesztéseit és kiegészítéseit.[11]

Kanban táblák[szerkesztés]

Sample Kanban Board.png

A mellékelt ábra egy szoftverfejlesztési munkafolyamat vizualizációját mutatja egy Kanban táblán.[12] A Kanban táblák kialakítását a felhasználási környezetük igényeinek megfelelően tervezik. A táblák az oszlopokban munkaelem típusokat (Az ábrán „feature” és „user story” megnevezéssel szerepelnek) tartalmaznak, és soronként pedig munkamenetek sorakoznak egymás alatt. Az a cél, hogy a munkafolyamat aktuális állása értelmezhető legyen mind a résztvevő dolgozók, mind a cég egyéb alkalmazottai, vagy befektetői részére.

A Szoftverfejlesztéshez adaptált Kanban módszerról szóló könyvek leírják a Kanban két fő gyakorlatát:[4][3] vizualizáld a munkádat és korlátozd a egyidőben folyamatban levő munkafolyamataid számát (work in progress - WIP). Az "Essential Kanban Condensed" című könyvben négy további általános gyakorlatot publikáltak: menedzseld a folyamatot, implementálj visszacsatolási hurkokat és javítsd a hibákat együttműködve. [11]

A fenti ábrán látható Kanban tábla a Kanban első három általános gyakorlatát mutatja be.

  • Vizualizálja a fejlesztő csapat munkáját (feature, user story).
  • Meghatározza az egyidőben végzett feladatok számát a fejlesztési lépésekhez. Tehát korlátozza azon részfeladatok számát, amit az adott fejlesztési lépésben el tudnak végezni a fejlesztők.
  • Dokumentálja a fejlesztői politikákat, vagyis hogy mit jelent a kész fogalma.[9] Ez utóbbi látható az ábrán a kék szövegdobozokban.
  • Mutatja a kanban munkafolyamat menedzsmenetet a "User Story Preparation", "User Story Development" és "Feature Acceptance" lépésekhez. Mindhárom lépésnek van egy Folyamatban és egy Kész oszlopa. Minden lépéshez érvényben van az egyidőben végzett feladatok számának korlátozása, amely megakadályozza hogy a részfeladatok mennyisége túlterhelje a fejlesztőket.

A Munkafolyamat menedzselése[szerkesztés]

A Kanban közvetlenül menedzseli a munkafolyamatot a Kanban táblán. Az egyidőben végzett feladatok számának korlátozása azonnali visszajelzést nyújt a fejlesztőcsapatnak a munkafolyamat problémákról.[4][9]

Például a fenti Kanban táblán a telepítés(Deployment) lépésnél egyidőben végzett feladatok számának öt van beállítva, és az oszlopban öt darab feladatrész(epic) látható. Amíg egy feladatrész nem kerül át ebből a lépésből a következőre, addig nem kerülhet új feladatrész ebbe a lépésbe. Ez a módszer megakadályozza a telepítés(Deployment) lépés túlterhelődését. Az előző lépésben szereplő feladatrészeknek várnia kell, amíg a telepítés lépés tele van, így a Kanban tábláról egyből le lehet olvasni, hogy melyik lépésnél torlódtak fel a részfeladatok, és hol kell besegíteni a munka haladásának érdekében.

Amint az öt feladatrész elkészül a telepítés lépésben, azokat át lehet helyezni a leszállított(Delivered) státuszba, és helyükre a funkció elfogadása(Feature Acceptance) lépés kész(Ready) oszlopából maximum 5 részfeladatot lehet áthelyezni. A képen jelenleg 2 részfeladat látható a Ready oszlopban, ezeket lehet áthelyezni a telepítés oszlopba. A folyamatban(In progress) oszlopokból előbb át kell helyezni a kész(Ready) oszlopba a részfeladatokat, és csak utána lehet továbbhaladni velük a következő lépésre.

A munkafolyamat irányítása az összes lépésnél hasonlóan működik. A problémák vizuálisan láthatóak, és azonnal értelmezhetők. Az újratervezés folyamatosan zajlik. A munka menedzselése úgy lehetséges, ha az egyidőben végzett feladatok száma úgy van beállítva, hogy a csapattagok ezt folyamatosan láthatják és követhetik.

Kanban mérések[szerkesztés]

A Kanban különleges technikákat használ a csapat kapacitásának mérésére és a projekt hosszának becslésére.

A csapat sebessége azt definiálja, hogy mennyi részfeladatot tud elvégezni a csapat egy adott időszak, például egy hét alatt.[13] A sebességet időszakonként számítják. A csapat azzal segíti a pontosságot, hogy hasonló méretű részfeladatokat hoznak létre. A csapat sebességének meghatározása megkönnyíti a feladat befejezés idejének megbecslését.

Lead and cycle time
A teljes feladat idő és a ciklusidő

A teljes feladat idő és a ciklusidő azt az átlagos időt definiálja, ami a feladat teljesítéséhez szükséges. A teljes feladat idő onnantól számít, amikor a csapat megkapja az ügyfél igényét. A ciklusidő onnatól kezdődik, amikor a csapat ténylegesen elkezd dolgozni a feladaton. A teljes feladat idő azt az időt mutatja, amit az ügyfélnek ki kell várnia a termék elkészítéséig. A ciklusidő azt mutatja milyen gyorsan készül el a csapat a termékkel. [14]

A Cselekvőképes(Actionable) agilis mérési módszer a ciklusidőt használja, hogy pontosabban megbecsüljék mikorra lesz kész egy projekt. Daniel S. Vacanti 2015-ben hozta létre a Cselekvőképes agilis mérési módszert,[15] amely azt méri, hogy mennyi ideig tartott elkészíteni a feladatok 50, 85 és 95 százalékát. A mérés által kapott eredmény arra használható, hogy a csapatnak segítséget nyújtson jobban megbecsülni és irányítani a termék leszállítás dátumát.

lásd még[szerkesztés]

Hivatkozások[szerkesztés]

  1. Womack, James P.. The Machine That Changed the World (2007). ISBN 978-1847370556 
  2. a b Ohno, Taiichi. Toyota Production System: Beyond Large-Scale Production (1988). ISBN 978-0915299140 
  3. a b c Corey, Ladas. Scrumban and other essays on Kanban System for Lean Software development. Seattle, Washington: Modus Cooperandi Press (2008. június 6.). ISBN 9780578002149. OCLC 654393465 
  4. a b c Anderson, David J.. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press (2010. április 1.). ISBN 978-0-9845214-0-1 
  5. Anderson, David J. (2005. november 1.). „From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution at Microsoft's IT Department”., Microsoft Corporation. 
  6. Reinertsen, Donald. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing (2009. május 1.). ISBN 978-1935401001 
  7. Benson, Jim. Personal Kanban: Mapping Work, Navigating Life. Modus Cooperandi Press (2011. január 1.). ISBN 978-1453802267 
  8. Burrows, Mike. Kanban From The Inside. Seattle, WA: Blue Hole Press (2014). ISBN 978-0-9853051-9-2 
  9. a b c Brechner, Eric. Agile Project Management with Kanban. Microsoft Press, 160. o. (2015). ISBN 978-0735698956 
  10. Leopold, Klaus. Kanban Change Leadership. Hoboken, NJ: John Wiley & Sons (2015). ISBN 978-1-119-01970-1 
  11. a b Anderson, David J.. Essential Kanban Condensed. Seattle, WA: Lean Kanban University Press (2016). ISBN 978-0-9845214-2-5 
  12. Boeg: Priming Kanban. InfoQ, 2012. február 1. (Hozzáférés: 2014. február 17.)
  13. What is Velocity in Agile? | Agile Alliance (amerikai angol nyelven), 2015. december 17. (Hozzáférés: 2020. október 22.)
  14. Lead and Cycle Time - How to Use the Kanban metrics (amerikai angol nyelven). teamhood, 2020. október 15. (Hozzáférés: 2020. október 22.)
  15. ActionableAgile. actionableagile.com. (Hozzáférés: 2020. október 22.)

Ajánlott irodalom[szerkesztés]