info@lebersoftware.hu

Milyen front-end fejlesztőnek lenni egy jól működő scrum csapatban egy IT nagyvállalatnál

Leber László vagyok, 8 hónapja dolgozok a Lufthansa Systems Hungaria-nál Senior front-end fejlesztőként egy scrum csapatban, ahol a vezető front-end fejlesztő posztot töltöm be.

Ebben a blog posztban kétféle szempontból szeretném leírni, hogy egy front-end fejlesztőnek milyen feladatai vannak nagyvállalati környezetben.

  1. milyen feladatokkal találkozhat, ami a csapathoz köthető. Céges szinten az egyik legjobban működő scrum csapatába csatlakozhattam, így fontosnak érzem leírni ennek működését és benne betöltött szerepemet.
  2. milyen technológiai feladatai vannak egy front-end fejlesztőnek, ami túlmutat a HTML, Javascript, CSS-en, de még a rájuk épülő keretrendszereken is, komplett front-end stack-ben kell gondolkodni.

1. Front-end fejlesztő scrum csapatban betöltött szerepe

Mint írtam, egy nagyon jól működő scrum csapatnak lehetek tagja, ami most jelenleg létszámban 10 fő (már nagyon a felső határ létszámban), amik a következők:

  • 1 fő product owner
  • 1 fő scrum master
  • 3 fő front-end-es
  • 3 fő back-end-es
  • 1 fő business analyst
  • 1 fő technical writer

Én jelenleg a front-end-es vezetőfejlesztő vagyok a csapatban, általános feladatim közé tartozik természetesen a kód írás (erről a 2. pontban írok majd részletesen), teszt írás és a code review-zása a többi front-end-es kollégának, de ezen felül számos más feladat is szóba jön, amihez ismerni kell egy scrum csapat működését.

Két projekten dolgozunk ezen csapattal, de egyazon témához kapcsolódóan. Amin dolgozunk, arról nem ejthetek szót, csak az általános működésünkről, de nyilván mivel egy repülőtársaság informatikai cégénél dolgozunk, nem titok, hogy repüléssel kapcsolatos dolgot fejlesztünk 🙂

A projektek sprintekre vannak bontva, 1 sprint 2 hetet vesz igénybe. Most leírom a sprintet megelőző és a sprint lépéseit is. Az egész folyamatot és a részfolyamatokat is a Scrum master vezényli le.

  1. Előzetesen a product owner a UX designerrel egyeztet (ennek legelső lépése egy workshop, amin az ügyfél is részt vesz – később írok erről is), jó előre kap egy jó adag megoldandó feladatot, amit ő megpróbál story-kra bontani és beteszi a backlog-ba.
  2. Még sprint előtt a csapat egy, vagy több refinementet tart, ahol az egész csapatnak bemutatja a product owner, hogy milyen story-k lógnak bent a backlog-ban, amik majd később kerülnek megoldásra. Itt fogjuk ezeket a story-kat és apróbb teendőkre bontjuk. Itt szeparáljuk a back-end és front-end feladatokat külön egy story-n belül. Itt a feladatom általában, hogy elmondjam, hogy szerintem front-end részről milyen lépéseket igényel a probléma megoldása.
  3. Ha kellően sok story-t kidolgoztunk, akkor egy rendszerben szavazást indítunk azok összetettségéről. Mindenki egyesével szavazhat, a projekt leírásban benne vannak a pontszámok, hogy milyen összetettséghez kb. milyen pontszám illik, de itt mindenki maga döntheti el, hogy egy story-ra melyik pontszámot adja. Itt közös megállapodás kell szülessen, ha nagy a szórás, akkor indoklás szükséges. A pontszámok nagyon fontosak, mert ez dönti el, hogy mekkora mennyiségű feladat fér el egy sprintben.
  4. A sprint kezdő napján (ami nálunk hétfő) megtartjuk a review/retro/planning megbeszélést, ahol először is megtartjuk a demo-t az előző sprintben elkészült dolgokról. Ez a demo a csapatnak szól, az mutat be, aki előzetesen elvállalja azt és felkészül rá. Itt be kell mutatni az elkészült szoftver egységet több tesztesetre is.
    A demo-t követően megyünk végig a backlogon és eldöntjük, hogy mit húzzunk be az aktuális sprintbe. A végén megállapodunk a sprint tartalmáról, megfogalmazódik a sprint célja és kezdetét veszi a kéthetes sprint.
  5. A két hét alatt minden nap tartunk daily megbeszélést, ahol mindenki elmondja, hogy előző nap mivel foglalkozott és aznap mivel fog. Ez kb. 15 percet vesz igénybe.
  6. A két hét során megbeszélt időpontokban a 2. pontban említett refinementekre is sor kerül.
  7. A második hetében a sprintnek már elegendő story elkészül ahhoz, hogy a tesztelés is elkezdődjön. Ez is egy nagyon fontos része a sprintnek, az ügyfél elégedettségét leginkább befolyásoló tényező, hogy a must-have story-k makulátlanok legyenek. Minden csapattag tesztelhet, de vannak azért tesztelésre jobban szakosodott kollégák és automatikus tesztek is, amiket egy kolléga ír a story-k alapján! Minden story minden taskja végigvan nyomogatva. Ehhez még hozzátartozik, hogy a sotry-khoz be lett írva az is, hogy minek kell teljesülni, hogy az a story sikeresnek tekinthető legyen.
  8. A sprint végén van demo preparation megbeszélés, ahol eldöntjük, hogy az elkészült story-kat ki demozza majd a csapaton belül.
  9. A sprint vége után 2 nappal megtörténik a nagy demo, ez már az ügyfél felé, amit általában a product owner és a business analyst prezentál. Ott van az ügyfél, annak cégének több képviselője, a UX designer, … Szerintem elég annyit leírnom a demo-val kapcsolatban, hogy egyszer az ügyfél a demo után annyit mondott, hogy a legjobb dolog, ami történt vele a COVID-19 idején az a demo-nk volt. Eddig szerencsére minden demo-nkal teljes mértékben elégedettek voltak.

