5.6 Sprint és kanban gondolkodásmód juniorként

Áttekintő

Ha az első munkanapodra belépsz egy tech céghez, szinte biztos, hogy találkozni fogsz két szóval: sprint és kanban. Valamelyik formájában szinte minden fejlesztőcsapat valamelyik Agile módszertant használja – és ha nem érted a játékszabályokat, könnyen elveszhetsz benne.

Ez az alfejezet nem arról szól, hogy megszerezd a PMI-ACP vagy SAFe tanúsítványt. Arról szól, hogy juniorként hogyan navigálj a csapatod munkaszervezési rendszerében – mit vállalj be, hogyan mutasd meg a haladásod, és mit jelent a retró.

Miért számít az állásinterjún?
Sok technikai interjú tartalmaz kérdéseket mint: „Dolgoztál már Agile csapatban?" vagy „Hogyan szoktad becsülni a feladataidat?" Ha nem tudod értelmesen megválaszolni, az piros zászló. Ha igen, kitűnsz.

Miért számít az első munkanapodtól?
Sprint planning, daily standup, retró – ezek mind olyan rituálék, amikben részt kell venned. Ha érted a logikájukat, nem csak elszenvedője leszel, hanem aktív résztvevője.

Részletes leírás

Sprint vs. Kanban – Mi a különbség valójában?

Mindkettő az Agile gondolkodásmód megvalósítási formája, de különböző logikával működnek.

Sprint (Scrum-alapú)

A sprint időzített doboz – általában 1-4 hét, leggyakrabban 2 hét. A csapat a sprint elején eldönti, hogy mit fog elvégezni, és a sprint végére kiszállítja. Sprint közben a scope alapvetően nem változik.

Hogyan épül fel egy sprint ciklus:

Sprint Planning (sprint eleje)
  → Daily Standup (minden nap)
  → Development (sprint közben)
  → Sprint Review / Demo (sprint vége)
  → Sprint Retrospective (sprint vége)
  → [következő Sprint Planning]

Kulcsfogalmak:

Sprint backlog: az a ticket-lista, amit a csapat a sprintre bevállalt
Product backlog: az összes még el nem végzett feladat, amiből a sprintre kiválasztunk
Sprint goal: mi az a egy dolog, amit a sprint végére el kell érni?
Velocity: mennyit tud elvégezni a csapat egy sprint alatt (story pointban mérve)

Kanban

A kanban folyamatos áramlás – nincs rögzített időkeret. Feladatok jönnek be, bekerülnek a boardra, és haladnak végig az oszlopokon (To Do → In Progress → Review → Done). Nincs sprint planning, nincs sprint review.

Kanban board tipikus oszlopai:

| Backlog | To Do | In Progress | In Review | Done |

Mikor melyiket használják?

Sprint/Scrum: új termékfejlesztés, tervezett feature-ök, rendszeres kiszállítás
Kanban: support csapatok, ops, bugfix-orientált csapatok, ahol az igény kiszámíthatatlan

A valóság: A legtöbb csapat hibrid – sprint keretrendszert használ, de kanban-szerű flexibilitással. Ha a céged azt mondja „Scrum-ot csinálunk", valószínűleg Scrum-ish módszertant csinál. Ne lepődj meg.

Junior szerep egy sprintben: mit vállalj be és mennyit?

Ez az egyik legtöbbször elrontott dolog junioroknál – és mindkét irányban el lehet rontani.

Az alul-vállalás csapdája

Ha minden sprintben 1-2 ticket-et vállalsz be, miközben a csapat többi tagja 5-8-at, az látható. A seniorok nem fogják hangosan mondani, de megjegyezik. Úgy tűnhet, hogy nem vagyok elég motivált, vagy nem fejlődsz.

A túl-vállalás csapdája

Ha a lelkesedéstől elvakítva 10 ticket-et vállalsz be, majd a sprint végére csak 4-et teljesítesz, az még rosszabb. A csapat a te vállalásodra épített, és most csúszik valami.

