Az egész előzménye annyi, hogy pár hónapja érkezett hozzánk egy új kolléga. Zsolt egy igazi Agile Warrior, akinek még otthon is van saját Kanban táblája, szóval nem telt sok időbe, amíg ez irányú fixációit a cégben a többiekre is átragasztotta.

 

Talán kezdjük egy gyors áttekintővel arról, hogy mi is az a Kanban rendszer.

 

A Kanban rendszer a Toyota Production System mintájára lett adaptálva a szoftverfejlesztésben. 

Bár a TPS alapvetően autógyártási folyamatokra lett tervezve, de azt hiszem, szemléletesebben be lehet mutatni a működését egy áruházlánc példáján.
 

 

Nálunk a Kanban tábla használatára áttérés gondolata egy olyan termék fejlesztése kapcsán került szóba, ami már nagyon közel van az élesítési fázishoz. Ilyenkor már nagyon nehéz Scrum szerint megtervezni egy időszakot - még úgy is, hogy csak 2 hetes sprintekkel dolgozunk -, hiszen rengeteg a bizonytalan, nehezen becsülhető feladat. Mint például a tesztelés, a hiba javítás, a külső függőségek kezelése, illetve az élesítés előtti napokon nagyon nagy intenzitással változhat az elvégzendő feladatok prioritása is annak függvényében, hogy mi mennyire szembetűnő a leendő felhasználóknak, vagy mi olyan kritikus hiba, ami éppenséggel még várhat.

Továbbra is Scrum-os alapokon, de Kanban által megtámogatott módszerekkel dolgozunk.

 

A táblát mindig a célnak megfelelően kell felosztani, így nagyon nagy rugalmasságot ad, és nem csak fejlesztési projektekhez, hanem akár teljes céges folyamatok áttekintéséhez is kiváló. Erről azonban majd csak a következő posztban írok részletesebben.

 

 

Akkor lássuk mit is jelent ez esetünkben.
A tábla bal oldalán vannak azok a feladatok, amiket előbb utóbb el kell készíteni (User stories). Amikor már látszik az egyes elemek prioritása, megvan minden előfeltétel, akkor tudja a Scrum Master vagy Product Owner a Queue megfelelő helyére tenni az elemet. Amennyiben ez egy kisebb feladat, vagy hiba javítás, akkor ezt egyből el is tudja kezdeni a csapat, míg ha egy nagyobb funkcióról van szó, akkor egy közös tervezést követően szétbontjuk azt kisebb részfeladatokra, amiket a Planned oszlopba helyezünk el.
Itt jól jött, hogy különböző színű és méretű post-itekkel tudtunk gazdálkodni, így külön tudtuk kezelni a fejlesztői és sitebuilder feladatokat, illetve a nagyobb kifejtendő, és a kisebb valamint hiba javítási feladatokat. Jól látszik a fenti képen is, hogy ez mennyire megkönnyítette az eligazodást a táblán. Nem utolsó sorban a Product Owner is csak rá kell nézzen a táblánkra, és egyből látja a projekt pillanatnyi státuszát. A fejlesztés alatt álló feladatokat az Implement oszlopban látjátok. Itt és a Test oszlopban különböző figurák jelölik, hogy ki éppen mivel foglalkozik. A jobb sarkában lévő szám pedig azt jelzi, hogy maximum ennyi feladat lehet egy időben a fejlesztőcsapatnál. Az elkészült feladatok pedig szépen vándorolnak át a Test és a Done oszlopokba.
 

Fontos újítás mág a Parking lot, ami Zsolt kollégám találmánya. Ide kerül minden olyan feladat, amire a fejlesztőcsapatnak nincsen ráhatása. Persze ezeknek a számára is oda kell figyelni, de az magában megér egy újabb posztot.