A vízesés modellről az agilis fejlesztésre történő átállást – buktatóit figyelembe véve - akár raftingoláshoz is hasonlíthatjuk. Hogy nehogy sziklának csapódjunk, az IT ipar szakértői megosztottak velünk néhány jó tanácsot.

A VerizonOne tavaly kiadott "The 9th Annual State of Agile Report"-ja szerint (az Analysis.Net Research független szaktanácsadóikkal együtt) a cégek 94 százaléka használja az agilis fejlesztést. A beszámolóban 3925 válaszadótól származó információ alapján határozták meg azokat a kihívásokat, melyekkel a szervezeteknek szembe kell nézni az agilitás bevezetése során.

Szakértőink szerint ehhez minden fél részéről gondolkodásmódbeli váltás, valamint a felsővezetők, a vállalat és a fejlesztő csapatok maximális támogatása szükséges.
Lássunk néhány olyan példát, melyek megfontolandók a vízesésből az agilissá alakuláshoz.

Mi szól a vízesés ellen?

"A vízesés fejlesztési modellt ismerhetjük még a programozás/fejlesztés klasszikus vagy hagyományos életciklus modelljeként. Ez egy egymást követő, egymásra épülő modell, melynek minden fázisának határozott és jól elkülönülő célja van. Amikor egyszer elérted a következő fázist, nem fordulhatsz vissza, ahogy egy vízesés sem, amely szikláról sziklára zuhog lefelé a hegyoldalon", mondja Joe Mack, az Enterprise Technology Transfromation Transphorm-beli konzultánsa. A vízesés-modell jobban megállja helyét az olyan szituációkban, ahol tiszták az elvárások és a fejlesztésben résztvevőknek, valamint az ügyfeleknek sincs lehetőségük megváltoztatni a project kereteit. Sajnálatos módon nincs túl sok valós IT probléma, ami ebbe a kategóriába esik.

Sudhakar Gorti, az Environmental Data Resources vezérigazgató-helyettese szerint az agilis módszertan egyik legnagyobb előnye a vízesés modellel szemben az, hogy egy iteratív (a célhoz folyamatosan közelítő) megvalósulást láthatunk, és így a felelős menet közben dönthet a terméket érintő változtatásokról.

Helyesen agilissá válni

A cégeknek, mielőtt belevágnának az átalakításba, tisztában kell lenniük azzal, hogy milyen problémákat szeretnének megoldani, és hogy az agilitás hogyan tud ezeken segíteni. Meg kell vizsgálniuk továbbá azt is, milyen eredmények esetén tartanák sikeresnek az átalakulást? Mennyire elkötelezett, támogatja-e a társaság ezt a változást? Van-e szüksége külső segítségre?
Az agilis modellre történő áttérés remek dolgokat hozhat egy szervezetnek. Elősegíti a projektben résztvevő tagok együttműködését, növelheti a csapat által létrehozott kódok minőségét, lerövidítheti a piacra kerülés idejét, növeli a fogyasztói elégedettséget, mindezek mellett még a fejlesztés költségeit is csökkentheti. De mindezt csak akkor, ha jól csinálják. "Rosszul végrehajtva sokkal több problémát okoz az agilis fejlesztés, mint amennyit megold." - mondja Nathan Wilson a Gartner kutatási igazgatója.

Mindenki a fedélzetre!

A Gartner szerint az agilissá alakuláshoz az IT és az üzlet szoros együttműködésére van szükség, ahol vezérigazgatótól a legjuniorabb fejlesztőig mindenkinek egy irányba kell haladnia. "Az agilis módszertanok használata átalakítja az IT és az üzlet kapcsolatát, és pozitív hatással van az IT értékteremtő képességére. A siker elengedhetetlen része, hogy az informatikai vezető és az egész IT menedzsment elkötelezett legyen a változások iránt." - mondja Wilson.
Mack mindezzel egyetért, szerinte ez az agilisság szíve. "A - minden agilis módszertannal együtt járó - iteratív folyamatra jellemző, hogy az üzleti terület részvételét igényli minden tervezési szakaszban, és sokszor a napi működés során is."

