SCRUM Meetup

Március 10-én kollégáim társaságában részt vettem a JCI Fiatal Vezetök Egyesülete és a Budapest Agile Meetup közös szervezésében létrejött, Szoftver fejlesztési módszertanok a magyar valóságban című rendezvényen. Az eseményen lehetőség nyílt a szoftver fejlesztési módszertanokkal kapcsolatos tapasztalatcserére. A szervezők egy rövid csapatjátékkal indítottak, mely után két tanulságos esettanulmány hangzott el. Ráadásként pedig ízelítőt kaphattunk a szervezeti kultúrával kapcsolatos kérdésekből is, mert hogy gyakran az emberi tényezőt elég mostohán kezelik a szoftverfejlesztési folyamatban a technológiai tényezők mellett.

Az első esettanulmány témája nemzetközi banki szoftverfejlesztési folyamatokról szólt, melyben Szőke Ákos (Multilogic) bemutatta, hogy miként váltották fel a klasszikus vízesés modellt agilis módszerrel az ország legnagyobb bankjának hitelező rendszerének fejlesztése során. A szóban forgó projekt 2007 és 2010 között futott a 1949-es alapítású, a régióban terjeszkedő OTP banknál. Az IRIS (Integrated Risk Management System) valójában egy hitelezést támogató rendszer, amely elemző, döntéstámogató és monitoring funkciókkal bír, továbbá kockázatelemzéssel képes eldönteni, hogy egy ügyfél hitelezhető vagy sem. Funkciói közül kiemelendő az ügyfélnyilvántartás, fedezetnyilvántartás és adósminősítés.

Az alkalmazás 3 rétegű technológiára épül, .NET környezetben C# programnyelven fejlesztették, s a mögötte lévő adatbázis Oracle alapú. A rendszer óriási, akár a felhasználók számát nézzük, ami ezres nagyságrendre rúg, akár a kódsorok számáról van szó, amely több mint 3 millió. Nyolcszáz adatbázistábla tartalmazza az adatokat, továbbá 111.000 szereplőről és 130.000 ügyletről beszélünk.

A banki környezet különleges kihívások elé állítja a fejlesztőket, hiszen a programozói tudás mellett fontos, hogy értsék az üzletemberek nyelvét is. Szigorú bankbiztonsági szabályok vonatkoznak a munkára, így a hibajavításra is, és külön kihívás azoknak a szkripteknek az írása, amelyek garantálják, hogy a titkos banki adatok megfejthetetlenek legyenek. Maguk a fejlesztési szabályok is szigorúak, mindent specifikálni kell, és persze jóváhagyatni. A pilotok rendszerint hosszú nyúlnak, miközben szigorú határidőket kell betartani. Külön kihívás, ha egy politikai döntésnek köszönhetően olyan dolgokat kell bevezetni, mint mondjuk a Széchenyi Kártya, amellyel a hazai vállalkozókat kívánja támogatni a kormány.

A kommunikáció a banki projektek során különösen fontos, legyen szó akár személyes, akár szakmai témákról. A bizalmat ki kell vívni, amely csak a közös célok meghatározásával megy, továbbá csapatépítéssel, akár sörözések formájában. Az irányítás is nagy kihívás nemzetközi környezetben, s itt nem csak technológiai problémákról van szó, hanem például fordítási hibákról, vagy a cirill betűk okozta nagyobb ablakméretről.

A Multilogic szakemberei saját, SCRUM elvekre épülő fejlesztési módszertant alkottak, amelyben SCRUM szerű szereplőkről beszélnek:

development coordinator - SCRUM Master,
Product & QA - Product Owner,
Development Team,
és egy riportíró ember, mivel banki környezetben erre nagy az igény.
A termékek is SCRUM szerűek:

Orderlog + Development Unit - Product Backlog,
Backlog - Iteration Backlog,
Burndown Chart.
A dokumentációigény viszont igen magas: specifikációk, kézikönyv, részletes változásleírás, melyeket meg kell írni és jóvá kell hagyatni. Az issue menedzsment pedig Microsoft Sharepoint alapokon (Sherpa) történt.

A folyamat maga SCRUM alapú:

release, iteration planning - sprint planning,
iteration review - sprint review.
Viszont nincs rendszeres retrospective, napi megbeszélés és részletes követelménykezelés.

A kibocsátást különleges "ceremónia" kíséri, minden nyelvi változatra külön-külön és a manuális teszteket sem lehet elkerülni, a hosszadalmas engedélyezési folyamatról és a távtelepítésről nem is beszélve.

Érdekes volt még hallani, hogy a Multilogic fejlesztői a kanban elvek és lean szemlélet nyomán vizualizálták a teljes munkafolyamatot.

A fejlesztés tapasztalatai igazolták, hogy az agilis alapokon működő munkának köszönhetően csökken a csúszások száma, kevesebb a felesleges munka, és a változásokra gyorsabban lehet reagálni.

A rendezvényen hallottunk még érdekes dolgokat a Scrum Master nagyvállalati környezetben történő működéséről és az együttműködés alapú hatékonyságról, de a leggyakorlatiasabb előadás nagyon jól bemutatta, hogy milyen kihívásokkal és problémákkal kell megküzdeni nemzetközi banki környezetben, továbbá azt, hogy milyen is maga a fejlesztés folyamata.

Forrás: Spiller László IT Fejvadász Blogja

Hozzászólások

Ez tényleg egy it fejvadász blogja, láthatóan nem egy magyartanáré...
esettanulmány hol két szó, hol egy... (helyesen egy)
merthogy két szóban...
"agilis módszerrel, az ország" felesleges vessző
"hogy egy ügyfél hitelezhető, vagy sem" felesleges vessző
"Funkciói közül kiemelendő az ügyfélnyilvántartás, adósminősítés, fedezet nyilvántartás és adósminősítés.": és még adósminősítést is tud, no meg adósminősítést. Mondtam már, hogy adósminősítést is tud?
"A szóban forgó projekt 2007 és 2010 futott ": ez magyarul úgy van, hogy ? 2007 és 2010 között?
130 ezer ügylet az nem óriási, hanem bemelegítő jellegű egy rendesebb oracle adatbázisnak.
"Nyolcszáz adatbázis tábla" itt a nyolcszáz minek a jelzője? kiderülne, ha azt a felesleges szóközt kivennéd... 800 adatbázistábla.
"mindent specifikálni kell, és persze jóváhagyatni": ez helyesírás szempontjából elmenne, de hogy magyartalan, az biztos...
"pilotok rendszerint hosszú nyúlnak": ahha...

-1
Kapcsolodo idezet:

Szóval, röviden: egy blogon a helyesíráson rugózni nem menő. Sőt, gáz. A blog ugyanis hagyományosan egy rendkívül kötetlen dolog. Az oké, ha ez valakinek nem tetszik, de akkor sem az a megoldás, hogy megpróbálod a műfaj művelőit rávenni arra, hogy egy másik műfaj szabályrendszerét alkalmazzák - értsd: hülye vagy, ha a szabadversből hiányolod a rímet.

-Leiter Jakab, http://leiterjakab.blog.hu/2010/01/06/a_helyesirasrol

--
Auto correct can go straight to He'll.

Tudod, az a baj, hogy egy elég komoly pozícióban lévő IT-s barátom átnézte, de neki sem tűntek fel a hibák.

Én meg annyira gyorsan írok, hogy rengeteg hibát ejtek. Meg hát 4-es helyesíró voltam. Lehet, hogy most max kettes lennék?

Lényeg, hogy kijavítottam.

Spiller László IT Fejvadász
Blog: http://spillerlaszlo.wordpress.com/