Az Agilis kiáltvány megjelenése alapjaiban változtatta meg a szoftverfejlesztést. Az alapelvek gyorsan elkezdték átalakítani az egész IT ipart és meggyőződésem hogy a cégvezetési módszereket is át fogják alakítani. Azonban hamar nyilvánvalóvá vált, hogy egy hagyományos módszerekkel működtetett IT üzemeltetés mellett az agilis projektek sikere csak korlátozott lehet.

A fejlesztők és üzemeltetők között sok helyen már az agilis módszerek elterjedése előtt is voltak súrlódások, a fejlesztési ciklus felgyorsulásával és az iteratív munkamódszerek térhódításával azonban a két világ összeütközése elkerülhetetlennek tűnt. A DevOps megoldást nyújtott ezekre a problémákra és az agilis módszerek folytathatták diadalútjukat az üzemeltetés birodalmába.

De vajon sikerül az agilis szemléletnek teljesen átalakítani az üzemeltetés gyakorlatát? És ha igen az azt jelenti, hogy egy agilis szervezetnek már nem lesz szüksége az ITL-re?

Szükséges egyáltalán az IT üzemeltetésnek agilissá válnia?

Az agilis módszereket eredetileg szoftverfejlesztők dolgozták ki azért hogy gyorsabban, jobb eredményeket érjenek el. Még a DevOps és a Kód Alapú Infrastruktúra (Infrastructure As Code) is csak egy részét fedi le az IT üzemeltetése tevékenységeknek. Jogosan merül fel a kérdés hogy egyáltalán szükséges-e hogy az IT üzemeltetés agilissé váljon.

Olyan projektek vezettek a Manifesztum megszületéséhez amik az alapos tervezés, dokumentálás és szigorú projekt vezetés ellenére is kudarcba fulladtak. A fejlesztők azt látták, hogy ezek a projektek azért nem vezettek sikerre mert a tervek, folyamatleírások, a szerződések és a dokumentálás mind fontosabb volt mint a fejlesztők és megrendelők hatékony együttműködése és a megváltozott igényekhez való gyors alkalmazkodás. Problémák amelyek üzemeltetési projektekből is ismerősek lehetnek…

Emellett ha a fejlesztés felgyorsul de az üzemeltetés még mindig lassan és körülményesen dolgozik akkor a termék minősége romlik és továbbra is lassan jutnak el a felhasználókhoz az új funkciók.

Végül az IT-val szemben támasztott elvárások is nőttek. A sikertelen és/vagy elhúzódó projektek miatt a megrendelők és a cégvezetők elvárásai is nőttek. Az várják az IT-tól hogy változtasson a munkamódszerein és biztosítsa a magasabb minőséget és a gyorsabb megoldásokat. Különösen akkor amikor a digitalizáció egyre fontosabb szerepet kap minden vállalat életében.

Az agilis működés a kulcsa az IT üzemeltetés magasszintű múködésnek is. De nem lehet – és nem is kell – minden esetben egy az egyben lefordítani az agilis módszereket az üzemeltetés területére.

Agilis alapelvek és ITIL. Egy furcsa pár?

Az ITIL az évek során egy széleskörű keretrendszerré vált. Mára lefedi szinte az összes szolgáltatás nyújtással kapcsolatos tevékenységet. De annak ellenére hogy bár az ITIL a legjobb gyakorlatok gyűjteménye a megvalósítás során sokszor mégis nehézkessé, bonyolultá, túldokumentáltá és túlszabályozottá vált. Nem túl jó kezdés az agilissá váláshoz.

Az agilis módszerek kitűnő megoldást nyújtanak komplex, nem kiszámítható lefolyású projektekre. Az IT üzemeltetés számos feladata azonban rendszeresen ismétlődő, mindig hasonló módon lezajló folyamat. Nem éppen az agilis módszerek tipikus felhasználási területe…

Ennek ellenére egyáltalán nem lehetetlen feladat egy jó üzemeletetési csapat működését agilissá tenni. A megközelítés különböző lesz az ismétlődő, kiszámítható és a más típusú folyamatok esetében. Az IT szolgáltatások területén is számos komplex, nehezen megjósolható feladat van, ezekben az esetekben az agilis módszerek is egyszerűbben alkalmazhatók.

Vegyük például egy új Service Desk rendszer beveztését. Egy ilyen projektet sokkal jobb eredménnyel lehet agilis módszerekkel lebonyolítani. Ha napi szinten működünk együtt a felhasználókkal akkor a megoldás sokkal inkább meg fog felelni az igényeknek mintha megpróbáljuk megírni a tökéletes igényspecifikációt. Ingyenes tesztverziókból többféle tesztkörnyezet építhetünk és első kézből szerezhetünk tapasztalatot az alkalmazások működésével kapcsolatban – hasonlóan a fejlesztésben alkalmazott A/B teszteléshez. Ez olyan tapasztalatot nyújt amit kereskedelmi prezentációkból nem lehet megszerezni. Ha a kiválasztott toolt limitál funkcionalitással gyorsan beüzemeljük az gyors eredményt
hoz szemben azzal ha széleskörű funkcionalitással mindenféle modullal együtt kezdenénk el használni – sokkal később.

