Agilis fejlesztési megközelítés

Elhúzódó projekt helyett gyors piacra lépés

A nagy volumenű fejlesztési projektek egyik csapdája, hogy mindent egy lépésben és egyszerre szeretnénk megvalósítani. A valóság ezzel szemben az, hogy a projekt kezdetén sosem látható előre tökéletesen az a műszaki tartalom, amire végül szükségünk lesz. Ezért agilis megközelítés mellett ügyfeleink minél gyorsabb piacra lépésén dolgozunk, majd a terméket gyors release ciklusokban fejlesztjük tovább.

A hagyományos “waterfall” projektmetodika hátrányai

A vízesés (waterfall) metodikával dolgozó szoftverfejlesztesek jellemző alapvetése, hogy a rendszert először alaposan megtervezzük, lefejlesztjük, majd tesztelés után bevezetjük. Projekt vízióból megvalósítási terv születik, ezt pedig jellemzően műszaki specifikáció és felületi tervezés követ. Mire a projekt a fejlesztési szakaszba jut, igyekszünk mindent tökéletesen megtervezni, a projekt életciklusa pedig túl van az első hónapjain és az első néhány száz munkaóra ráfordításon. Elméletileg már csak fejlesztenünk kell. Mi a baj ezzel a megközelítéssel? Röviden: az, hogy kis mértékben működik.

Aki részt vett már komplex IT projektben az bizonyosan tapasztalta már, hogy a fentiek ugyan jól hangzanak, de a gyakorlatban ritkán sikerülnek. Bármilyen alapos is a tervezési előkészítés, az eredetileg elképzelt és specifikált igényhez képest a végeredmény sokszor eltér, a megrendelő nem pont azt kapja, amire eredetileg szerződést kötött. Ez gyakorta okoz konfliktust szállító és megrendelő között.

De miért is olyan nehéz egy előre jól definiált projekt műszaki tartalmát változtatások nélkül pontosan leszállítani? Ennek az az oka, hogy az eredménytermékkel szemben támasztott követelmények menet közben természetszerűen változnak. Egy komoly portálfejlesztés több hónapos, néha fél-egyéves időszakot is jelenthet, amely az e-kereskedelemben igen sok idő. A gyors reagálású és kompetitív piaci viszonyok változása azt eredményezi, hogy a fejlesztés menete közben új igények lépnek fel vagy korábban fontosnak tartott igények másodrendűvé válnak. Számos digitális szegmensben egy fél évvel ezelőtt készült üzleti specifikáció már elavultnak számít.

Így fordulhat elő, hogy a fejlesztés kezdetekor szükségesnek ítélt és gondosan megtervezett funkciócsomag élesítéskor már nem helytálló. A hiba ott van, hogy a vízesés-szerű projekt metodika ellenérdekeltté teszi a feleket az eredetileg rögzített célok változtatásában, hiszen az sorozatos szerződés módosításokat és a projekt tartalmának folyamatos újratárgyalását jelenti. Ez a helyzet a megrendelő és szállító közti viták melegágya, ahol mindenki érzi a változtatások szükségességét, ám a vízesés jellegű szerződésben rögzített pénzügyi feltételek és az intenzív tervezési fázisba invesztált rengeteg munkanap mereven rögzíti a felek pozícióját. A tényleges kész termek így eltér a valódi üzleti igénytől.

A klasszikus vízesés-alapú projektek tipikus hibája: a projekt követelményei menet közben változnak,
ám a megvalósítás közben az eredeti, leszerződött műszaki tartalom nehezen változtatható.

 

Képzeljünk el egy egyszerű példát: hétvégi bevásárlásra indulunk (= projekt) egy előre elkészített bevásárlólista alapján (= előre rögzített projekt scope). Bármennyire is gondosan állítjuk elő a listánkat, nem életszerű, hogy végül egy az egyben, pontosan az abban összeírtakat vásároljuk majd meg. Valószínű, hogy a bolt sorai között járva eszünkbe jut, hogy vennünk kell még cukrot, amivel viszont eredetileg nem terveztünk. A vízesés megközelítés ennek nem engedne teret, hiszen a bevásárlólista előre rögzített. A húspultnál járva kiderülhet, hogy a listánkon szereplő csirkecomb mégsem olyan fontos, inkább vennénk helyette halat. A vízesés modell viszont nem engedi meg, hogy a csirkecombot felcseréljük egy azzal egyenértékű, de más termékre, hiszen szerződésünk van róla, hogy akármi van, a boltból csirkével fogunk távozni. A vízesés modell ugyancsak képtelen kezelni a piaci viszonyok vagy a körülmények rendkívüli változását, például azt, ha a párunk vásárlás közben ránk telefonál, hogy a mosópor helyett inkább öblítőt vigyünk haza.

