Boldog Árpád, a HumanoIT ügyvezető igazgatója

– Tulajdonképpen igen. Az agilis szoftverfejlesztési módszertan főbb jellemzői közé tartozik, hogy kis lépésekben haladunk, a menet közbeni változtatást nem bûnnek, hanem erénynek tartjuk, elfogadjuk a tévedés lehetőségét, és rendkívül nagy hangsúlyt fektetünk a kommunikációra. Ugyanezeket az elveket kell megvalósítani az agilis projektmenedzsmentben is.

– Miben más az agilis projektmenedzsment?

– A hagyományos módon végzett projekteket hosszú tervezési szakasz előzi meg: a szerződést csak akkor írják alá, és a tényleges munka csak akkor kezdődik, amikor elkészült a végleges(nek szánt) specifikáció.

Az agilis projekteknél a hosszú, több hónapos vagy éves, tervezési szakasz elmarad. Ebben az esetben is szükség van egy rövid koncepcionálásra, specifikálásra, de ezt néhány hét alatt el lehet végezni, amiben kiemelt jelentősége van az ügyfél képviselőjének részvételére. A fent kidolgozott irányoknak megfelelően rövidtávú, kisebb, kézzel fogható feladatokat kell meghatározni, megvalósítani, ellenőrizni, elfogadni, tehát elvégezni.

A félreértések elkerülése miatt itt emelem ki, hogy az agilis mûködés nem ad hoc megközelítés, hanem komplett módszertan: kerettel, folyamatokkal, kontrollokkal, minőségmérésekkel.

Az ügyfélnek van bizonyos elképzelése, hogy mit szeretne, ezt elmondja, a másik fél igyekszik megérteni és minél gyorsabban megvalósítani. A szállító, a fejlesztő rövid időn belül előáll valamivel, megkérdi a megrendelőt, hogy ezt szeretted volna? Ha igen, folytatják, ha nem, változtatnak, és folyik tovább a munka.

– Ilyen körülmények között hogyan oldható meg a hosszú távú tervezés?

– Ha szükség van valamire, utólag is be kell emelni a projektbe, és ellenkezőleg, el kell fogadni, hogy ha valami nem jó – ilyenkor bizony ki kell dobni, bele kell törődni, hogy bizonyos időt és pénzt elvesztegettünk. De ez rendszerint sokkal kisebb, mint a hagyományos projektmenedzsmentek esetén, ahol általában túl későn jönnek rá, hogy valaminek nem úgy kellene lennie, és akkor már csak óriási költségekkel lehet módosítani. Egy agilis projektben sohasem a valamikor régen lefektetett terveknek kell megfelelni, hanem a mindig aktuális és éppen ezért változó ügyféligényeknek.

– Mennyiben igényel más hozzáállást az agilis projekt a megrendelő és a szállító munkatársaitól?

– Az egyik különbség a hagyományos módszertanokhoz képest, hogy az ügyfél képviselője is a kezdetektől fogva aktív részese a mindennapi projektmunkának. Nem abból áll a feladata, hogy a fázis elején kiadja a munkát, majd időszakonként értékeljen; és csak adott fázisok végén az átvételi teszteknél vagy a dokumentáció elfogadásánál „kerül elő”, hanem folyamatosan és aktívan részt vesz a munkában. Optimális esetben az ügyfél munkatársa beül a fejlesztőcéghez, és ott napi szinten hoz döntéseket – azért, mert ő tudja a legjobban, hogy a megrendelő igényeit milyen módon kellene kielégítenie a vállalkozónak.

Az agilis projektvezetés erősen bizalmi viszonyt tételez fel a két fél között. A szállító abban érdekelt, hogy valóban használható megoldást szállítson le az ügyfélnek – még akkor is, ha ugyanazért a pénzért, ugyanakkora munkával szállíthatna olyat is, ami éppen csak a specifikációnak felel meg, de a tényleges ügyféligényeknek már nem. Egy agilis projektnek nem az a lényege, hogy minél kevesebb munkával, minél több pénzért szállítsunk le valamit. Az ügyfél oldaláról meg ahhoz kell bizalom, hogy ezt a hozzáállást el is higgye partneréről.