40
MÛANYAG- ÉS GUMIIPARI ÉVKÖNYV 2015
lenesen akár nullára is) eshet. Ez nem azt jelenti,
hogy nem történik semmi, csak a beszállítói ol-
dal a szoftver előállítására koncentrál. Ez alatt az
időszak alatt a megrendelőnek egy speciális idő-
szakra kell felkészülnie, amely során a szükséges
ráfordításai tervezhetetlenül jelentkeznek.
A „felbukkanó” kérdések száma mindenképp utal
a specifikációs munka minőségére. Azonban ön-
magában abból, hogy felbukkannak ilyen kérdé-
sek nem szabad messzemenő következtetéseket
levonnunk. Bizonyára mindenki találkozott már
azzal a jelenséggel a saját munkája során, hogy a
tervezéskor lehetetlen minden részletkérdést teljes
mélységében tisztázni. Egyszerűen azért van így,
mert bizonyos kérdések csak a tényleges megva-
lósítás során merülnek majd fel. A háttérben egy
implementációs munka zajlik, amelyet ezek a kér-
dések különböző mértékben ugyan, de megakasz-
tanak. Ezért nagyon fontos ezeknek a mielőbbi
megválaszolása.
Lényeges, hogy az implementálás időszakáról le-
gyenek visszajelzéseink. A készülő részeket ellen-
őrizzük már előállítás közben. Ennek célja kettős:
• egyrészt ez egy jó visszacsatolási pont, hogy va-
lóban az készül-e el, amit szeretnénk.
• másrészt gyakran, amíg nem látunk egy szoft-
vert működés közben, addig nem látjuk tisztán
a kigondolt funkciók használhatóságát, hasznos-
ságát, főképp, ha egyébként nem szoftverek és
felhasználói felületek tervezésével foglalkozunk.
A fejlesztési szakaszban végzett demók nagymér-
tékben hozzájárulnak ahhoz, hogy a szoftverát-
adást követő tesztidőszak meglepetéseit minima-
lizálni lehessen. Minderre erőforrást kell tervezni
mindkét oldalon.
A bemutatókon a specifikációért felelős menedzs-
menten túl célszerű a tényleges felhasználók kép-
viselőinek is részt venniük. Ez növeli a későbbi
rendszer elfogadásának a mértékét, és gyakran
valóban új aspektusokra világít rá az adott funkci-
óval szemben. Az ilyen jellegű beszállítói demók,
gyakran nem a kész szoftverrészekkel, hanem
prototípusokkal történnek, és közben az elkép-
zelt működést magyarázzák a szállító munkatár-
sai. Céljuk nem a hibamentes működés, hanem a
készülő rendszer egyes részeinek bemutatása, az
ezzel kapcsolatos tervek és elképzelések helyes-
ségének igazolása. Ha a beszállító szeretne ilyen
alkalmakat teremteni, akkor mindenképpen támo-
gassuk ebben a törekvésében. Minél előbb fede-
zünk fel egy nem megfelelően működő funkciót,
az annál kisebb költséggel korrigálható.
Számos projektet gyakran az ítél sikertelenségre,
hogy “túl nagyot akar markolni”. Ennek oka lehet,
az éppen rendelkezésre álló büdzsé, egy nagyobb
ívű vízió, vagy más szempont. Jót tehet azonban a
projekteknek, ha azt olyan kisebb részekre bont-
juk, amelyek könnyebben megvalósíthatók, a koc-
kázatok pedig ezáltal csökkenthetők. Nem csak
azért lehet mindez hasznos, mert a kisebb terjede-
lem jobban átgondolható, könnyebben kezelhető
és a rövidebb átfutási idők mindig jótékony hatást
gyakorolnak a megvalósulásra. Hanem azért is,
mert az összeszokott projektcsapatok, akik sike-
res közös munkákat tudhatnak a hátuk mögött,
gyakran a következő alkalommal sokkal jobb tel-
jesítményt nyújtanak, mint előzőleg. A több, tény-
legesen függetlenként kezelt projektlépcsőre való
bontás gyakran hasznosnak bizonyul és hozzájárul
a sikerhez komplex feladatok kivételezésekor.
3. ábra: Az egyik legnépszerűbb agilis szoftverfejlesztési
metodika, a Scrum áttekintő elvi ábrája. Jól látható, hogy
alapvetően a feladatok több egymást követő, kezelhető mé-
retű iterációra bontásában gondolkodik.
Egy ilyen nagyívű feladatnak tudatos és átgondolt,
a szereplők együttműködésére épülő tevékeny-