De az agilitás sokkal többet jelent ennél. A napi üzemeltetési feladatok terén is rengeteg lehetőség van az agilis működésre. Itt sokkal inkább az agilis működés filozófiája és a Leanben gyökerező módszerei (mint például a Kanban és a Kaizen) az ami lehetővé teszi a transzformációt.

Hogyan válhatnak ITIL folyamatok agilissá?

Lássuk pár ITIL folyamat példáján mennyire más jelent az agilitás egyes esetekben.

Incidens management

Az Incidenskezelés szerencsére már önmagában is elég agilis. Gyors, a prioritás mátrix elősegíti hogy a felhasználó számára igazán fontos dolgokra koncentráljunk. Iteratív, hiszen lehetőség van első körben workarounddal megoldani a bejelentést és szoros az együttműködés a felhasználóval.

De lehetőség van még agilisabbá tenni a folyamatot például a Kanban bevezetésével vagy a kivételek hatékonyabb kezelésével. Ha túl bürokratikusan kezeljük a priorizálást akkor sokszor akadályozhatjuk a felhasználót. Nincs szabály ami segít eldönteni mikor nem kell ragaszkodni a prioritás mátrixhoz. De felhatalmazhatjuk (és oktathatjuk) az SD csapatot hogy jó döntéseket hozzanak. Biztos vagyok benne hogy jobban fognak emlékezni a felhasználók egy egy ilyen esetre mint például egy nyomtató probléma gyors elhárítására… Természetesen korlátozni kell a kivételek számát de készen kell állni a gyors reagálásra mikor bekövetkeznek. És amint tudjuk kivételek mindig lesznek.

Change management

A változáskezelés már nehezebb dió. A standard változások hatékony, ismétlődő feladatok, Minél több feladatot tudunk standard változásként kezelni annál jobb. De természetsen ezeket is lehet továbbfejleszteni például a Kód Alapú Infrastruktúra (Infrastructure As Code) bevezetésével. Egy jól letesztelt kód segítségével gyorsabban és jobban lehet elvégezni a konfigurációs feladatokat.

Azonban a komplex változások (amit valamiért normálnak neveznek az ITILben) kezelése az ami igazán megkülönböztet egy agilisen működő IT csapatot egy hagyományostól. Minden fejlesztő csapatot frusztrál ha várnia kell a heti (netán havi?) CAB megbeszélésre. Ha a DevOps jól működik akkor a felhasználó, az IT security az egész folyamatban részt vesz. Így azokat a szempontokat amiket a Change manager vagy a CAB megfontolna a csapat már a folyamat során megtárgyal. A change manager “felügyelőből” minőségbiztosító funkcióvá válik. Ha a változások száma növekszik de a change manager mégis unatkozni kezd akkor tudni fogjuk hogy jó úton járunk…

Eszköz és konfiguráció kezelés

Az eszköz és konfiguráció kezelés megint egész más műfaj. Általában láthatatlan a felhasználó számára és sokkal ritkábban van szükség egyeztetésre a folyamat “vevőjével” mint más folyamatoknál. A hatékonyság itt még az agilitásnál is fontosabb. Ezen a területen is lehet előrelépni például automatizált “felderítő” (discovery) alkalmazásokkal amelyek folyamatosan naprakész adatot szolgáltatnak az informatikában használt rendszerekről. Ha ellenállunk a kisértésnek hogy teljes elszigeteltségben működjön ez a folyamat, ha automatizáljuk a konfiguráció kezelő rendszerünket akkor kihozzuk a maximumot a lehetőségekből.

Amint látható az agilitás minden ITIL folyamatot másként érint. Nincs olyan megoldás ami minden szervezetre ugyanúgy működik, hiszen a szervezet típusa és mérete már önmagában más megközelítést tesz szükségessé. De amíg az agilitáshoz vezető út különböző lehet a cél mindig azonos.

Az ITIL folyamatok átalakítása agilissá teszi a szervezetet?

Természetesen nem. Az agilitás egy szervezeti kultúra váltás, az agilis módszerek a kultúra váltás eredményei és nem fordítva.

Az agilitásnak sok oldala van. Jelenti a csapatok felhatalmazását a döntések önálló meghozatalára ugyanúgy mint a komplex problémák részekre bontását és iteratív megoldását. Jelentheti az ügyfelelkkel való napi szintű együttműködést. Mindenképp része az iterációk folyamatos áttekintése és a tanulságok felhasználása a folyamatos tanulási folyamatban. Része a rövid távú, 2-4 heti célok kitűzése hosszú távú (6-12 hónapos) célkitűzések helyett. Ezek mind lényegi változások amit nem mindig egyszerű elérni.

Az agilitás elősegíti az IT szolgáltatások továbbfejlesztését. Az ITIL folyamatok átalakítása segíti ezt az átalakulást de nem szabad elfelejteni hogy ez csak az eszköz és nem maga a cél. A cél az hogy gyorsabban érjünk el eredményeket és jobban tudjunk alkalmazkodni és előnyt kovácsolni a változásokból.