Az arany közép: hogyan becsüld helyesen?

1. Kérdezz, ne tippelj

Ha bizonytalan vagy egy feladat méretében:

„Ez hasonló ahhoz, mint amit múlt héten csináltam?" – ha igen, kb. ugyanannyi idő
„Van bármilyen ismeretlen technikai rész?" – ha igen, +50% biztonsági ráhagyás

2. Törj kisebb egységekre

Ha egy ticket azt mondja: „Implementáld a jelszó visszaállítás funkciót" – ez nem egy feladat. Ez legalább 4-5 feladat:

Form UI megcsinálása
API endpoint megírása
Email küldés integrálása
Token generálás és érvényesítés
Tesztek írása

Ha nem látod a részeket, a becslésed valószínűleg rosszul fog sülni el.

3. Az első 1-3 sprint: tanulj, ne optimalizálj

Az első sprintekben az a célod, hogy kalibrálj. Vállalj be annyit, amennyit biztosan tudsz. Majd a következő sprintben finomíts. Senki nem várja el, hogy azonnal tökéletes becslőgép legyél.

4. Buffer idő létezik – számolj vele

A sprint ideje nem 100%-ban fejlesztés. Van:

Daily standup (napi 15 perc = sprint alatt ~2.5 óra elvész)
Code review (mások PR-jait is nézed)
Meetingek, 1:1-ek
Váratlan bugok, kérdések

Realista kalkuláció: egy 2 hetes sprint alatt egy junior fejlesztőnek ~6-7 "mély" fejlesztési napja van.

Daily standup és a ticket kapcsolata

A daily standup 3 kérdés:

Mit csináltam tegnap?
Mit csinálok ma?
Mi blokkol?

Juniorként a leggyakoribb hiba: homályos, folyamat-alapú válaszok adása:

❌ „Tegnap dolgoztam a bejelentkezésen, ma is azzal folytatom."

✅ „Tegnap lezártam a PROJ-142-t (login form validáció), ma a PROJ-143-on kezdek (API endpoint). Semmi nem blokkol."

Miért a ticket száma fontos?

Mert a csapatod a boardot nézi, nem téged emlékeznek mindenre. Ha ticket számokat mondasz, bárki megnézheti a boardon, hogy pontosan mit értesz alatta. Ez átláthatóságot teremt.

Blocker – ne rejtsd el

Ha elakadtál, mond el a standupban. Ne szenvedj csendben 2 napig. Ha valami blokkol:

„Blokkol az, hogy az X service API dokumentációja hiányos és nem tudom, milyen paramétert vár. Ha valaki tud segíteni, megköszönöm."

Ez nem gyengeség – ez professzionális kommunikáció.

Retrospektív: mire való és hogyan vegyél részt juniorként?

A retró a sprint utolsó eseménye, ahol a csapat visszanéz:

Mi ment jól?
Mi ment rosszul?
Mit változtatunk a következő sprintre?

Juniorként sokan csendben ülnek a retrókon. Ez érthető – nem akarsz kritizálni seniort, nem akarsz hülyén hangzani. De ez hiba.

Miért fontos, hogy megszólalj?

Te látsz dolgokat, amit a seniorok már nem – Ha valami dokumentálatlan volt és te elvesztetted emiatt fél napod, ez értékes visszajelzés. A seniorok már annyira belenőttek a rendszerbe, hogy nem is látják, hogy ez probléma.

A retró nem vitázásra való – Ez egy biztonságos tér, ahol normák szerint senki személyesen nem támadható. A folyamatokat kritizáljuk, nem az embereket.

Ha nem szólsz, nem változik semmi – És te is frusztrált leszel ugyanattól a problémától 3 sprint múlva.

Hogyan szólalj meg hatékonyan?

Formátum: Megfigyelés + Javaslat (nem panasz)

❌ „A PR review nagyon lassú volt."

