User storyk és agilis módszertan a webfejlesztésben
Mielőtt beleugranánk a témába, hogy mik is azok a user storyk pontosan, ejtsünk pár szót arról, hogy elméletileg milyen környezetben kellene találkoznunk a kifejezéssel!
A user storyk és az agilitás is itthon leginkább az IT területén, berkein belül lelhető fel, de az agilitás és az agilis módszertan nem kimondottan vagy feltétlen csak ezen területre korlátozódik. Mi több az agilis módszertan semmi olyat nem kiállt ki, ami IT specifikus.
Mi az hogy agilis, mi az az agilis módszertan? Hogyan jelenik meg az agilitás az IT szektorban és a webfejlesztésben applikáció fejklesztésben?
Az agilitás lényege hogy rugalmasan kezeljük a változásokat és felmerülő kéréseket problémákat. Az agilis manifesto négy értéke, ami magát az agilitást jelenti:
- Az egyének és személyes kommunikáció előnyben részesítése a módszertanokkal és eszközökkel szemben:
(Nem jelenti, hogy a megszokott módszereket és az eszközöket elfelejtjük, hanem hogy a személyes megbeszélés és kapcsolat sokkal többet segít, mint egy üzenet vagy email küldés, illetve kérdések esetén sokkal előremutatóbb is.) - A működő termék (szoftver) előnyben részesítése az átfogó leírás, dokumentációval szemben:
A klasszikus fejlesztési folyamat során összetett hosszú dokumentumokat kellett készíteni a tesztelés előtt, azonban a működő szoftver a preferált, a dokumentumok később is ráérnek. - Az együttműködést a megrendelővel/klienssel részesíti előnyben a szerződéses egyeztetéssel szemben:
Természetesen szükséges a szerződés is, azonban az még a fejlesztés során is egyeztethető, a folyamatos szerződésre hivatkozásokkal szemben. Együtt kell működni a megrendelővel! - A változás iránti készséget részesíti előnyben a tervek szolgai követésével szemben:
A nem működő terv bármi áron követésre erőszakolása helyett, hasznosabb, ha az idomul az esetleges változásokhoz. Semmi, így a fejlesztések sem fognak 100%-ban a kezdeti elképzeléseknek megfelelően megvalósulni, általában ennél több a végeredmény.
Ejtsünk pár mondatot a már előző bejegyzéseinkben is említett user storykról, és az elfogadási feltételekről/elfogadási kritériumokról!
Az agilis módszertanok közös jellemzője, hogy a feladatokat az azokat megoldó szereplők jól megfogalmazott és körülírt formában kapják meg (ennek mindenhol így kellene lennie szerintünk), ennek a legismertebb neve pedig a "User Story", azaz a felhasználói történet.
Az elvárt működés definiálása a legfontosabb része a fejlesztésnek, hiszen bármilyen apró feature-vel kapcsolatban kérdések, elvárások merülhetnek fel, amiket tisztázni kell, ezeket a kérdéseket/elvárásokat pedig költség és időhatékonyság miatt is a lehetőségeinkhez mérten legkorábbi státuszban kell kérdések esetén feltenni, elvárások esetén pedig lefektetni.
A lehető legjobb mód erre egy közös planning (tervezés) a megrendelővel, és a fejlesztőkkel, ami nem csak tiszta képet ad magáról az üzleti igényről, vagy a megrendelő elképzeléseiről, de akár már a kezdeti fázisban kiderülhet, hogy valamit lehet-e adott/elvárt módon kivitelezni, vagy akár egy olcsóbb és/vagy jobb megoldással lecserélhető. (Költséghatékonyabb és a fejlesztőknek is könnyebb, nem egy már működő feature-t átírni, hanem az első pillanattól kezdve jól megtervezve lefejleszteni azt.)
Mit írjunk le a működési igényben / elfogadási kritériumokban a fejlesztés előkészítésének fázisában?
Nos, a fent megfogalmazottak alapján, a felhasználó szemszögéből látott elvárt funkcionalitást, illetve az esetleges rejtett/nem-rejtett de nem egyértelmű működésekre is kitérünk. Egy egyszerű példával élve, ha egy regisztrációt szeretnénk user story formájában megfogalmazni, az a következőképpen nézhetne ki:
Én mint az oldalra érkező felhasználó, szeretnék egy felületen képes lenni eltárolni a felhasználói adataimat, amivel a későbbiekben be tudok jelentkezni.
Elfogadási kritériumok:
- A regisztráció első lépése során a felhasználó az oldalon belül egy "/registration" url-en csupán "e-mail cím"; "jelszó"; és "jelszó megerősítése" mezők kitöltése után, illetve egy "elfogadom a az ászf-ben foglaltakat" checkbox bepipálásával mentésre kerül az adatbázisba.
- A felhasználó csak a megadott e-mail címre érkező megerősítő-linkre történő kattintás után tud az oldal felületére bejelentkezni.
- A checkbox szövege admin-felületen változtatható, illetve cserélhető alatta a hivatkozás is.
- Regisztráció során a felhasználó a hírlevél feliratkozók közé is felvételre kerül, amely az "elfogad pipánál" szintén feltüntetésre kerül. A kicsi de számunkra fontos kiegészítéseket is nyugodtan vegyük fel!
Láthatóan semmi technikai információ/döntés nincs a leírtakban, ezek meghozatalát igyekezzünk a profikra bízni, csak az igényeket tisztázzuk számukra a lehető legegyértelműbb formában, hogy a tervezéshez minden szükséges információ a rendelkezésükre álljon!
Végezetül annyit, hogy egy jól megtervezett feature a késsőbbiekben tovább terjeszthető ki más működésekkel, így ne legyünk restek megosztani a terveinkket a fejlesztőkkel, higgyük el, hogy ők nem fogják a szerintünk "fantasztikus" és "piacon egyedi" ötleteinkket ellopni.
Szerző: Dombi István
2010 óta fogalkozom webfejlesztéssel, az egyszerű céges weboldalaktól kezdve az e-kereskedelmi platformokon és különböző API integrációkon át (fizetési átjárók és egyéb harmadik féltől származó APIk), egészen a nemzetközi komplex webalkalmazásokig gyakorlatilag mindenféle projekten volt már szerencsém dolgozni. Fő stack-em a backend fejlesztés, azon belül PHP és a GO nyelv.