Az 1990-es évek elején, aamikor a PC széles körben elterjedt a vállalati szférában, attól nem függetlenül válsághelyzetbe jutott a szoftverfejlesztés. Az üzleti igények felmerülése és az azokat kielégítő alkalmazások elkészülte közötti időtartam átlagosan három évre rúgott, ami már akkor is megengedhetetlenül hosszúnak számított. Ennyi idő alatt ugyanis teljesen megváltozhattak a követelmények, a rendszerek, még akár az egész üzleti stratégia is; a változások lekövetése pedig ilyen tempóval egyszerűen lehetetlenné vált.

Számtalanszor kellett már futó fejlesztéseket feladni, de a befejezett megoldások jelentős része sem elégítette ki teljesen a megváltozott igényeket – még akkor sem, ha az eredeti célkitűzésnek megfeleltek. Ez a három év ráadásul csak az átlag volt – a védelmi iparágban vagy a repülőgépgyártásban évtizedes lemaradásban voltak a fejlesztők. Jól példázza ezt az amerikai űrsiklóprogram, ami 1982-es indulása ellenére az 1960-ban szerzett információkra és technológiákra alapult.

Alkalmazkodni a megváltozott helyzethez

Erre a helyzetre reagálva állt elő Jon Kern repülőmérnök az 1990-es években egy olyan módszerrel, ami lehetővé teszi az eredeti kritériumok fejlesztés közben történő módosítását. Addig ugyanis az eredetileg megállapodott követelményekhez igazodtak a fejlesztés teljes ideje alatt, ami bebetonozta a készülő megoldások képességeit. Kern tehát a közismert és általánosan használt vízesés (waterfall) modell leváltásán gondolkodott másfél tucat társával együtt, akikhez az utókor az agilis szoftverfejlesztés létrejöttét köti.

A vízesés modell megkövetelte, hogy a fejlesztési folyamatok egyes, egymásra épülő elemei teljesen készüljenek el, mielőtt a következő feladat elkezdődhetne. Míg a múlt század második felében hagyományosnak számító mérnöki munkákban fényesen bevált ez az eljárás, addig a programozók teljesítményét jelentősen korlátozta. Előbbinél ugyanis sokkal ritkábban változnak a paraméterek; például egy híd tervezésekor nem kell arra számítani, hogy fél-egy éven belül drámai eltérések lesznek az eredeti és az aktuális szükségletekhez képest.

A szoftveriparban azonban gyors fejlesztésre volt szükség, annyira gyorsra, hogy az ehhez szükséges idő alatt ne változzanak (sokat) az eredeti igények. Emellett alapvető fontosságúvá vált a rövid válaszidejű felhasználói visszajelzések kezelése, amivel hamar lehetett korrigálni a téves, elavult jellemzőket, és hozzáigazítani a megoldásokat az aktuális szükségletekhez. Ez, és a változtatásra való hajlandóság végül az agilis szoftverfejlesztés alapköveivé váltak.

Az agilis szolgáltatásmenedzsment pedig ebből, vagyis az agilis szoftverfejlesztésből fejlődött ki. Az utóbbi által megcélzott kihívások zöme ugyanis jelen volt, van az ITSM-ben is.
 

Előtérben az ügyfél érdekei

A 2001-ben megjelent Agilis Kiáltvány (Agile Manifesto) tizenkét alapelve a módszert sikeressé tevő  négy tételt járja körül. Eszerint az egyéneket és a közöttük való kölcsönhatásokat részesíti előnyben az eljárások és az eszközök helyett, illetve a működő szoftvert favorizálja a minden részletre kiterjedő dokumentáció helyett. Inkább a változásra adott reakcióra koncentrál az eredeti terv betű szerinti betartása ellenében, és az ügyféllel való együttműködésre helyezi a hangsúlyt a szerződéses tárgyalás előtérbe hozása helyett.

De mit is jelent ez a gyakorlatban? Nos, az agilis szolgáltatásmenedzsment az ügyfél érdekeire fókuszál, az ő elégedettségét igyekszik elérni a gyors és folyamatos megoldások nyújtásával. Hiszen nincs is nagyobb ügyfélmegtartó erő, mint a szolgáltatásokért, termékekért fizető kliensek igényeinek maradéktalan kielégítése. Ehhez természetesen szükség van az üzleti feladatokat végzők és a fejlesztők közötti intenzív kommunikációra, mivel utóbbiak az előbbieken keresztül tartják a kapcsolatot az ügyfelekkel. Az ügyfelek visszajelzései nem a fejlesztőkhöz érkeznek közvetlenül, azok megfelelő interpretálása a kapcsolattartók feladata.

Az agilis koncepciók és elvek gyakorlati megvalósítására számos keretrendszer kínál lehetőséget. Ilyen például a Scrum, a KANBAN vagy a Continuous Delivery, melyek közül az első számít a legnépszerűbbnek.

Ez három-kilenc emberből álló, kvázi spontánul szerveződő munkacsoportokra alapul, akik kétheti munkafolyamatokban (sprintekben) dolgoznak. A komplett projekt alacsony szintű részfeladatokra bontása elősegíti a gyors alkalmazkodást a változó körülményekhez. Alapvető fontossággal bír a feladatok a lehető legnagyobb mértékben - az üzleti szempontoknak is megfelelő - felhasználói igényekhez való igazítása. A munkacsoportok a scrum master irányításával napi maximum negyed óra alatt átveszik az előző napra tervezett és az aznapi feladatok állapotát, így tartva kordában a fejlesztés irányát.

CSI, de nem Miamiban, hanem vállalati környezetben

Voltaképp a fentiekről van szó az ITSM esetében is. Az agilis fejlesztés szemszögéből újratervezett, továbbgondolt szolgáltatásmenedzsment eljárások és módszerek révén hatékonyan szolgálhatók ki az ügyfelek gyakran változó igényei. Maguktól összeálló munkacsoportok gyorsítják fel az egyes problémák legyőzését és az ügyfelekkel megbeszélt feladatok megoldását. A legnagyobb eltérés a sprintek idejében rejlik: általában három-négy hétig tart egy ilyen folyamat. Ennek oka, hogy a csapatokban részt vevőknek el kell látniuk a napi szintű üzemeltetési feladataikat is, ami szintén időt követel.

Végső soron így nem csak gyorsabban és hatékonyabban lesznek kielégíthetők az ügyféligények, hanem maga a szolgáltatói csapat is agilisabbá válik. A gyorsan leszállított korai sikerek pedig meggyőzik a klienseket a szolgáltató kompetenciájáról.

Az agilis ITSM-re való átállás nem túlságosan nehéz feladat. Ha a szolgáltató már egyébként is érdekelt az állandó szolgáltatásfejlesztésben (Continual Service Improvement, CSI), akkor az agilis szolgáltatásmenedzsment bevezetése gyakorlatilag a következő, természetes lépcsőfokot jelenti. Ha a minőségfejlesztés már amúgy is ciklikus megközelítésben zajlik az adott szervezetnél, akkor a Scrum adoptálásával tulajdonképpen csak hivatalos formát kap az addig is követett gyakorlat.

Amennyiben azonban még nem jellemző az állandó szolgáltatásfejlesztés a vállalatnál, akkor az agilis ITSM bevezetése is nehezebbé válik. A sikeres átállás után azonban jóval nagyobbak lesznek az előnyök. A jobbá váló üzleti kapcsolatok révén könnyebb megérteni, mi történik a piacon; ennek minél korábban való felismerése pedig alapvető fontosságú az IT-szolgáltatások egymással versengő környezetében.