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áknak is együttműködniük, kompromisszumokat kötniük 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 az agilis manifesztó a személyes kommunikációt előtérbe helyezi a módszertanoknál és az eszközöknél; a működő szoftver előbbre való 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égkultú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 legelterjedtebbek az agilis területen.
Kanban
A Kanban módszertant a japán szövőgép-, 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ása 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 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ékgazda, aki érti az üzleti területet, folyamatokat, egy Scrum master, aki a Scrum-ceremóniákat 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 sprinten belüli változásokhoz, 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érrel.
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éligényekhez igazodunk, agilisan.
A Scrumban egyfajta keveréke a Scrum és a Kanban tanoknak, vettük a bevált elemeket, és egybegyúrtuk őket. Az ügyféligényeket egy szabályozott 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éligényből a termékgazda 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ékgazda é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.
