Az informatikai fejlesztési projektekben nem létezik „bölcsek köve”, mindenki számára egyaránt alkalmazható recept. Vannak azonban közismert és bizonyított módszertanok, amelyek jó kiindulópontot jelenthetnek saját projektjeink körvonalazásában.
A fejlesztési módszertanok egyik legrégebbi változata a vízesésmodell. Ilyenkor úgy kell elképzelni a folyamatot, mintha egy vízesésen zúdulna le a víz kőről kőre: az egyes kövek a projekt előre definiált mérföldkövei, amelyek lezárnak egy fázist, és csak akkor lehet továbblépni, ha az adott fázist befejezte a fejlesztés. Kezdeti formájában egy egyenesként lehetett leírni a vízesésmodellt, ahol az egyes fázisok között még visszacsatolás sem volt, nem lehetett visszatérni egy előző lépésre (mint ahogy a vízesés sem folyik a másik irányba).
Egyenesen előre
Elég hamar felismerték a modellnek ezt a hiányosságát, és válaszul megszületett a visszacsatolásos vízesésmodell – mondja Molnár Ágnes, az L&M Solutions vezető tanácsadója. Ennek lényege, hogy az egyes mérföldkövek között már visszafelé is lehet lépni: ha kiderül, hogy a fejlesztők elhibáztak valamit, az utólag még javítható. Ettől függetlenül a vízesésmodell nem igazán rugalmas: a fejlesztés során jelentkező új igényekre már nem lehet reagálni. Az ügyfél előre megmondja, hogy mit szeretne, azt a fejlesztő megcsinálja, és ezzel készen is van. A menet közbeni változáskérelmek befogadására már nincs mód, mert az újabb projektet jelentene; a visszacsatolás csak a hibajavításra vonatkozik.
Éppen a hiányosságai miatt ma már csupán egy nagyon szûk körben alkalmazzák a vízesésmodellt.
Táguló körökben
A rugalmasság viszont a fejlesztésben is alapkövetelmény lett. Az ügyféligények nagyon gyorsan változhatnak: nem feltétlenül azért, mert a leendő felhasználó az elején nem tudja, hogy mit akar, hanem mert az üzleti környezet hetek alatt is vehet olyan fordulatot, amelyre mindenképpen reagálni kell a projektben.
Ezekre az igényekre válaszul született meg az 1980-as évek második felében a spirálmodell. Alapötlete, hogy a szoftverfejlesztést nem egyetlen egyenes mentén képzeli el, mint a vízesésmodell, hanem spirálvonal formájában: az egyes tengelyek a különböző fázisokat jelentik, a spirál aktuális sugara (a középponttól mért távolsága) a rendszer fejlettségi fokát tükrözi. Minden az igényfelméréssel kezdődik, aztán jön a fejlesztés, a tesztelés, az átadás, majd az egész folyamat indul elölről, újabb és újabb funkcionalitással bővítve a meglévő elemeket.
A spirálmodellben is ki lehet tûzni mérföldköveket, de azt igazán nem lehet előre megmondani, hogy hány kört kell leírnia a spirálnak – mondja Molnár Ágnes. A megvalósítandó feladat minél pontosabb ismerete és a korábbi tapasztalatok segíthetnek a projekt megtervezésében, de még ilyen esetben is szükségessé válhatnak menet közbeni módosítások, körök összevonása, esetleg újabbak hozzáadása.
Folyamatos kapcsolat
Még tovább megy a rugalmasságban az agilis módszertan. Ilyenkor a fejlesztői csapat nagyon kis lépésekben, rövid fázisokban halad előre, és folyamatosan kéri a visszajelzést a felhasználóktól – ad rövid magyarázatot Molnár Ágnes. Ennek megfelelően nem merev a projekt felépítése, az indulásnál nem rögzítenek pontosan mindent, teret hagynak a későbbi döntésekben.
|
Ügyfele válogatja |
|---|
|
Manapság már az agilis tekinthető a legelterjedtebb fejlesztési módszertannak, a versenyszférában szinte egyeduralkodónak számít. |
A projekt lehet esemény- vagy idővezérelt. Előbbi esetben a fejlesztők azonnal felkeresik az ügyfelet, amint elkészült valamilyen komponens (kezelőfelületi képernyő, funkció, üzleti logika), és elébe tárják az eredményt: erre gondolt-e, tetszik-e, vagy módosítsanak rajta, és ha igen, hogyan? A kapott észrevételek alapján folytatják a munkát. Az idővezérelt projekt hasonlóan zajlik, csak ott éppen rendszeres időközönként találkoznak egymással a felek. „A lényeg a minél sûrûbb találkozásokban van, nehogy az legyen, hogy hónapokig dolgozunk valamin, ami aztán nem felel meg az ügyfélnek – hangsúlyozza Molnár Ágnes. – Az agilis módszertan lelke a sûrû kapcsolattartás; a mi gyakorlatunkban legfeljebb két hét telik el két megbeszélés között.”
Az ügyfelek kimondottan kedvelik azt a rugalmasságot, amit az agilis módszertan visz a fejlesztési projektekbe – idézte fel saját tapasztalatait a vezető tanácsadó. Ennek köszönhetően ugyanis nagyon ritkán „megy félre” a fejlesztés, az ügyfél mindig tájékozott a projekt állását illetően, és a végén pontosan azt kapja, amit szeretne, amit elképzelt. Ugyanakkor ez a módszertan az ügyfelek részéről is igényel némi önfegyelmet. Egyrészt a projekt elején tisztázni kell, hogy nem akármilyen mértékû változási kérelem vihető be és teljesíthető. „Nyilván kivitelezhető, hogy egy nyomógomb ne a bal, hanem a jobb oldalon legyen, de ha teljesen új, hónapokig tartó fejlesztésekkel megoldható funkciókat szeretne, az már nem fér bele a rugalmasságba” – tisztázza a határokat Molnár Ágnes.
Schopp Attila
