SZAKDOLGOZAT Tuboly Tibor 2017

SZAKDOLGOZAT Tuboly Tibor 2017

Budapesti Corvinus Egyetem Gazdálkodástudományi Kar Logisztika és Ellátási Lánc Menedzsment Tanszék AZ AGILIS SZOFTVERFEJLESZTÉSI MÓDSZER BEMUTATÁSA Elmélet és gyakorlat az IBM példáján keresztül Készítette: Tuboly Tibor Logisztikai menedzsment 2017 Szakszeminárium vezető: Matyusz Zsolt

I. számú melléklet NYILATKOZAT SAJÁT MUNKÁRÓL Név: Tuboly Tibor E-mail cím: ttibi7@gmail.com NEPTUN kód : J6NPJ2 A szakdolgozat címe magyarul: Az agilis szoftverfejlesztési módszer bemutatása elmélet és gyakorlat az IBM példáján keresztül A szakdolgozat címe angolul: Introducing the agile software development method theory and practice through IBM s example Szakszeminárium-vezető (vagy konzulens) neve: Matyusz Zsolt Én, Tuboly Tibor (a hallgató neve) teljes felelősségem tudatában kijelentem, hogy a jelen szakdolgozatban szereplő minden szövegrész, ábra és táblázat az előírt szabályoknak megfelelően hivatkozott részek kivételével eredeti és kizárólag a saját munkám eredménye, más dokumentumra vagy közreműködőre nem támaszkodik. Budapest,.. hallgató aláírása Párhuzamos képzés esetén kitöltendő! Én,. (a hallgató neve) teljes felelősségem tudatában kijelentem, hogy a jelen szakdolgozatom és a párhuzamos képzésemen leadott szakdolgozatom közötti átfedés nem haladja meg a 10% százalékot, a Tanulmányi és Vizsgaszabályzat Gazdálkodástudományi kari mellékletének II. fejezetében a 6. (2) alapján. Tudomásul veszem, hogy amennyiben a szakfelelősök (vagy az általuk megjelölt személyek) 10%-nál nagyobb egyezőséget állapítanak meg, akkor a tanulmányi kötelezettségeimet nem teljesítettem, záróvizsgát nem tehetek. Budapest,.. hallgató aláírása TÉMAVEZETŐI NYILATKOZAT Alulírott,. konzulens kijelentem, hogy a fent megjelölt hallgató fentiek szerinti szakdolgozata (egyetemi/ mesterképzésben diplomamunkája) benyújtásra alkalmas és védésre ajánlom. Budapest,.. (a konzulens aláírása)