Az agilis modell sikeres alkalmazásához szükséges, hogy mindenki a kezdetektől részese legyen a folyamatnak. Az üzleti területnek és a fejlesztő csapatoknak közösen kell dolgozniuk, hogy meghatározzák a specifikációkat, KPI-kat (kulcs teljesítmény mutatókat), ütemezéseket, büdzséket és még nagyon sok mindent. "Az érintetteket az első naptól kezdve be kell vonni az átállás folyamatába. Ők ismerik a teljes képet, amit neked, mint IT vezetőnek kell feldarabolnod olyan részekre (funkciók logikus és tesztelhető csoportjaira), amelyek értelmesek alkalmazás oldalról és technológiai nézőpontból is." - mondja Michael Spano, az IBM Resiliency Services infrastruktúra szolgáltatásának ügyvezető igazgatója.

Kihívások az agilissá válás során

Gorti szerint bonyolult lehet a megvalósítás. "Kihívás mindenkit úgy összehangolni, hogy működjön egy új folyamat, továbbá néhány embernek téves elképzelései vannak és/vagy kevésbé értik meg, hogy mit is jelent igazából az agilisság. Ahhoz, hogy a felső vezetést meg tudd győzni az átalakítás szükségességéről, kulcsfontosságú, hogy a csapatod és a vezetőség tisztában legyen vele, mi az agilisság és ez miképp válhat a cég javára. A kulturális változás a másik nagy kihívás Mack szerint. "Attól függően, hogy meddig használták a vízesés modellt, néha nehezebb a fejlesztés szervezeti kultúráját megváltoztatni."

Derek Plunkett, a John Hancock Retirement Plan Services IS alkalmazás fejlesztés részlegének alelnök-helyettese egyetért ezzel: "Az egyik legnagyobb kihívás olyan irányba terelni a csapat gondolkodásmódját és viselkedését, hogy az egyéni teljesítménnyel szemben a csapat-eredményeket helyezzék előtérbe." Ennek érdekében Derek azt javasolja az IT vezetőknek, hogy határozzanak meg célokat és ajánljanak pénzbeli jutalmakat a csapat-tagoknak.

Az anyagi megtérülést már nehezebb garantálni. Mack azt mondja, az agilisság költségoldalról egy befektetésnek tekinthető. A felső vezetés aggódni szokott a megtérülés ideje miatt, mert a fejlesztési idő növekedésével nő a dolgozók időráfordítása, a különféle minősítésekre kiadott pénz és a szaktanácsadók díjai.
Más nehézségek is adódhatnak az áttérés során. Spano szerint: " A megrendelők gyakran akarnak időre dolgoztatni vagy sok mindent gyorsan megcsináltatni, ami a funkciók gyengébb kódolásához és teszteléséhez vezet. Ezen túl sok fejlesztő és megrendelő nem veszi észre, ha egy új funkció kihat az korábbiakra is, amit regressziós teszteléssel, esetenként átdolgozással kellene garantáltan biztosítani, hogy korábbi funkciók ugyanúgy működjenek, ahogy meg lettek írva. A megrendelők elvárásaival szemben az "elég jó" megközelítés végtelen fejlesztést és tesztelést eredményez."

A kudarc 3 leggyakoribb oka

Hiba a tervezésben

Mack szerint minden követelmény és kalkuláció csak a megfelelő fázisban határozható meg. Ha nem ismert az összes releváns információ, akkor majdnem biztos, hogy a becslések és ezzel együtt a fejlesztési idő ütemezés (és ebből következően a költségvetés) is téves lesz, még mielőtt a fejlesztés elkezdődne.

A terjedelem elcsúszása

"Az agilis projektek bukásának második oka a terjedelmük megnövekedésére vezethető vissza, ami akkor fordulhat elő, ha ideje korán annyi érintettet vonsz be, amennyit csak lehetséges. Ilyenkor új körülmények válnak ismertté, amiket "egyszerűen be kell építeni". Ez késlelteti a csapatokat és gyakran okozza az egész projekt csúszását is." - mondja Spano.