A vízesés modellben zajló fejlesztések korai stádiumban mindenre kiterjedő pontos tervezést és becslést írnak elő, holott azok nem lehetnek megalapozottak. Kiváltképp igaz ez az e-kereskedelemre ahol gyakorlatilag hetente érkezik valamilyen piaci változást indukáló innováció.


Agilis megközelítés: beépítjük a projektbe a változás lehetőségét

Az agilis fejlesztési megközelítés azt jelenti, hogy elfogadjuk azt az elkerülhetetlen törvényszerűséget, hogy egy komplex fejlesztési projektet képtelenség 100%-ban, maradéktalanul előre definiálnunk, mi több, nem is célszerű vagy reális erre törekedünk.  Ezért inkább teret engedünk annak, hogy a projekt műszaki tartalma menet közben kristályosodjon ki. Beemeljük a projektbe a változás lehetőségét. Ez azt is jelenti, hogy a fejlesztés üzleti követelményeit definiáljuk ugyan, de a pontos műszaki tartalmat menet közben, közösen alakítjuk ki.

A fenti példánál maradva az agilis bevásárlás azt jelenti, hogy meghatározunk egy olyan minimális eredményterméket (MVP), amely nélkül semmiképpen sem megyünk haza a boltból, vagyis amely nélkül a bevásárlás értelmetlen. Tej, sajt és pékáru mindenképpen kell, e nélkül az egész bevásárlásnak nincsen értelme. Ugyanakkor elfogadjuk és tudatosítjuk, hogy a vásárlás közben pontosodnak az igényeink, ugyanis a vásárlás folyamatában reálisabban látjuk őket, mint előre a teljes csomagot. Ezekre megszabunk egy pénzügyi keretet, amelynek terhére a sorok között járva dől el, hogy végül mi landol a kosarunkban. Ezt a megközelítést a való életben szinte mindenhol alkalmazzuk, legyen az bevásárlás, ház építés, egy nyaralás lebonyolítása vagy saját vállalatunk fejlesztése. Miért a szoftverfejlesztés lenne kivétel?

Az agilis módszertannal minimalizáljuk annak a lehetőségét, hogy olyan, eredetileg fontosnak vélt fejlesztéseket csináljunk, amikről – mire sorra kerülnek – kiderül, hogy valójában annyira nem is fontosak és helyettük akár teljesen új igényeket is kiszolgáljunk, amikre a projekt kezdetén nem is gondoltunk.

Gyors és iteratív átadási ciklusok

Ennek eszköze a sprintekre bontott fejlesztés. A sprint rövid (jellemzően) 2 hetes fejlesztési ciklusokat takar. A sprint egy a fejlesztő csapattal közösen végzett tervezéssel kezdődik, ahol átbeszéljük és priorizáljuk a soron következő eredménytermékeket. A sprint demózással ér véget, ahol a megrendelő megtekinti és használatba veszi a leszállított fejlesztéseket. Így a tesztelés nem a projekt végén történik, hanem tulajdonképpen folyamatosan.

A sprintek aktív résztvevője az ügyfél Product Owner-e, hiszen ő dönti el, melyik funkció legyen a következő a sorban. A fejlesztő csapattal együtt tervez és gondolkozik. Azáltal, hogy sprintről sprintre, a megrendelő döntése alapján vesszük elő és valósítjuk meg a fejlesztési csomagokat, a sprintek menet közben korrigálják és a helyes irányba terelik a projektet. Íme erről egy szemléltető ábra:

Az agilis fejlesztési módszertan lényege, hogy a projekt tartalmát menet közben korrigáljuk úgy,
hogy minél gyorsabban piacra lépjünk egy MVP (minimum viable product) termékállapottal.

 

Fontos szabály, hogy a sprinteknek mindig önmagukban is teljes értékű terméknövekményt kell leszállítaniuk. A sprint eredményeit a megrendelőnek azonnal használatba kell tudni vennie. Vagyis ha a sprintben a feladatunk például egy hitelkalkulátor fejlesztése, akkor azt a sprint végére kompletten le kell szállítanunk, minden komponensével együtt letesztelve, demózásra kész állapotban.

Másik fontos szabály, hogy az éppen futó sprinten menet közben nem változtatunk. Egy agilis release ciklus gyors, ám ehhez az kell, hogy a fejlesztő csapat azon zavartalanul tudjon dolgozni. A folyamatban levő sprint egy olyan időszak, ami alatt nem módosulhatnak a célkitűzések, a fejlesztők védettek a külső behatásoktól, így eredményesebbek.

A sprinteknek természetesen vannak bemeneti követelményei is. Egy fejlesztés akkor emelhető be a sprintbe, ha az üzleti specifikációból már fejlesztési specifikációs fázison is túlesett, azaz kellően definitív (sprint-ready), megvannak hozzá a design tervek, elfogadási kritériumok. A sprintben leszállított terméknövekmények átadása is szigorú szabályokhoz között, a projekt elején ugyanis egy DoD (definition of done) követelményprofilban rögzítjük, hogy mikor tekintünk késznek egy feladatcsomagot.

