Kíváncsi vagy, hogy mi is valójában az agilitás, miért nem tudják a legtöbb helyen sikeresen alkalmazni, miképpen csinálhatod jól, hogyan is kellene rá tekinteni? Akkor olvass tovább!
Az Agilitás a japán autóiparból ered, szóval elhihetitek, ez a keretrendszer nem arról szól, hogy valamikor fog valami történni, sok hiba lesz és amúgy sem tudjuk, hogy mikor leszünk készen.
A történelmi hátterére ennél jobban nem térnék ki, akit érdekel, úgyis hamar megtalálja az interneten, most inkább foglalkozzunk azzal, hogy mi az, amiben szinte mindenhol hibáznak, amit nem értenek meg vele kapcsolatban és ahogy sikerre lehet ezt a sokak által fekete mágiának tartott valamit. Persze ezekről napokat lehet beszélni, ezért csak röviden, érintőlegesen kóstoljunk bele mindenbe, legyen ez az agilis degusztációs menünk.
Az Agilitás egy keretrendszer, egy doboz, amit az igényeinknek megfelelően kell alakítani, megtölteni. Ha egy falra szögezett szentképként tekintünk rá, akkor bukásra vagyunk ítélve, hiszen a rendszer lényegét, a változásokra való reagálás képességét veszítjük el. Ne legyünk agilis nácik!
A problémák 80%-a az esetek 20%-ban keletkezik, itt sincs ez máshogy.
A probléma egyik része annál keletkezhet, aki ki lett nevezve, hogy bevezesse, facilitálja a programot. Karrierem során sok Scrum Masterrel (az a személy, a klasszikus PM feladatok nem pénzügyi, nagyon technikai oldalát viszi, az esetek 99%-ban ő tanítja be az Agilitást) volt szerencsétlenségem dolgozni, akik közül 1-2 kivétellel abszolút nem értették az egész lényegét. Megtanulták a szentírást, hozzá olvastak egy kis pszichológiát és máris azt hitték magukról, hogy így nem csak a projektet és a céget tudják megváltani, de az emberek lelki üdvét is elhozzák, mint egy modern Jézus. Mondanom sem kell, hogy ezek az emberek veszélyesek és a legtöbb esetben a törvényesség határát is súrolják, amikor pszichológusnak vagy pszichiáternek képzelik magukat. A legtöbbször olyanok állnak a magyar piacon SM-nek, akik nem nagyon értenek semmihez, nincs tapasztalatuk a cégekkel, emberekkel, jól-rosszul képesek beseggelni pár tíz oldalt és az így szerzett könyvtári tudásukat szeretnék a lehető legtöbb pénzre beváltani. Mivel nincs tapasztalatuk, nem láttak még bukást se győzelmet, nem tudják más rendszerekhez mérni, hasonlítani a saját és környezetük tudását, ezért nem is képesek agilisen alkalmazkodni. Azt tudják, ami le volt írva a szentkönyvben.
Másik része a gondnak a vezetés oldalán képződhet. Az Agilitás nem valósulhat meg csak egy pár emberrel úgy, hogy a vezetés kijelenti, hogy ők bár támogatják, de őket hagyják békén ezzel a new age hülyeséggel, ők eddig is jól működtek úgy, ahogy vannak, ők ezek után is mindent úgy akarnak, ahogy eddig volt. Ha az elvárások nem változnak felülről, akkor alul sem lehet munkamódszert váltani.
De mi is tulajdonképpen az Agilitás?
A munka és a felelősségi körök felosztása egységnyi csomagokra, majd ezeket a csomagokat addig bontjuk tovább, amíg meg nem kapjuk azt, hogy az adott pillanatban kinek mivel kell foglalkoznia és egy rövid 1-4 hetes időtartamon belül már szállítható/bemutatható termékrészletet kapunk, ami bemutatja a haladásunkat és megnyugtatja az ügyfelet, nem lesz kérdés, hogy mit is csináltunk, ráadásul ha jön valami új igény, változás, ami pedig mindig jön, esetleg az ügyfél a bemutatón rájön, hogy ő mégsem ilyen lovat akart, akkor nem több hónapnyi, évnyi munkát dobunk ki, hanem csak legrosszabb esetben egy ilyen szállításnyi ciklusnyit (Sprintnek nevezzük ezt a rövid időszakot). Minden más csak körítés.
Hogy is kellene ezt jól csinálni?
Azonosítani kell a feladatköröket, ezeket be kell tölteni emberekkel, hogy mindennek legyen felelőse és egy olyan szállítási folyamatot kell felépíteni, amiben nincsenek kivételek, minden esetben tiszta lesz, hogy akkor mi történik és kinek kell tovább vinnie a feladatot. A módszer szempontjából teljesen mindegy, hogy krumpliról vagy szoftverről van szó, a kész terméknek egy folyamat keretében az asztalra vagy a laptopunkra kell jutnia.
Az internet teli van akár ingyenes eszközökkel is, amik meglepően jól használhatóak, hogy őszinték legyünk, mi is egy ilyet használunk. A legtöbb esetben 3 oszlopot előre létre is hoznak nekünk, amit utána a nagy valószínűséggel bővítenünk kell majd. To Do, In Progress, Done. Értelemszerűen a folyamatunk általában összetettebb annál, mint hogy valamit csinálunk és aztán kész is. Jó esetben legalább egy minőség-ellenőrzés, jóváhagyás legalább van a folyamatban, de a legjobb, ha úgy alakítunk ki státuszokat, hogy ahogy a feladat a különböző feladatkörök között halad, minden szereplőre legyen egy oszlop és esetleg egy azt megelőző, ami jelzi az illetőnek, hogy a feladat rá vár.
A témáról még nagyon sokat lehetne és fogunk is beszélni, de így se lett rövid a poszt. Az erőforrás becslés, sprint tervezés, meetingek szervezése, Epic, User Story, Task, a csapat felépítése mind mind egy egész estés filmre való történetet takar.
Stay Tuned Folks!
