Mindannyian vágyunk a csodára. Természetes velejárója ez az emberi létezésnek: a vágyódás valami varázslatos dolog után, ami egy csapásra megoldja minden bajunkat, meggyógyítja a betegségeinket, gazdaggá, széppé, vagy éppen sikeressé tesz.

Nem kerülte el a csodavárás iparágunkban az elmúlt másfél évtizedekben az agilitást sem. Nem véletlen ez, hiszen a legtöbben azt hallhatták az agilis megközelítésről, amire mindig is vágytak: a programozók azt hitték, szabadon, specifikációk nélkül szárnyalhatnak végre, az üzleti oldal azt gondolta, végre sprintről sprintre bármiben meggondolhatja magát, a vezetők pedig örömkönnyekbe törtek ki, amikor meghallották, hogy az IT mostantól féléves release-ek helyett kéthetente fog szállítani.

Azt mára már mindannyian megtanultuk – néhányan a mások kárán, de a legtöbben a sajátunkon –, hogy az agilitás sem mindenható csodafegyver, különösen ha nem arra és úgy használják, ahogy azt kitalálták.

A 2018-as CIO Hungary konferencián több mint 90 magyar nagyvállalati IT-vezetővel egy nagyszabású közös workshopon arra vállalkoztunk, hogy feltárjuk az agilitás mai helyzetét iparágunkban: összegyűjtjük, milyen gyakorlati tapasztalatok övezik a témát, mire és hogyan érdemes alkalmazni az agilis megközelítést.

Kezdjük a rossz hírrel: erre nem alkalmas az agilitás

Általános vélekedés volt a résztvevők között, hogy üzemeltelést és supportot nem érdemes agilisan végezni. Itt a már kialakult folyamatok megbolygatását a többség nem érezte indokoltnak.

Tanács Lajos

A szerző programozó matematikus, a Wunderplan szervezetfejlesztési és projektmenedzsment tanácsadási iroda alapító-ügyvezetője és a népszerű Derrick és Harry Projektmenedzsment Blog társalapítója és szerzője.

Szintén nem tartotta jó ötletnek a többség az üzletkritikus rendszerek agilis fejlesztését, ahogy a nem agilisan fejlesztett rendszerek agilis továbbfejlesztését sem. Ezek a vélemények markánsan szembe mennek az agilis evangelisták által hirdetettekkel. Mivel azonban nagy valószínűséggel gyakorlati tapasztalatokon alapulnak, és rávilágítanak két fontos igazságra. Egyrészt arra, hogy az agilis kísérletek olyan kockázatokat hordoznak, amiknek nem szabad az üzletmenetet. Másrészt arra – az egyébként örök érvényű – igazságra is rámutat, hogy ha valami jól működik, azt nem érdemes bolygatni.

Az a konszenzus alakult ki, hogy nem jó ötlet sem az egyszemélyes feladatokat, sem a „hídépítés” jellegű projekteket agilis útra terelni. A hídépítés analógia természetesen átültethető minden olyan IT-projektre is, ahol nem lehetséges a kis lépésekben történő átállás: agilis elemeket persze lehet alkalmazni ott is, de az könnyen belátható, hogy a folyamatos élesítés nem valósítható meg.

A közbeszerzéses projektek maradtak a tiltólista végére: általános a vélekedés, miszerint az emberiség még nem találta fel azt a dimenziókaput, amivel a közbeszerzések és az agilitás világa átjárhatóvá válna.

A gyakorlat: Hogyan ne csináld?

Elkapkodni semmiképpen nem lehet: a "quick and dirty" megközelítés a biztos kudarc záloga. Például a krízisben vergődő projekteket semmiképpen se próbáljunk megmenteni agilitással. Világos vízió nélkül ugyancsak nem érdemes az agilis transzformációnak nekiállni: érteni és tudni kell, milyen előnyöket várunk, meddig akarunk eljutni, és azt is, milyen áldozatokat fogunk hozni az átállásért.

Gyakori és végzetes hiba a tervezés elhanyagolása. Ez rávilágít az egyik alapvető tévhitre: az agilitással feleslegessé teszi a hosszú távú és magas szintű tervezést.

A csak üzleti vagy csak IT oldali átállás megvalósítható ugyan, de nem lehet kihagyni a másik oldalt a transzformációból akkor sem, ha az nem alakul át. Ugyancsak kiemelt jelentősége van az üzemeltetés bevonásának, különösen a napjainkban, amikor a fejlesztés-üzemeltetés DevOps-tól vezérelt egyre szorosabb összefonódása figyelhető meg.

A jó hírek: erre alkalmas az agilitás

Az agilis szemlélet általános előnye az, hogy gyorsan változó közegben biztosítja a gyors reagálás lehetőségét, az organikusan fejlődő termékekhez pedig kiemelten alkalmas. Például a startup cégeknél kiválóan alkalmazható, ahogy fúziók esetében is: tágabb értelemben tehát olyan szituációkban, amikor nem pontosan tudjuk, mit akarunk elérni, de az biztos, hogy mennünk kell valamerre.

Meglevő rendszerek kisebb lépésekben történő fejlesztésére is alkalmasnak érezték a workshop résztvevői az agilitást. Ez látszólag ellentmond ugyan annak a fentebb megfogalmazott gondolatnak, hogy „ha valami nem volt agilis, ne tegyük azzá”, ugyanakkor az volt az általános vélekedés, hogy a két irány összebékíthető. Ehhez az kell, hogy az átállást ne projektek kellős közepén, hanem azok lezárása után kezdjük el.

Kevésbé összetett, kevesebb üzemeltetést igénylő és kisebb feladatokra különösen alkalmas a megközelítés könnyű súlya és egyszerűsége miatt. Ugyancsak alkalmas a független (vagy csak nagyon lazán integrált) rendszerek fejlesztésére.

Összefoglalás

Az agilitás már rég nem újdonság a hazai informatikai életben, sok szervezetben megtalálta a helyét, mások még csak kísérleteznek vele. Az azonban mindenképpen elmondható, hogy lecsengett a témát övező eufória.

Van aki szereti, van aki utálja, van aki hisz benne, és van aki még mindig messziről elkerüli. Összességében azonban öröm volt látni, hogy a megközelítés szervesen beépült az iparágunkba. És az is kétségtelen ma már, hogy az agilitás egy általánosan elfogadott eszközzel bővítette az IT-vezetők eszköztárát.