II. számú melléklet NYILATKOZAT A SZAKDOLGOZAT NYILVÁNOSSÁGÁRÓL Név (nyomtatott betűvel): Tuboly Tibor Alapszak, szak neve: Mesterszak, szak neve: Logisztikai menedzsment Egyetemi képzés, szak neve: Szakirányú továbbképzés, képzés neve: Egyéb képzés neve: Dolgozatom elektronikus változatának (pdf dokumentum, a megtekintés, a mentés és a nyomtatás engedélyezett, szerkesztés nem) nyilvánosságáról az alábbi lehetőségek közül kiválasztott hozzáférési szabályzat szerint rendelkezem. TELJES NYILVÁNOSSÁGGAL A könyvtári honlapon keresztül elérhető a Szakdolgozatok/TDK adatbázisban (http://szd.lib.unicorvinus.hu/), a világháló bármely pontjáról hozzáférhető, fentebb jellemzett pdf dokumentum formájában. KORLÁTOZOTT NYILVÁNOSSÁGGAL A könyvtári honlapon keresztül elérhető a Szakdolgozatok/TDK adatbázisban (http://szd.lib.unicorvinus.hu/), a kizárólag a Budapesti Corvinus Egyetem területéről hozzáférhető, fentebb jellemzett pdf dokumentum formájában. NEM NYILVÁNOS A dolgozat a BCE Központi Könyvtárának nyilvántartásában semmilyen formában (bibliográfiai leírás vagy teljes szöveges változat) nem szerepel. Budapest, a hallgató (szerző) aláírása

1 Tartalomjegyzék 1 Bevezetés... 1 1.1 A szoftverfejlesztés fontossága... 2 1.2 A szoftver és a fejlesztés... 3 1.2.1 A szoftver:... 3 1.2.2 A fejlesztés:... 3 2 Az agilis szoftverfejlesztés előzményei... 5 2.1 Az iteratív és inkrementális szoftverfejlesztés a XX. században... 5 2.2 A vízesés módszertan... 6 2.2.1 A vízesés modell fázisai:... 7 2.2.2 A vízesés megközelítés alkalmazása:... 9 2.2.3 A vízesés megközelítés előnyei:... 9 2.2.4 A hagyományos vízesés megközelítés hiányosságai, hátrányai... 10 2.3 Az agilis folyamatfejlesztés forrásai... 13 2.3.1 Lean fejlesztés:... 13 2.3.2 Kanban:... 16 2.3.3 Scrum:... 18 3 Az agilis fejlesztés... 23 3.1 Az Agilis Kiáltvány... 23 3.2 Szerepek és felelősségi körök az agilis fejlesztésben... 25 3.3 A leggyakrabban alkalmazott agilis technikák... 29 3.4 A sikeres agilis szervezetek jellemzői... 34 4 A vizsgált vállalat bemutatása... 46 4.1 Az IBM-ről általában... 46 4.2 Az IBM magyarországi tevékenysége... 48

4.3 Az IBM székesfehérvári működése... 49 5 Az agilis módszertan bevezetése a székesfehérvári IBM telephelyen... 51 5.1 Projekt a 2017-es bevezetésre... 51 5.1.1 A 2016-os év eredményei:... 51 5.1.2 A 2017-es év transzformációs tervei:... 53 5.2 Az IBM-nél leggyakrabban alkalmazott eszközök, melyek az agilis gyakorlatokat támogatják... 56 5.2.1 Mural... 56 5.2.2 Slack... 57 5.2.3 Trello... 58 5.3 Az agilis projekt bemutatása... 61 6 Összefoglalás... 66 7 Források... 68

Táblázatok, ábrák jegyzéke 1. táblázat: A vízesés és a scrum módszertan különbségei... 22 2. táblázat: A 2016-os év eredményei... 52 3. táblázat: A Mural, a Slack és a Trello alkalmazhatósága... 59 4. táblázat: Néhány agilis technika alkalmazhazósága... 60 5. táblázat: A vízesés és a scrum módszertan különbségei... 64 1. ábra: A vízesés modell szekvenciális felépítése... 7 2. ábra: A lean fejlesztés alapjai... 13 3. ábra: A kanban tábla... 17 4. ábra: A product owner mint összekötő szereplő... 28 5. ábra: Példa a visszatekintések esetén alkalmazott táblára... 31 6. ábra: Az empátia térkép... 33 7. ábra: A bürokratikus és agilis csapat különbségei... 37 8. ábra: A bürokratikus és agilis szervezet különbségei... 39 9. ábra: A szervezeti felépítés lehetőségei... 42 10. ábra: Az agilis transzformáció 4 lépése... 53 11. ábra: Az agilis transzformáció legfőbb szereplői... 55 12. ábra: Mural-ban készített empátia térkép... 56 13. ábra: A Slack... 57 14. ábra: A Trello tool... 58

1 Bevezetés Szakdolgozatom témája az agilis szoftverfejlesztési módszertan bemutatása. Egyre gyorsuló világunkban fontos, hogy a vállalatoknál tevékenykedő csoportok minél hatékonyabban oldják meg az előttük álló feladatokat. Ebben a világban szükség van olyan módszerekre, technikákra, mint amilyen az agilis fejlesztés is, amely rendszert visz a csoportok működésébe és elősegítik e cél elérését. Szakdolgozatom célja az agilis szoftverfejlesztés előzményeinek, kialakulásának és alapjainak elméleti bemutatása, melyet az IBM példáján keresztül gyakorlati szempontból is vizsgálok. Amikor a témámat kiválasztottam, igyekeztem olyan témában gondolkodni, amely az elméleti feltérképezés után gyakorlati hasznot is jelenthet, emellett szívesen elmélyülnék a témakörben. Mivel az agilis fejlesztés elméletéről a logisztikai menedzsment mesterképzés során már tanultam, továbbá az IBM keretein belül a munkám során szinte minden nap találkoztam ezzel a fejlesztési metódussal, így úgy döntöttem, hogy ebben a témában szeretném megírni a dolgozatomat. A kutatásom során elsőként összegyűjtöttem a releváns szakirodalmat arról, hogy mi vezetett az agilis folyamatfejlesztés kialakulásához, majd megvizsgáltam, hogy milyen alapokból táplálkozik ez a módszertan, ezt követően bemutattam magát az agilis fejlesztést. Az elméleti áttekintés után ismertettem az IBM-et, mint azt a vállalatot, amelynél a módszer gyakorlati megvalósulását elemeztem. Végül interjúk segítségével tanulmányoztam azt, hogy miként ültetik át a gyakorlatba az agilis folyamatfejlesztést az IBM székesfehérvári telephelyének keretein belül. 1

1.1 A szoftverfejlesztés fontossága A szoftverfejlesztés egy összetett folyamat, amely nagy mennyiségű időt, energiát és kreativitást igényel. A szoftver területen tevékenykedő kutatók, kezdetben mérnöki megközelítések alapján dolgoztak, melyek teljes mértékben azon a feltételezésen alapultak, miszerint a problémamegoldás egy mechanisztikus folyamat, ahol a lépéseket előre meg lehet határozni. Emellett, azt is gondolták, hogy egy racionális megközelítés az optimális megoldáshoz vezethet. Néhány elképzelés, amely mostanság látott napvilágot, alapvetően szembemegy ezekkel a nézőpontokkal. Mióta megépítették az első számítógépet, a szoftverek egyre inkább jelentős szerepet játszanak az életünkben. A szoftverek főként olyan számítógépes alkalmazások, melyeket a könyvelés, irodai automatizáció, oktatás vagy játékok terén használunk. A fogyasztók folyamatos igényt táplálnak a termékek újabb és újabb verzióira. Ez az igény nagy terhet rótt a szoftverfejlesztőkre, egyre gyorsabban, egyre több alkalmazást kellett készíteniük egyre kevesebb hibával. Emellett a verseny is nőtt, ami szintén nagy nyomást helyezett a szakemberekre. Az internet megjelentése, illetve az e-kereskedelemben használatos alkalmazások iránti növekvő kereslet továbbnövelte a szoftverek jelentőségét, illetve azok bonyolultságát. A játékrendszerek, mint például a Nintendo, Game Boy, Playstation növekvő népszerűségnek örvendtek és még most is népszerűek, több változatuk is létezik, sőt játékok ezrei kaphatók hozzájuk. Az ilyen rendszerek nem jöhettek volna létre azon előrelépések nélkül, melyek a szoftverfejlesztési technológiában történtek az elmúlt évtizedekben. A számítógépes alkalmazások megjelenése azonban csak a kezdet volt. Ahogy a számítógépek az életünk szerves részévé váltak, úgy a szoftverek is követték ezt. Olyan dolgok, melyeket gyakorlatilag minden nap használunk, legyen az óra, autó, porszívó, telefon, konyhai eszköz vagy sztereó rendszer, egyre nagyobb mértékben támaszkodnak kifinomult számítógépekre és szoftverrendszerekre. Sok esetben ezek a technológiák zökkenőmentesen integrálódnak az életünkbe és mi észre sem vesszük a jelenlétüket. Vannak hűtőszekrények, melyek képesek monitorozni az egyes ételek felhasználási trendjeit, sőt, képesek rendelni, ha valamelyik tételből alacsony mennyiség áll rendelkezésre. Ez csak egy példa arra, hogy a számítógépek és a szoftverek hogyan vezérlik az életünket. A számítógép mindenhol ott van, így a szoftverek is. A 2

fejlesztőknek folyamatosan meg kell vizsgálniuk eddigi feltételezéseik helyességét és alkalmazniuk kell új gondolkodásmódokat a jövőbeli sikerek reményében (Brown et al., 2004) 1.2 A szoftver és a fejlesztés 1.2.1 A szoftver: A beágyazott szoftver egy termék része, méghozzá egy olyan terméké, amely változik. A vállalati szoftver az üzleti folyamat része, egy olyan üzleti folyamaté, amely rendkívül összetett. Ha bonyolult számításokkal és komplikált információáramlással kell szembenéznie egy vállalatnak, akkor a szoftver feladata, hogy rendet tegyen ebben rendszerben. A szoftverek rengeteg feladatot látnak el, melyek változhatnak, így időnként bele kell nyúlni a már kész szoftverbe. Az idő múlásával a szoftverkészítés módosítása egyre nehezebb és költségesebb lesz. A változtatások növelik a komplexitást, a komplexitás merevvé teszi a kódbázist. A vállalatok gyakran szembesülnek azzal, hogy a szoftverfejlesztés egy kezelhetetlen kódhalmazzá válik. Ennek azonban nem szükséges megtörténnie. A legjobb szoftver termékek egy évtezeden át is megtalálhatóak a piacon, azonban élettartamuk során mindegyikük változik. Ezen termékek fejlesztési folyamatai úgy kerültek kialakításra, hogy a kódírás tolerálja a későbbi esetleges változtatásokat. 1.2.2 A fejlesztés: A fejlesztés az a folyamat, amely során az ötletek termékké alakulnak. Két irányzat is létezik, melyek másképpen tekintenek erre az átalakítási folyamatra. Az úgynevezett determinisztikus irányzat szerint először egy termékdefiníciót kell meghatározni, majd ebből kiindulva kell nekikezdeni a megvalósításnak. Az empirikus irányzat viszont egy magas szintű termék koncepciót alkot meg a folyamat kezdetén, amely visszajelzések alapját képezi majd. Ezek a visszajelzések alkalmasak a 3

tevékenységek módosítására, amelyeknek köszönhetően elkészül a koncepció megfelelő értelmezése. A Toyota fejlesztési rendszere az empirikus irányzatra épül. Elsőként a járműkoncepciót alkotják meg és nem a kreálnak exakt definíciót a kezdetekkor. Innen empirikus módon, tapasztalatokra építve alakítják ki a terméket a fejlesztési folyamat során. Egy jó példa erre a Prius megalkotása. A Prius egy hibrid autó, ám a termékkoncepció ezt egyáltalán nem kérte. A koncepció szerint egy olyan járművet kellett megalkotni, amely egy liter üzemanyaggal 20 kilométert képes megtenni. A Prius koncepciója azt is tartalmazta, hogy tágas legyen az utastér, viszont nem határozta meg a jármű pontos méreteit. A fejlesztési folyamat során került bele később a hibrid hajtómű, annak okán, hogy ez a motor volt képes az aggresszív üzemanyag célokat elérni. Minden fejlesztési folyamat, amely a változó környezettel foglalkozik vagy abban játszódik le, az empirikus irányzatra kell, hogy épüljön. Mivel a szoftverek olyan módon kerülnek kialakításra, hogy képesek legyenek alkalmazkodni a változásokhoz, így a szoftverfejlesztést is az empirikus irányzat alapelvei mentén érdemes kivitelezni (Poppendieck, 2006). 4

2 Az agilis szoftverfejlesztés előzményei A második fejezetben megvizsgálom azokat az irányvonalakat, amelyek hozzájárultak az agilis fejlesztés kialakulásához. Elsőként feltárom röviden az iteratív és inkrementális szoftverfejlesztés fontosabb XX. századi történéseit, azután részletesen kitérek a vízesés megközelítésre, amely az egyik legjelentősebb szoftverfejlesztési módszertan és amelynek a hiányosságai nagyban hozzájárultak az agilis megközelítés kialakulásához. Végül két fejlesztési irányzatot és egy eszközt mutatok be, amelyből az agilis szoftverfejlesztés merített. 2.1 Az iteratív és inkrementális szoftverfejlesztés a XX. században Az iteratív és inkrementális szoftverfejlesztés (IID - Iterative and Incremental Development) egy olyan szoftverfejlesztési módszer, amely a fejlesztendő termék esetén a ciklikusságot, a fokozatos javítást és tökéletesítést helyezi előtérbe. Az iteratív és inkrementális fejlesztésnél az első lépés egy terv elkészítése, ezt iteratív fejlesztési ciklusok követik, ahol folyamatos a visszajelzés a felhasználó felől. Minden ciklus végén keletkezik egyfajta hozadék, félkésztermék (Technopedia, 2017). Az iteratív és inkrementális szoftverfejlesztés az 1930-as években jelent meg elsőként. Ekkora a Bell Labs nevezetű cégnél Walter Shewhart alkalmazott rövid plando-study-act (PDSA) ciklusokat a minőség javítása érdekében (Shewhart, 1986). Az 1940-es években W. Edwards Deming kezdte el a PDSA ciklus promótálását szélesebb körben, aki a minőségfejlesztés terén ismert guruként tevékenykedett (Deming, 1982). Az 1950-es években az X-15-ös hiperszonikus repülőgép fejlesztése egy mérföldkő volt az IID történetében. Habár nem szoftver projekt volt, az IID nagyban hozzájárult az X-15 sikeréhez (Dana, 1993). Az 1960-as években indul el a NASA irányításával az úgynevezett Project Mercury, amely már az IID alapjain nyugodott. A projekt során nagyon rövid, félnapos 5

iterációkat alkalmaztak. A fejlesztőcsapat végezte a változtatások technikai felülvizsgálatát, valamint ez a csapat alkalmazta az úgynevezett Extreme Programming (röviden XP) gyakorlatot a tesztelés során (Larman et. al., 2003). Az XP egy olyan szoftverfejlesztési módszertan, amely a hagyományos megközelítésekkel szemben az alkalmazkodásban látja a nagyobb értéket és nem pedig az előrejelezhetőségben (SelectBS, é.n.) Az 1970-es években Winston Royce révén vált ismertté az úgynevezett vízesés modell, mely a korszak leghíresebb folyamatfejlesztési módszertanává vált (Royce, 1970). 2.2 A vízesés módszertan A vízesés modell volt az egyik elsőként létrehozott folyamatmodell. Nevezik még lineár-szekvenciális életciklus modellnek is. A vízesés modell a szoftverfejlesztést lineáris-szekvenciális folyamatként illusztrálja, innen ered a lineáris-szekvenciális életciklus modell elnevezés. A használata és megértése rendkívül egyszerű. A vízesés modell a folyamatot fázisokra bontja, ezeket a fázisokat az 1. ábra szemlélteti. Minden egyes fázisnak be kell fejeződnie ahhoz, hogy a követő fázis elkezdődhessen, nincs átfedés köztük. Mivel a vízesés megközelítés esetén nincs átfedés az egyes folyamatfázisok között, ezért gyakran a megelőző fázis outputja szolgál a követő fázis inputjaként (Tutorialspoint, 2017). 6

1. ábra: A vízesés modell szekvenciális felépítése Forrás: Saját készítésű ábra, Tutorialspoint, 2017. 2.2.1 A vízesés modell fázisai: 1. Felmérés: Az első fázis során meg kell érteni, hogy mit kell megtervezni, ehhez milyen funkciók, célok, stb. kapcsolódnak. Ha nem tudjuk, hogy mit szeretnénk létrehozni, nem tudunk továbbmenni a projekttel. Még egy egészen rövid kód megírása, mint például két integer szám összeadása is úgy történik, hogy tudjuk nagyjából mi lesz a kimenetel. Ennél a pontnál listázzuk a követelményeket, igényeket, melyeket a jövőben kielégít majd a szoftverünk. Ezután ezeket az igényeket a programozó csapat elé tárjuk. Ha ez a fázis sikeresen lezárult, akkor ez már egyfajta zökkenőmentes működést biztosít a többi fázis számára, mivel a programozókat már nem terheli az, hogy a követelmények megváltoznak a jövőben. 7

2. Elemzés: A követelmények alapján egy megfelelő szoftver és/vagy hardver szükséges a projekt befejezéséhez, amit ebben a fázisban elemeznek. Olyan fontos pontokról történik döntés ebben a szekcióban, mint például az, hogy milyen programnyelvet kellene használni a szoftvertervezés során vagy milyen adatbázisrendszert alkalmazzunk a szoftver működtetéséhez. 3. Tervezés: A program vagy a szoftverkód algoritmusa, folyamatábrája ebben a szakaszban készül el. Ez egy igen fontos fázis, mivel a következő két szakasz erre épül. A megfelelő tervezés biztosítja a következő állomások precíz végrehajtását. Ha a tervezési szakaszban további követelményekre derül fény, melyek a kód tervezéséhez szükségesek, akkor visszalépés történik a második fázishoz, majd a tervezési fázist az új források alapján hajtják végre. 4. Kódolás: Az elkészített algoritmus vagy folyamatábra alapján elvégzik a szoftver tényleges kódolását. Ez az a szakasz, ahol az alkalmazás ötlete, folyamatábrája testet ölt. A korábbi fázisok biztosítják a megfelelő alapot ehhez a részhez. 5. Tesztelés: Miután az alkalmazás kódolása befejeződik, a megírt kód tesztelése következik. A teszt során ellenőrzik, hogy került-e hiba a szoftverbe, illetve megvizsgálják, hogy a specifikációknak megfelelően készült-e el. Ennek a fázisnak a helyes végrehajtása biztosítja, hogy az ügyfél érdekelt-e a kész szoftverben, illetve elégedett-e a késztermékkel. Ha bármiféle hiba jelentkezik, akkor a fejlesztési folyamat újra visszatér a tervezési szintre, majd végrehajtják a szükséges változtatásokat és következhet újra a kódolás és a tervezés. 6. Alkalmazás: Ha befejeződött az alkalmazás kódolása, illetve a megírt kód tesztelése, akkor következik a vízesés modell utolsó állomása a szoftverfejlesztésben. A korábbi fázisok 8

precíz végrehajtása elégedett ügyfelet eredményez. Ebben a fázisban lehet, hogy adni kell az ügyfélnek némi támogatást az elkészült szoftver mellé. Ha a kliens további finomításokat kér a szoftverre, akkor a fejlesztési folyamat újrakezdődik, egészen az első fázistól kezdődően (McCormick, 2012). 2.2.2 A vízesés megközelítés alkalmazása: A különböző szoftverfejlesztési munkák esetén eltérőek a külső és belső tényezők, így ennek megfelelő megközelítést ajánlatos követni. A vízesés modellt javasolt használni, ha: - a követelmények jól dokumentáltak, világosak és nem változnak a folyamat során - van egy egzakt termékdefiníció - a technológia érthető és nem változik dinamikusan - nincsenek félreérthető, kétértelmű pontok a követelmények között - bőséges forrás, valamint megfelelő szakemberek állnak rendelkezésre - a projekt rövid 2.2.3 A vízesés megközelítés előnyei: A vízesés fejlesztés előnye, hogy lehetővé teszi a feladatok lebontását és az irányítás összehangolását. Összeállítható egy ütemterv határidőkkel a fejlesztés minden fázisa számára és a termék végigmehet a fejlesztési folyamat mindenegyes szakaszán. A fejlesztés a koncepció kialakításától kezdve a tervezésen, megvalósításon, tesztelésen, telepítésen, hibaelhárításon keresztül végül a működtetés és fenntartás szakaszába jut. A fázisok végrehajtásának szigorú rendje van (Tutorilaspoint, 2017). Ez a következőket jelenti: - egyszerű a kezelése a modell merevsége miatt, minden fázisnak saját eredménye és felülvizsgálati folyamata van - a fázisok jól definiáltak - jól érthető mérföldköveket tartalmaz 9

- könnyű a feladatok kiosztása - a folyamat és az eredmények jól dokumentáltak 2.2.4 A hagyományos vízesés megközelítés hiányosságai, hátrányai Mik a követelmények, igények a szoftverek fejlesztésénél? Az érintett felek szempontjából a rendszer jellemzői és specifikációi lehetnek azok. A követelmények meghatározzák, hogy a fejlesztők mit hozhatnak létre. Például a a rendszernek rendelkeznie kell egy website-tal, ahol e-kereskedelmet lehet lebonyolítani, ami tegyük fel, hogy 10 ezer vásárlást is fel tud dolgozni óránként, illetve hozzáférhető az esetek 99,9 százalékában. A vízesés módszertan egyik legnagyobb problémája, hogy arra a feltételezésre épül, miszerint a projekt követelményeit a kezdetekkor pontosan meg lehet határozni. Az elemzők hetekig, hónapokig szenvednek, hogy összegyűjtsenek mindent, ami igényként előfordulhat, majd egy specifikációt állítanak elő, amit SRS-nek neveznek (Software Requirement Specification a szoftverkövetelmények specifikációja). Miután ez készen van, az elemzők az SRS-t továbbítják a fejlesztőknek, ők maguk pedig belekezdenek egy másik projektbe (Szalvay, 2004). Képzeljünk el egy olyan forgatókönyvet, ahol a szoftverfejlesztők egy kritikus szoftverrendszert alakítanak ki. Meg lehet határozni egy csapásra mindenegyes tényezőt, amelyekre a fejlesztőknek szüksége van? A kezdetektők fogva rengeteg aspektust kellene figyelembe venni: üzleti szabályok, kivételek, egyidejű felhasználói támogatás, böngésző vagy operációs rendszer támogatás, felhasználói interface szabályok, felhasználói szerepkörök és korlátozások. Valójában elkerülhetetlen, hogy a kezdetekkor ne legyen olyan tényező, amely kimarad, akár abból az egyszerű okból kifolyólag is, hogy az érdekelt felek nem mondják el a fejlesztőknek a projekt elején. Ez azt jelenti, hogy a követelmények szükséges változása esetén az egész projektet át kell tervezni, amely igen költséges lehet. A követelmények változása a komplex tervekre drámai hatással lehet, ami a megvalósítási és tesztfázist befolyásolhatja. A változtatás költsége a vízesés projekteknél exponenciálísan növekszik az idővel, mivel a fejlesztők kénytelenek már a projekt elején meghozni az összes döntésüket (Beck, 2000). 10

Mi van, ha az üzleti igények még kialakulóban vannak és az elvárt rendszer bizonyos aspektusai gyorsan változnak vagy nem lehet meghatározni még őket? Az üzleti célok és az üzleti környezet gyorsan változik, főként most, amikor az azonnali információ idejét éljük. Vajon megengedhető egy olyan merev projekthez való ragaszkodás, ahol a változtatás költségei exponenciálisan növekednek? A piacok arra sarkallják a szoftverfejlesztőket, hogy rugalmas fejlesztési tervekkel álljanak elő, ami csökkenti a változtatás költségeit. Az embereknek látniuk és érezniük kell valamit, még mielőtt tudják, hogy akarják. A Tudom, ha látom tövény szerint a szoftverek vásárlói jobban definiálják azt, amit szeretnének eredményként látni, ha előtte láthatják, kipróbálhatják. Az egész vízesés folyamat hasonlít egy vak rajzolásra. Ha rajzolás közben becsukjuk a szemünket, nem tudjuk lerajzolni azt, amit nyitott szemmel készítenénk. Úgy kell meghatároznunk a rendszer alapjait, hogy nem látjuk a fejlődést, nem változtathatjuk meg a követelményeket. A vízesés egy úgynevezett over the fence megközelítés: az igényeket megkapjuk a felhasználóktól és rövid idő múlva már be is kell mutatni a kész eredményt. Ez teljesen természetellenes, mert a vevőknek is nehéz az elvárt szoftvert tökéletesen leírni, ha nem látják a fejlődést és a haladást. A meghatározhatatlan, változó követelmények nagy kihívást jelentenek a vízesés projektek számára, mert minden igényt a projekt indításának kezdetén meg kell határozni, ami a költséges módosítások kockázatát rejti magában (Szalvay, 2004). A szoftverfejlesztés egy igen komplex terület, sok a változó, ami a rendszerre hatással lehet. Minden szoftver tökéletlen, mert nem lehet matematikai és fizikai bizonyosságra építeni. Míg egy híd építése matematikai és fizikai törvényeken alapul, addig a szoftverfejlesztésnek nincsenek törvényei, amelyekre építeni lehet. Ennek eredményeképpen egy szoftver gyakran hibás vagy nem eléggé optimalizált. Azt is figyelembe kell venni, hogy a szoftverprojektek építőkövei maguk is szoftverrendszerek (például programnyelvek, adatbázis-platformok, stb.), ezek szintén tartalmazhatnak hibákat és nem lehet támaszkodniuk rájuk biztonsággal. Mivel a szoftverfejlesztés alapjai eredendően instabilak és megbízhatatlanok, a szervezetek által fejlesztett szoftvereknek olyan változókat kell ismerniük, melyek nagyrészt a menedzsment kontrollon túl nyúlnak. Ezért mondhatjuk, hogy a szoftverfejlesztés jobban hasonlít egy új termék létrehozásához szükséges kutatásra, mint egy összeszerelő sor segítségével történő gyártásra. A szoftverfejlesztés egy innováció, felfedezés és művészet is egyben, 11

minden projekt új kihívásokat állít, amelyeket nem lehet egy csapásra megoldani (Schwaber et. al., 2001). A vízesés módszer feltételezi, hogy a kezdeti tervezés elég arra, hogy figyelembe vegyünk minden változót, amely érinti a fejlesztési folyamatot. Valójában a vízesés projektek során nagy erőfeszítéseket tesznek arra, hogy felmérjenek minden kockázatot és csökkentsék azokat. Ennek ellenére vajon fel lehet becsülni minden változót, ami hatással van a szofver projektre? Az empirikus tapasztalatok alapján nem (Szalvay, 2004). Emellett egyértelmű, hogy a ciklus legutolsó pontjáig nem jön létre működő szoftver. Gondot okozhat az is, hogy nehéz mérni a haladást a fázisok között, valamint magas a kockázat és a bizonytalanság a folyamat során. Összességében kijelenthető, hogy nem alkalmas komplex és hosszú folyamatok esetén (Tutorialspoint, 2017). Ezek a hiányosságok vezettek ahhoz, hogy új fejlesztési metódus kialakítására került sor. A következő alfejezetben bemutatom, hogy mely irányzatokból merített az agilis fejlesztés. 12

2.3 Az agilis folyamatfejlesztés forrásai Az agilis szoftverfejlesztés számos módszertani forrásból táplálkozik. Rigby et. al. (2016) ezek közül hármat emel ki: - lean: a pazarlások folyamatos megszüntetését hangsúlyozza - kanban: az átfutási idők és a munkamennyiség csökkentéséhez járul hozzá - scrum: a kreatív és adaptív csoportmunkát helyezi előtérbe a komplex problémák megoldására 2.3.1 Lean fejlesztés: A lean fejlesztés egy end-to-end fókuszú termékfejlesztési paradigma, ahol a cél az érték előállítása a vevő számára, a pazarlás megszüntetése az értékáram optimalizálása valamint a folyamatos fejlesztés. A lean gondolkodásmód több iparágba is beivódott az idők folyamán. Kezdetben a gyártásban alkalmazták, ahol a csapatok felhatalmazása, pazarlás csökkentése, munkafolyamatok optimalizálása, valamint a piaci és vevői igény kielégítése volt az elsődleges cél, melyet a 2. ábra mutat be (Ebert et. al. 2012). 2. ábra: A lean fejlesztés alapjai Forrás: Ebert et. al., 2012. 13

Poppendieck (2003) a következő pontokat emelte ki, mint a lean fejlesztés alapelvei: - Pazarlás megszüntetése: minden pazarlásnak számít, ami nem ad értéket a termékhez vagy a vevő nem érzékeli azt értékként. A lean gondolkodásmódban a pazarlás meghatározása kritikus pont. Ha egy alkatrész a polcon porosodik, akkor az pazarlás. Ha a fejlesztési ciklus során egy könyvben összegyűjtik a fejlesztés követelményeit, amely később csak porfogóként szolgál, akkor az pazarlás. Ha egy gyár több terméket állít elő, mint amennyi az adott pillanatban szükséges, akkor az pazarlás. Egy gyárban a termékek mozgatása pazarlás. A termékfejlesztés során a fejlesztés átruházása egyik csoportról a másikra pazarlás. Az ideális, ha kitaláljuk, hogy a vevő mit szeretne, majd kifejlesztjük és pontosan azt szállítjuk, amit szeretne, gyakorlatilag azonnal. Bármi, ami a gyors vevői igénykielégítés előtt akadályként megjelenik, az pazarlásnak számít. - A tanulás erősítése: A fejlesztés és a termelés eltérnek egymástól, így a fejlesztés lean megközelítése is eltér a lean termelési gyakorlattól. Főzésből származó hasonlattal élve a fejlesztés olyan, mint egy recept megírása, míg a termelés inkább hasonlít egy ételnek az elkészítéséhez. A receptet tapasztalt séfek írják, akik ösztönösen tudják, hogy mi működik és mi nem, illetve képesek módosítani az összetevőkön, hogy megfeleljen az étel az adott alkalomnak. Még a legjobb séfek sem készítenek tökéletes receptet elsőre, iterációk során egyre közelebb jutnak a legjobb recepthez, amely ízletes és könnyű reprodukálni. A szoftverfejlesztés is egy hasonló tanulási folyamat, azonban itt még egy extra nehézség az is, hogy a fejlesztői csapat nagy méretű és az eredmény is sokkal komplexebb, mint egy recept. A legjobb módja a szoftverfejlesztés környezetének a javításának a tanulás erősítése. - A döntéshozatal késleltetése: a döntéshozatal késleletetése hatékony, mivel lehetőség alapú megközelítést tesz lehetővé. Azzal, hogy több opciót is kialakítanak, a piacok halogatják a döntés meghozatalát, amíg a jövő minél közelebb nem kerül és könnyebb megjósolni azt. A döntések elhalasztása 14

értékes, mivel jobb döntés születhet, amely tényeken alapul, nem pedig spekuláción. Egy fejlődő piacon a tervezési lehetőségek terén történő el nem köteleződés értékes. - Olyan gyorsan szállítani, mint amennyire lehet: egészen mostanáig a gyors szoftverfejlesztést nem értékelték. Eddig az óvatos, hibamentes megközelítés volt a legfontosabb. A minőség mellé mára már felzárkózott a sebesség is a legfontosabb költségtényezők közé. A gyors fejlesztésnek számos előnye van. Sebesség nélkül nem lehet a döntéshozatalt késleltetni, nincs megbízható visszacsatolás. A fejlesztés során a felfedezési ciklus kritikus a tanulás szempontjából: tervezés, végrehatjás, visszacsatolás, javítás. Minél rövidebben ezek a ciklusok, annál többet lehet tanulni. A sebesség biztosítja azt, hogy a vevő azt kapja, amit most akar és nem azt, amit tegnap akart. A sebességnek köszönhetően késleltethető a vevői elkölteleződés mindaddig, amíg pontosan nem tudja a vevő, hogy mit szeretne eredményként. Az értékáram tömörítése a lehetőségeknek megfelelően egy alapvető lean stratégia a pazarlás megszüntetésére. - A csapat felhatalmazása: a tökéletes kivitelezés a részletekben rejlik és senki nem ismeri annyira a részleteket, mint azok az emberek, akik az adott munkafolyamatot végzik. A fejlesztők bevonása a technikai döntések meghozalatába lényeges a kiváló teljesítmény elérése során. Mikor ezek az emberek megfelelő szakértelemmel rendelkeznek és vezető segíti az útjukat, akkor jobb technikai és folyamatdöntéseket hoznak. Mivel a döntéseket késleltetve hozzák és a végrehajtás gyors, nem lehetséges, hogy egy ember csak egy központi irodából irányítsa a dolgozókat. A lean gyakorlatok pull technikákat alkalmaznak a munkafolyamat ütemezésére, valamint ezek a technikák segítenek abban, hogy a dolgozók egymás között tudjanak arról, hogy mit kell pontosan csinálniuk. A lean szoftverfejlesztésben a pull mechanizmus egy megállapodás is egyben arról, hogy szoftver egyre kifinomultabb verzióját szállítják meghatározott időközönként. A dolgozók közti jelátvitel grafikonok, napi meetingek, gyakori integráció ás átfogó tesztelés formájában történik. 15

- Integritás beépítése: a koncepcionális integritás az, amikor a rendszer központi koncepciói összedolgoznak, mint egy egységes egész. Ez egy kritikus tényező az észlelt integritás létrehozásában. A szoftvereknek egy további integritásszintre is szükségük van, fenn kell tartaniuk a hasznosságukat az idő múltával. A szoftverektől elvárt, hogy fejlődjenek idővel, mivel alkalmazkodniuk kell a jövőhöz. Ha egy szoftver esetén, ahol megfigyelhető az integritás, akkor jellemzően van egy koherens architektúra, magas használhatósági fokkal rendelkezik, mivel fenntartható, alkalmazkodó és bővíthető. A kutatások azt mutatják, hogy az integritás a következőkből ered: bölcs vezetés, megfelelő szakértelem, hatékony kommunikáció, a folyamatok, eljárások és mérések nem helyettesíthetőek megfelelően. - Lásd az egészet: a komplex rendszerek integritása mély szakértelmet kíván a különböző területeken. Az egyik legnehezebben kezelhető probléma az, hogy a termék teljesítményét maximalizálják ahelyett, hogy az egész rendszer teljesítményére fókuszálnának. Mikor az egyének és a szervezetek az alapján vannak értékelve, hogy milyen a saját hozzáadott értékük, nem pedig milyen a rendszer teljesítménye, szuboptimalizáció léphet fel. Ez a hatás még jelentősebb, ha két cég köt szerződést, mivel ekkor mindkét cég a saját maga teljesítményét szeretné maximalizálni. Igazi kihívás olyan gyakorlatok alkalmazása, melyek megakadályozzák a szuboptimalizációt. 2.3.2 Kanban: A kanban a lean termelésnél használatos technika (Intrieri, 2013), egy olyan eszköz, ami segít az anyag, információ stb. áramlás kezelésében a folyamat során. Ha nem áll rendelkezésre, legyen az dokumentum, alapanyag, információ, az késésekhez vezethet, ám ha túl sok áll a rendelkezésre, az már egyfajta pazarlás. A kanban egy olyan eszköz, amely segít a munkafolyamat kezelésében (Klipp, é.n.). 16

A kanban alapértékei: - A munkafolyamat vizualizálása: a munkafolyamatot részekre bontják, az egyes részeket kártyákra írják, majd a falra helyezik őket. Ahogy azt a 3. ábra mutatja, a falon különböző oszlopok szerepelnek, melyek a munkafolyamat egyes állomásait jelképezik. Abba a munkafolyamatot jelképező oszlopba kell helyezni a kártyát, ahol az adott termék éppen tart (Kniberg et al., 2010). A folyamat vizuális megjelenítésével pontosan látható, hogy halad a folyamat. Minél komplexebb a folyamat, annál hasznosabb és fontosabb a vizualitás, mert így egy bonyolult folyamatot is át lehet látni egy pillanat alatt (Klipp, é.n.). - A folyamatban lévő termékek korlátozása: minden egyes munkaállomáson explicit korlátokat kell megadni, melyek mutatják, hogy mennyi termék lehet az adott munkaállomáson (Kniberg et al., 2010). A kevesebb néha több. Van egy határ amit még képes a rendszer nagyon jól kezelni, néha ez a határ sokkal alacsonyabb, mint hinnénk. Lehet a folyamat komplex vagy egyszerű, létezik egy optimális mennyiségű munka, amit anélkül el lehet végezni, hogy beáldoznánk vele a hatékonyságot. A kanban mérőszámai segítenek megtalálni az optimumot (Klipp, é.n.). - Az átfutási idő mérése: a folyamatot addig kell optimalizálni, amíg az átfutási idő minimális nem lesz, illetve ameddig nem lehet azt pontosan előre jelezni (Kniberg et al., 2010). A fejlődést mindig objektív mérőszámok segítségével kell megítélni (Klipp, é.n.). 3. ábra: A kanban tábla Forrás: Pinterest, 2017. 17

2.3.3 Scrum: A scrum egy olyan folyamat-keretrendszer, melyet már az 1990-es évek elejétől kezdve használnak a komplex termékfejlesztés kezelésére. A scrum nem egy folyamat és nem is egy technika, hanem inkább egy olyan keretrendszer, amely során különböző folyamatokat és technikákat lehet alkalmazni. A scrum keretrendszere scrum csapatokból, illetve ezekhez a csapatokhoz kapcsolódó szerepekből, eseményekből, tárgyakból és szabályokból áll. A scrum empirikus folyamatellenőrzési elméleten nyugszik, ami azt takarja, hogy tudás és a döntéshozás tapasztalatokon alapszik. A scrum iteratív, inkrementális megközelítést alkalmaz a kockázatcsökkentés és az előre jelzés optimalizálása érdekében. A scrum alapjait három pillér képezi: - Átláthatóság: azoknak, akik a folyamat eredményéért felelősek, a folyamat jelentős aspektusait látniuk kell. Ezeket az aspektusokat egy közös sztenderd alapján meg kell határozni, mivel ez biztosítja, hogy a résztvevők ugyanazt értik a látottak alatt. - Ellenőrzés: a scrum-ot használóknak gyakran meg kell vizsgálniuk a folyamatot és fel kell deríteniük a nemkívánatos elemeket. Az ellenőrzéseket nem szabad gyakran végezni, mivel az hátráltatná a munkát. - Alkalmazkodás: ha egy ellenőrzést végző személy észleli, hogy a folyamat bizonyos elemei eltérnek az elfogadottól, így a termék elfogadhatatlanná válik, akkor a folyamaton módosításokat kell végrehajtani. Ezeket a módosításokat minél előbb el kell végezni, hogy minimalizáljuk a még nagyon eltérést. A scrum csapatok köré szerveződik, amelyek általában egy product owner-ből, egy scrum master-ből és a fejlesztő csapatból állnak. A scrum csapatok önszerveződő, keretszfunkcionális csoportok. Az önszerveződő csapat általában arra fekteti a hangsúlyt, hogy minél jobban végrehatjsa a munkát, nem pedig arra, hogy megfeleljenek egy külső irányítás elvárásainak. A keresztfunkcionális csapatok úgy alakulnak meg, hogy meglegyen minden szükséges kompetencia a munka elvégzéséhez, ne kelljen csapaton kívüli erőforrást igénybe venni. 18

A product owner felel azért, hogy a termékből a maximumot hozzák ki, illetve ő felelős a fejlesztő csapat munkájáért. A végrehajtás módja különbözik attól függően, hogy milyen szervezetben kell a feladatokat végrehajtani, illetve milyen csapatokkal, egyénekkel kell együtt dolgozni (Schwaber et. at., 2013). A fejlesztő csapat olyan szakemberekből áll, akik azért dolgoznak, hogy egy késztermék jöjjön létre minden sprint végén. A sprint egy olyan meghatározott periódus, amely során egy bizonyos munkafolyamatot be kell fejezni (TechTarget, 2017). Keresztfunkcionalitás jellemzi a csapatot, mivel fontos, hogy a csapat rendelkezzen mindazon képességekkel, melyek a feladat végrehajtásához szükségesek. A scrum szerint a fejlesztő csapatot nem szabad részekre tagolni, illetve annak ellenére, hogy a tagok eltérő képességekkel rendelkeznek, a fejlesztés különböző területeire fókuszálnak, a felelősséget az egész csapat viseli. Ami a csapat létszámát illeti, általában a három főnél kisebb csoportok nem képesek igazán hatékonyan működni, ekkor alacsony az interakció foka, valamint ebben az esetben képességbeli problémák léphetnek fel. Amennyiben túl sok tagja van egy csapatnak, akkor a koordináció okozhat nehézséget és a komplexitás is növekszik, így kilenc főnél nagyobb csoportokat sem ajánlatos képezni. A scrum master felelős azért, hogy a scrum alapelveit, szabályait megértsék, illetve a scrum gyakorlatokat megfelelően használják a csoportok. A scrum master segíti a product ownert, például technikákat keres a megfelelő product backlog kezeléshez. A product backlog gyakorlatilag a folyamat során elvégzendő feladatokat tartalmazza priorizálva. A scrum master a fejlesztői csapatot is szolgálja: - segít a csapatnak a magas értékű terméket készíteni - tréningeli a csapatot az önszerveződésre és a keresztfunkcionalitásra - eseményeket szervez - elhárítja azokat az akadályokat, melyek a csapat előtt állnak 19

A fejlesztői csapat és a product owner mellett segíti a szervezetet is: - felkészíti a szervezetet a scrum-ra való átállásra - a scrum szervezeten belüli bevezetését előkészíti - segíti az érintetteket, munkavállalókat, hogy megértsék a scrum alapjait - javítja a scrum csapat hatékonyságát A scrum előír bizonyos eseményeket, melyeknek az a célja, hogy rendszerességet hozzanak a folyamatba, illetve hogy csökkentsék a szükségtelen találkozók számát. Az eseményeknek mindig van egy meghatározott időkeretük. Az időkeretet úgy alakítják ki, hogy meglegyen a megfelelő idő a feladatok elvégzésére, de ne töltsenek el felesleges időt a folyamattal, mivel az pazarlás. A scrum lelke az úgynevezett sprint. Az egész fejlesztési folyamatot felbontják folyamategységekre, melyeknek van egy saját időkeretük. Ezek az egységek a sprintek. Minden sprint esetén van egy speciális cél, amit el kell érni. A sprintek maximum egy hónap hosszúságúak lehetnek. A segítségükkel javul az egész folyamat előrejelezhetősége, ezáltal csökken a költségbeli kockázat is (Schwaber et. at., 2013). A scrum során kialakítandó termékre a rugalmasság a jellemző, melyet számos környezeti tényező befolyásol, például a rendelkezésre álló idő, a költség vagy a funkcionalitás. Emellett még hatással van a projektre a piaci intelligencia, az ügyfélkapcsolat, valamint a fejlesztői készségek is. A környezetre való reakció miatt a folyamat során gyakran változtatni kell a terméken. A scrum projektekre a következő pontok jellemzőek: - rugalmas termék az elkészítendő tartalmat a környezet befolyásolja - rugalmas ütemterv a terméket akár korábban vagy akár később is igényelheti a vevő a tervezettnél - kis csapatok általában nem több, mint hat fő - egy projekten több csapat dolgozik - gyakori felülvizsgálat a csapat munkáját olyan gyakran vizsgálják felül, mint amennyire azt a környezeti komplexitás és a kockázat megköveteli (általában 1-4 hetes ciklusok vannak) 20

- együttműködés a csapaton belüli és kívüli érdekeltekkel - célorientált minden csapat meghatározott célok elérésére törekszik A scrum módszertan előnyei: A hagyományos fejlesztési módszereket úgy tervezték, hogy csak a folyamat elején képes reagálni az esetleges változásokra. A scrum módszertan ezzel szemben az egész folyamat során rugalmas etéren. Olyan ellenőrzési mechanizmusokat építenek be a scrum projektekben, melyek képesek kezelni a változókat a folyamat alatt, ennek köszönhetően a szervezet bármikor képes a terméken változtatni, hogy a legmegfelelőbb produktum jöjjön létre a fejlesztés végére. A scrum egyfajta szabadságot biztosít a fejlesztők számára. Szabadon dolgozhatnak megoldásokon a projekt során, mivel változik a környezet, illetve a fejlesztők a folyamat során tanulnak is. A kis, kollaboratív csapatok meg tudják osztani a tacit tudásukat egymással a folyamat végzése alatt. A scrum egy kiváló tanulási környezetet teremt a résztvevők számára (Schwaber, 1998). A vízesés és scrum módszertan különbségei: A két modell számos pontban eltér egymástól, például a vízesés modell már a projekt elején definiálja az egész folyamatot, míg a scrum módszertannál csak a folyamat bizonyos fázisai kerülnek meghatározásra. Ezeket az eltéréseket az 1. táblázat mutatja. 21

1. táblázat: A vízesés és a scrum módszertan különbségei Vízesés Scrum Folyamat előre definiálása Szükséges Csak a tervezés és a zárás Végtermék Projektköltség Befejezés dátuma A tervezési fázis alapján meghatározott A tervezési fázis alapján meghatározott A tervezési fázis alapján meghatározott A projekt során alakul ki A projekt során alakul ki A projekt során alakul ki Környezetre való reagálás Csak a tervezés során Az egész folyamat során Csapat rugalmasság, Korlátozott Korlátlan kreativitás Tudástranszfer A projektet megelőző tréning során Csapatmunkában az egész folyamat során A siker valószínűsége Alacsony Magas Forrás: Schwaber, 1998. 22

3 Az agilis fejlesztés Miután ismeretettem azokat a tényezőket, melyek közreműködtek az agilis fejlesztés kialakulásában, a következő fejezetben bemutatom az agilis módszertan alapjait. Elsőként kitérek az Agilis Kiáltványra, amely az agilis megközelítés alapköveként szolgált, majd megvizsgálom, hogy milyen szerepek és technikák jelennek meg ennél a fejlesztési irányzatnál. Végül pedig kitérek arra, hogy mik azok a pontok, amelyek betartásával, figyelembe vételével egy szervezet sikeresen alkalmazhatja az agilis módszertant. 3.1 Az Agilis Kiáltvány Ahogy azt Günal (2012) megfogalmazta, 2001 februárjában tizenhét szakember, akik a programozási módszerek tudósai voltak, összegyűltek egy megbeszélés keretében Utah-ban, hogy megvitassák a jelenleg használatos módszerekkel kapcsolatos problémákat, illetve azt, hogyan küzdhetnék le ezeket, valamint mik azok az értékek, melyek magas szinten támogatják az agilis szoftverfejlesztést. A megbeszélés alapján kiadták az Agilis Kiáltványt, melyben négy alapvető értéket emeltek ki: 1. Az egyének és az interakciók fontosabbak, mint a folyamatok és az eszközök. 2. A működő szoftver fontosabb, mint az átfogó dokumentáció. 3. A vevővel való együttműködés fontosabb, mint a szerződések tárgyalása. 4. A változásokra való reagálás fontosabb, mint a tervek követése. Ezzel a négy értékkel az Agilis Kiáltvány egyértelműen megfogalmazza, mik azok a tényezők, melyek fontosak a folyamatfejlesztés terén történő előrelépés során. Az Agilis Kiáltvány létrejötte segít abban, hogy megérthessük és követhessük az agilis szoftverfejlesztést, illetve elkülöníthessük a többi hagyományos módszertől. 23

1. Az egyének és az interakciók fontosabbak, mint a folyamatok és az eszközök. Az Agilis Kiáltvány első pontja kifejezi, hogy az emberek nagyobb jelentősséggel bírnak mint bizonyos folyamatok és eszközök. A hagyományos módszerek jelentős része, mint például a vízesés megközelítés vagy a CMM (Capability Maturity Model), olyan folyamatokkal rendelkeznek, melyek szereporientáltak. Ez alapvetően azt jelenti, hogy az emberek helyettesíthetőek, amely még inkább kellemetlenül érinti a szoftverek fejlesztését, ahol az egyéniség elengedhetetlen tényező. Ennek következtében az emberek pótlása, helyettesítése nem egyszerű a szoftveres környezetben. Ez arra is rámutat, hogy az egyének közti interakciók lényeges elemek az emberek közötti megbeszélések során, ami új megoldásokhoz vezet. Cockburn (2001) is azt mondja, hogy inkább legyen egy kevésbé dokumentált folyamat interakciókkal, mint egy dokumentált folyamat interakciók nélkül. 2. A működő szoftver fontosabb, mint az átfogó dokumentáció. A követelmények, tervezés, ábrák és folyamatok dokumentációja a szoftverfejlesztési folyamat egy hasznos eleme, mivel segít az ötletek, elképzelések vizualizálásában, a követelmények meghatározásában, információk összegyűjtésében, valamint a teljesítménymérési lehetőséget is hordoz magában. Következésképpen, ez az agilis érték nem ellenzi mindenáron a dokumentációt, inkább azt fejezi ki, hogy a dokumentumokat vonalvezetőkként érdemes használni, más szóval olyan módon, mintha a projekt jövőjét szeretnénk körvonalazni velük. Ahelyett, hogy erősen dokumentációorientált megközelítésék helyett fontosabb, hogy a működő szoftverre fókuszáljunk, ami visszajelzést adhat a folyamatról és a csapat teljesítményéről. Cockburn (2001) szerint a dokumentáció hasznos lehet, ám elég azt az éppen megfelelő vagy az elégséges szinten tartani, mialatt a kód alakulása, illetve a működő szoftver szolidan tükrözi, hogy mit sikerült elérni. 3. A vevővel való együttműködés fontosabb, mint a szerződések tárgyalása. Az együttműködés nem mást jelent, mint ugyanazon a feladaton dolgozni aktív kommunikációval és közös döntéshozatallal. A hagyományos módszerekkel ellentétben, 24

ahol a fejlesztői csapat elszeparálódik a vevőtől, végfelhasználótól, az agilis szoftverfejlesztés esetén szoros kapcsolat alakuk ki a csapat és a vevő között. Cockburn (2001) azt mondja, hogy az agilis szoftverfejlesztésnél nincs többé mi és ők, csakis mi létezik. Az együttműködést szerinte a közösséggel, közös döntéshozatallal, gyors kommunikációval és az egyének közti interakciók összekapcsolásával hozható összefüggésbe. Másrészről a vevőtől elvárt, hogy megfelelő tudással rendelkezzen a fejlesztés tárgyáról, valamint érdekelt legyen a szoftverfejlesztésben való részvételben. Boehm (2002) szerint, hacsak a vevő nem elkötelezett, nem rendelkezik megfelelő tudással, nem jól tájékozott, nem együttműködő, a termék nem lesz igazán használatra alkalmas, még akkor sem, ha kielégíti a vevői igényeket. Az agilis módszerek akkor működnek a legjobban, ha a vevők dedikált módon együttműködnek a fejlesztő csapattal, valamint amikor a tacit tudásuk elegendő. Emiatt lehetséges, hogy a tradícionális módszerek egyes esetekben megfelelőbbek. 4. A változásokra való reagálás fontosabb, mint a tervek követése. Ez az érték azt az elképzelést támogatja, miszerint a szoftvertermék teljes igényrendszerét nem lehet a használat előtt tudni, mivel a követelmények folyamatosan változnak. Más szavakkal, ahelyett, hogy mereven ragaszkodnánk egy tervhez, jobb, ha periodikus megszakításokkal rugalmasan reagálunk a vevők igényére és prioritására. Ahogy Cockburn (2001) állítja, a tervkészítés hasznos, ám az agilis módszertanokra, mint a scrum vagy az adaptív folyamatfejlesztés, sajátos tervezési tevékenység a jellemző, emellett olyan mechanizmusokat is tartalmaznak, melyek megbirkóznak a változó prioritásokkal. 3.2 Szerepek és felelősségi körök az agilis fejlesztésben Az agilis fejlesztés során négy nagy szereplőt különíthetünk el. Először is van egy agilis csapat, majd ehhez jön egy product owner, egy iteration manager és egy project manager (Sziklai 2015). 25

A csapat: Az agilis csapatra jellemző a keresztfunkcionalitás, azaz a csapatot különböző ismeretekkel rendelkező egyének alkotják. A csapattagok tisztelik egymást és egyformán felelősek a csapat tevékenységéért. Elkötelezettek a feladatok iránt és időben végrehajtják azt (Sziklai 2015). Iteration manager: McKergow (2015) szerint az iteration manager az agilis fejlesztői csapat azon funkciója, aki összetartja a csapatot és segít abban, hogy gördülékenyen működjön. Támogatja a csapatot az agilis praktikák, elvek megértésében, illetve annak a megértésében, hogyan is működik az agilis fejlesztés, valamint hogyan lehet gyorsan reagálni a változó világra. A következő feladatok tartoznak az iteration manager feladatkörébe: - Biztosítja, hogy az agilis folyamatfejlesztés eseményei (például napi standup meetingek, visszatekintő meetingek) megfelelően szervezettek, illetve megfelelően végre lettek hajtva. - Biztosítja, hogy a jelenleg folyó és a soron következő iterációt megtervezték. - Biztosítja, hogy az elvégzendő feladatokat megfelelően priorizálták, illetve a csapat a legfontosabb feladatokat végzi el elsőként. - Figyel arra, hogy a feladatokat vizuálisan jól jelenítik meg (ha egy feladat éppen zajlik, akkor a folyamatban van szekcióhoz van rendelve) - Elhárítja azokat az akadályokat, melyek a csapat tevékenységét nehezítik - A project manager-rel és a product owner-rel együttdolgozva segít abban, hogy a csapat ne terelődjön el a céltól - Tréningeket tart. Felkészíti a project manager-t és a product owner-t az agilis alapelvek, értékek és gyakorlatok megértésére. Segít az önszerveződés és keresztfunkcionalítás kialakításában. Segít ott, ahol nem sikerült teljesen átvenni az agilis módszertant. - Frissíti a diagramokat és az ábrákat a fejlesztési folyamat során. - Folyamatosan tájékoztatja a project manager-t és a product owner-t arról, hogy áll a csapat a cél elérésében. 26

Product owner: Ahogy azt Ambler (2014) is írja, a product owner elsődleges feladata az, hogy képviselje az érintettek (például vevők) igényeit és vágyait az agilis fejlesztési csapatban. Minden egyes agilis csapat, sőt, nagyobb horderejű projekteknél minden egyes agilis alcsapat saját product owner-rel rendelkezik. A product owner másik feladata az, hogy a csapatot képviselje az érdekelt felek előtt, tehát egy összességében egy összekötő szereplőről beszélünk, amit a 4. ábra szemléltet. Az elsődleges feladata szerint a product owner a következőkért felel: - Információért folyamodik az érintettekhez - Fontossági sorrendbe helyezi az igényeket - Aktív résztvevője a tesztelési folyamatnak - Oktatja a csapatot az üzleti szféráról - A finanszírozás megoldásában közvetítő szerepet játszik - Kezeli azokat a helyzeteket, ahol más csapatokkal kell együttműködni kölcsönös függőségek miatt A másodlagos feladata szerint a product owner a következőkért felel: - A csapat arca a projekt érintettjei felé - Bejelenti, ha egy termék elkészült - Kommunikálja a csapat státuszát - Felülvizsgálatokat, ellenőrzéseket szervez - Tájékoztatja az érintetteket a fejlesztési folyamatról - Tárgyal a prioritásokról, a finanszírozásról és a menetrendről 27

4. ábra: A product owner mint összekötő szereplő Forrás: Ambler, 2014. Project manager: Banerjee (2016) azt mondja, hogy a hagyományos projektmenedzsment feladatkör, valamint felelelősségi kör kibővült az agilis módszertannak köszönhetően. Az agilis projektek project manager-e kezeli a projekt pénzügyi feladatait, készít jelentés a projekt státuszáról, ellát irányítói és üzleti kommunikációs feladatokat. Részletesen a következő feladatkörök tartoznak a project manager hatásköre alá: - Irányítja a dolgozókat a kiszámíthatatlan, stresszes környezetben az agilis projektekre jellemző, hogy szigorúan kell tartani egyfajta ütemtervet. A project manager biztosítja, hogy egy-egy sprint időben befejeződjön. - Motivál mindenkit, hogy a fókusz továbbra is a kitűzött cél elérésén legyen. - Módosítja az időtervet és a munkaütemet, hogy a munka a megfelelően haladjon. A projektet számos fázisra bontják, az egyes fázisoknak saját ütemterve van. A project manager feladata, hogy kiossza a feladatokat az egyéneknek, illetve kiegyensúlyozza a munkavégzést. - Kezeli a problémákat és eszkalálja a megfelelő hatóságok felé. Ő informálja a megfelelő embert a megfelelő időben, hogy a probléma megoldódjon. - Kommunikálja a változásokat az érintettek felé. A project manager informálja az érdekelt feleket a projekt státuszáról. - Küzd a szükséges erőforrásokért. Ő kezeli a jóváhagyásokat, melyek a szükséges erőforrásokhoz kellenek. - Projekttervet készít és módosítja azt, ha szükséges. A project manager segít a projekttervek elkészítésében, illetve abban, hogy azokat a csapat kövesse. 28

Ha változtatás szükségeltetik, akkor ő biztosítja, hogy a projekttervet ennek megfelelően módosítják, valamint ezt kommunikálják is. - Kockázatkezelési terveket készit. Ő azonosítja az esetleges kockázatokat, valamint kockázatkezelési terveket alkot. - Megoldja a problémákat, melyek a projekt akadályát jelentik. A project manager biztosítja, hogy a személyes konfliktusok, politikai kérdések, technikai képességek hiánya vagy a költségvetés hiánya ne legyen káros hatással a projektre. Megelőző intézkedéseket tesz ennek érdekében. Ahogy azt fent megfigyelhetjük, a szerepek nem különülnek el teljesen tisztán az agilis projektek során. Vannak olyan feladatok és felelősségi körök, melyek több szereplőhöz tartoznak. Az iteration manager és a project manager feladatában például közös, hogy mindketten felelősek azért, hogy a fejlesztési munkálatok előtt álló akadályokat megfelelően elhárítsák. A product owner és a project manager is végez kommunikációs feladatokat, valamint mindketten foglalkoznak az ütemtervvel és a rendelkezésre álló erőforrásokkal. Az iteration manager és a product owner feladatkörében közös, hogy mindketten tartanak tréningeket, oktatásokat. 3.3 A leggyakrabban alkalmazott agilis technikák A következőkben néhány fontosabb agilis praktikát vázolok fel azok közül, amelyeket Andrew C. Lee (2016) gyűjött össze. A gyakorlatok nagyban függnek azoktól, akikkel el szeretnék végezni őket, illetve befolyásolja még az adott helyzet is. Néhányat ezek közül ismétlődő jelleggel végeznek, míg vannak olyanok, amelyekre csak egyszer kerül sor. Mielőtt egy csapat esetén alkalmaznának bármiféle gyakorlatot, megvizsgálják, hogy érdemes e alkalmazni az adott szituációban. Stand-up meetingek vezetése: Ezek a stand-up meetingek 5-10 perces összejövetelek a csapaton belül. Gyakran kerül ezekre sor, általában hetente három alkalommal gyűlnek össze pár percre a csapattagok. A megbeszélés során a csapat termelékenységét veszik górcső alá. A résztvevőknek három kérdésre kell választ adniuk: 29

- Mit értem el az előző találkozás óta? - Mit fogok csinálni a következő találkozóig? - Milyen tényezők jelenthetnek akadályt számomra? Ezek a stand-up meetingek ösztönzik a csapattagokat, hogy támogassák egymást a napi célok elérésében. Ezek a gyakorlatok egy hatékony módot jeleneten arra, hogy találjuk meg azokat az utakat, amelyek mentén a munkát gyorsabban elvégezhetjük. Visszatekintések alkalmazása: Az agilis visszatekintő egyfajta meeting, amelyet egy bizonyos munkafolyamat végén alkalmaznak. A visszatekintések alatt a csapat feltárja, hogy mi történt az adott folyamat során és milyen módok állnak rendelkezésre a további fejlődésre. Úgy tekinthetünk erre, mint egy tanulási procedúrára. Három alapvető kérdést tehetünk fel, amit az 5. ábra is szemléltet: - Mit csináltunk jól? - Mit csináltunk rosszul? - Miben lehet fejlődést elérni? Ez a típusú megbeszélési forma előzetes alapok lehelyezését igényli, a csapatnak meg kell beszélnie például, hogy milyen lefolyása legyen a visszatekintő meetingnek vagy kérdés lehet, hogy milyen formában történjen a döntés a fejlesztésekről. 30

5. ábra: Példa a visszatekintések esetén alkalmazott táblára Forrás: saját készítésű ábra, 2017. A csapat hangulatának megismerése: A csapat alkalmazhat olyan technikákat, amelyek során névtelenül felmérik a tagok adott napi hangulatát. Ez segíthet a napi munka megfelelő előkészítésében, emellett a vezetők alkothatnak egy általános képet a csapatról. Gyakran különböző színű sticky note-ok segítenek ebben. Az egymástól távol dolgozó csapattagok esetén érdemes egy hangulatfalat is alkalmazni, de a csapat dönthet úgy, hogy más módokon próbálja felmérni az adott napi hangulatot és nem a jól bevett szokásokat alkalmazza. Társadalmi szerződés létrehozása: A társadalmi szerződés itt egy olyan csapat által megkomponált szerződésre utal, amelyben a csapat meghatározza hogyan fogja elérni az eredményeket. Ez a szerződés csapatonként, projektenként változhat. Ideális esetben kifüggesztésre kerül egy falra egyfajta emlékeztetőként a csapattagok számára. Az elért eredmények közzététele: Szintén egy falra kifüggesztve hasznos lehet, ha egy-egy termék vagy szolgáltatás érdekeltjei visszajelzést kaphatnak vizuálisan az adott termék, szolgáltatás jelenlegi és korábbi állapotáról. Ennek a segítségével a témák megvitatása is könnyebb lehet. 31

Gátlásoldó gyakorlatok: Az agilis filozófia szerint a csapattagoknak nyíltnak és őszintének kell lenniük az előttük álló kihívások terén. E technika segítségével felszínre hozhatóak a rejtőzködő félelmek és aggodalmak. Nagyjából fél órát vesz igénybe ez a gátlásoldó gyakorlat személyenként és általában csak egyszer van rá szükség, de előfordulhat, hogy hasznos visszatérni hozzá a jövőben. A vállalaton belül elérhető online fórumokon történik ennek a végrehajtása. A lépések a következők: 1. Egy fórum topic létrehozása a témában 2. Háttérleírás 3. Határidő kitűzése 4. Együttműködés ösztönzése 5. A beérkező inputok elemzése 6. Akciótervek priorizálása 7. Annak a megvitatása, hogy milyen módon dolgozzanak az egyes személyek csapatként (alapszabályok és alapelvek leszögezése) Agilis döntési technika: Ez a döntési technika lehetővé teszi, hogy fejlesszék és meggyorsítsák a döntéshozatali folyamatot egy egyszerű keretrendszer segítségével. Az IBM-nél a döntéshozatal tipikusan eltérő sebességgel és hatékonysággal működik, az egyes csapatok rendkívül sok időt töltenek adatok összegyűjtésével és prezentációvá transzformálásával. Az agilitás bevonása a döntéshozatalba felgyorsítja a folyamatot. A döntéshozatal a napi életünk része és ez a módszer alkalmazható a mindennapokban. Leginkább akkor hasznos, ha csapat esetén alkalmazzuk. Többek között a következő üzleti életet érintő területeken érhetünk el javulást a technika alkalmazásával: - megnövekedett működési sebesség - javuló folyamathatékonyság - fólusz a problémamegoldásra kerül 32

A döntési folyamatot három elkülönülő lépésre bonthatjuk: 1. a probléma meghatározása 2. a lehetőségek összegyűjtése 3. javaslattétel és döntéshozatal Empátia térkép használata: Az úgynevezett empátia térkép egy eszköz arra, hogy betekintést nyerjünk a vevők és a vállalati érintettek gondolataiba (mit érez, lát, hall, mond, mi a pozitívum és a negatívum). Körülbelül 30 percet vesz igénybe és 6 különböző területet ölel fel, melyeket a 6. ábra szemléltet. Eszközként olyanok jöhetnek szóba, mint például a prezentációs tábla, sticky note-ok vagy a Google doc, amely a virtuális csapatmunkát segíti. 6. ábra: Az empátia térkép Forrás: saját készítésű ábra, 2017. A folyamat során a csapat összegyűlik, meghatározzák az alapokat, mint például mi a célja ennek ez empátia térképnek az adott esetben. Kinyomtatnak vagy 33

megrajzolnak egy vázlatot a térképhez. A csapattagok sticky note-okat és tollakat kapnak. Minden résztvevőnek a térkép minden szekciójához muszáj valamit írni, hozzátenni. A tevékenység során a következő kérdésekre kell válaszolni az adott embernek: - mit gondol, érez, mik az aggodalmai? - mialatt használja mondjuk az adott terméket, mit hall a barátaitól, főnökétől ezzel kapcsolatban? - mit lát, miközben használja az adott terméket? - mit mond vagy csinál, miközben nyilvánosan vagy privát környezetben használja a terméket? - mit tapasztal, mint gyenge pont vagy félelem, mialatt a terméket használja? - mit tapasztal, mint erősség vagy haszon, miközben a terméket használja? A tevékenység során a központi figura karaktere szép lassan kialakul. Showcase: Ez egy olyan gyakorlat, amely során a csapat egy informális meeting keretében bemutatja az adott iteteráció során elkészült terméket vagy termékegységet a product ownernek, illetve az érintetteknek, akiknek a visszajelzése alapján megbeszélést folytathatnak az esetleges korrekciós lépésekről, amennyiben azok szükségesek. 3.4 A sikeres agilis szervezetek jellemzői A következőkben felsorolok és kifejtek néhány olyan kulcsfontosságú pontot, amely jellemző azokra a vállalatokra, akik sikerrel alkalmazzák az agilis módszertant. 1. Megértik, miről szól az agilis fejlesztés Vannak olyan vezetők, akik az agilis módszertant az anarchiával hozzák összefüggésbe: mindenki azt csinál, amit akar. Mások úgy gondolják, hogy ez inkább a csináld, amit mondok, csak gyorsabban módszer. Valójában egyik sem. Több forrásból táplálkozik, melyek más-más szempontokra támaszkodnak, ilyen a lean fejlesztés vagy a scrum is. 34

A scrum alapjai viszonylag egyszerűek. A szervezet, vállalat létrehoz 3-9 főből álló kis méretű csoportot. A csapat keresztfunkcionális jellegű, minden területen szakértelemmel bír, ami a feladat elvégzéséhez szükséges, valamint önmagát menedzseli és szigorúan saját maga felelős az elvárt és elvégzett munkáért. A csapatban szerepel egy product owner, aki többek között azért felelős, hogy az értéket a vevő felé közvetítse. Ez a személy általában valamilyen üzleti területről csatlakozik a csapathoz és megosztja a munkaidejét: egyrészt dolgozik a csapattal, másrészt koordiációs tevékenységet is végez az érdekelt felek között (vevők, vezetők, menedzserek, stb.). A product owner bizonyos agilis technikákat alkalmazva létrehoz egy úgynevezett portfolio backlog-ot, amely egyfajta feladat- és tevékenységlista, mely fontossági sorrend szerint van rendezve a rendezés alapja a belső és a külső vevőknek, illetve az üzletnek szállított érték becsült szintje. A product owner nem dönti el, hogy ki mit csinál, mi meddig fog tartani. Ez a csapat feladata. A csapattagok a legfontosabbnak tartott feladatokat kisebb egységekre bontják, meghatározzák, hogy mennyi időt kell valószínűleg velük tölteni és hogyan tudják elvégezni őket. Meghatározzák, hogy mikor tekinthető egy feladat elvégzettnek, majd elkezdenek dolgozni a terméken kisebb ciklusokban (amelyek maximum egy hónapig tarthatnak). Van egy process facilitátor ő irányítja, felügyeli a folyamatokat. Segít, hogy a csapat ne térjen el az eredeti céltól, illetve hogy a csapat beletegye a szakértelmét a feladat elvégzésébe. A folyamat mindenki számára átlátható és egyértelmű. A csapattagok naponta rövid stand up meetingeket tartanak, hogy megnézzék, hol tartanak a folyamatok, illetve hogy azonosítsák az akadályokat. Feloldják az egyet nem értést kísérletezések és visszajelzések segítségével ahelyett, hogy végtelen vitákban vennének részt. Tesztelik néhány vevővel, érintettel az egyes kisebb fázisban keletkező prototípusokat. Ha a vevő elégedett, akkor a prototípus már mehet is a gyártásba, még akkor is ha a vezetőség nem elégedett. Ezután a csapat brainstorming-ot tart a jövőbeli ciklusok javítása érdekében és felkészül a következő feladatra (Rigby et. al., 2016). 35

2. Kis csapatokat alkalmaznak Az egyik, szinte majdnem univerzális agilis jellemző az, hogy az adott szervezetben az ezt a filozófiát követő munkatársak azt a nézetet osztják, hogy a munkavégzésnek kis, autonóm, keresztfunkcionális csapatokban kell folynia, rövid ciklusokban, viszonylag kis feladategységekkel, melyek a vevőnek értéket szállítanak, emellett folyamatos visszajelzés érkezik a végső vásárlótól vagy a végfelhasználótól. Az agilis szoftverfejlesztés első évtizede főként arról szólt, hogy megpróbálták kitalálni, hogy hozzák létre ezeket a nagy teljesítményre képes csapatokat szisztematikusan. A 20. században szerzők sora javasolta a kis csoportban való munkavégzést a jobb munka eredményének reményében. Az egész Mary Parker Folletttel kezdődött az 1920-as években, majd ezt folytatta Elton Mayo és Chester Barnard az 1930-as években, Abraham Maslow az 1940-es években, Douglas McGregor az 1960-as években, Peters és Waterman az 1980-as években, míg Smith és Katzenbach az 1990-es években. Ennek ellenére a legtöbb szervezet maradt a bürokratikus berendezkedésnél. Az egyik oka ennek az az elterjedt menedzsment elképzelés, miszerint a csapatok nem igazán képesek hatékony teljesítményt nyújtani. Hasznosak a komplex, egyszeri problémák megoldásában, ám a rendszeres munkavégzés esetén a bürokrácia a jobb legalábbis ez volt az általánosan elfogadott bölcsesség. A másik ok az, hogy a 20. században a csapatok csak nevükben voltak csapatok, igazából nem alkottak azt. Az igazi, önszerveződő csapatok, melyek aztán eredményt is képesek voltak elérni, ritkaságszámba mentek. A csapatok esetén a szakirodalom igazából a nagy teljesítményt elért csapatokról beszélt, legalább 2-3-szoros növekedést vártak el tőlük. Ez keveseknek sikerült, azt is inkább szerencsének tartotta a szakirodalom. Az agilis fejlesztés volt az, amely aztán megvalósította azt, hogyan hozzunk létre nagyteljesítményű csapatokat konzisztens módon (Denning, 2016). 36

7. ábra: A bürokratikus és agilis csapat különbségei Forrás: Denning, 2016. Denning (2016) szerint az agilis csapatok munkavégzésének alapjai a következők: 1. A munkát apróbb ciklusokba szervezik. 2. A menedzsment nem avatkozik be, amíg a munka kész nincs. 3. A csapat a kliensnek riportál, nem pedig a menedzsernek. 4. A csapat megbecsüli, mennyi időt igényel a munka. 5. A csapat eldönti, hogy mennyi munka után tartsanak iterációt. 6. A csapat eldönti, hogy végezzék a munkát iteráció keretében. 7. A csapat méri saját teljesítményét és minden egyes munkaciklus során egy komplett, elvégzett munkát tesz le az asztalra. 8. A munkára vonatkozó célokat mindenegyes ciklus előtt meghatározzák, a user story-k eredményeképpen. 9. A menedzserek szisztematikusan lebontják a fennálló akadályokat. 10. A csapat szisztematikusan nyomon követi a teljesítményt és alkalmazkodik, hogy biztosítsa a folyamatos fejlődést. 3. Megértik, hogy a módszertan hol működik és hol nem Az agilis módszertan nem egy csodaszer. A legkönnyebben és leghatékonyabban a szoftver innovációnál megjelenő környezetben lehet bevezetni: a megoldandó probléma komplex, a megoldások kezdetben ismeretlenek, a termék követelmények valószínűleg változni fognak, a munkafolyamat több kisebb részre bontható, szoros 37

együttműködés megvalósítható a végfelhasználóval (illetve gyakori és gyors visszajelzések érkeznek tőle). Tapasztalatok szerint ezek a feltételek megjelennek a termékfejlesztési funkcióknál, a marketing projekteknél, a stratégiai tervezési tevékenységeknél, az ellátási lánc kihívásainál, illetve az erőforrás allokációs döntéseknél, ám kevésbé jellemzőek a rutinszerű működéseknél, mint például a létesítményfenntartás, beszerzés vagy számvitel esetén. Az agilis innováció nagyban függ attól, hogy van-e egy lelkes résztvevőkből álló csoport, ugyanis a módszertan egyik alapelve is ezen nyugszik: építsünk projekteket a motivált egyének köré, adjuk meg nekik azt a környezetet és támogatást, ami a munkavégzéshez szükségeltetik, majd bízzunk abban, hogy elvégzik a munkát. Ha a vállalat vagy egy csoport úgy dönt, hogy alkalmazza az agilis gyakorlatokat, akkor a vezetőnek lehet, hogy ki kell vennie a csoportból azokat, akik ellenállóak és hátráltatják a munkát. Az OpenView Venture Partner cég úgy döntött, hogy agilis útra lépnek. Ez a vállalat körülbelül 30 cégbe fektetett be. Sok cég ezek közül már alkalmazta az agilis fejlesztést. A vállalat úgy döntött, hogy ő maga is átveszi ezeket a módszereket. A vezetés rájött, hogy vannak olyan területek, ahol jól működnek ezek a technikák, és vannak olyan területek, ahol nem. Jól működtek a marketing vagy stratégiai tervezés terén, ahol például komplex problémával álltak szemben, amely apróbb feladatokra bontható és ezek a feladatok aztán kreatív multidiszciplináris csapatok segítségével elvégezhetőek. A sales terén viszont nem működött jól a rendszer. Bonyolult és időigényes volt a sales csapat összehívása, a portfolio backlog megváltoztatása (Rigby et. al., 2016). 4. A vevőkre fókuszálnak Az agilis szervezetek egy másik jellemzője, hogy a munkavállalók a vevői érték létrehozására koncentrálnak. A vevő elsődleges fontosságát már az Agilis Kiáltvány is alapelvként említi. Az agilis fejlesztés első évtizedes működése során a vevő csak másodlagos szerepet kapott. Ehelyett inkább a nagy teljesítmény elérésére képes csapatokra helyeződött a hangsúly akkoriban. Ez idő alatt a csapatok viszonylag kevés 38

időt töltöttek a tényleges vevővel történő kapcsolattartással. Az agilis fejlesztés első éveiben a vevőt egy képviselő, az úgynevezett product owner helyettesítette, aki valamilyen úton-módon tudta, hogy a vevő mire vágyik. Miután az agilis fejlesztés során megoldódott a nagy teljesítményű csapatok kérdése, a figyelem a vevőre helyeződött. A globalizáció, a dereguláció, az új technológiák, különösen az internet, a vevőket választási lehetőségekkel, információs forrásokkal látták el, képesek lettek más vevőkkel is kapcsolatba lépni. Hirtelen a vevő került vezető helyzetbe, az elvárt értéket pedig azonnal, súrlódásmentesen és személyre szabottan kellett biztosítani. Ennek eredményeképpen a vállalatoknak másképp kellett tekinteniük a vevőkre. A 20. századi cégek hozzászoktak ahhoz, hogy kihasználhatják és manipulálhatják a vevőiket. Ha a vevőnek nem tetszett egy ajánlat, a vállalat erre azzal válaszolt, hogy ez rendben van, de ezt tudják biztosítani, megnézik mit tehetnek, de a változtatás évekbe is telhet. A mai, sokkal kompetitívebb jellegű piacokon ez a megközelítés már nem igazán hatékony. A vevő mára már így reagál egy ilyen felvetésre: Miért várjunk még éveket? Ha nem tudod most megoldani, találunk valakit, aki megcsinálja. A 8. ábra mutatja azt, hogy a bürokratikus és agilis szervezetek milyen főbb pontokban térnek el. 8. ábra: A bürokratikus és agilis szervezet különbségei Forrás: Denning, 2016. Az agilis szervezetben mindenkinek, aki a szervezet része, tisztában kellene lennie a végső vevővel, illetve azzal, hogy az ő munkája mit ad a vevőnek. Ha az adott munkavállaló munkája nem jelent értéket a vevőnek vagy más felhasználóknak, akkor 39

jön a kérdés, hogy vajon mi értelme van azt elvégezni egyáltalán? A cég minden téren alkalmazkodni próbál, a célokat, értékeket, alapelveket, folyamatokat, rendszereket, gyakorlatokat, adatstruktúrákat megváltoztatja, hogy folyamatosan új értéket hozzon létre a vevőknek, illetve megszüntessen mindent, ami ehhez nem járul hozzá (Denning, 2016). 5. Kicsiben kezdték és hagyták elterjedni: A nagyobb vállalatok általában nagy erőfeszítéseket tesznek a változtatások bevezetésére, ám a legsikeresebb agilis bevezetések általában kicsiben kezdődnek. Gyakran csak IT területen indítják el, ahol a szoftverfejlesztők ismerik az alapelveket. Ezután az módszertan átterjedhet más területekre, ahol már a korábbi teszelők trénerként működhetnek. Minden sikeres bevezetés kreál egy-egy kis csoportot, melynek tagjai már alig várják, hogy másoknak is megmutathassák, milyen hasznos is lehet az agilis fejlesztés és hogyan is működik. A módszertan alkalmazására és elterjesztésére jó példa lehet a John Deere, ahol George Tome, egy szoftvermérnökből lett projektmenedzser egy kis csoportban kezdte el alkalmazni 2004-ben. Néhány év elteltével az agilis gyakorlat fokozatosan megjelent más egységeknél is: először a szoftverfejlesztés vette át, majd eljutott egészen a vállalat üzleti fejlesztéséig és marketing osztályáig. 2012-ben Tome mint menedzser dolgozott a vállalat marketing osztályának, amely többek között felelős volt a technológiák kifejlesztéséért, illetve a John Deere ajánlatainak forradalmasításáért. Jason Brantley, ennek a vállalategységnek a feje, aggódott, hogy a hagyományos projektmenedzsment technikák lassítják az innovációt, így Tome-mal karöltve úgy döntöttek, megnézik mire mennek az agilis módszer segítségével. Tome két menedzsert is meghívott tréningekre, ám a terminológia és a példák, melyek alapvetően a szoftverek területéről jönnek, nem jelentettek sokat az egyik, ilyen területen tapasztalattal nem rendelkező menedzsernek. Tome kapcsolatba lépett egy olyan Agile trénerrel, akinek volt tapasztalata szoftveres háttérrel nem rendelkező kollégák képzésével. Az elmúlt években számos csapatot tréningelt ezután a vállalat R&D központjaiban. Tome elkezdte az agilis módszerek és alapelvek publikálását, többek között a vállalt honlapján, illetve az érdeklődőknek külön e-mail 40

üzenetben. Munkatársak százai csatlakoztak. Ezzel egyfajta tudásbázis kiépítését fektette le, célja az volt, hogy az agilis fejlesztés a vállalat egy része legyen. Az agilis technikák használata jelentősen csökkentette az innovációs projektek ciklusidejét sok esetben akár 75 százalékkal is. Emellett a csapat elkötelezettsége is javult, e területen eredetileg az alsó harmadba tartozott ez az egység a vállalaton belül, ebből sikerült a felső harmadba jutni. Növekedett a minőség színvonala is. A sebesség (amit az egyes sprintek alatt elvégzek munka alapján mértek), növekedett, méghozzá átlagosan több, mint 200 %-kal, de egyes csapatok 400 % fölé is mentek, valamint az egyik csapat sikeresen elért 800 %-ot. Az efféle siker figyelemfelkeltő. Mára már a John Deere-nél majdnem minden terület alkalmazza az agilis fejlesztést, vagy gondolkodik azon, hogyan alkalmazhatná (Rigby et. al., 2016). 6. Hálózatként működnek Az agilis organizácó egy jellemzője az, hogy a munkavállalók a szervezetet egy átlátható, interaktív hálózatként látják, amely hozzájárul a közös célhoz, az elégedett vevőkhöz. Az agilis mozgalom első éveiben úgy gondolták, hogy ha vannak jól teljesítő csapatok a szervezetben, akkor a szervezet máris agilis. Később kiderült, hogy ez nem így van. Nem elég, hogy a csapatok arra koncentrálnak, hogy vevői érték jöjjön létre, ha a csapat egy hierarchikus, bürokratikus szervezet, amely arra fókuszál, hogy minél inkább több költséget takarítson meg és növelje a részvényértéket. A hálózat az agilis módszertan egy új kulcsfontosságú pontja lett. A 20. század közepén a vállalatok menedzsmentje úgy tekintett a cégre, mint egy hatékony gépezet, amelynek a célja a létező üzleti modellben rejlő lehetőségek kiaknázása. A hagyományos, MBA alapú gondolkodás ahogy azt a Google vezetői, Eric Schmidt és Jonathan Rosenberg írták a How Google Works című könyvükben azt diktálja, hogy építs fel egy fenntartható kompetitív előnyt a riválisokkal szemben, amit aztán védj, mint egy erődöt, akár forró olajjal vagy tüzes nyilakkal. A jelenlegi üzleti modell kiaknázása elsőbbséget élvez az új lehetőségek felfedezése felett. 41

Az évtizedek folyamán számos fejlesztési lehetőséget tártak fel, melyek célja a szervezetek statikus felépítésének a javítása volt, azonban ezeket a fejlesztési lehetőségeket ugyanúgy a régi szervezeti elképzelés mentén alkalmazták, amelynek a lényege a hatékony gépezet. A nagyfőnökök továbbra is kisfőnököket neveztek ki, a szervezet továbbra is egy óriási csatahajóként üzemelt, nagy volt, erős, de lassú és nehezen manőverezhető. Ezzel ellentétben, mikor az egész szervezet agilissá válik, akkor inkább egy motorcsónakra, mintsem egy csatahajóra hasonlít. Ahelyett, hogy egy mozdulatlan gép lenne, a szervezet egy organikus, élő hálózattá alakul, a hálózat elemei pedig a nagyteljesítményű csapatok. Ezekben a szervezetekben, a menedzserek felismerik, hogy a kompetencia a szervezeten belülről fakad, illetve az innováció bárhonnan jöhet. Az egész szervezet, beleértve a vezetést is arra törekszik, hogy minél jobb értéket közvetítsen a vevők felé. Az agilis csapatok maguktól indítják projektjeiket, valamint kapcsolatba lépnek más agilis csapatokkal, hogy megoldják a közös problémákat. Gyakorlatilag, az egész szervezet egy közös gondolkodásmódon alapszik, illetve hatékony csapatok hálózatát képezi. Természetesen nem csak tisztán agilis vagy bürokratikus szervezet létezik, további lehetőségeket mutat a 9. ábra. 9. ábra: A szervezeti felépítés lehetőségei Forrás: Denning, 2016. Egy tévhit azonban, hogy az agilis szervezetekre nem jellemző a hierachia. Az agilis vállalatoknál a felsővezetésnek megvannak a maga fontos funkciói, például a 42

szervezés és a vállalati irányvonal meghatározása. Az embereket itt is kirúgják, ha nem végzik megfelelően a munkájukat. A hatékonyságra, nagy teljesítményre való ösztönzés az ilyen szervezeteknél még erősebb, mint a bürokratikus vállalatoknál. Ami különbség, az az, hogy a hierarchia az agilis szervezeteknél inkább a kompetenciák hierarchiája, nem pedig a hatalomé. A szervezet interaktív, dinamikus kommunikáció mentén működik, mind vertikális, mind horizontális irányban. Bárki beszélhet bárkivel. Az ötletek bárhonnan jöhetnek, a vevőktől is. Mint egy hálózat, a szervezet növekedhet, tanulhat, egy élő organizmus, ami egy folyamatos áramlásban van, ahol új lehetőségeket aknázhat ki, illetve értéket adhat a vevőknek. Ha jól csinálják, a vevőknek történő folyamatos értékteremtés kevesebb munka eredménye, valamint ez valódi hozadékot jelent majd a szervezet számára (Denning, 2016). 7. Lerombolnak minden akadályt, ami a módszer akadálya lehet A Scrum Alliance kutatása, amely egy független, nonprofit cég, megállapította, hogy az agilis módszertant gyakorlatban használók 70 %-a észlelt már feszültséget a csapata és a szervezet között (Rigby et. al., 2016). Egy nagy pénzügyi szolgáltató cég, amelyet megvizsgáltak, elindított egy fejlesztést egy olyan mobil applikációra, amely agilis gyakorlatot használ. Az első lépés a csapat összehívása volt. Ehhez szükség volt egy költségvetésre, amely finanszírozza a projektet. A kérvény a költségvetéshez először bekerült egy jóváhagyási folyamatba. Hónapokig vizsgálták az ügyet, mire elfogadásra került. Az applikáció végül sikeres lett, a vevő dicsérte, a csapat büszke volt a munkára. Ám mielőtt az alkalmazást kiadták volna, át kellett esnie egy tesztelésen a hagyományos vízesés folyamat keretében Erre a folyamatra sokat kellett várni, nagy volt a sorban állók száma. Az applikációt integrálni kellett ezután az IT rendszerbe, amely még egy vízesés alapú folyamat volt 6-9 hónapos várakozással. A következőkben felsorolok néhány ötletet arra, hogy lehet elhárítani a hasonló problémákat.: - Mindenkit állítsunk egy oldalra: Ha egy új mobil applikáció a legfontosabb feladata a szoftverfejlesztésnek, akkor ennek kell lennie a legfontosabbnak a költségvetés, sebezhetőségi vizsgálat és szoftverintegráció terén is.. 43

- Ne a struktúrákat változtassuk meg, inkább a szerepeket: Sok vezető úgy gondolja, hogy minél inkább jellemző egy csapatra a keresztfunkcionalitás, annál inkább szükséges a szervezeti struktúra megváltoztatása. Ez nem helyes. A keresztfunkcionális csapatoknak szükségük van egyfajta mátrix alapú szervezetre, menedzsmentre, de a legfontosabb, hogy megtanulják, hogyan dolgozzanak együtt a különböző területeken. - Egy döntés, egy vezető: Az embereknek sok vezetője lehet, döntése csak egy. Egy agilis alapú modellben kritikus, hogy tudjuk, ki a felelős a keresztfunkcionális csapat kialakításában, a csapattagok kiválasztásában és lecserélésében, új csapatvezető kinevezésében, a csapat döntéseinek elfogadásában. - Fókuszálj a csapatra és ne az egyénekre: Az MIT egy kutatása szerint az egyének tudása hatással van a csapat teljesítményére, azonban a csapat kollektív tudása ennél is fontosabb és sokkal könnyebb változtani rajta (Rigby et. al., 2016). Az agilis csapatok facilitátorokat alkalmaznak, akik segítik a folyamatos javulást ezen a téren például tisztázzák a szerepeket, konfliktusmegoldó technikákat tanítanak, illetve biztosítják, hogy a csapattagok egyformán hozzájárulnak. Ha az output és a kihasználtság helyett (például milyen elfoglaltak az emberek) az üzletre való hatást és a csapat boldogságát mérjük (milyen értékesek és elkötelezettek az emberek), az szintén segít, ahogy az a jutalmazási rendszer is, ami a csapat teljesítményét jutalmazza az egyén helyett. - Vezess kérdésekkel és ne parancsokkal: George S. Patton ezredes híres volt arról, hogy a vezetőit arra tanította, ne azt mondják meg az embereiknek hogyan kell megcsinálni, hanem azt, mit kell csinálni. Az emberek a többit a találékonyságukkal megoldják. Az utasítások helyett az agilis vezetőknek meg kell tanulniuk kérdésekkel irányítani, például Mit javasol? vagy Hogyan ellenőrizhetnénk?. Ez a menedzsment stílus hozzájárul ahhoz, 44

hogy az egyes funkciók szakértői vezetők lehessenek, illetve segíti a vállalati stratégiát megalkotókat is abban, hogy az erőforrásokért harcolók helyett kollaboratív keresztfunkcionális csapattá váljanak (Rigby et. al., 2016). 45

4 A vizsgált vállalat bemutatása A következőkben ismertetem az IBM-et mint azt a vállalatot, ahol az agilis módszertan megjelenését a későbbiekben vizsgálom. Ezt azért tartom szükségesnek, hogy jobban körvonalazódjon az a környezet, ahol ezt a megközelítést alkalmazzák, ezáltal jobban megérthetőek bizonyos lépések, történések. Elsőként röviden bemutatom az IBM globális tevékenységét egy rövid történeti áttekintéssel karöltve, majd rátérek az IBM magyarországi működésére, végül pedig a székesfehérvári telephely részleteire, ahol a vizsgálataimat végeztem. 4.1 Az IBM-ről általában Az IBM (International Business Machines) egyike a világ legnagyobb információtechnológiai vállalatainak. A cég, melyet gyakran neveznek Big Blue-nak, a hardverek terén jónéhány virágzó évtizedet tudhat maga mögött, többek között a mainframe számítógépek legnagyobb beszállítiója volt korábban. Az évek során azonban a vállalati fókusz eltolódott a hardverek felől a szoftverek és a szolgáltatások irányába. A 2010-es években az IBM üzleti palettája továbbmódosult, mára olyan ágazatok kerültek előtérbe, mint a felhőalapú szolgáltatások vagy a kognitív számítástechnika. IBM Watson, amely egy kognitív rendszer, a vállalat egyik zászlóshajójává vált a technológiai szegmensben. Az IBM továbbra is egy jelentős IT cég, ám elvesztette korábbi dominanciáját a mainframe korszak alatt. A vállalat 2016 októberéig zsinórban 18 egymást követő bevételvisszaesést volt kénytelen elkönyvelni. Míg 2011-ben még 106,9 milliárd dolláros bevétellel büszkélkedhetett, ez 2015-ra 82,7 milliárdra apadt (TechTarget, 2017). Az IBM rövid története: Az IBM 1911-ben Computer-Tabulating Recording Company (CTR) néven kezdte meg működését, amely aztán 1924-ben kapta meg a jelenleg is használatos nevét. A második világháború alatt az IBM gépeit statisztikák nyomon követésére használták. A második világháború után egészen az 1980-as évekig a cég a vállalatokat és 46

kormányzati szerveket látta el számítógépekkel, majd a 80-as években megjelentek a piacon az első IBM személyi számítógépek, melyek már a hétköznapi embereket is szolgálták. Az 1990-es években döntött úgy a vállalatvezetés, hogy a jövőben inkább a szolgáltatások felé irányul majd az IBM tevékenysége. Miután 2005-ben a Lenovo felvásárolta az IBM személyi számítógép divízióját, a vállalat gyakorlatilag teljes mértékben szolgáltatóvállalattá alakult (Madrigal, 2011). A TechTarget (2017) a következő szoftvereket és szolgáltatásokat emelte ki az IBM fő csapásvonalaként: - Szoftverek: A vállalat szoftverpalettája rendkívül széles. Megtalálható itt az IBM Cognos Analytics, IBM SPSS, IBM Maximo Asset Management és a DB2 is. Számos termékhez a felvásárlások során jutott hozzá az IBM. - Szolgáltatások: Az IBM szolgáltatási egysége közé tartozik az Global Business Services, mely otthont ad a vezetési tanácsadási műveleteknek, illetve a Global Technology Services, amelynek része többek között a networking, üzleti kontinuitás és kirszervezés. Az elmúlt években az IBM nagy hangsúlyt fektetett a cloud terén tanácsadással, kivitelezéssel foglalkozó cégek felvásárlására. Így lett az IBM része a Bluewolf vagy a Meteorix LLC is. - Cloud: Az IBM SmartCloud szoftver és szolgáltatás üzletága 2011-ben indult. 2013-ban az IBM felvásárolta a SoftLayer Technologies vállalatot. Ezek után a SmartCloud és a SoftLayer összeolvadt és a felhő alapú szolgáltatás diviziót szolgálta. 2016-ban az IBM Bluemix, amely egy alkalmazás platform, magába olvasztotta a SoftLayer-t ezzel létrejött egy olyan cloud alapú szolgáltatás portfolio, amely olyan riválisokkal versenyez, mint az Amazon Web Services, a Google vagy a Microsoft. - Kognitív: Az IBM Watson szuperszámítógép, mely a mesterséges intelligenciát és az analitikus szoftvereket ötvözi, a vállalat zászlóshajójává vált a kognitív számítógépes kínálat terén. A Watson képes kognitív számítástechnikai komponenseket építeni a különböző alkalmazásokba. Az 47

IBM dolgozik azon, hogy ezt a technológiát összekösse a felhőalapú szolgáltatásaival. 4.2 Az IBM magyarországi tevékenysége Az IBM magyarországi története egészen a 70-es évekig nyúlik vissza. Az IBM első magyar leányvállalatát, a Watson Electronic Accounting Machines Kft-t még 8 munkavállalóval és 50 ezer pengő regisztrált tökével alapították az Amerikai Egyesült Államokban 1936-ban. Az elmúlt 70 évben a világ sokat köszönhet a technikai innovációk és fejlesztések terén az IBM-nek, amely nélkül ezek közül bizonyára sok nem valósult volna meg. Az IBM azon kevés cég közé tartozik Magyarországon, amely megőrizte relatív függetlenségét a kommunizmus idején, mivel a Magyar Népköztársaság hatóságainak szüksége volt a minőségi adattárolási rendszerekre és az egyéb IBM által kínált lehetőségekre. Az IBM-es eszközök fontosak volt az egykori kormányoknak, mivel az ország statisztikai adatait ezeken a gépeket dolgozták fel. 1995-ben az IBM úgy döntött, hogy egy új gyárat létesít Magyarországon (a már meglévő váci mellé), az IBM Storage Products Kft-t, amely Székesfehérváron kezdte meg a merevlemezek gyártását. A székesfehérvári gyártás 2003-ban állt le, így a váci telephely maradt az egyedüli működő gyár. Az IBM egyike az ország legrégebbi befektetőinek. Az IBM Data Storage Systems az IBM folyamatosan növekvő, Vácon elhelyezkedő egysége, amely 25 percnyi autóútra található a fővárostól. Ez az egyetlen hely a világon, ahol a cég a kiváló minőségű ESS alrendszereit gyártja. Ezek a gépek gyors és biztonságos megoldásokat kínálnak az európai, amerikai és keleti piacoknak. Az elmúlt években nagy változásokat hajtottak végre a hatékonyságnövekedés reményében a vállalatnál. Az egyik ilyen változás az IVM Global Services Kft, és a váci székhelyű IBM Data Storage Systems Kft. egyesülése IBM Data Storage Systems Information Technology Kft. néven, melynek a központja Vácon található. A váci és székesfehérvári telephelyen kívül megkezdte működését a budapesti egység is IBM 48

International Shared Services Center Kft. néven, ahol többek között a HR, könyvelés, beszerzés és pénzügy területek találhatóak meg (Dominó, 2015). 4.3 Az IBM székesfehérvári működése 1997-ben az IBM vezetése úgy döntött, hogy egyet a nyolc stratégiai, nemzetközi szolgáltató központjai közül Székesfehérvárra telepít azért, hogy innen szolgálhassa ki az IBM-es és nem IBM-es ügyfeleit. Nekik elsősorban az operációs rendszerek terén történő segítségnyújtást, adattárolást és rendszerhálózatok távfelügyeletét kínálja szolgáltatásként a cég mindezt különböző platformokon. Korábban ezt a tevékenységet Németországban végezték, onnan került át Fehérvárra ez a terület. A vállalat, amely jelenleg IBM Data Storage System Kft. néven működik, 1997 decemberében kezdte meg működését Székesfehérváron a világ egyik legnagyobb multinacionális információstechnológiai vállalat leányvállalataként. A vállalat fő célja ezzel az volt, hogy biztosítsa az IBM komputerizált globális hálózati rendszerének felügyeletét Magyarországról. A 90-es évek végén mindössze 20 emberrel kezdődött meg a vállalat fehérvári története. Egy évvel később 19 újabb kolléga csatlakozott a székesfehérvári site-hoz. 2001-ben a cég egy új épületbe költözött, ami a Videoton Ipari Parkban található, ezzel biztosítva azt a kapacitást, amire az egyre bővülő létszámnak szükséges volt. 2005-ben a Székesfehérváron működő IBM Global Services Kft. és a váci székhelyű IBM Data Storage Kft. egyesültek, ezzel jött létre az IBM Data Storage Systems Információstechnológiai Kft., amely ezentúl váci központtal, de két telephelyen működött. 2006-ban a fehérvári site-on már 650-en látták el napi feladataikat. A növekedések hatására az épület szárnyait is elkezdték bővíteni, 2007 márciusában megnyitották a második szárnyat. További feladatokat kapott a telephely, ezért a bővüléseknek köszönhetően újabb másfél szárnnyal kellett az épületet kiterjeszteni 2009-ben. Ekkor már 912 munkaállomás helyezkedett el a 7000 négyzetméternyi irodai területen. A következö mérföldkövet a 2009-es együttműködés kezdete jelentette a brno-i szolgáltató központtal, amellyel egy közös szervezeti struktúrát alakítottak ki és létrejött az Integrated Delivery Centre Central Europe, amely 4800 főt foglalkoztatott. 2010-ben aztán egy új marketinghullámnak köszönhetően minden Integrated Delivery 49

Centre-t Delivery Centre-re kereszteltek. 2015-ben, hogy a vállalat kihangsúlyozza az ügyfélközpontúságát és a globális stratégiáját, minden Delivery Centre-t IBM Client Innovation Center-re neveztek át. Ma az IBM Client Innovation Centre Szekesfehervar & Budapest több mint 1500 dolgozót foglalkoztat, amely a láthatóan nagyon jól elvégzett munkának köszönhetően várhatóan tovább növekszik majd. Az IBM Client Innovation Centre Szekesfehervar & Budapest kiváló lehetőségeket kínál azoknak a vállalatoknak, akik kiszerveznék az IT szolgáltatásaikat. Az itt dolgozó szakemberek szinte minden IT szolgáltatásokhoz kapcsolódó dolgokban a kliensek szolgálatára állnak, például szerver felügyelettel vagy IT biztonsági szolgáltatásokkal olyan platformokon, mint a MVS, VM, UNIX, Wintel vagy az iseries. Ami magát a konkrét munkavégzés típusát és feladatkörét illeti, a dolgozók általában adminisztratív, számítógép előtti munkakört töltenek be, ahonnan elláthatják a konstans, egész napos felügyeletet. Ez megköveteli a három műszakos munkarendet Székesfehérváron. Az egyéb, nem felügyeletet ellátó területek, mint például a HR, a pénzügy vagy a menedzser asszisztens pozíciók, normál, irodai munkarendben látják el a feladataikat. A vállalati struktúrában a dolgozókat közvetlenül a menedzserek irányítják, ők az adott terület vezetői, míg felettük az úgynevezett Managing Director áll (Dominó, 2015. ) 50

5 Az agilis módszertan bevezetése a székesfehérvári IBM telephelyen Az ötödik fejezetben bemutatom azt, hogy az agilis módszertan hogyan valósul meg az IBM székesfehérvári központjában. Elsőként kitérek arra, hogy mi történt a 2016-os évben, amely egyfajta tesztidőszakként szolgált a telephely életében, ezután rátérek arra, hogy mik a tervek a közeljövőre vonatkozóan. Ezt követően ismertetem azokat az agilis működést támogató eszközöket, melyeket Székesfehérváron alkalmaznak az IBM-nél. Végül bemutatok egy olyan projektet, ahol az elméletet átültették a gyakorlatba. 5.1 Projekt a 2017-es bevezetésre 5.1.1 A 2016-os év eredményei: A 2017-es projektterv elkészülését a 2016-os év felülvizsgálata előzte meg, amely inkább csak próbaként szolgált a székesfehérvári IBM központ agilis működésében. Az elért eredményeket a már ismeretett visszatekintő, restrospektív meetingeknél alkalmazott agilis technika segítségével mutatom be a következő, 2-es számú táblázatban. 51

2. táblázat: a 2016-os év eredményei Ami jól működött Számos osztály vett részt agilis tréningeken a 2016-os évben Pozitív visszajelzések érkeztek a tréningekről és a trénerekről A vállalat kommunikációs csapata motivált volt, több körlevél került kiküldésre Nagy termeket sikerült lefoglalni a tréningekre Szervezőgárdákat hoztak létre, élükre vezetők kerültek Ami nem működött jól Az alap tréningeken kevesen vettek részt Időhiány jellemezte a tevékenységeket A szervezőcsapatok a tesztfázis elindulásakor még nem voltak kialakítva A projekteken belül nem voltak világosan meghatározott feladatok, feladatkörök Ami zavart okozott a rendszerben A projekteken való részvétel önkéntes alapon működött csak A trénerek száma kevés volt A tréning anyagokat át kellett alakítani Forrás: saját készítésű ábra, interjúk Összességében a 2016-os évben több mint 350 emberrel sikerült megismertetni az agilis módszertant. Több csoport is kiemelt figyelmet kapott. A vezetői szint külön képzésben részesült, így mára már minden menedzser rendelkezik az agilis fejlesztés alapjaival, de az agilis csoportok vezetői is kaptak különböző oktatásokat. 52

5.1.2 A 2017-es év transzformációs tervei: A legfőbb terv az előttünk álló évre vonatkozóan az agilis módszertanban járatos kollégák számának növelése. Ennek érdekében a vezetőség azt tűzte ki célul, hogy a dolgozók nagyjából 70 %-ának részt kell vennie agilis tréningeken. E cél elérése érdekében egy négy lépcsőből álló programot alakítottak ki, amit a 11. ábra szemléltet röviden. 10. ábra: Az agilis transzformáció 4 lépése Forrás: saját készítésű ábra, interjúk A program első lépése során a résztvevők keresztfunkcionális csoportokat hoznak létre, melynek tagjaként a tréning folyamán végig együtt dolgoznak. Ez a fázis két részre bontható. Az első részben a program résztvevői részesülnek egy alapvető agilis oktatásban, amely során megismerik az agilis folyamatfejlesztés lényegét, technikáit, valamint azokat az IBM nyújtotta lehetőségeket, amelyek az agilis csoportokat támogatják a munkavégzés alatt. A fázis második felében a csoportok különböző feladatokat kapnak, ahol a feladat végrehajtása során az oktatás alatt tanult tudást kell a gyakorlatba átülteni. Mivel a keresztfunkcinális csoportok eltérő területről érkező szakamberekből állnak (egy-egy csapatban van IT specialista, HR-es munkavállaló, pénzügyes, stb.), így a megoldandó feladatok általában a mindennapi életből érkeznek, például egy város szerkezetének a megépítése, egy családi nyaralás megszervezése, stb. Az egyes csoportok mellett folyamatosan ott áll egy tréner, akinek a feladata, hogy segítse a csapatot abban, hogy minél inkább a korábban elhangzottakra támaszkodva oldják meg a feladatokat, illetve hogy ne térjenek el a témától. Az első fázis végére a dolgozók mind elméletben, mind gyakorlatban megismerik az agilis módszertan alapvető elemeit. 53

A második lépés során sokkal kisebb, azonban személyre szabottabb oktatáson vesznek részt a munkavállalók. Ennél a lépésnél már nincs alapozó oktatás, szigorúan a gyakorlatokra helyezik a hangsúlyt, sokkal mélyebben belemennek a részletekbe, mint az első fázis alatt. A harmadik lépésben a korábbi tréningeken részt vett csapatok implementálják a tanult praktikákat a saját működésükbe. Tapasztalt trénerek segítségével megvizsgálják a csapatok saját folyamatait, majd ezekben a folyamatokban keresik a hibákat az agilis gyakorlatok segítségével. A nap végére a csapat nehézségeire kell megoldást találniuk. A negyedik lépés során a csapat már képes önállóan alkalmazni a begyakorolt technikákat a napi operatív munkában, ám még itt is szoros az együttműködés a trénerekkel, akik segítik a csapatok munkáját. A négy fázisú program körülbelül hat hét alatt zajlik le. Egy-egy programban nagyjából 50 személy vesz részt. A tervek szerint 17 ilyen program fut majd 2017-ben. Ami a 2-es számú táblázatban láthathó nehézségeket illeti, a vállalat igyekszik tenni azért, hogy ezeket a 2017-es év programja kiküszöbölje. A tréningeken való részvételt a 2016-os évben önkéntes alapon végezték, míg 2017-ben már kötelező jelleggel kell a dolgozóknak megjelenniük az agilis alapokat átadó oktatásokon. Az időhiányt az okozta, hogy 2016 volt a tesztelés éve, hirtelen ötletként jött a bevezetés és így nem maradt idő egy jól megszervezett tervezet kialakítására. 2017-re már megvan ez a program, tehát ezt a nehézséget már szinte biztosan legyűri majd a cég. Ez a program tartalmazza a szervező csapatok teendőit és felépítését, ennek köszönhetően a szervező csapatok kialakításával, feladatkörével kapcsolatos kérdések is megválaszolásra kerülnek. A trénerek alacsony száma a 2017-es évre is problémát jelenthet, mivel ők juttatás nélkül, a mindennapi munkájuk mellett végezték és fogják végezni ezt a tevékenységet. Talán egy megoldást jelenthet majd, ha valamiféle pénzügyi támogatást biztosítana a vállalat, de ez még egyáltalán nincs tervben. Az utolsó zavart okozó tényező a tavalyi évben a tréninganyagok minősége volt. Ezt a Székesfehérvárra érkező nagytudású agilis tréner segítségével fogja a vállalat kiküszöbölni. 54

A létesítmény további tervei: - Egy központi agilis trénert kap maga a nagy projekt - Körleveleket küldenek a témában kéthetente - Folytatják a 2016-ban elkezdett Train the Trainer programot A projekt végrehajtásáért felelős szereplők: A székesfehérvári telephelyen kialakítottak számos fontosabb szerepkört, melyek feladata az agilis transzformáció elősegítése, ezeket a szerepköröket 11. számú ábra szemlélteti. Először is a projekt szponzoraként megjelenik a fehérvári központ vezetője. Maga az agilis folyamatfejlesztés bevezetése is egy agilis projekt, ami így saját project owner-t kapott. Az operatív szinten a legfőbb agilis vezetői szintet a szervezésért felelős csapatok vezetője tölti be. Alá négy nagyobb szervezői csoport tartozik. Egy csapat a kommunikációért felelős, egy az oktatásért, egy a bevezetésért és teljesítménymérésért, valamint egy a projekt ütemezésért. 11. ábra: Az agilis transzformáció legfőbb szereplői Forrás: saját szerkesztésű ábra, interjúk 55

5.2 Az IBM-nél leggyakrabban alkalmazott eszközök, melyek az agilis gyakorlatokat támogatják 5.2.1 Mural Számos gyakorlat igényli azt, hogy a résztvevők együttműködve, táblákra írva oldjanak meg bizonyos feladatokat. A Mural egy virtuális eszköz, ami ezt lehetővé teszi. Egy ideális világban a csapatok fizikailag egy helyen dolgoznak, ahol van lehetőség fehér táblákon megosztani egymással az ötleteket, ám ez nem mindig lehetséges. A Mural lehetőséget biztosít arra, hogy a résztvevők szabadjára engedjék elképzeléseiket és megosszák azokat annak ellenére, hogy nem tartózkodnak egy légtérben. 12. ábra: Mural-ban készített empátia térkép Forrás: Hawk, é.n. 56

A Mural-ban a dolgozók egyidőben módosíthatnak elemeket és mindenki azonnal látja a változtatásokat, emellett ezt az eszközt egy beépített csetfunkcióval is ellátták, sőt a döntéstámogatás érdekében még szavazást is le lehet bonyolítani a Muralon keresztül (Hawk, é.n.). 5.2.2 Slack A Slack egy felhőalapú, valós idejű, üzenetküldésre és értesítésekre alkalmas rendszer. Egy csetfunkciót tartalmaz, amely az e-mailhez képest egy interaktívabb alternatívát biztosít a csoportmunkákhoz. A csapattagok egy külön dedikált csatornán keresztül kommunikálhatnak a csapattal. A Slack fájlmegosztási lehetőséget is rejt magában. A beszélgetéseket a rendszer megőrzi, melyek között később kereshet a felhasználó. 13. ábra: A Slack Forrás: Saját készítésű kép A csapatok általában arra használják ezt az eszközt, hogy minimalizálják a zavaró tényezőket, mivel a kevesebb e-mail-t és személyes találkozót eredményez a használata. A Slack által biztosított csatornák rendkívül fontosak a fejlesztési műveletek összehangolásában, mert a nyílt csatornáknak köszönhetően folyamatosan informálódhatnak a csapattagok a fejlesztésről (Hawk, Bridges, é.n.). 57

5.2.3 Trello A Trello egy feladatszervező eszköz, amely a projekteket különböző virtuális táblákra helyezi, ahol nyomon lehet azokat követni. Ezeken a táblákon aztán megjeleníthetünk gondolatokat, feladatokat, stb. Rengeteg lehetőséget hordoz magában. Fájlokat csatolhatunk, ellenőrző listákat adhatunk hozzá, határidőket szabhatunk, címeket adhatunk a projekteknek, embereket rendelhetünk hozzá a feladatokhoz. 14. ábra: A Trello tool Forrás: Eric Griffin, 2013. 58