Sokféleképpen vélekednek a magyar CIO-k az agilitásról, derült ki az idei CIO Hungary tudásmegosztást segítő programjában. Tanács Lajos írása.
Hirdetés
 

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 bevezetés és alkalmazás kockázatai

Az agilis átállást kiemelten kockázatosnak látta szinte minden résztvevő. A leggyakoribb hátráltató vagy nehézséget jelentő tényezők:

merev vállalati működés, szabályok, hierarchia;
• nehéz visszamérni az átállást;
• a tradicionálisan is könnyen alacsony prioritást kapó dokumentációk még kevésbé készülnek el;
• alapvetően megváltozik a projektek költségkontrolljának módja;
• a transzformáció drága és hosszadalmas: nem elég folyamati és szabályzati szinten hatni, a szokások szintjére is le kell menni;
• problémát okozhat, hogy az üzleti terület a megszokottnál intenzívebben vesz részt a projektekben, hiányzik a valós üzleti allokáció
• átértékelődik a határidők szerepe
• markánsan megváltozik a megtérülés számítása, különösen a nyitott végű agilis projekteknél;
illúzió, hogy a profi agilis coach vagy a neves tréning elvégzése önmagában megoldja dolgot

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.

A sikeres átállás és alkalmazás kulcsa

A résztvevők összegyűjtötték azt is, szerintük melyek azok az alapvető feltételek, melyek elengedhetetlen az akár részbeni, akár teljes agilis transzformáció megvalósításához. Ezek a következők:

• szervezeti érettség;
• elkötelezett támogatás a HR és vezetés részéről, valamint – ehhez kapcsolódóan – a jó stakeholder-menedzsment, különösen a nehéz időkben;
kockázatvállalási hajlandóság;
nyitottság és bizalom minden résztvevő irányába, ami együtt jár például a hibázás elfogadásával;
• gyorsan mutass eredményt, és jelezz vissza;
• oktatás, megértés, hogy kialakuljon a közös nyelv – és türelem a meghonosodásáig;
• stabil, állandó csapat, a gyakori személycserék a siker gyilkosai;
• az IT nagyobb mozgástere.

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.

Piaci hírek

Kikupálódott a szingapúri dohányosokra vadászó MI

A szigorú törvényeiről és magas technológiai szintjéről ismert városállam a tilos helyen dohányzókat is automatikus megfigyeléssel igyekszik tetten érni.
 
Hirdetés

A NIS2-megfelelőség néhány technológiai aspektusa

A legtöbb vállalatnál a megfeleléshez fejleszteni kell a védelmi rendszerek kulcselemeit is.

Az uniós direktíva felpezsdíti a magyar kiberbiztonsági piacot, az auditokból átfogóbb képet kapunk a gazdaság és az ország kiberképességeiről is. Interjú dr. Bencsik Balázzsal, az SZTFH kibervédelmi igazgatójával.

a melléklet támogatója a RelNet Technológia Kft.

CIO KUTATÁS

TECHNOLÓGIÁK ÉS/VAGY KOMPETENCIÁK?

Az Ön véleményére is számítunk a Corvinus Egyetem Adatelemzés és Informatika Intézetével közös kutatásunkban »

Kérjük, segítse munkánkat egy 10-15 perces kérdőív megválaszolásával!

LÁSSUNK NEKI!

Amióta a VMware a Broadcom tulajdonába került, sebesen követik egymást a szoftvercégnél a stratégiai jelentőségű változások. Mi vár az ügyfelekre? Vincze-Berecz Tibor szoftverlicenc-szakértő (IPR-Insights) írása.

Nyílt forráskód: valóban ingyenes, de használatának szigorú szabályai vannak

Különösen az early adopter vállalatoknak lehet hasznos. De különbözik ez bármiben az amúgy is megkerülhetetlen tervezéstől és pilottól?

Sok hazai cégnek kell szorosra zárni a kiberkaput

Ön sem informatikus, de munkája során az információtechnológia is gyakran befolyásolja döntéseit? Ön is informatikus, de pénzügyi és gazdasági szempontból kell igazolnia a projektek hasznosságát? Mi közérthető módon, üzleti szemmel dolgozzuk fel az infokommunikációs híreket, trendeket, megoldásokat. A Bitport tizennegyedik éve közvetít sikeresen az informatikai piac és a technológiát hasznosító döntéshozók között.
© 2010-2024 Bitport.hu Média Kft. Minden jog fenntartva.