Agilis Szoftverfejlesztök Egyesülete

Fordítva a lovon

Mint annyi minden mással, az agilis szoftverfejlesztéssel is ez történt: utólag sokkal egyértelműbbnek, magától értetődőbbnek tűnik. Pedig még emlékszem önöm magamra, mekkora megrökönyödéssel figyeltem – SSADM-n és RUP-n szocializálódott szemléletemmel – Marko Boger – farmernadrágos, kockásinges – kinyilatkoztatásait az eXtreme Programming-ról egy yorki, amúgy angolosan konszolidált UML konferencián 2001-ben. Nem, ez így biztosan nem működhet, erősítettem magamban – a sok fáradsággal megszerzett – tervezés és dokumentum centrikus fejlesztésbe vetett hitemet. Most pedig gyakran kérdezik tőlem: Mi ebben az új? Mi már régen így dolgozunk!

Hat éve, hogy szakmánk metodológus prominensei – egy Utah állambeli síelés közepette – megfogalmazták a „Kiáltvány az agilis szoftverfejlesztést” c. proklamációt. Nos, akkor 6 év alatt megoldottuk a szoftverfejlesztés minden módszertani kérdését? Visszakérdezek. Körülbelül 20 éve tanulja szakmánk az objektumorientált rendszertervezést, fejlesztést. Minden új rendszerünk objektum orientált? (És most tekintsünk el a „szép új” SOA 20 évvel ezelőtti procedurális szemléletét?!)

Az agilis szoftverfejlesztés – itthon is és külföldön is – betette a lábát az ajtóba. Nem lehet megkerülni, de ez korántsem jelenti azt, hogy minden szoftver projektünk agilis! Elvben sem lehet, hiszen szemléletváltásról van szó. Ehhez pedig kell egy új generáció. Kell egy olyan generáció, amelyik végre nem fordítva ül a lovon. Mi sajnos „megvezettük” magunkat, a szemellenző nem a lovon, hanem rajtunk volt. Húsz éve annak, hogy Watts Humphrey bedobta a köztudatba a „szoftver gyártás” analógiát, azaz azt az elképzelést, hogy szoftvert is úgy gyártsunk mint egy teáscsészét vagy gépkocsit. A CMM-t (Capability Maturity Model) a MMM (Manufacturing Maturity Model) mintájára dolgozta ki a SEI (Software Engineering Institute). Ebben a történelmi pillanatban egy alapvető félreértés született. A gyártás ugyanis ugyanazon specifikációnak megfelelő termékek ismétlődő előállítása. A szoftverfejlesztés viszont kicsit, vagy nagyon más, esetleg teljesen új termék előállítása. A gyártás jól tervezhető, a termékfejlesztés (értsd szoftverfejlesztés) viszont csak nagyfokú bizonytalansággal tervezhető, vagyis van egy olyan időtáv, részletezettség, amelyre már nem érdemes tervezni. Nem így a gyártásban. A gyártási tervek pontosításával csökkenthető a bizonytalanság. A dobozgyártás hatékonysága növelhető a specializációval, a katonás munkaszervezéssel („Isten hozta, Őrnagy úr!”), de a doboz design (értsd szoftverfejlesztés) nem.

Érdemes megkérdezni a szoftver projekt után az ügyfelet. A projekt melyik szakaszában váltak számára leginkább világossá a szoftverrel szembeni elvárásai? A válasz nem kétséges, a projekt végén. Akkor viszont miért teszünk úgy, mintha pontosan ismernénk a követelményeket a projekt elején! Miért áltatjuk magunkat (a fejlesztő és az ügyfél) azzal, hogy a szerződés pillanatában – minden részletében – ismert a kívánatos végeredmény? Ezzel nemcsak eleve „kódoljuk” a jövőbeli félreértéseket, félreértelmezéseket, hanem – és ez még fontosabb – megfosztjuk magunkat a valóság ismeretén alapuló döntésektől. Ha abból indulunk ki, hogy a projekt indításakor megfogalmazott követelmények helyesek és teljesek, akkor – értelemszerűen – a projekt végrehajtás és felügyelet technikáit a tervekhez való ragaszkodás célja szerint alakítjuk ki. Minél következetesebben, annál később és annál végzetesebben szokott összeomlani a projekt. A valóság végül menthetetlenül kicsúszik a kontrollálhatóság mezsgyéjéből. Ha viszont elfogadjuk, hogy a projekt indításakor csak vázlatos elképzeléseink vannak az elvárt végeredményről, lehetőségünk nyílik olyan projekt végrehajtási és felügyeleti technikákat bevezetni, amelyek lehetővé teszik a változásokhoz való alkalmazkodást. Agilis projektben a változás „szívesen látott” esemény, hiszen ez az önkorrekciós folyamat alapja.

Hát persze! A változás kezelés már régóta része minden valamirevaló módszertannak. Igen ám, de ez a változáskezelés nem az a változáskezelés! A klasszikus szemlélet a változások okozta „zaj” kiküszöbölésére törekszik – értsd „nem szereti” a változásokat -, míg az agilis projekt irányítás motorja a változás.

E sorok olvastán talán (remélem) sokan azt mondják magukban: hát persze Zsolt, ez napnál világosabb! Szerintem is! Akkor viszont miért van az, hogy ennek a szemléletnek a csírája sem jelenik meg a tenderkiírásokban. Sem az állami, önkormányzati, sem a nagyvállalatok beszerzési politikájában? Miért van az, hogy - jóindulatú – légvárak fejlesztésében kell a vállalkozónak árversenyezni? Miért van az, hogy a szoftver minősége nem, vagy csak csekély mértékben szempont a beszerzéseknél (az a jó – minőségű – szoftver, amely ténylegesen használható, hasznot hoz az ügyfél számára)?

Szemléletváltásra van szükség a fejlesztői és megrendelői oldalon egyaránt. Ennek a szemléletváltásnak az elősegítésére jött létre – külföldi társszervezetek mintájára - az Agilis Szoftverfejlesztők Egyesülete. Úgy gondoljuk, - a Magyar Architektúra Fórummal közösen -ma már helyes irányban ülünk a lovon, de a sebesség, a ritmus még nincs szinkronban a valósággal.

Zsuffa Zsolt

Elnök