"Leggyakrabban az új követelmények megjelenése miatt szoktak tágulni a projekt határai, hacsak nem rendkívül fegyelmezett a csapat. Ez meghosszabbítja az időtartamot és az eredeti költségbecslések túllépéséhez vezet. Előfordul, hogy bedőlnek projektek vagy felfüggesztik azokat ebben a fázisban, mert túl költségesek vagy a vállalat prioritásai változtak meg az indulás óta." - állítja Plunkett.

Képtelenség alkalmazkodni a változáshoz. "Ahogy a követelményekről további részletek derülnek ki, lehetetlen mindegyik miatt változtatni a követelményleíráson, kivéve, ha elrendelik a változást eszközlő folyamatot, ami a fejlesztési idő és a költségek növekedéséhez vezet." - mondja Mack.

Érdemes bevonni külsős tanácsadókat?

Az attól függ, hol tartasz a folyamatban. Spano szerint, ha induláskor vonsz be egy külső konzulenst és tanítod, segíted a teamed, akkor az egyes részek felfedezése sokkal jobban megy majd, mintha már a kész csapathoz csatlakozik a külső tanácsadót.

Ha Te is először találkozol hasonló projekttel, akkor még fontosabb a fejlesztő csapatok képzése. A valós tapasztalatok kiemelkedő jelentőségűek a siker szempontjából az agilis modellre történő átállás korai szakaszában, mondja Mack. "Sajnos nem nyújt elég gyakorlati tapasztalatot, ha belső erőforrásból neveljük ki az agilis „oktatónkat”, sőt egy összetett agilis fejlesztésnél ez veszélyezteti a sikert. Egyszóval külső segítséget bevonni rizikós, de majdnem mindig megéri."

Gorti szerint ugyanilyen fontos, hogy "jó" agilis oktatót hívjunk. "Olyan elismert személy hívjunk be, akinek van tapasztalata ezen a területen és biztosak lehetünk benne, hogy minden dolgozó előtt példaképként jelenik meg." Itt jön el az ideje, hogy kiválasszuk azokat az embereket, akikről úgy gondoljuk, a leghatákonyabban tudnak részt venni az átalakításban. "Továbbá jelentősen növelheti a változás elfogadását, ha teamenként egy-egy ezért felelős embert nevezünk ki, és bevonjuk az átalakítás folyamatába." - mondja Plunkett.

Kezdjük kicsiben!

Elkerülhetjük a hirtelen, egyszerre végbemenő átalakulás okozta sokkot. Plunkett szerint "Az átalakítást kisebb kísérleti teamekkel érdemes kezdenünk. Ha az alapkiképzés és az eszközök terén is helyén van minden, valamint a kulturális háttér is megfelelő, indulhat a többi team átalakítása is." Ez a fajta megközelítés minimumra próbálja szorítani az egész vállalat egylépcsőben történő átalakításának kockázatát, és lehetővé teszi a vezetőknek, hogy átgondoltan felmérjék és számba vegyék az összes akadályt, ami előkerül a kísérleti szakasz alatt.

Használjuk azt, ami működik!

Az agilisság nem fogja megoldani az összes problémánkat. Gartner szerint a különböző fejlesztési osztályok problémái különböző megközelítést kívánnak. Miközben úgy tűnik, az egész fejlesztési világ agilis lett, a szakértők hozzáteszik, hogy a vízesés, a hibrid és más modellek is valamilyen szinten mindig jelen lesznek a fejlesztés modern világában. "A vízesés projekteknek ott a helye, ahol a követelmények tiszták és jól meghatározottak, az idő nem kritikus tényező, és bár az agilis modell itt is működik, az előnyök sokkal szignifikánsabbak, ha az előbb említett tényezők nem teljesülnek. Én ebben a világban élek." - mondja Spano.

(forrás)

***

Ha Te is kreatív, kihívásokkal teli mérnök állást keresel minőségi munkáltatónál, jó helyen jársz, mert a Schönherz Bázis épp azért jött létre, hogy Neked segítsen.

Gyere, nézz szét aktuális állásaink között!