A sprintek kulcsfontosságú momentuma a sprintforduló, amely scrum master szervezésével zajlik. Itt történik az előző sprint eredményeinek bemutatása és a következő sprint feladatainak megtervezése, illetve ilyenkor a megrendelő PO-ja személyesen is találkozik a csapatokkal, így közösen tudják értékelni a projekt előrehaladását. A sprintfordulón történik a backlog elemek pontosítása, a specifikációk közös ellenőrzése és véglegesítése is.

Az agilis megközelítés fontos előnye tehát az is, hogy sokkal egyszerűbb csak a soron következő sprint funkciókészletét jól megtervezni mint a teljes projektet annak indulásakor. Megrendelőként pedig sokkal könnyebb az előző sprintben leszállított terméknövekményt átvenni, megismerni és használatba venni, mintha a teljes projektet egy az egyben, egészben “zúdítaná ránk” a fejlesztőcég tesztelésre. A szoftvert nem teljes funkcionalitásában indítjuk el a megrendelőnél a felhasználóknál, hanem fokozatosan kezdik el használni a rendszer funkcióit.

Agilis fejlesztés az e-kereskedelemben

Mit jelent mindez egy webáruház fejlesztés esetén? A gyakorlatban 2 fázist valósítunk meg, amelyek a fenti agilis metodika szerint mennek végig:

  • Első lépésben kész, gyorsan átadható és megrendelői oldalról könnyen átvehető alapszoftvereket vezetünk be. Olyanokat, amelyek minden webáruházhoz szükségesek. Ilyen lehet például az OANDER Hodor frontend sablon, kulcsrakész és gyorsan bevezethető Magento modulok vagy integrációs igények esetén az előre elkészített csatolókészletként funkcionáló Oander Connect middleware platform. A cél az, hogy ügyfélként Ön ezeket minél gyorsabban bevezesse, megismerje és akár piacra is lépjen velük. Ekkor érünk el a prototípus termék állapotába. Magukat a kész szoftverelemeket is sprintek keretében, fokozatosan vezetjük be az ügyfeleinknél, hiszen az induló készlet eleve komplex és megrendelői oldalon könnyebb, hatékonyabb azt “darabokban” megismerni, átvenni, kipróbálni.
  • Ezt követi egy támogatási és továbbfejlesztési szakasz, amely során egyedi igények mentén módosítjuk a prototípus termék komponenseit. Például egyedi design alapján átalakítjuk a frontend sablont, további modulokat vezetünk be és természetesen egyedi fejlesztéseket is implementálunk. A gyors iterációkkal gazdagított sprintek során megrendelőként Ön dönt arról, hogy melyik funkciócsomag fejlesztése következzen. Nem kell előrelátnia a teljes projekt scope-ot, mindössze azt, hogy mi a legfontosabb következő állomás, amivel foglalkozzunk. A működő szoftvert látva és használva pontosabb döntések és jobb továbbfejlesztési ötletek születnek, amik akár eltérhetnek a projekt kezdeti víziójától is.

Az agilis e-kereskedelmi fejlesztés során tehát megrendelőként Ön első körben egy kész terméket (Magento alaprendszer, sablon, kész modulok) és annak bevezetését vásárolja meg, hogy minél gyorsabban piacra tudjon lépni. Ezt követően folyamatos ügyfél- és terméktámogatás mellett, gyors release ciklusok formájában továbbfejlesztjük azt, és egyedi fejlesztésekkel megerősítjük a piaci pozícióját.

Az agilis metodika működésének néhány feltétele

  • Az agilis fejlesztési metodika akkor működik, ha a megrendelő vállalati kultúrájának része a tervezés-elemzés-visszacsatolás jellegű kereskedelmi gyakorlat, vagy legalábbis jelentős nyitottsággal áll a lean megközelítéshez.
  • A módszertan fontos pillére, hogy a megrendelő nem passzív szemlélője a tervezésnek és fejlesztésnek, hanem annak aktív, “betársult” résztvevője. Akkor működik, ha a megrendelő nyitott a sprintekre fókuszáló közös tervezésnek, hajlandó bevonni magát az üzleti vagy akár a műszaki specifikációk elkészítésébe, és van lehetősége gyors, tartalmas interakciókra épülő fejlesztésben részt venni.
  • Az agilis fejlesztés harmadik feltétele pedig, hogy a megrendelő bevonjon a projektbe egy olyan Product Owner-t, aki a fejlesztési stratégia prioritásai mentén haladva, technikai rálátással menedzseli a teljesítéseket és veszi át azokat. A megrendelő oldali Product Owner együtt dolgozik a tervező és fejlesztő csapattal, dönt az egyes sprintek tartalmáról és kezeli a backlog-ot.