Gyorsan változó világunkban gyorsan változó piaci igények jelennek meg, melyekre megoldást kínál az agilitás. Nem csak az IT világhoz szorosan kapcsolódó cégeknek szükséges belekezdeni az agilis transzformációba.
Kanban vs Scrum módszertanok összehasonlítása

Mi is az agilitás?

A munka világa átalakult, ma már nem látunk magányos polihisztorokat, akik több szakmához is kiválóan értenek. Sok szakma tovább szűkült és specializálódott, emiatt megnőtt az igény a szakemberek kommunikációjára, a szoros együttműködésre. Ahogy a rögbiben kapaszkodnak össze a csapattársak és tolonganak a másik csapat játékosaival a labdáért, úgy kell a különféle szakmának is együttműködni, kompromisszumokat kötnie a megrendelő kegyeiért.

A cégek nem minden esetben engedhetik meg maguknak, hogy saját IT, HR, vagy más szakterületből saját egységet építsenek fel, így marad a kiszervezése ezeknek a feladatoknak. A közös célért kell két cégnek dolgoznia, meg kell találni a kompromisszumokat, hogy az együttműködés gyümölcsöző legyen. Ennek érdekében a személyes kommunikációt előtérbe helyezi a módszertanoknál és az eszközöknél; a működő szoftvert előre valóbb az átfogó dokumentációnál; a megrendelővel való jó együttműködés felülírja a szerződéshez való ragaszkodást; a változáshoz való rugalmas hozzáállás fontosabb a tervek szolgai követésénél.

Egy hagyományos vízesés modell alapú szoftverfejlesztés csak nagyon ritkán nyújt megfelelő körülményeket, mivel az egyik legfontosabb jellemzője, hogy rosszul tűri a változást. Egy tűpontos specifikáció mentén, mely nem változik a fejlesztési folyamat során, persze remek eredményt hozhat, de ki látott ilyet?! Az agilis manifesztó nem arról szól, hogy ne legyen szerződés, ne legyenek módszertanok, ne tervezzünk, sokkal inkább a hangsúlyt helyezi át, hiszen a világ is máshogy működik. Egy cég működésében fontosak a felsoroltak, de probléma, kritikus helyzetek kezelésére alkalmasabbnak látszik az agilis szemlélet. Az agilitás támogatja a fejlődést, a változást, a kritikus helyzetek kezelését, míg a stabilitást, a növekedést, a sztenderdizálást nem.

Egy szoftverfejlesztés során a változás a biztos, emiatt olyan fejlesztési folyamatok, olyan cég kultúra szükséges, mely a folyamatos változást követeli meg és ezt a változást teszi biztonságossá. Minden ember szereti a biztonságot, a rutinjaink teszik keretbe az életünket, melyben egy kis rugalmasság, egy kis változatosság belefér.

Az agilis módszertanok adottnak veszik a fejlesztésre szánt időt és költségvetést a fejlesztési területet tekintik változónak. A gyakori, működőképes elemeket szállítva, figyelve a projekt kereteire, a változó piaci helyzetre jól reagáló módszertant kapunk.

Az XP és a Lean mellett a Kanban és a Scrum irányok a legelterjedtebb agilis területen.

Kanban

A Kanban módszertant a japán ruha- majd autógyártó Toyota cég fejlesztette ki. Vizualizálta a gyártási folyamatokat egy egységes, jól átlátható táblán. Az elemek számának korlátozásával optimalizálja a folyamatokat, erre helyezi a fő hangsúlyt, nem pedig az igényekre. A Kanban előnye egyben a legnagyobb veszélyforrásai is, az egyszerűsége. Kellő átgondolás és folyamatszabályozás nélkül könnyen csődöt mondhat és eltörhet a projekt.

Scrum

A Scrumnál véges iterációkkal tervezünk, sprintekben gondolkodunk, míg a Kanban táblára folyamatosan kerülnek fel a feladatok a táblára. A Scrum dedikált szerepköröket és eseményeket ír elő, amik bár igen egyszerűek, mégis szervezeti átállást követelnek meg.

A Scrum csapatban kell egy termék gazda, aki érti az üzleti területet, folyamatokat, egy Scrum master, aki a Scrum ceremónikat vezeti és persze a fejlesztők, tesztelők. A fejlesztéseken jellemzően több Scrum csapat dolgozik és szállítják a sprintek végén a működő megoldásokat.

MELYIK A MEGFELELŐ AZ ÉN PROJEKTEMHEZ?

A Scrum, mely nehezen alkalmazkodik a sprintekbeli változásokra inkább azokra a projektekre alkalmas, ahol a sprint időszakára pontosan lehet feladatokat kiosztani és a fejlesztői csapat számára rendelkezésre áll egy termékgazda döntési jogkörrel és mély szakmai háttérel.

A Kanban megfelelő választás lehet extrém gyorsan jövő igények kielégítésénél, olyan szervezeteknél, ahol nincs lehetőség szervezeti átalakításra, kiszervezésre.

Mit használunk mi?

Nálunk az agilitás van fókuszban, nem tudtuk letenni a voksunkat egyetlen módszertan mellett, inkább az ügyfél igényekhez igazodunk, agilisan.

A Scrumban egyfajta keveréke a Scrum és a Kanban tanoknak, vettük a bevált elemeket és egybe gyúrtuk őket. Az ügyfél igényeket egy szabályzott Kanban táblára vezetjük fel, a szabályokat az Atlassian termékcsalád eszközeivel automatizáljuk, szabványosítjuk és vezetjük végig a teljes gyártási / fejlesztési folyamaton. A folyamat átlátható az ügyfél számára, látja, érzi, aktív részese a fejlesztésnek.

Az ügyfél igényből a termék gazda segítségével egy egészen pontos, jól behatárolható fejlesztési feladat lesz. A folyamat átlátható, a fejlesztői csapat mit fog fejleszteni, várhatóan mennyi idő alatt, mennyi erőforrás felhasználásával. A termék gazda és az ügyfél együtt dolgozva alakítja ki, melyik az üzletileg legfontosabb feladat, amit le kell fejleszteni. A fejlesztés után tesztelésre kerül az elkészült funkció, majd az ügyfél is teszteli és elfogadja.

A Scrumból megtartottuk a stand-up és a retrospektív ceremóniákat, hogy folyamatosan fejlődjünk. Sprinteket csak a hosszú projektek esetén tartjuk meg, ahol rapid fejlesztésre van szükség, ahol üzletileg kiemelt a gyorsabb reagálás ott kanban szerint priorizáljuk a feladatokat és oldjuk meg. Ezeket a váltásokat csak tapasztalt kollégákkal lehet megtenni és egy nagyon transzparens szervezeti életben. Efelé a cél felé megyünk, minden sprinttel eggyel közelebb.

Kapcsolat

Vedd fel velünk a kapcsolatot