Hogyan lehet a fürge még fürgébb? Keverjünk a SCRUM módszertanunkhoz egy csipetnyi Kanbant

Azok a csapatok, akik magabiztosan használják a SCRUM-ot és próbálják hatékony és dokumentált menedzsment eszközként kezelni, de a munkájuk során üzemeltetési feladatokat is el kell látniuk, valószínűleg ugyanazzal a problémával küzdenek: a folyamatosan érkező igények mellett muszáj hozzányúlni a feladatokhoz a sprint alatt.

A SCRUM módszertan tökéletesen működtethető a fejlesztési projekteket ellátó csapatoknál, de üzemeltetési feladatokat tekintve korlátot jelenthet, ugyanis a folyamatban lévő iterációhoz csak a sprint scope változtatásával adható újabb feladat. Ha tehát a sprint elején A, B és C feladatot terveztünk be, akkor ha jön egy új D igény, azt csak a következő sprintbe vehetnénk fel, vagy az A,B,C közül valamelyiket ki kell vennünk a sprintből.

Ez persze nem azt jelenti, hogy azok a csapatok, akiknél jellemzően sok beeső vagy folyamatosan változó feladat van, ne tudnák használni a SCRUM-ot. Mert nem az a lényeg, hogy egy-egy módszertanhoz tankönyv-szerűen ragaszkodjunk. Fel kell ismernünk, hogy bármely módszertan csak egy eszköz. Nem arra vannak, hogy önmagában működtessük őket, hanem minket szolgálnak. Használjuk tehát őket bátran, olyan formában, ahogy az minket a leginkább szolgál.

Lássunk tehát egy kiegészítő eszközt, ami segítségünkre lehet a fent vázolt probléma kezelésében.

Kanban
A Kanban a Lean kezdeményezésben bukkant fel először, hogy segítse a vállalati kultúra átalakítását és a folyamatos fejlődést. Nem szoftverfejlesztési vagy projektmenedzsment életciklusmodell vagy -folyamat. A Kanban szemlélet, mely a meglévő projektmenedzsment vagy szoftverfejlesztési módszereink részévé teszi a változást.

Egy nagyon egyszerű gondolaton alapszik. A végrehajtás alatt álló feladatok (work-in-progress, rövidítése WIP) számát korlátozni kell, és új teendőt csak abban az esetben szabad elkezdeni, ha egy „munkadarab” elkészült, vagy azt egy következő feldolgozási folyamat átvette.
A szó eredetét tekintve a Kanban a „Just In Time” nevű vezetéselméleti gyártási rendszerben használatos japán fogalom, melynek szószerinti jelentése „jel” vagy „utasítás kártya”. Olyan vizuális jel, ami arra utal, hogy megkezdődhet egy új feladat végrehajtása, mivel a folyamatban lévők száma nem éri el a megengedett maximális értéket.

Simple-kanban-board-

Mivel a végrehajtás alatt álló feladatok száma korlátozott a Kanban-rendszerben, bármi, ami megakad a folyamatban, a teljes rendszer bedugulását eredményezi. Ez arra készteti a szervezetet, hogy a megakadt munkafázisra figyeljen, és mielőbb elhárítsa az akadályt, hogy újra megindulhasson a folyamat.

Hogyan ültethetjük át ezt a szemléletet a saját SCRUM folyamatunkba?

A Kanbanban a WIP közvetlenül, munkafolyamat-lépésekre korlátozott. A SCRUM esetében azonban a WIP-et indirekt módon, időegységre vonatkoztatva határozhatjuk meg. Ez a gyakorlatban azt jelenti, hogy egy iterációban a csapat nem feltétlenül az előre meghatározott feladatokra vállal kötelezettséget, de az elvégzendő munkamennyiség számát mindenképp meghatározza, korlátozza. És abban a pillanatban, ahogy beesik egy új teendő, vagy egy meglévő feladatról kiderül, hogy összetettebb, mint ahogy az elején becsültük, kiemelünk a sprintből egy másik feladatot, hogy a plusz idő miatt ne essünk a sprint végén csúszásba.

Milyen előzetes tervezés szolgáltatja ehhez az alapot?

  • Minden feladatot előzetesen fel kell becsülnünk. Itt általában nem konkrét fejlesztésre fordítandó óraszámokat használunk, hanem egy olyan számot, ami képes jelezni a feladatok egymáshoz képesti komplexitását.
  • A sprintbe felvett feladatokat már az induláskor prioritási sorrendbe kell állítani. Így ha egy bizonyos munkaértéknyi feladatot ki kell vennünk a sprintünkből, nem kell minden feladatot újra átnézni, egyszerűen a prioritási lista legaljáról húzzuk ki az utolsókat.

A folyamatosan változó, új igények miatt a fejlesztések elcsúszhatnak. De ha abban a pillanatban reagálunk, ahogy egy-egy kisebb egység fejlesztésére szánt idő emelkedne, még sprint közben meg lehet csípni az esetleges csúszást.

Mi lesz a sprintből kiemelt feladatokkal?

Az újratervezéskor kiemelt feladatoknak nem feltétlenül kell automatikusan a következő sprintben landolniuk. A csapat motiválására használható, ha ezeket első körben egy külön konténerbe helyezzük, amiből a csapat akkor emel ki feladatot, ha a betervezettekkel már végzett. Így érhető el, hogy a csapatunk az előzetes terveket ne csak egyszerűen teljesítse, hanem módja van túl is szárnyalni. Amit persze külön jutalmazási rendszer kidolgozásával előmozdíthatunk.

Használjunk tehát bármilyen módszertant a fejlesztéseink során, akár SCRUM-ot, akár Kanbant, akár egy teljesen egyedit, fel kell rá készülnünk, hogy csak az alapvető szabályokat határozzák meg, viszont kísérletezésen keresztül bátran a saját körülményeinkre szabhatjuk őket.