✅ „Megfigyeltem, hogy a PR-jeimre átlagosan 2 napot kellett várni review-ra, ami néha elakasztott engem a következő ticketen. Próbálhatnánk-e egy megállapodást, hogy max 24 óra a review idő?"

Ez konkrét, nem személyeskedő, és javaslatot tartalmaz.

Tipikus retró formátumok:

Start / Stop / Continue:

Start: mit kezdjünk el csinálni?
Stop: mit hagyjunk abba?
Continue: mi működik jól, amit tartsunk meg?

Mad / Sad / Glad:

Mi bosszantott fel?
Mi szomorított el?
Mi tett boldoggá?

Ha látod, hogy a facilitátor (általában a Scrum Master) elindítja a retró templatejét – ne várd meg, hogy más szóljon elsőnek.

Hogyan mutasd meg a haladásodat a csapat felé?

Juniorként az egyik legnagyobb tévhit: „majd látják a munkámat a commitjaimban / a merge-elt PR-okban."

Nem látják. Vagy nem elég időben.

A haladásod kommunikálása proaktív feladat – nem fog senki utánad kérdezni minden nap (legalábbis egy egészséges csapatban nem).

Eszközök a haladás kommunikálásához

1. Board frissítése valós időben

Ha elkezdesz egy ticketen dolgozni → húzd In Progress-be.
Ha befejezted és PR nyitottál → húzd In Review-ba.
Ha merge-ölték → Done.

Ez egyszerűnek hangzik, de sok junior elfelejti. A board az igazság forrása – ha ott nem látják, hogy dolgozol, a menedzsment szemszögéből nem dolgozol.

2. PR-t korán nyiss meg (Draft PR)

Ha egy feladaton dolgozol, amit másnap nem fejezel be, nyiss Draft PR-t. Ez jelzi:

Elindultál
Látható a haladás a commitok formájában
Kérhetsz early feedbacket

3. Írj commentet a ticketre, ha elakadsz

Ha blocker van és nem tudsz megoldást a standupig:

Megjegyzés a ticketre:
"[2026-04-30] Elakadtam az X API integráción - a dokumentáció nem írja le, 
hogy milyen auth headert vár. Megpróbálom a Slack-en megkérdezni a backend teamtől, 
de ha valaki tudja, szóljon."

Ez láthatóvá teszi a problémát, és dokumentálja, hogy nem ülsz tétlenül.

4. Sprint Review-n mutass meg dolgot

Ha a csapatod tart Sprint Review-t (demo), ne bújj el. Ha van bármilyen befejezett feladatod – mutasd meg. Nem kell tökéletesnek lennie. 5 perc is elég.

Életszerű példák

Példa 1: Sprint Planning – Mit vállalj be?

Szituáció: Első sprint planning-ödön vagy. A product owner bemutat 15 ticketet. A Scrum Master megkérdezi, ki mit vállal.

❌ Rosszul: Csendben ülsz és vársz, hogy a senioral döntsék el.

❌ Rosszul: Felvállalod az összes nehéz backendest, mert „megmutatom, hogy bírom".

✅ Jól:

Megnézed a backlogot és kiemeled azokat, amiket valószínűleg elvégezhetsz a sprint alatt.
Megkérdezed: „A PROJ-201 – ez kb. akkora feladat mint a múlt sprinten befejezett PROJ-185?"
Bevállalsz 3-4 ticketet, amit reálisnak érzel, és jelzed: „Ha ezeket befejezem, felveszek még egyet a backlogból."

Példa 2: Elakadtál Sprint közben

Szituáció: Hétfőn bevállaltad a PROJ-210-et (payment integráció). Szerdán még mindig azon töröd a fejed, hogyan működik a Stripe webhook. A sprint pénteken ér véget.

❌ Rosszul: Csendben szenvedsz, reméled, hogy megtalálod a megoldást, és pénteken azt mondod „sajnos nem sikerült".

✅ Jól:

