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. Az interjú első része itt érhető el.
Mi az agilis fejlesztési folyamat elméleti modellje?
Az agilis fejlesztési folyamat és a vízesés folyamat közti legnagyobb különbség az, hogy az előbbiben a követelményeket akkora darabokra bontjuk, ami normális tempóban leszállítható a csapat által, egy iteráció alatt. A kisebb egységek lefejlesztése azonban nagyjából a vízesés folyamatot követik.
Az agilis fejlesztés alapfogalmainak megismerése fontos ahhoz, hogy rálátásunk legyen erre a fejlesztési módszertanra nem csak elméleti, de gyakorlati szinten is.
Napjainkban a leginkább elterjedtebb módszertan a Scrum, ami egy iteratív, inkrementális folyamatokat összefoglaló keretrendszer, amit gyakran használnak az agilis szoftverfejlesztés eszközeként. Fontos megjegyezni, hogy az agilis fejlesztés nem a Scrum keretrendszer alkalmazása betűről betűre, hanem a projektnek megfelelő eszközök kiválasztása és használata.
A Scrum keretrendszer főbb elemei, a teljesség igénye nélkül:
- User Story: egy megtervezett funkció leirása, ami tipikusan tartalmazza a UI tervet, az elvárt működés leírását, az “acceptance critera”-kat (a teljesítendő feltételek, amik alapján a PO leszállítottnak nevezheti az adott funkciót).
- Backlog: A kidolgozott userstorykból álló lista.
- Sprint: minden „futam” (sprint) során a csapat egy működő szoftveregységet hoz létre, melynek leszállítása tipikusan 2-4 hetet vesz igénybe.
(A Scrumról bővebb információ itt olvasható.)
Általában a PO és a BA közösen összeállítanak egy roadmapet (ütemterv), ami közép-hosszú távon (6-12 hónap) tartalmazza a lefejlesztendő funkciókat, nagyvonalú időbecsléssel együtt. Az ütemterv természetesen az üzleti igényekkel együtt folyamatosan változik/változhat.
A scrumtól egy egészen eltérő (és más célt szolgáló) módszertan is szárnyra kapott. A Kanban olyan - előszőr az ipari termékgyártási folyamatok optimalizálására kitalált - módszertan, amely vizualizálja a munkafolyamatokat, így azok jól átláthatóak valamennyi résztvevő számára. Korlátozza a párhuzamosan folyó feladatok számát, ezzel megelőzve az esetlegesen kialakuló szűk keresztmetszeteket. Minden résztvevő fő célja segíteni a feladatok áramlását a folyamatban. A folyamat szabályai egyértelműen definiáltak: meghatározott, hogy milyen feltételek teljesülése esetén kerülhet át a fejlesztett funkció az egyik folyamat lépésből a másikba.
Hogyan valósul ez meg a gyakorlatban?
Nálunk általában két bevezető fázis előzi meg a fejlesztési folyamatot:
- Pár napos igényfelmérés: Egy tapasztalt ember kimegy az ügyfélhez, 2-3 nap alatt feltérképezi, hogy mire van szükség.
- Megvalósíthatósági terv: Fel kell mérni, hogy az ügyfélnek hány emberre lenne szükség és kb. mennyi időre - ez alapján tudja eldönteni, hogy kéri-e vagy nem a szolgáltatást.
A fejlesztési folyamat maga hasonló a vízesés modellben megismertekhez. Az aktuális projektünkön ez a következőképp néz ki:
Követelmény analízis
A leszállítandó termék specifikálása, user storyk elkészítése (egy megtervezett funkció leírása), amiket egyesével le tudunk szállítani. Ennek a fázisnak a végére általában összeáll egy backlog, amiből már lehet sprinteket tervezni.
Tervezés
A „3 amigos session” előzi meg a sprint planninget: Leül a fejlesztő, a tesztelő és a termék felelős Product Owner (PO) vagy Business Analyst (BA), és maguk elé vesznek egy storyt. A fejlesztő feladata, hogy a technológiai problémákra rávilágítson, illetve jelezze ha túl komplikáltnak, nagynak találja a storyt (ebben az esetben fel kell bontani kisebbekre). A tesztelő felméri, hogy milyen módon és mekkora energia befektetéssel lehetne tesztelni; lehet-e automatikus teszteket írni, kellenek-e valamilyen speciális eszközök. A BA/PO eldöntheti, hogy számára ez így megfelelő-e. A tüskéket (“spike” - kockázatos dolgok, pl. senkinek nincs benne tapasztalata) kell először megvitatniuk. Egy spike tipikusan egy megvalósithatósági tanulmánnyal, vagy technológiai demóval zárul, ami alapján már el lehet kezdeni a tényleges fejlesztést.
Egy másik tervezési tevékenység a becsléshez kapcsolódik, ez pedig a „Planning poker”: mindenkinek becsülnie kell az adott user storyra egy komplexitás méretet, pl. prímszámokban vagy póló méretben. Ez utóbbi esetben, az egyszerű feladatok S-es jelzést kapnak, a bonyolultak XL jelzést. Fontos hangsúlyozni, hogy itt nem a fejlesztés időigényét kell megbecsülnünk, hanem a feladat összetettségét. Jelentős különbségek lehetnek egy-egy feladat megítélésében. Ezeket meg kell vitatni. Végül kap egy komplexitás jelzést a ticket. Ez alapján válogatják be az egyes sprintekbe a feladatokat.
Fejlesztés
Ha elkezdődik egy sprint, akkor a fejlesztők felvesznek 1-1 ticketet amin dolgoznak. Itt fontos kiemelni azt a fejlesztői eszköztárat, aminek a segítségével akadálymentesen dolgozhat több fejlesztő ugyanazon a terméken. Ilyen például a verziókövető rendszer, a folyamatos integrációs szerver, vagy a code reviewk alkalmazása.
Tesztelés
Az elkészült funkció ezután kikerül egy tesztkörnyezetbe, ami pontos mása az éles környezetnek. Innentől a tesztelő kezében a labda, akár manuális, akár automatizált tesztekről van szó. Ha minden sikeres, és a ticket megfelel a “Definition of Done (DoD)” dokumentumban megállapított feltételeknek, a ticket késznek tekinthető. Ha a csapat esetleg kifogyna a feladatokból a sprint lezárulta előtt, bármikor behúzhatnak újabbat a backlogból.
Prezentáció az ügyfélnek
Minden 2-3 hetes sprint végén ügyfél demó történik. Ha az ügyfél rábólint az elkészültekre, az kikerülhet az éles környezetbe. A demó során a megrendelő visszajelezhet, módosítást kérhet, amiket a későbbi sprintek során készít el a csapat. Ez által biztosítható, hogy a teljes fejlesztési folyamat során az kerül leszállításra, amit az ügyfél szeretne. A folyamatos demózás és kommunikáció megerősíti a megrendelő, és a fejlesztő csapat közötti bizalmat.
Fontosnak tartom kiemelni, hogy mindig az adott csapattól függ milyen folyamatokat választ az adott projekthez. Ugyanis nincsen egy olyan általános megoldás, ami mindenre jó lenne. A választott fejlesztési folyamat nagyban függ a termék milyenségétől. Illetve tapasztalataim alapján a folyamatok erősen korrelálnak az adott termék kiadásának sürgősségével.
Egy konkrét példával élve; dolgoztam olyan dobozos terméken, aminek csak évente volt egy kiadása. Ugyan ott is Scrumot használtunk, de az iterációknak kevésbé volt jelentősége, mint egy olyan terméknél, ahol például hetente van frissítés. Persze így is hasznos volt mert az ügyfél (ez esetben a PO) tudta követni, hogy hol tartunk a tervezett roadmapen. Annál a projectnél volt időnk megtartani minden Scrum ceremóniát, hiszen kellően nagy csapatban dolgoztunk és a meetingek által lefoglalt idő megfelelő arányban volt fejlesztéssel töltött idővel.
Erre ellenpélda egy tipikus mai startup által fejlesztett weboldal/szolgáltatás/API, ahol kicsi, de hatékony csapat fejleszti sokszor a saját termékét. Ilyenkor a Scrum ceremóniák csak felesleges időpazarlások. Ettől még lehet agilis módon fejleszteni. Általában ilyenkor komolyabb becslés helyett a frekventált releasek miatt inkább csak az éppen folyamatban levő dolgok követésé a cél, erre pedig a Kanban tábla használata a megoldás.
Az aktuális projectemnél (és itt megjegyezném, hogy mostanában ez kezd a bevált szokás lenni) keverjük a Scrumot, és a Kanbant, un. Scrumban-t használunk, azaz a kidolgozott user storyk fejlesztését egy Kanban boardon követjük az adott sprinten belül.
A módszertanok mellett mindenképpen ki kell térnünk az alkalmazott fejlesztői eszközökre is. Ezek teszik lehetővé ugyanis, hogy az adott csapat gördülékenyen tudjon fejleszteni, és publikálni dolgokat.
A legfontosabb talán az, hogy a project legelején célszerű a fejlesztést a CI pipeline-nal kezdeni, amivel a későbbiekben automatikussá válik a buildelés, programatikus tesztelés és a termék publikálása a cél környezetbe. Ez lehetővé teszi, hogy kézi beavatkozás nélkül, akár a technikai tudás hiányában is lehessen újabb verziót kiadni.
Mivel mi leginkább “cloud-first” dolgozunk, azaz egy megadott felhő szolgáltatót (tipikusan Amazon Web Services) használunk, a másik fontos szempont a cél környezet létrehozásának és felügyeletének automatizálása.
Ez az ún. “infrastructure-as-code”. Azaz a szükséges erőforrások egy konfigurációs állományban vannak leírva, és egy automatizált szoftver végzi az erőforrás managementet. Például, egy alkalmazásnak szüksége van 3 szerverre, 2 adatbázisra, 1 load balancerre. Ezeket az erőforrásokat akár kézzel is létre tudjuk hozni az adott szolgáltató webes felületén, de ez idő igényes, és nagy a hiba kockázat. Ezért használunk erre specializálódott szoftvereket (pl. Terraform), ami képes automatikusan létrehozni számunkra a teljes virtualizált hardver környezetet és hálózati konfigurációt a felhőben.
Egy korábbi blogbejegyzésben röviden leírtuk a webalkalmazás fejlesztésének folyamatát. Egy agilis fejlesztési folyamat miben tér el ettől?
A blogbejegyzésből én hiányolom a folyamatos visszajelzést. A leírt fejlesztési/tervezési fázisok helyénvalók, de a leírt formában inkább hasonlít a vízesés modellre, mintsem egy ciklikus iterációra. Lehet, hogy csak egy vissza nyíl hiányzik a folyamat elejére.
Az interjút Mátis Eszter Léna és Hetes Réka készítette.