Tóth Bálint Rudolf (2020) Agilis szoftverfejlesztés a középvállalati szektorban - Az AgileXpert Kft. saját fejlesztésű szoftverének termékfejlesztési folyamatait támogató módszertani és technológiai háttér kidolgozása a piacra történő bevezetés előkészítéséhez. Pénzügyi és Számviteli Kar.
PDF
toth_balint_rudolf_K9P2YR_szakdolgozat.pdf Hozzáférés joga: Csak nyilvántartásba vett egyetemi IP címekről nyitható meg Download (15MB) |
|
Archive (ZIP)
toth_balint_rudolf_K9P2YR_szakdolgozat_burn_down.xlsx.zip Hozzáférés joga: Csak nyilvántartásba vett egyetemi IP címekről nyitható meg Download (109kB) |
|
PDF
BA_TO_toth_balint_rudolf_K9P2YR.pdf Hozzáférés joga: Csak nyilvántartásba vett egyetemi IP címekről nyitható meg Download (318kB) |
Absztrakt (kivonat)
Dolgozatom céljának az AgileXpert Kft. jövőbeli húzótermékének szánt AXAMOP szoftver fejlesztési folyamatainak optimalizálására történő javaslattételt tűztem ki. Ennek első lépése, a projekt tárgyának és körülményeinek pontos meghatározása volt. A projekten jelenleg a fejlesztést két junior kolléga végzi, akik munkáját két tapasztalt munkatárs ellenőrzi és segíti. A koordinációs, problémaelhárító, valamint az ügyfél nézeteit képviselő feladatokat a csapat vezetője látja el. Ezen felül egy tesztelő kolléga segíti a projekt működését. A fejlesztés a scrum szabályaival extrém programozási eszközök segítségével folyik.A folyamat vizsgálatának és optimalizálásának első lépése az volt, hogy van-e szükség a teljes gondolkodásmódot átalakító, agilitást elhagyó változtatásra. A vizsgálatok alapján kiderült, hogy ezt semmi sem indokolja, sőt kifejezetten hátrányos lenne a folyamatok számára. Megvizsgáltam az agilitás jelentősebb irányelveit, ide sorolva az Extrém programozást, a Dinamikus rendszerfejlesztési módszert (DSDM), a Lean fejlesztést és a Kanbant. Minden módszertan tartalmaz olyan eszközöket, amelyek felhasználhatók az AXAMOP fejlesztésében. Az extrém programozás elemeit eddig is használta a csapat így azoknak a felülvizsgálata volt szükséges. A Dinamikus rendszerfejlesztési módszer alapelvei segíthetnek a megfelelő gondolkozásmód kialakításában, a lean fejlesztésből a felesleges költségek felkutatását és megszüntetését az, amely felhasználásra érdemes, az optimalizálási folyamatban. A kanbanból pedig a Work in progress (WIP) maximalizálása, valamint az átfutási idő mérése felhasználandó eszköz. Az újonnan bevezetendő módszereken felül szükséges a jelenlegi eszközök felülvizsgálata és optimalizálása is. Az eddigi futamok vizsgálata alapján kiderült, hogy az utolsó két futam tekinthető „szabályos” scrum. Így tényleges következtetést ezekből lehet levonni. Ezek azt mutatják, hogy jelentős mennyiségű feladat nem készül el a futamok alatt. Okát két fő tényezőre lehet visszavezetni. Az első a tesztkörnyezet nem megbízható futása. A vállalat nagyon nagy hangsúlyt fektet a kód minőségére, így jelentős minőségbiztosítási folyamattal rendelkezik minden projektje, így az AXAMOP is. Ilyen minőségbiztosítási eszköz a magas szintű integrációs tesztlefedettség. Gyakori az olyan teszt futtatás amikor - habár nincsenek ténylegesen hibát jelző tesztek – rendellenességet mutat a tesztrendszer, így nem engedi tovább a fejlesztést. Ennek mielőbbi kivizsgálása kulcsfontosságú. A másik késést okozó jelentős tényező a sprintek tervezésének pontatlansága. Erre megoldás lehet, a sprint tervezésének két részre bontása. A tényleges tervezés előtti napon, az előző ügyfél demo napján tart a csapat egy „előtervezést”, amelyen meghatároznak egy nagyjábóli feladatcsomagot, amit el szeretnének végezni a következő sprint alatt. Másnap kora délután tartandó tényleges tervezésig átgondolják a feladatokat, majd készítenek minden feladatra egy várható erőforrásigényt. Ezeket a várható erőforrásigényeket a tényleges tervezésen egyesítik, megvitatják és azok alapján hozzák meg a tényleges döntést.Továbbá nem elhanyagolható optimalizációs lépés, a kommunikáció javítása a feladatok különböző állapotainak felelősei között. A feladatok különböző állapotaiért a felelősség megoszlik a csapat tagjai között, de az állapotok közötti feladatmozgás nem jár azonnali információ áramlással. Erre megoldást integráltan nyújt az agilis tábla fenntartását végző szoftver, a Jira. Minden feladat, amelyet elmozdítanak a To Do állapotából rendelkezik egy felelőssel, amit lehet módosítani. Így amikor az adott cetli átkerül az egyik oszlopból a másikba módosítani kell a felelősét, így aki megkapta a feladatot azonnal értesítést kap e-mail formájában a rendszertől, hogy valaki egy feladatot jegyzett a nevére.Az eddigieken felül optimalizálási lehetőséget rejt még magában a tesztfuttató környezet. A megfelelő működése esetén is több mint egy óra alatt képes csak lefuttatni minden integrációs tesztet. Ezt újabb szerverbe való beruházás segítségével lehet akár fél órára csökkenteni, amely hiba esetén többszöri futtatást is tartható keretek közé terel.A következő fejlesztendő tényező az maga a humánerőforrás készlet. Ez okozza többek között a futamok késését és a projekt előre haladásának lassú tempóját is. Első lehetőség, hogy a fejlesztő kollégákat le kell cserélni nagyobb tapasztalattal rendelkezőkre. A vizsgálatok során kiderült, hogy ez nem jelent megoldást a problémára, ugyanis hiába nagyobb az általános tudása az újonnan felvett alkalmazottaknak, ha a projektben való jártassága, jóval csekélyebb. Ezen lemaradás bepótlása akár fél évet is igénybe vehet, amely idő alatt a jelenlegi fejlesztők a vizsgálatok alapján közel 50% fejlődésre képesek. Így mire a megfelelő mértékben betanulnának az új munkatársak addigra a jelenlegiek is képesek lennének felfejleszteni magukat olyan szintre, hogy ne érje meg a tapasztalt fejlesztők extra bérigényét kifizetni. Ezzel szemben a csapat bővítése jó megoldás lehet, ugyanis az nem jár kiemelkedően magas extra költséggel és a teljesítményben sem okoz hullámzást, csak a növekedés mértékét emeli előrejelzések alapján nemsokkal a bekerülése után már 25%-kal.Továbbá megvizsgáltam az agilis projektmenedzsment szoftverek kínálatát és az projekten használt rendszert, a Jira-t hasonlítottam össze, a VersionOne-nal. Az összehasonlítás eredménye azt mutatta, hogy a váltás nem ajánlott, hiszen az utóbbi alkalmazás csak és kizárólag Windows operációs rendszert támogat és a projekten a fejlesztők Linux-on dolgoznak.Az eddigi optimalizálásokon felül a projekt folyamataiba új eszközök felvételét is ajánlottam. Az első ilyen eszköz a Work in progress maximalizálása. Javaslatomban erre a hármat határozom meg, ugyanis a két fejlesztő egy-egy feladata és ezen felül egy, hogy ha egy későbbi állapotban is elérte a maximumot, akkor ne kelljen megállítani a fejlesztést, hanem határok között ugyan, de folyhasson tovább. Ezzel teljes mértékben elkerülhetők a megakadt feladatok, hiszen addig nem mehet kezdhet újat, ameddig meg nem oldja azt.A másik ilyen bővítő eszköz az átlagos átfutási idő mérése, amely a feladat elkezdésétől a funkcionális tesztelés befejeztéig eltelt időt méri. Ez a sprintek tervezésében, valamint értékelésében tud segítséget nyújtani, oly módon, hogy tendenciáját vizsgálva lehet a csapat hatékonyságának változását mérni.
Intézmény
Budapesti Gazdasági Egyetem
Kar
Tanszék
Gazdaságinformatika Tanszék
Tudományterület/tudományág
NEM RÉSZLETEZETT
Szak
Mű típusa: | diplomadolgozat (NEM RÉSZLETEZETT) |
---|---|
Kulcsszavak: | AgileXpert Kft., agilis módszertan, burn-down diagram, kanban, optimalizálás, SCRUM, SWOT-elemzés |
SWORD Depositor: | Archive User |
Felhasználói azonosító szám (ID): | Archive User |
Rekord készítés dátuma: | 2021. Már. 16. 12:59 |
Utolsó módosítás: | 2021. Már. 16. 12:59 |
Actions (login required)
Tétel nézet |