Bíró Tamás

– Mennyiben más egy klasszikus fejlesztési projekt és az agilis szoftverfejlesztés?

– Jobban szeretem az eredeti angol „agile” kifejezést, mert az, a magyarral ellentétben, nem annyira a mozgékonyságra, mint inkább a rugalmasságra, alkalmazkodóképességre utal. De a kérdésre válaszolva: nagyon mély elméleti és gyakorlati különbségek léteznek. Az egyik legfontosabb, hogy az agile módszertan a működő szoftverre koncentrál, és nem a tervdokumentációt, a specifikációt akarja minél jobban kidolgozni. Fontos még, hogy az embereket és kapcsolataikat többre értékeli, mint a formális folyamatokat és eszközöket. Ugyancsak megkülönbözteti más módszerektől az ügyfelekkel való szorosabb együttműködés. A magyar megrendelők többsége – tisztelet a kivételnek – már-már ellenfélként kezeli a beszállítót, mert a korábbi rossz tapasztalatok miatt hiányzik a bizalom a két fél között.

– Hogyan tudja megteremteni egy módszertan a bizalmat?

–Nem a módszertan teremt bizalmat, hanem az általa fontosnak tartott, kendőzetlen őszinteség. Nem lehet egy összetett szoftverprojektről előre megmondani, hogy pontosan mikor készül el minden elemében, és pontosan milyen lesz. Ezért aztán a fix árra és határidőre szóló szerződések voltaképpen hazugságokra épülnek – és ezt az ügyfelek is tudják. Ezzel szemben az agile a transzparenciát hirdeti. Bevallja, hogy nem tudja, mi és mikorra fog elkészülni, de a legjobbra törekszik. Az egyik agile módszertana, a SCRUM például a projektet kicsi, 10–30 napos szakaszokra, úgynevezett sprintekre bontja, és minden szakasz végén már valami működőképeset mutat. A fejlesztő gyakran találkozik és egyeztet az ügyféllel, nem pedig arról van szó, hogy kap egy specifikációt, és a megrendelő hónapok múlva jön vissza a kész szoftverért.

– Nem vesznek el így a részletekben, hogyan képesek látni a nagy képet?

– Természetesen van távlati jövőkép, tudjuk, hogy hova akarunk eljutni, csak éppen nem készítünk gigászi specifikációkat. Egy több hónapos munkával elkészített, nagyon részletes, ezeroldalas specifikáció óhatatlanul hemzseg az ellentmondásoktól, ráadásul az üzleti környezet és a felhasználói igények változásai miatt már akkor elavult, amikorra elkészült.

Az agile módszertanban csak a következő sprinthez készül pontos specifikáció, és minél messzebb van egy feladat, annál kevésbé részletesen van kidolgozva. Így az adott sprint specifikációja mindig a már elvégzett munkán alapul, az aktuális igényeket tükrözi, és a fejlesztők akár fejben is tudják tartani. A nagy előny a rugalmasság: a még el nem készült feladatokon bármikor változtathatunk, elhagyhatunk belőlük, újakat vehetünk fel helyettük, nem köti a kezünket a kőbe vésett specifikáció.

– Hogyan lehet a nagy rugalmasságot szerződéses keretek közé önteni?

– Mi is fix összegre szerződünk, csak éppen a műszaki tartalmat nem határozzuk meg szigorúan. Egy kétnapos feladatot bármikor ki lehet cserélni egy másikra vagy két darab egynaposra. Ráadásul a szoftver már azelőtt üzleti értéket termelhet, hogy teljesen elkészülne. Még az is elképzelhető, hogy mire eljutunk az összes sprint feléig, a szoftver már olyan jól működik, hogy a további elemekre nincs is igazán szükség, mert kevesebb hasznot hoznának, mint amennyibe kerülnének. Ilyenkor a fennmaradó összeget fel lehet használni valami másra, ami nagyobb hasznot hoz.