A gyorsan változó üzleti és technológiai környezet kaméleonszerű alkalmazkodást igényel, így van ez a projektek hajtómotorját jelentő szoftverfejlesztés esetében is. Az adaptáció sosem volt annyira fontos képesség, mint most, az információtechnológiában is tetten érhető változásokat hozott: a nagyobb hatékonyságra való törekvésnek és a korai „szállítás” elérésének köszönhetően az agilis szemléletmódon alapuló szoftverfejlesztés virágkorát éli. De vajon mennyire helytállóak manapság a húsz éve megfogalmazott irányelvek és mi dinamizálhatja az informatikát az agilitás után?
Kereken két évtizeddel ezelőtt, 2001-ben a szoftveripar nagyjai egybecsengően megfogalmazták az agilis szoftverfejlesztés manifesztumát, a tizenkét pontból álló „agilis alapelvet”. Az Agilis Kiáltvány az elmúlt két évtizedben Sarkcsillagként mutatta az agilitás felé vezető irányt, és annak ellenére, hogy az informatikában egyetlen nap alatt minden megváltozhat, az Agile Manifesto mégis kiállta az idő próbáját. Ugyanakkor felmerül a kérdés: miként lehet valami most is érvényes az IT-ban, ha húsz éve írták?
Él-e még a kiáltvány?
„A kiáltvány jól megfogalmazza a sarkpontokat, az általános érvényű elveket és ha elfogadjuk a logikáját, akkor jó alapot építhetünk rá, attól függetlenül, hogy milyen szervezeti »vázra« húzzuk ezeket az agilis alapelveket. Szerintem, ami miatt most is valid a Kiáltvány, az az, hogy nem a termékre, hanem a folyamatokra és az együttműködésre helyezi a hangsúlyt. A közvetített gondolkodásmód közelebb hozza a kollaborációt, és háttérbe szorítja azt a régimódi szemléletet, miszerint az elefántcsonttoronyból kell irányítani a folyamatokat, ami nem sok rugalmasságot feltételez”, fogalmazta meg Török Balázs, a SIGNAL IDUNA Biztosító alkalmazásfejlesztési osztályvezetője.
Ugyanakkor van, aki azt az álláspontot képviseli, hogy Kiáltványra ráférne egy kisebb ráncfelvarrás, még akkor is, ha alapvetően jó irányvonalat határoz meg. „Azt gondolom, maga a szemlélet jó, de van, ahol megérett az átdolgozásra. Egyfajta dimenzióváltásra, szélesebb látókörre van szükség ahhoz, hogy minél hatékonyabbá válhasson a húsz éve megfogalmazott agilis módszertan. A cégeknek fel kell ismerniük, hogy nemcsak a szoftverfejlesztésben, hanem minél több területen alkalmazniuk kell, viszont ehhez a módszertan kiterjesztésére van szükség”, mondta His Imre, a BM OKF Informatikai Főosztályának főosztályvezető-helyettese, térinformatikai és fejlesztési osztályvezető.
A jelenleg nagyon divatossá vált agilis módszertant mégsem lehet minden szervezetre ráhúzni, mert a sémák átvétele és alkalmazásuk kikényszerítse hosszú távon több kárt okoz, mint hasznot. Akkor fog eredményesen működni, ha az adott szervezet egyéniségére van szabva. „A folyamatos felülvizsgálat és finomhangolás a kulcsa a sikeres agilis működésnek. A rugalmasság ebben az esetben is fontos, hogy csak bizonyos elemeket használjunk fel a módszertanból, másokat viszont hagyjunk figyelmen kívül, ha nem passzol a folyamatokhoz. A Kiáltvány lényege szerintem az, hogy az agilitás alkalmazásával képesek legyünk olyan munkamódszert kialakítani, amely előnyökkel jár számunkra, és egyben értéket is teremt, ehhez pedig pont annyit kell a Kiáltványból felhasználni, amennyi épp szükséges. Nem szabad szentírásként tekinteni rá”, tette hozzá Popovics László, az OTP Bank fejlesztési igazgatója, aki szerint az agilitás több mint rugalmasság: a proaktivitás is hozzákapcsolódik.
Az agilitás és proaktivitás kéz a kézben járása jól látható a változásra nyitott szervezeteknél, ahol egyre inkább próbálják a felülről vezérelt és kontrollált hierarchiát úgy átalakítani, hogy az alulról szerveződő rendszerré váljon. „Ez a törekvés logikus, hiszen azok találkoznak a problémákkal, akik a frontvonalban harcolnak. Épp ezért nagyon fontos, hogy legyen folyamatos kommunikáció a vezetőség és a kollégák közt, és olyan menedzsment irányelvek, amik a két szempontrendszert egyesítik, ezáltal kihasználva a kollektív bölcsességet”, tette hozzá.
A szoftver tolja előre az üzletet
Persze nemcsak az informatikusok szembesültek azzal, hogy a változás elkerülhetetlenné és rapiddá vált az évek előrehaladtával, hanem a stratégiát megtervező üzleti döntéshozók is. 2021-re már nincs olyan, hogy öt évre előre betervezhető egy szoftverfejlesztési projekt, hiszen egyetlen nap alatt is rengeteg változás történik, és mindezt piaci oldalról le kell reagálni, az ehhez kapcsolódó üzleti hatást pedig lekövetni. Ez pedig egy új szoftverfejlesztési irányt vetít előre, a DevOps-ot.
„A DevOps módszer hatékony működéséhez a két szakterületnek az erőforrásaikat és folyamataikat is össze kell hangolni az elérni kívánt cél érdekében. Ez a szemlélet segít azokban a helyzetekben, ahol a magas szintű rendelkezésre-állás kiemelt követelmény”, mondta His Imre.
A DevOps képes kiszolgálni azt, amire most igény mutatkozik. „A DevOps esetében lerövidül a kétlépcsős folyamat, hiszen az fejlesztő ismeri legjobban a szoftvert, aki egyben az üzemeltető szerepét is betölti. Ez a lehető leggyorsabb reagálást teszi lehetővé, amire szükség is van, hiszen eljutottunk oda, hogy egy nagyobb szervezetnek is tartania kell az egy napos reakcióidőt. Ezért látom hosszú távon a DevOps térnyerését”, mondta Török Balázs.
Ami pedig az agilitás jövőjét illeti, sok cég, vállalat és vállalkozás is elindult az agilitás útján. Ennek ellenére, sokszor találkozni a módszertan félreértéséből fakadó működéssel, amelynek köszönhetően nem valósult meg teljesen az agilitás, és bizonyos területeken még mindig a silószerű a működés.
„A következő szint, talán az lenne, ha a szervezeteken belül az összes határ eltűnne, és minden a fejlesztésben résztvevő szervezeti egység kommunikálna a másikkal anélkül, hogy ehhez szükség lenne hierarchiára”, fogalmazta meg Popovics László. „Szerintem a jövőben olyan szoftverek és termékek várhatók, melyek a megfelelő információt biztosítva közös, jól átlátható platformot adnak a komplex, más területet is érintő projektek számára is”, mondta His Imre.
A kényszer nagy úr
Magyarországon egyelőre jellemzően a nagyvállalatok körében találkozhatunk agilis vezetési gyakorlatokkal. Maga a gondolkodásmód a digitális szolgáltatási modellekből érkezik, amelyek alkalmazói igyekeznek rugalmasságukkal, alkalmazkodóképességükkel kitűnni versenytársaik közül.
„A kkv-kben létezik egy egészséges szkepszis a nemzetközi gyakorlatokkal kapcsolatban. Ők nem kísérletezhetnek túl sokat innovációs eszközökkel sem, mert ezekkel esetleg túl sokat kockáztathatnak”, mondja Mizsei Szabolcs, a Kürt Akadémia agilis szakértője.
Esetükben egy egészen konkrét és sürgető fejlesztési kényszer hozhat valós érdeklődést az agilis fejlesztési eszköz alkalmazására. Azonnal sikert várnak, és csak akkor nyúlnak új eszköz felé, ha a hagyományos, eddig megszokott vezetői gyakorlataik kudarcot vallottak, vagy konkrét veszteséget okoztak. Ez azért önmagában egy ellentmondás, amit nehéz feloldani. Agilissal nem mehetünk biztosra, hiszen induláskor nem ismerjük a teljes komplexitást.
A másik kkv-s kihívás a forrásbevonás. Sokat segítene, ha az EU-s kkv-s pályázatok kiíró legalább alapszinten ismernék, de legalább elfogadnák az iteratív-inkrementális fejlesztések létezését. Jelenleg a pályázati rendszer kifejezetten tiltja az ilyen jellegű tervezést és utóelszámolás alkalmazását.
Mindenki a maga útján
Milyen tényezők hívhatják életre a kkv-agilitást? Üzleti oldalról ilyen sürgető ok lehet a beszállítói vagy a vevői kör hirtelen változása, amely formálja a meglévő üzleti modellt. A másik agilitási terep a jelenlegi szolgáltatások digitalizációja, egy stratégiai informatikai megoldás iránti igény. Már nincs 6-8 hónap egy szoftveres megoldás specifikálására, hogy aztán egy újabb fél év teljen el, mire elkészül a termék.
Ami az agilitás gyakorlati megvalósítását illeti, a csapat megalakításánál egész pontosan tisztázni kell az elérendő üzleti célt (ami nem csak szoftverfejlesztés lehet!), majd azt le kell bontani rövidebb fázisokra, általában kéthetes sprintekre, amelyek során már kézzelfogható eredmények születhetnek. Ugyancsak hasznosak lehetnek a scrum módszerek alapjainak és a fő ceremóniáknak az átvétele: ilyen a sprintek tervezése, az igények finomhangolása, a napi megbeszélések, a két heti eredmények bemutatása és a retrospektív.
A szakértő ugyanakkor arra is nyomatékosan felhívja a figyelmet, hogy az agilis módszertanokban nincs egyetlen, mindenki számára üdvözítő út. „Az agilitás egyik legfontosabb elve, hogy a csapat maga szervezi a működését, maga tárja fel és javítja a felmerülő hibákat. Az agilitás nem fél a hibáktól, amíg azok kiderülnek, és elég figyelmet kapnak. A rendelkezésre álló módszereket adaptálni kell a csapat működéséhez, a helyi viszonyokhoz, vagy akár az adott projekthez”, tanácsolja Mizsei Szabolcs.
A vezetőn múlik
A scrum-csapatok kulcsszereplői közül a product ownernek (PO-nak) mindenképpen a cég soraiból kell kikerülnie. Ő az, aki ismeri a céget, és minden ízében tisztában van a fejlesztési céllal is, amelynek szállítása az agilis fejlesztés feladata, erre pedig egy külső szakértő biztosan alkalmatlan.
|
Vezetői vélemény
A forráskód minőségére és karbantarthatóságára vonatkozó irányelveket is be lehetne iktatni, hiszen a szoftverfejlesztés során a forráskód az első számú érték. A megrendelő nem azért fizet elsősorban, hogy a szoftver végrehajtsa, amit, kell, hanem azért, hogy mennyire karbantartható a szoftver kódja: azaz mennyire egyszerű bővíteni, biztonsági frissítést, a dinamikusan változó igényekre reagáló funkciókat beletenni. Ehhez szorosan kapcsolódik az egyre népszerűbbé váló DevOps irány, ahol a fejlesztés és az alkalmazás működtetésének kiadása összevonódik. A szoftverek életciklusa gyorsabb lesz, így gyorsabban kell fejlesztési és üzemeltetői oldalról is reagálni. A másik irány, amifelé a szoftverfejlesztés halad, az az ügyfélközpontú, UI és a UX központú megközelítés. Legyen szó webes, mobil felületről, vagy alkalmazásról, ha nincs megtámogatva megfelelő UI-vel és UX-szel, akkor a felhasználók nem fogják szeretni, és más, jobb felhasználói élményt nyújtó szoftvert felé fordulnak – mondta Ekler Péter, az AutSoft technológiai igazgatója. |
A másik fontos szereplő a csapat napi tevékenységét vezető scrum master, aki a módszertan betartásáért, a ceremóniák levezényléséért is felel. Neki mindenképpen értenie kell a scrumhoz, így egy kisvállalatnak többnyire külső szakértőt kell megbíznia ezzel a feladattal, legalábbis addig, amíg házon belül ki nem képződik egy hozzáértő szakember. Emellett, és talán ez a legfontosabb, olyan felhatalmazást, önállóságot kap maga a fejlesztői csapat, amely a hierarchikus, a felelősséget a tulajdonosra testáló vezetéstől 180 fokban eltér.
Éppen ezért kulcsfontosságú az első számú vezető (tulajdonos) szerepe, még ha maga nem is tagja a scrum csapatnak. A tulajdonos vagy az első számú vezető a projekt operatív döntéseit, a priorizálást, a célok meghatározását átadja a PO-nak, és ezután már csak rajta keresztül szólhat bele a munkába (de az a legjobb, ha nem szól bele). A megadott felhatalmazást megtartani nem könnyű, főleg, ha vita van a PO és a tulajdonos/ügyvezető között. „Érthető módon a legtöbb vezető, tulajdonos számára ez nagy kihívás. Aki felépített egy sikeres céget, megszokta, hogy eddig a kezében tartotta a stratégiát, most pedig csak kéthetente, a sprintek végén értesül arról, hogyan állnak a dolgot. „A vezetés az agilisban feloszlik. A kérdés az, mit szól ehhez egy kkv vezetője?”, teszi fel a kérdés Mizsei Szabolcs.
Tanácsadói oldalról nem könnyű külső segítséget bevonni. Az agilitás népszerű, nincs elég szakember, a legjobbakat pedig felszívják a pénzügyi, informatikai vagy gyógyszeripari szektor tőkeerős vállalatai. A sok referenciával és széles ismerettel rendelkező, profi agilis szakemberek olyan munkadíjat kérnek, amit egy tipikus kkv nem igazán tud megfizetni. „Ilyen körülmények között egy kkv-nak gyakran sajnos a kondér alját kell kapargatnia, amikor szakértőt keres”, teszi hozzá Mizsei Szabolcs.
Mindez mégis megéri, mert a fenti akadályozó tényezőket elháríthatók, a kkv-k üzletfejlesztése és ezzel az egész szektor innovációs munkája pedig sikeresebb lehet az agilitással.
Kiss Franciska –Schopp Attila
