Kanban (szoftverfejlesztés)

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.

Egy kanbantábla

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 kanbantá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 kanbanmó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 kanbanmó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 kanbanmódszert. 2009-ben Don Reinertsen publikált egy könyvet a második generációs lean termékfejlesztésről,[6] amelyben leírja a kanbanrendszer 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 scrummó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 című 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 kanbanmó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 kanbanmódszerről, amelybe már beépítették a korábbi kanbanprojektek fejlesztéseit és kiegészítéseit.[11]

Kanbantáblák szerkesztés

  A mellékelt ábra egy szoftverfejlesztési munkafolyamat vizualizációját mutatja egy kanbantáblán.[12] A kanbantá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 kanbanmó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 az egy idő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ó kanbantá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 egy idő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-menedzsmentet 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 egy idő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 kanbantáblán. Az egy idő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 kanbantáblán a telepítés (Deployment) lépésnél egy idő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árni kell, amíg a telepítés lépés tele van, így a kanbantá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őek. Az újratervezés folyamatosan zajlik. A munka menedzselése úgy lehetséges, ha az egy időben végzett feladatok száma úgy van beállítva, hogy a csapattagok ezt folyamatosan láthatják és követhetik.

Kanbanmé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.

 
A teljes feladatidő és a ciklusidő

A teljes feladatidő és a ciklusidő azt az átlagos időt definiálja, ami a feladat teljesítéséhez szükséges. A teljes feladatidő onnantól számít, amikor a csapat megkapja az ügyfél igényét. A ciklusidő onnan kezdődik, amikor a csapat ténylegesen elkezd dolgozni a feladaton. A teljes feladatidő 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ékleszállítás dátumát.

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. április 26.). 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. [2020. november 3-i dátummal az eredetiből archiválva]. (Hozzáférés: 2020. október 22.)

Fordítás szerkesztés

Ez a szócikk részben vagy egészben a Kanban (development) című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

Ajánlott irodalom szerkesztés

Kapcsolódó szócikkek szerkesztés