Szerdai standupon jelzed: „PROJ-210-en dolgozom, de elakadtam a webhook mechanizmuson. Ha valaki csinált már hasonlót, segítene 15 percet?"
Ha senki nem reagál azonnal, Slack-en megkérdezed a csatornán.
Ha péntekre sem sikerül befejezni, pénteki standupon jelzed: „PROJ-210 nem kerül Donera ezen a sprinten – még kb. 1 napnyi munka van hátra. Átvisszük a következő sprintre."

Ez nem kudarc – ez transzparencia. A sprint nem teljesítése akkor probléma, ha meglepetésként éri a csapatot.

Példa 3: Kanban csapatnál vagy

Szituáció: Support-fejlesztési hybrid csapatnál kezdesz. Nincs sprint. Reggel belépsz a boardra, és a „To Do" oszlopban 8 ticket van.

❌ Rosszul: Véletlenszerűen választasz egyet.

✅ Jól:

Megnézed a prioritást (általában van priority label, vagy a sorrend maga mutatja)
Kiválasztod a legmagasabb prioritásút, amit egyedül megcsinálhatsz (ne válassz olyat, ahol blocker van)
Húzod „In Progress"-be, és elkezded
Ha befejezted → „Done", és kihúzod a következőt

A kanban logikája: ne kezdj el sok mindent egyszerre. Egy dolgot csinálj, fejezd be, utána a következő. Ezt hívják WIP limit-nek (Work In Progress limit).

Példafeladat: Sprint tervezési szituáció

Kontextus: A csapatod 2 hetes sprintben dolgozik. A sprint capacity 60 story point (az egész csapaté). Te a csapat junior fejlesztője vagy, és az elmúlt 2 sprintben összesen 8-10 story pontot teljesítettél sprintenként.

A backlogból az alábbi ticketek érhetők el:

Ticket	Leírás	Story pont	Megjegyzés
PROJ-301	Login form bugfix (rossz hibaüzenet)	1	Hasonló volt már
PROJ-302	Felhasználói profil oldal UI frissítése	3	Design készen van
PROJ-303	Exportálás Excel-be funkció	8	Ismeretlen library
PROJ-304	Admin dashboard statisztikák	5	Backend kész, csak frontend
PROJ-305	Email értesítés beállítások	5	Email rendszer ismeretlen
PROJ-306	Jelszó erősség indikátor UI	2	Tiszta frontend
PROJ-307	Rate limiting implementáció	13	Senior feladat

Feladatod:

Válaszd ki, melyik ticketeket vállalod be a sprintbe és miért!
Melyiket hagyod a backlogban és miért?
Mi az, amit mindenképpen megkérdeznél sprint planning előtt?

Mintamegoldás (saját megoldás után nézd meg!):

Mintamegoldás megtekintése

Bevállalt ticketek:

PROJ-301 (1 pont) – Kis bugfix, ismerős terület, gyorsan kész
PROJ-302 (3 pont) – Design már kész, megcsinálható
PROJ-306 (2 pont) – Tiszta frontend, valószínűleg nincs ismeretlen rész
PROJ-304 (5 pont) – Ha a backend valóban kész, ez kezelhető

Összesen: 11 pont – kicsit több mint az elmúlt sprintekben, de kezelhető.

Backlogban hagyott ticketek:

PROJ-303 – Ismeretlen library. Vagy megkérdezed, van-e belső tapasztalat, vagy a következő sprintre hagyod, amíg utánajársz.
PROJ-305 – Email rendszer ismeretlen. Kockázatos.
PROJ-307 – Senior feladat, nem neked való ebben a szakaszban.

Kérdések sprint planningre:

„A PROJ-304-nél pontosan milyen adatokat kell megjeleníteni? Van mockup?"
„A PROJ-303-hoz melyik Excel library-t preferálja a csapat?"
„A PROJ-302-höz van component library amit használjak, vagy nulláról csináljam?"

Helyes válasz: b – Konkrét ticket szám + mit csinálsz ma + blocker státusz.