Az agilis fejlesztés az informatikusok számára olyan, mint az Eldorádó: mindenki arról beszél, mindenki azt akarja csinálni, de senki nem látta. A valóságban pedig... khmm... a valóság nem vett tudomást az informatikusokról.

Az agilis fejlesztés az informatikusok számára olyan, mint az Eldorádó: mindenki arról beszél, mindenki azt akarja csinálni, de senki nem látta. A valóságban pedig... khmm... a valóság nem vett tudomást az informatikusokról.

Számos portál, előadás, könyv, cikk és szerveződés jelent meg az elmúlt években Magyarországon és a világban, zászlajára tűzve az agilis fejlesztést mint célt, életcélt, életmódot. Gyakran láthatunk dicsőséges statisztikát mennyire sikeres, milyen sokan használják.

Úgy érzem hogy a valóság egész más. Most nem szeretném ízekre szedni az agilis fejlesztést, mert azt sokan megtették. Az agilis hívők egyenlőre nem jutottak túl az alapkoncepció monoton hangoztatásán, még nem sikerült a kérdésekre választ adni, és nem sikerült a koncepciót gyakorlatba ültetni.

Mert a tapasztalataim alapján ez a módszer életképtelen multinacionális céges környezetben.

A főbb problémák a következők:

• - Komoly informatikai fejlesztésekhez tenderezésen keresztül vezet az út. Vagyis előre meg kell határozni a leszállítandókat, a határidőt és az összeget ami a produkció kerül. Tessék, már felborultak az agilis alapelvek...
  
• - Ha sikerült elnyerni az ügyfél kegyeit és bennünket választ, akkor jön a következő probléma: kiderül hogy az ügyfél nagyon nem ér rá a projekttel foglalkozni. Ugyanis ő üzletet csinál, ez a dolga. Talán még arra sem ér rá, hogy az alapvető igényeit elmondja. Így biztosan nem teljesülnek az agilis fejlesztés feltételei.
  
• - A projekt határidejének közeledtével pedig - az elszámoltatós multi kultúra részeként - a fejlesztőkön elkezdik számonkérni a projekt elején tett ígéreteket. Az speciel senkit nem fog érdekelni, hogy közben mennyi minden más készült el, hogy milyen hamar készült el egy működő béta, és hogy a fejlesztők mennyire rugalmasan alkalmazkodtak az új igényekhez.
  (Akinek ez nem tetszik, kérdezze meg jogászát...)
  
• - Ha a fejlesztők túl akarnak élni, akkor mereven ragaszkodniuk kell az eredeti tervhez és eredeti leszállítandókhoz a rugalmasság kárára, tehát gyakorlatilag egy hagyományos vízesés modellt kell eljátszani. Akkor már nem lenne egyszerűbb vízesés modell szerint dolgozni?
  
• - Amiről nem szoktunk beszélni: az agilis fejlesztés tart a legtovább, ezzel a módszerrel lesz a szoftver kész a legkésőbb. Ez logikus is, hiszen az agilis fejlesztésben rengeteg „waste" azaz hulladék van - folyamatosan újraírjuk azt, amit már egyszer elkészítettünk, szemben egy hagyományos fejlesztési modellel ahol (elvileg) mindent csak egyszer fejlesztenek ki.
  
• - Az agilis fejlesztés tart a legtovább, és igényli a legtapasztaltabb fejlesztőket -> ergo a legdrágább metodológia. A mai világban - amikor mindenki a legolcsóbb megoldást keresi - ez biztos recept a bukáshoz.
  

Aki kételkedne a fentiekben, nézze meg a hazai Agilis fejlesztéssel foglalkozó portálokat. Mindent fog találni, csak igazi case study-k és referenciák nincsenek (tekintsünk el a pet projektektől és a házi fejlesztésektől).

Mindezek ellenére úgy gondolom, megvan a helye és szerepe az agilis módszertanoknak. Tudni kellene őket használni. Mondjuk túl kellene jutni az alapelvek monoton hangoztatásán, szert tenni némi gyakorlatra, és megérteni, hogy ez mire jó. Sajnos Magyarországon többnyire a témában olyanok tartanak előadást, akik még nem jutottak erre a szintre.

A teljesség igénye nélkül megemlítek pár jelet. Ha ezeket hallod, tudhatod hogy az előadó nem kompetens:
- Az agilis fejlesztés alapelveiről beszél - teljesen más az elmélet és a gyakorlat
- Nem beszél az agilis fejlesztés peremfeltételeiről (ügyfél, beszerzés, kompetens fejlesztők)
- Úgy beszél az agilitásról, mint egy univerzálisan használható, mindenre megoldást adó elvről  - fentebb leírtam hogy miért nem az
- Úgy látja, hogy a módszertan terjed - a valóságban nincs szó semmiféle forradalomról
- Ha csak az agilitás szoftverfejlesztői oldaláról beszél - a való világban van ügyfél is...

Ezek helyett miről kellene szólnia az előadásnak?
- Milyen körülmények között célszerű elővenni ezt a módszertant, és mikor nem
- Ha mégis Agile-t használunk, mik ennek a peremfeltételei
            - Ügyfél oldalon
            - Milyen fejlesztőkkel lehet sikeres
            - Projekt management oldalon
- Hogyan építsük fel a projektet
- Hogyan vezessünk egy Agile projektet (PM módszertanok vs Agile)
- Milyen erőforrásokra lesz szükség
- Hogyan tudjuk fenntartani a kontrollt, eredményeket felmutatni és elérni a célokat
- Hogyan tudunk egy formális környezetben (ahol határidők és kötött feladatok vannak) agilisak maradni
- Hogyan tudunk új fejlesztőt beilleszteni a csapat (pl. valakit másik projektre raktak át)

(Megjegyzés: van nemzetközi banknál SCRUM referenciám)