Agilis Szoftverfejlesztök Egyesülete

K

Üdvözlöm Magyarországon. Mi volt budapesti látogatásának célja?

V

A mai konferenciára jöttem.

K

Az agilis szoftverfejlesztés miért és miben különbözik a hagyományos módszerektől?

V

Véleményem szerint van néhány alapvető különbség. Először is az, hogy az agilis szoftverfejlesztés rendkívüli együttműködést igényel. A munkatársak együtt fejlesztik a szoftvert, nem egyszerűen dokumentációkat gyártunk, és azokat egymásnak átadjuk, hanem egymás mellett dolgozunk a fejlesztésen. Ez tehát egy fontos különbség. Továbbá jelentősen jobb kapcsolatot alakítunk ki az ügyfeleinkkel, és megrendelőink maguk is a fejlesztési folyamat aktív résztvevői, tehát megkeressük azokat az eszközöket és technikákat, melyekkel lehetővé válik az ügyfelek bevonása. Ezen felül nagy értéket képviselő tevékenységekre is koncentrálunk, az agilis szoftverfejlesztés során azt szoktuk mondani, hogy ez tulajdonképpen az el nem végzett munka maximális kihasználásának művészete. Szerintem a hagyományos fejlesztők hajlamosak sokkal több dokumentációt előállítani, mint amire szükségük van, és sokkal több vizsgálatot és értekezletet tartanak, mivel túl sok szakember van a csapatban, akiknek sokkal több feladatot kell elvégezniük, mintha általános szakemberek, (www.agilemodeling.com/essays/generalizingSpecialists.htm) lennének, akiket akár hívhatunk reneszánsz fejlesztőknek, illetve mesterembereknek. Ezek tehát szerintem a legfontosabb különbségek. `

K

Hogyan tudná meghatározni a különbséget a laikus, tehát nem szakember számára?

V

Úgy gondolom, hogy bizonyos szempontból az agilis szoftverfejlesztés nagyobb nehézséget jelenthet a túlságosan specializált szakemberek és a kezdők számára. Az a fontos, hogy az ember hajlandó legyen új technikákat megtanulni, és azt is meg kell érteni, hogy a feladatok széles skáláját kell elvégezni. Azok tehát, akik csak adatbázisokkal akarnak foglalkozni, felhasználói dokumentációt akarnak írni vagy javaban akarnak programozni, az agilis fejlesztést és az agilis környezethez való alkalmazkodást meglehetősen nehéznek fogják találni. Az ügyfél számára is vannak különbségek, és sok pozitív tényezőt találunk. A pozitívumok közé sorolható, hogy ideális esetben az agilis fejlesztők sokkal hatékonyabbak, mint a szoftverfejlesztők általában, nagyobb értéket hoznak létre az informatikai befektetés szempontjából, valamint sokkal szélesebb körű irányítást adnak a részvényesek kezébe, akik így meghatározhatják, hogy mennyi pénzt költsenek, mi legyen a fejlesztés tárgya, és rendszeres időközönként (minden iteráció végén) működő szoftvert látnak. Ezáltal nincs több titokzatosság, a fejlesztők nem tudnak elrejteni dolgokat. Az agilis csapatban minden egyes iteráció végén (melyek gyakran egy-két hét hosszúságúak) működő szoftvert mutatunk be, míg a hagyományos csapatban hónapokig, vagy akár évekig is tarthat, míg működő szoftvert látunk, ha ez egyáltalán bekövetkezik. Ezért gondolom azt, hogy a részvényeseknek sokkal nagyobb átláthatóságot biztosítunk az agilis csapatban. A kihívás itt az marad, hogy ragaszkodunk a részvényesek aktív részvételéhez, akiknek így napi rendszerességgel kell jelen lenniük a fejlesztésnél. Ezért tehát, ha valaki egy követelmény-specifikációt akar nekünk adni, aztán egy év múlva vissza akar jönni, hogy az átvételi tesztelést elvégezze, nos, ez nem igazán működik. A hagyományos csapatok működnek így, és a tapasztalat szerint ez a módszer a gyakorlatban elég csúnyán megbukott.

K

Milyen követelményeket támaszt az agilitás a fejlesztőkkel szemben?

V

Szerintem fontos a nyitottság és az alapvető informatikai tudás is. Tudni kell például szoftvert fejleszteni. Az igazán fontos tényező azonban a nyitottság, valamint a hajlandóság a többiekkel és az ügyfelekkel való együttműködésre. Ha ezek a feltételek teljesülnek, akkor nem lehet baj.

K

És mi a helyzet az agilis ügyfelekkel?

V

Igen, az ügyfeleknek is agilisaknak kell lenniük. Hajlandónak kell lenniük arra, hogy a megfelel? id?ben szolgáltassanak információt, meghozzák a döntéseket, és felelősséget vállaljanak azért, amit tesznek. Nos, ez olyas valami, ami nehéz, és amit sokan nem akarnak vállalni. Sokan nem akarnak felelősséget vállalni, és ez igazi nehézséget jelenthet. A hagyományos fejlesztés során a részvényesek és az informatikusok is könnyen bújhatnak ki a felelősség alól. Mindig van lehetőség arra, hogy egymást hibáztassák, és ezt gyakran meg is teszik.

K

Igazi paradigmaváltásról van szó? Valóban nagy változást jelent az agilis fejlesztés a hagyományoshoz képest?

V

Igen. A nagy változást az jelenti, hogy együttműködően kell dolgozni, rendszeresen élő szoftvert kell fejleszteni, és el kell fogadni, hogy nem kell és nem is lehet rögtön az elején mindent pontosan megérteni. A hagyományos fejlesztés világában az egyik legnagyobb hazugság az, hogy a fejlesztők azt hiszik, hogy az életciklus korai szakaszában meg tudják határozni a követelményeket. Ezzel szemben a gyakorlat azt mutatja, hogy nem tudják. Az emberek nem igazán tudják meghatározni, hogy egyáltalán mit is szeretnének. Ha pedig azt nézzük meg, hogy mi lesz a fejlesztés eredménye, a Káoszjelentés szerint a hagyományos projektekben a fejlesztés közel 2/3 része veszik kárba (www.agilemodeling.com/essays/examiningBRUF.htm). Engem aggodalommal töltene el, ha a befektetésem 2/3 része kárba veszne, de úgy tűnik, hogy a hagyományos csapatokat ez nem zavarja. Változásra van szükség.

K

Milyen különleges problémákkal találkozik a gyakorlati munkája során?

V

Szerintem az agilis csapatok számára a nehézséget az jelenti, hogy hagyják őket agilisan működni. Számos agilis csapatot az informatikai szervezeten belül olyanok vesznek körül, akik nem agilisak, így az agilis csapat arra kényszerül, hogy úgy tegyen, mintha CMMI szerint dolgozna. Ezen felül az ügyfelek nem akarnak felelősséget vállalni, és nehéz őket aktív részvételre bírni a projektben. Ami pedig még rosszabb, az az, hogy az adatbázis-kezelők csapata nagyon rugalmatlanul dolgozik, mindent nyugodtan, sorozatban akarnak tenni, aminek az az eredménye, hogy nagyon lassúak, ez pedig nehézségeket okoz. Számos szervezet részére a kihívást az jelentheti, hogy végül az egész informatikai osztálynak agilissá kell válnia, vagy legalábbis az osztály nagyobb részének hajlandónak kell lennie agilisan dolgozni, amikor ez szükséges, és ezt szerintem a vállalatok nem értik meg. Úgy gondolom, hogy az agilis közösségnek jobban kell segítenie az ügyfeleket, hatékonyabbá és agilisabbá kell válnia, ehhez pedig idő kell.

K

Az agilis szoftverfejlesztést öt évvel ezelőtt jelentették be. Még mindig csak fellángolásról van szó, vagy tekinthetjük azt bevált gyakorlatnak?

V

Szerintem éppen most kelünk át a szakadék felett. Ha megnézzük Geoffrey Moore könyvét, melynek címe „Átkelés a szakadék felett”, azt látjuk, hogy a szerző arról beszél, hogy a vizionáriusok és a korai elfogadók miként fogadják el ezeket az új technikákat. A könyv azután ahhoz a ponthoz ér, amikor azt látjuk, hogy a technikák eladása a korai tömeg, sőt még a később elfogadó tömeg számára is egy teljesen különböző ajánlatot igényel. Így tehát, szerintem, az iparág éppen most kel át a szakadék felett, és azt kell kitalálnunk, hogy miként tudjuk a korai és a későn elfogadó tömeg számára az eladást biztosítani. A válasz tehát a kérdésére az, hogy szerintem igen. Az agilis technikák már bevált gyakorlatnak tekinthetők néhány jobb vállalatnál, így tehát a valódi kérdés az, hogy „az adoptációs görbe jobb oldalán elhelyezkedők is válhatnak agilissá?” Szerintem mindez időbe telik. Az iparágnak 15-20 évbe telt, amíg elfogadta az objektum technológiát, és jelenleg ugyanezt az elfogadási ütemet tapasztaljuk az agilis közösségen belül. Még most is vannak olyan szervezetek, amelyek az objektum technológiával küzdenek, pedig annak népszerűsítése már legalább 15-20 évvel ezelőtt megkezdődött, ezért szerintem csak reális elvárásokat támaszthatunk.

K

Azt tudjuk, hogy az agilis szoftverfejlesztés nagyon erős az Egyesült Államokban és Európában, de mi a helyzet Ázsiában és Japánban?

V

Ebben a térségben jelenleg az agilis szoftverfejlesztés tanulmányozása folyik. Közel egy éve jártam Indiában és azt tapasztaltam, hogy néhány vállalat komolyan elgondolkozik rajta. A korlátozást számukra az ügyfélkör jelenti, mivel az ügyfelek nem agilisak, nem értik, hogy miről is van szó. Azok a vállalatok, amelyekkel beszéltem valóban agilisabbak akarnak lenni, és megpróbálják a technikát megérteni, azonban nincs még meg az a lehetőségük, amit szeretnének. A TATA nemrégiben kezdte el használni az „agilis” szót a marketing-irodalomban, ezért szerintem egy irányvonal kezdetének vagyunk most tanúi. Az utazásom során jártam Japánban, Malajziában és Szingapúrban is, és azt tapasztaltam, hogy ezek az országok is tanulmányozzák az agilis fejlesztést, esetükben azonban különböző kultúrákról és különböző időkeretekről beszélünk. Alapvetően úgy gondolom, hogy aki szoftverfejlesztéssel foglalkozik, vagy azért fizet, annak tanulmányoznia kell, és komolyan kell vennie az agilis technikát, mivel az értékajánlat nyilvánvalóan jelen van.

K

Hogyan látja az agilis szoftverfejlesztés hosszú távú jövőjét? Milyen pályát képzel el?

V

Szerintem a szoftverfejlesztésben jelenleg számháború folyik. Észak-Amerikában azt tapasztalom, hogy a csapatok azért válnak agilissá, mert komoly küzdelmet folytatnak az outsource-ot végrehajtó cégekkel. A vállalatok vagy Észak-Amerikában végeznek agilis szoftverfejlesztést, vagy pedig egyre inkább kihelyezik ezt a feladatot Indiába, esetleg Brazíliába, vagy akár Kanadába. Ez utóbbi országokban a munkaerő olcsóbb, így a küzdelem tényleg számháborúvá válik. Azt is tapasztalom, hogy öt vagy tíz agilis fejlesztő ugyanannyira hatékonyan dolgozik, mint egy ötvenfős CMMI fejlesztői csapat. Egyszerűen nem találom életképesnek a CMMI-alapú technikákat olyan környezetben, ahol jelentős összegeket fizetnek ki a munkáért. Ez egyszerűen nem működik így, ezért azt gondolom, hogy legalábbis Észak-Amerikában és Európában vagy a fejlesztői csapat válik agilissá, vagy az a helyzet alakul ki, hogy a munkát olyan helyre szervezik ki, ahol az olcsó munkaerőpiacokon sok fejlesztés folyik, és távolról csak a projekt vezetésére és a kiszervezett csapattal folytatott interakcióra van szükség.

K

Mi az Agilis Szoftverfejlesztők Szövetsége és az agilis mozgalom szerepe?

V

Egyre erősebbek és mindig is információforrásként szolgáltak; az Agilis Szoftverfejlesztők Szövetségének weboldala (www.agilealliance.com) pedig mindig is az elsőszámú hely volt, ahová az ember információért fordulhatott. Jelenleg konferenciákat valamint, ha jól látom, oktatásokat támogatnak. Ezen felül, legalábbis a színfalak mögött, olyan találkozóhelyként szolgálnak, ahol az agilis mozgalom értelmi vezetői eszmét cserélhetnek, kitalálhatják, hogy egyrészt miként adjuk el a technológiát az adoptációs görbe jobb oldalán elhelyezkedőknek, másrészt pedig, hogy hogyan győzzük meg a CMMI terméket fogyasztó nagyvállalatokat, akik lassan ez „meg is mérgez”, hogy váljanak egészségessé. A hagyományos technikák mögött hatalmas marketing gépezet áll, és óriási kulturális tehetetlenséget is tapasztalunk.

Az egyik kedvenc témám az adatbázis-kezelők közössége. Náluk nincs a nagyobb hatékonyságot és nagyobb agilitást megcélzó koherens szellemi vezetés, és még mindig a hetvenes évek szemléletét követik. Tényleg nem értik, hogy miről van szó, egyre inkább mellékvágányra kerülnek, és az idő haladtával egyre kevésbé fontossá válnak, és mindeközben ezt nem veszik észre. Olyanok, mint az egyszeri béka a fazékban, amikor a víz lassan melegszik, de a béka csak akkor veszi ezt észre, amikor már megdöglött. A víz most az adatbázis-kezelők közössége alatt forr, és úgy tűnik, hogy mindezt nem veszik észre.

Az Agilis Szoftverfejlesztők Szövetsége nulla marketing költségvetéssel dolgozik, mégis versenyképes marad azokkal a szervezetekkel, akik mögött több millió dolláros marketingforrás van, így mindezt érdekes tapasztalni.

K

Mi volt a benyomása a magyar agilis fejlesztőkről?

V

Néhány meglehetősen jó tapasztalatom volt. Szerintem a helyzet nem könnyű, és vannak olyan kulturális kérdések is, amelyekkel meg kell küzdeniük, de az a fontos, hogy az emberek megértsék, hogy szorosan együtt kell működniük másokkal, és akkor nagyobb hatékonyságot érnek el. Ugyanez elmondható sokakról az Egyesült Államokban is, tehát ez nem újdonság itt. Szerintem érdemes egyáltalán azt megérteni, hogy az agilis fejlesztés tényleg létezik. Lehet, hogy Magyarország kisebb piacot jelent, és a hagyományos fejlesztés támogatói nagyobb hatást gyakoroltak, mint amit megérdemelnek, ezért kissé nehezebb talán új elképzeléseket behozni, de úgy tűnik, hogy a dolgok a helyes irányban haladnak. Tudja, jártam itt néhány évvel ezelőtt, és úgy látom, hogy nyilvánvaló fejlődés történt. A mai konferenciára látogatók érdekesnek találták az agilis csoportot. 17h-kor kezdtünk, és sokan egyszerűen ott ragadtak a saját magánidejükben, ami figyelemre méltó. Ezért gondolom, hogy jó dolgok történnek itt.

K

Köszönöm, hogy válaszolt a kérdéseimre.

V

Én köszönöm a lehetőséget.