Előző alkalommal a webalkalmazás fejlesztés folyamatáról írtunk, ám nem tértünk ki a különböző fejlesztési módszertanok különbségeire. Ezt pótlandó, interjút készítettünk Sánta Tamással, a Leeds-i székhelyű InfinityWorks IT Tanácsadójával, akivel az agilis módszertan előnyeiről beszélgettünk a vízesés típusú fejlesztéssel szemben. Rengeteg érdekes tapasztalatot osztott meg velünk, így az interjút két részletben tesszük közzé.
Mit értesz agilis fejlesztés alatt?
Tipikusan azt, amikor a szoftvert darabokra bontjuk, részletekben fejlesztjük le és adjuk át ahelyett, hogy mindent egyszerre próbálnánk meg leszállítani a határidő végéhez közeledve. Kicsit formálisabban ez úgy hangzik, hogy azoknak a módszereknek, folyamatoknak és eszközöknek a használata, amelyek lehetővé teszik a gyors fejlesztési- és visszacsatolási ciklust.
Mi az agilis fejlesztés célja?
Ehhez előbb azt kell szemügyre venni, hogy mi az a probléma, amit a régebbi módszertanok nem tudtak megoldani. Az agilis fejlesztés szöges ellentéte a vízesés modell, amikor is az egész lefejlesztendő szoftver előbb megtervezésre kerül, később lefejlesztik, letesztelik, majd átadjak.
Ez régebben úgy nézett ki, hogy a fejlesztő mérnökök összeültek, és az üzleti követelmények alapján hónapokat (sokszor éveket) töltöttek tervezéssel, az utolsó szögig dokumentáltak mindent, majd átadták a fejlesztő csapatnak, akik a dokumentáció alapján lefejlesztették az adott szoftvert, majd tesztelés után élesbe ment.
Mi ezzel a baj? Leginkább az, hogy rengeteg idő telt el a termékötlet megszületésétől a projekt leszállításáig, ami sokszor azzal járt, hogy az idő múlásával az üzleti követelmények megváltoztak, felgyorsult a világ, és már nem arra volt szükség, amit korábban megálmodtak. Véleményem szerint ez még a jobbik eset, mert ez azt feltételezi, hogy azt építették meg a fejlesztők, amit az ügyfél szeretett volna. Viszont az esetek nagy többségében valójában a követelmények már a projekt elején nem lettek kellőképpen kommunikálva, így már a tervezés szakaszában elcsúszott minden. De erre csak akkor derült fény, amikor a projektet átadták. Akár évekkel később, rengeteg pénz elégetése után.
Az agilis fejlesztés célja a visszacsatolási ciklus minimalizálása, azaz minél előbb leszállítani egy MVP-t (minimum viable product), amit közvetlen a megrendelőnek lehet prezentálni, visszajelzést gyűjteni, és az alapján módosítani a követelményeket és leszállítani a következő iterációban a funkciókat és módosításokat.
Milyen az ideális agilis projekt?
Egy projekt minőségét sok tényező befolyásolja.
Jelentős hatással bír a megrendelő és a fejlesztő csapat felkészültsége, de az alkalmazott folyamatok milyensége és azok be(nem)tartása is. Végsősoron pedig az alkalmazott fejlesztői eszközöket és az automatizálást emelném ki, amik megfelelő technológiai alapot szolgáltatnak a projektnek.
Az ideális megrendelő legalább körvonalakban tudja, hogy mit szeretne és szeretne együttműködni. Be lehet vonni a fejlesztésbe, hallgat a fejlesztői visszajelzésekre és nem csak végig akar nyomni valamit a fejlesztő csapaton a gyors profit érdekében.
Az agilis fejlesztés alapelveit ő is követi: kommunikál és kollaborál. Partneri viszony tud kiépülni a fejlesztői csapat és a megrendelő között. Hajlandó az ügyfél rászánni legalább pár napot a fejlesztendő dolog kielemzésére. A fejlesztés során a felmerülő változtatási igényekre nyitott. A működő szoftvermegoldás prioritást élvez az átfogó dokumentációval szemben.
Fejlesztői oldalról a partneri hozzáállás és a megoldás keresése, szemben a szószerinti szerződés teljesítéssel szintén elvárt. A csapattagok tapasztalata is egy lényeges faktor: minél seniorabb egy csapat, annál könnyebb a kollaboráció. Ez nem azt jelenti, hogy egy csapat architect kell, hanem hogy a képességek és a senioritás eloszlása megfelelő legyen a csapaton belül.
Új csapat esetén ki kell alakítani a kémiát, mert az nem feltétlenül alakul ki magától. A projekt elején célszerű közösen összeállítani egy képesség vagy skill mátrixot: ebben a projekthez szükséges ismereteket rögzítjük, illetve mindenki beírja, hogy ki milyen szinten van adott technológiákban. Így már korán elejét vehetjük a csúszásoknak azzal, hogy tréning tervet dolgozunk ki, illetve csak low-risk feladatokat bízunk olyan csapattagra, aki az adott technológiában (még) nem jártas.
Meetingek kapcsán meg kell határozni, hogy mennyi az optimális mennyiség az adott csapatnál és projektnél. Ha túl sok a meeting, a hatékony programozási idő lecsökken. Ez gyakran a bevett, megszokott folyamatokhoz való ragaszkodás miatt alakul ki.
Másik jelenség az informatív meetingek hiánya - ehhez proaktív csapat kell. Ha passzív a csapat, akkor a megtartott meetingek elhúzódnak és unalmasak lesznek. Itt nincsen bevett módszer, kommunikációval és odafigyeléssel kell megtalálni a legmegfelelőbb mennyiséget.
Vannak olyan technológiai eszközök, amik jelentősen támogatják a fejlesztést, illetve használatuk miatt kevéssé kritikus, vagy teljesen eltűnik a rendszergazda, mint szerepkör. Ilyen például a folyamatos build és integációs szerver és a különböző DevOps eszközök.
DevOps (Development&Operation): egy mára már nem teljesen fiatal mozgalom, aminek a lényege olyan technológiák bevezetése, amik révén szükségtelenné válik a dedikált renszergazda, mivel a szoftver és infrastruktúra menedzsmentet a csapat bármelyik tagja képes elvégezni. Ezzel lecsökken a várakozással és csapaton belüli kommunikációval töltött idő, hamarabb kikerül a termék élesbe.
Ez komoly szemléletváltást hozott a fejlesztők körében. Máshogy kezdesz el fejleszteni valamit, ha tudod, hogy ezt neked kell üzemeltetni, hiszen senki sem szereti, ha hajnal 3-kor felhívjak, hogy nem működik valami.
Például figyelned kell rá, hogy amikor írod a szoftvert, legyen megfelelő mennyiségű és minőségű logolás, amikre megfelelő metrikát tudsz építeni. Ezen metrikák alapján már lehet automatizált figyelmeztetéseket generálni, valamint „önjavító” infrastruktúrát építeni.
Mindez nagyban megnöveli a termék ill. szolgáltatás rendelkezésre állását.
Folyt.köv.
Az interjút Mátis Eszter Léna készítette.
Fotó: Štefan Štefančík és rawpixel.com , Unsplash