Kerekes József:Az eddigi tapasztalatok azt mutatják, hogy az eddig alkalmazott vízesés módszerekkel megkezdett fejlesztési projektekhez óriási fejlesztési tapasztalat és projektmenedzsment tapasztalat szükséges. A hagyományos fejlesztési modellek mindenre kiterjedő részletes szabályozással, kontroll folyamatokkal, analízisekkel és rengeteg dokumentálással zajlanak. Gyakran megtörténik, hogy egy ilyen projekt az indulás után egy évvel a követelményspecifikációt még mindig nem sikerült lezárni.
Az új, agilis módszertanokban drasztikusan lecsökkenek a szabályok, így "nehéz súlyok" nélkül képes a projekt szárnyalni. az agilis fejlesztési módszerekkel ahelyett, hogy egy nagy csoporttal sok időt töltenénk el egy-egy nagyméretű (monolitikus) munka elvégzésével, több kisméretű csapattal, rövid idő alatt, kisméretű munkákat végzünk el. Az eredményeket pedig rendszeresen integráljuk, hogy az egész kép látható maradjon.
Szemben a kiterjedt, monolitikus rendszerek létrehozásakor alkalmazott vízesés modell gyakorlatával - amikor is a megrendelőnek a fejlesztést megelőzően minden részletre kiterjedő útmutatást kell adnia a megbízott csapatnak, s a késznek szánt szoftverrel találkozik először - az agilis alkalmazásfejlesztés módszertana jobban illik korunk nyílt innovációs környezetéhez. Bármennyire is törekszünk rá, lehetetlen pontosan részletezni ma azt, hogy milyen alkalmazáskörnyezet tudja kiszolgálni az üzletmenetünket az elkövetkező 3-5 évben. Az agilis módszertan lehetőséget biztosít arra, hogy lépésekben vázolja a kivitelező csapat számára a koncepcióját, s egy kiterjedt alkalmazást átlátható egységek egymásutánjában hozzanak létre. Az egyes modulok elkészülte után a megrendelő és a végfelhasználók visszajelzései alapján testreszabható a produktum. A megrendelő gyakori bevonása garancia lehet a sikerre.
Az agilis módszertanok megoldásfókuszúak, s a funkcionálisan működő alkalmazások létrejöttét tartják szem előtt. Ez a megközelítés nem fektet nagy hangsúlyt a dokumentálásra, ami a továbbfejlesztésbe vagy az üzemeltetésbe újonnan bevont szakemberek számára hátráltató tényező lehet.
Az agilis fejlesztések által létrehozott applikációk egyik legnagyobb problémája a skálázhatóság. Ezért van az, hogy ahol nagyszámú felhasználó számára fejlesztenek, ott a gyakorlott fejlesztési vezetők inkább a monolitikus módszertant, vagy a leginkább a vegyes megközelítést alkalmazzák. Mindez feloldható olyan keretrendszerek használatával, ahol a skálázhatóság a platform részét képezi.
Figyelmet kíván, hogy a fejlesztési szakaszokban kiosztott kis feladatok, probléma esetén összetorlódhatnak, “dugulást" okozva a fejlesztési folyamatban. Szintén probléma lehet egy-egy hosszabb fejlesztési igényű feladat kezelése, amely végül is ellentétes a rövid, gyors szakaszokból álló fejlesztési módszertannal. Éppen ezért nem kötelező egyetlen módszertant alkalmazni a fejlesztések közben. Sokkal inkább több módszertanból a számunkkra legjobb és leg hatékonyabb elemeket célszerű felhasználni, bátran kisérletezni.
A gyors és költséghatékony végrehajtás érdekében milyen fejlesztési szabályokat, kritériumokat lehet megkerülni?
Ne legyen nagyon nagy overhead, vízfej, az erőforrások kiosztása gyors kell, hogy legyen. A bürokrácia leépítése fontos. Értendő ez alatt a munkavégzéshez szükséges fizikai erőforrás, a közös alkotói munkát lehetővé tevő strukturált és naplózott kommunikációs platformok, a kreatív és adminisztrációs feladatok végrehajtásához szükséges célszoftverek, a forráskód releváns része megfelelő valós vagy teszt adatbázissal. A gyakorlatban sokszor hátráltató tényezőként jelennek meg erőforrás tervezési és elszámolási problémák, ezért fontos része továbbá a rendszernek a kontrolling funkció is, amely alapját képezheti az elszámolásoknak vagy az erőforrás allokációnak.
Amikor egy cég alkalmazást fejleszt, mire érdemes odafigyelni? Hogyan kell megtervezni egy ilyen projektet?
Először is azt kell vizsgálni, hogy a cél eléréséhez van-e már kész megoldás. Gyakran előfordul, hogy egy cég megvesz egy már kész terméket, aminek a felhasználási területén kívül akarja használni azt költségcsökkentés céljával. Ennek persze lehetnek negatív eredményei is, amit mérlegelni kell a választásnál.
Ezzel kapcsolatban megemlítenénk a felhasználói élmény fogalmát, mely a funkcionalitás és a válaszidő faktoraiból áll össze. Ha a használt szoftver funkcionalitása eltér a munkavégzés logikájától, akkor az többletterhet ró a felhasználóra. További problémát okozhat az, ha a már meglévő szoftvert össze kell kötnünk más szoftverekkel, azok adatbázisaival. Egy saját gyártású célszoftver szemben több eltérő fókuszú szoftver összedrótozott halmazával valószínűleg eltérő válaszidőt mutat. Első ránézésre minimálisnak tűnhet a különbség, de a végfelhasználó számára a napi munkavégzést szignifikánsan könnyebbé teszi egy számára ergonomikus funkcionalitás, s az egyszerű logikának és megfelelő hardveres háttérnek köszönhető gyors válaszidő. Érdemes felmérni ezek aspektusait, mielőtt vásárolt vagy fejlesztendő szoftver között döntünk.
Ha a fejlesztés mellett döntenénk, vegyük számításba, hogy a sikeres fejlesztés a gyakori UA (User Acceptance) teszteken alapul. A kezdeti prototípusok, később az ún. deszkamodellek validációja kiemelt figyelmet igényelnek. Továbbá figyelni kell arra is, hogy a projekt nem ér véget a szoftver átadásával. Folyamatosan figyeljük az egyes feladatok átfutási idejét, így láthatóvá válik a “torlódás" a folyamatokban. Ha szükséges vizualizáljunk, és ha úgy látszik, hogy egy eszköz, egy szabály korlátokat szab, akkor próbáljunk “javítnai" azon. Az agilis fejlesztés első tétele: “"az egyén és a személyes kommunikáció az eszközök és folyamatok felett". A folyamatos kommunikációval folyamatosan finomítsuk a meglévő folyamatainkat.
Az üzletmenet fejlesztésével vertikális és horizontális addíciók is szükségesek lehetnek, pl.: a felhasználói visszajelzések beépítése, de pusztán a vonatkozó jogi szabályozások miatt is szükség lehet a szoftver átalakítására. Ezektől függetlenül is szükség van a intangibilis jószágunk időnkénti karbantartására.
Hogyan lehet tesztelni az alkalmazásokat még az éles verzió kiadása előtt?
Leginkább a tesztorientált fejlesztési metódusok a legköltséghatékonyabbak projektszinten. A tesztorientált fejlesztés abból indul ki, hogy minél hamarabb derül fény egy hibára, annál fájdalommentesebben lehet azt korrigálni. Gyakorlatilag minden elkészült kódhoz írhatunk egy tesztet. Adunk egy bemeneti értéket, amelyről tudjuk, hogy mi lesz annak kimenete. Ha a teszt lefuttatása után az elvárásainknak megfelelő visszajelzést kapunk a futtató környezettől, akkor rendben vagyunk. Természetesen ha változik a kód logikája, akkor a teszt logikáját is változtatni kell. Újabb és újabb verzióknál is le tudjuk futtatni a már megírt tesztadatbázist automatizáltan.
Egy teljesen új rendszer esetében könnyen megvalósítható, hogy együtt fejlesszük a kódot, a tesztet és a tesztadatbázist. Nagyobb egységek ellenőrzésére szolgál az integrációs teszt, ami a felhasználói felületen történik és egy kattintó, kitöltő robotot tudunk alkalmazni modulszintű tesztelésre. Az end - to - end tesztelési folyamat a rendszer A-Z-ig való felhasználását tudja tesztelni felületi szinten robottal vagy felhasználóval, s az applikáció működési folyamatát nézi végig. Minden lehetséges esetre rendelkezünk egy tesztesettel, s lépésenkénti működési elvárásokat definiálunk. A tesztet futtató alkalmazást is meg kell tanítani, hogyan néz ki pl.: egy animáció, ami egy adott menüpont kiválasztásakor kell, hogy elinduljon.
Az agilis fejlesztés gyakorlatában egy pár napos vagy akár egy hónap terjedelmű iterációs folyamat eredménye mindenképpen egy futóképes, funkcionális változat. Ezután egy átvételi teszt következik, amely során a megrendelő véleményezi az elkészülteket, melyeket elfogadhat, de akár korábbi követelményeit is megváltoztathatja. Megfelelő technikai háttérrel az átvételi szakaszba a végfelhasználók széles köre bevonható, amely minden érintett érdeke.
Mikor érdemes külső erőforrásokat is igénybe venni egy fejlesztésnél? Hogyan oldható meg a külső fejlesztők és a házon belüli dolgozók együttműködése?
A ma jellemző nyílt innovációs környezetben mind a jogvesztő, mind a verseny diktálta határidőket be kell tartani. A kapcsolódó feladatok jellegéből adódóan gyakran a legkülönbözőbb kompetenciák egyesítésére van szükség. Több okból sem tudunk minden kompetenciát vállalaton belül megszervezni és megtartani, így külső tanácsadókra és szolgáltatókra minden vállalatnak szüksége van. Így van ez a szoftverfejlesztéssel is, ahol mennyiségi és minőségi kiegészítés szükséges.
A szoftverfejlesztő csapatok klasszikusan egy légtérben dolgoznak, ahol a közös tapasztalat eredményeként gördülékenyen kommunikálnak és hatékonyan végzik a munkájukat. Ezek az adottságok nem minden esetben jellemzőek. A belső és külső felelősök közreműködésének sikerét több feltétel teljesülésében látjuk. Egy, az üzleti logikát láttató flowchart létrehozása is lényeges, hogy a külsősök is rálássanak azokra a folyamatokra, amelyekhez szoftvert fejlesztenek. Ezen túl biztosítsunk távoli asztal környezetet a külső fejlesztő számára, ami segítségével a saját eszközéről is hozzáfér rendszereink azon elemeihez, amelyek szükségesek a feladata elvégzéséhez. Se többhöz, se kevesebbhez.
E környezeten belül szüksége lesz tárhelyre, levelező és valós idejű kommunikációt lehetővé tevő programokra, fejlesztő és tesztfuttató alkalmazásokra, jegy- és verziókezelő rendszerre, illetve kódtárra. A projektgazda vagy a megbízott egy önkiszolgáló portálon keresztül akár néhány kattintással is létrehozhat magának egy ilyen környezetet, ha a mögöttes technológiát erre felkészítettük. A verziókezelés és kódtár esetében érdemes kizárólag belső és külsősök által is elérhető két külön domain-t létrehozni. Fontosak a kreatív alkotást támogató eszközök, de legalább annyira lényeges az átlátható, clean kódminőség, a megfelelő dokumentáció és a valós környezet alapján modellezett tesztkörnyezet.
Látszólag talán ellentmond az eddig elmondottaknak, de a külsős és belső fejesztések hatékony eggyüttműködéséhez szükséges, hogy “korlátozzuk a lehetőségek számát" . Ha mindenkire rá van bízva, hogy teljesen saját igényére szabhatja a környezetét és eszközeit, csorbulni fog az egységesség, a kompatibilitás, és nem utolsó sorban a felügyeleti kontroll lehetősége.
A fejlesztésért felelős megbízottnak megfelelő arányban kell elosztania a munkát, továbbá utólag is látnia kell, hogy az egyes felhasználók mit és mennyi idő alatt hoztak létre. Az orchesztrációt, monitorozást és az utólagos hibakeresést is számos csereszabatos céleszköz teheti lehetővé.