Szóval a fentiek alapján elmondható, hogy a tervezésben erősen részt kell venni főleg vezető front-endesként, de alapjába véve minden részében a folyamatnak aktív résztvevője egy font-end fejlesztő, úgy, ahogyan a többi fejlesztő is.

A fentieken kívül, amivel még megtaláltak, amióta a cégnél vagyok, hogy menjek el workshopokra, ez általában külföldön történik, de Magyarország is a sorozat része. Ezen alkalmakkor jópár hónapra előre tervezve az ügyféllel közösen megbeszélve megtervezzük, hogy nagy vonalakban mivel fogunk foglalkozni. Ezen ott van általában a UX designer, az ügyfél, a product owner, a business analyst, és fejlesztők képviseletében 1-2 ember, így kerültem oda pl. én is.

Egyéb feladat, is adódhat még amivel cégen belül megtalálhatják az embert, ezek általában community feladatok, vagy egyéb programozási feladatok, pl. interjúkérdések készítése a leendő jelentkezőknek.

2. Front-end fejlesztő technológiai feladatai

Ha front-end fejlesztésről beszélünk, akkor legtöbben általában úgy képzelik el a dolgot, hogy CSS, HTML és egy JS framework/vagy library az, amit egy front-end fejlesztő általában használ. A valóság azonban az, hogy a front-end stack-hez jóval több minden tartozik egy átlagosnak mondható projektben egy komolyabb cégnél.

  1. Az első pont ami szinte triviális, hogy front-end fejlesztőnek mindig tisztában kell lenni az aktuálisan futó és gyakran használt framework-ökkel, pl. mostanában pl. React, Angular, Vue, valamelyikével, vagy többel is. Itt megemlíteném, hogy az alapnyelv újításaival is, tehát JavaScript-et betéve tudni kell. Aztán HTML, CSS-el,SASS-al, CSS post processorokkal, és egyéb mindenféle library-kal, ami még ezekbe integrálódik, tesztelő és tesztautomatizáló eszközökkel.
  2. Az általános front-end technológiákon kívül szükséges lehet használni valamilyen backend technológiát is, ami már nem annyira triviális egy front-end fejlesztőként, igaz? Példa képpen vegyük a Node.js-t. Tudjuk róla, hogy szerver oldalon futó kódot írunk vele, de még is részét képezheti a front-end stacknek olyan esetben például, ha pl. egy React, vagy egyéb front-end alkalmazást szerver oldalon szeretnénk kirenderelni (SSR – server side rendering), vagy szeretnénk a backend és a front-end közé egy middleware-t építeni egyéb okokból.
    Ilyenkor a böngészőbe beérkező kérés nem a backend-hez érkezik első kézből, hanem a Node.js alkalmazáshoz, ami elkészíti a React alkalmazás HTML kimenetét szerver oldalon, ehhez lekéri a backend-től az adatokat és mindent egyben elkülda front-end-nek. Erről bővebben az SSR-ről szóló írásban/videóban lehet olvasni: Link megnyitása
  3. Az előbbihez kapcsolódóan a front-end fejlesztő feladatához tartozik általában, hogy építse fel a teljes front-end stack-et, ami magába foglalja a front-end alkalmazást, pl. React, opcionálisan a middleware alkalmazást, pl. Node.js, akár egy NginX reverse proxy-t és ezeket konténerizálja be (mi Docker-t használunk). Itt szükségessé válhat némi shell script ismeret is kisebb script-ek elkészítésére akár. A konténer részét képezheti még akár egy hozzáférés-management rendszer (ami a usereket, azok jogait stb. kezeli) és maga a backend, de ezeket már a back-end-esek teszik be a konténerbe.
  4. Front-end-esnek kell bekötni különböző teszt automatizáló / tesztelő toolokat, pl. Cypress-t (Bővebb cikkem róla) és Enzyme + JEST-et (Bővebb cikkem róla) beépíteni a front-end stack-be.
  5. Tisztában kell lenni az aktuális CI rendszerrel, mert előfordul, hogy a front-end-endesnek kell bekonfigurálni pl. TeamCity-ben a Cypress-t, pl., hogy lefussanak a tesztek az automatikus build folyamat során.

Hát röviden (vagy hosszan) ennyiből áll a front-end fejlesztő feladata egy scrum csapatot figyelembe véve egy nagyvállalati környezetben 🙂

Leave a Reply