Feladat és jegy — mi ez, nyomonkövetési rendszerek és munka a feladatokkal

Mi az a feladat és jegy?

Feladat (angolul task) — egy nyomonkövetési rendszerben rögzített munkaegység. Tartalmaz leírást, prioritást (Critical, High, Medium, Low), végrehajtót, határidőt és státuszt. A mobilfejlesztésben a feladat lehet „Profilképernyő hozzáadása avatárral”, „Feed lapozás implementálása” vagy „A targetSdk verzió frissítése 35-re”. Minden feladat egy projekthez, sprinthöz és egy adott fejlesztőhöz vagy csapathoz van kötve.

Jegy (angolul ticket) — tágabb entitás. A jegy lehet hibajelentés („Az alkalmazás összeomlik képernyő forgatásakor Android 14-en”), funkciókérés („Sötét téma támogatásának hozzáadása”), technikai támogatási megkeresés („Push értesítés nem érkezik”) vagy menedzseri feladat („Havi crash rate jelentés elkészítése”). A feladat és a jegy közötti különbség elmosódott: a Jira-ban mindkét fogalom az Issue-ban egyesül. Fő különbség: a feladat mindig végrehajtóval rendelkező munka, a jegy lehet kérelem konkrét végrehajtó nélkül a triage pillanatáig.

A Scrum-ban és Kanban-ban a feladatok a backlog fő elemei. Minden feladatnak meg kell felelnie az INVEST kritériumnak (Independent, Negotiable, Valuable, Estimable, Small, Testable). A független feladatok bármilyen sorrendben megvalósíthatók. Becsülhető — a csapat meg tudja becsülni a munkaerő-ráfordítást. Kis méretű — belefér egy sprintbe. Tesztelhető — egyértelmű elfogadási kritériumokkal rendelkezik. A nagy feladatokat (epiceket) addig bontják kisebb részekre, amíg minden kritérium teljesül.

Feladattípusok a mobilfejlesztésben

Feature — az alkalmazás új funkcionalitása. Példa: „Bejelentkezési képernyő biometriával (Face ID / Touch ID)”. A Feature feladatok mindig user story-hoz kapcsolódnak és Elfogadási Kritériumaik vannak. Becslés — story points-ban (1, 2, 3, 5, 8, 13). Bug — a fejlesztés vagy tesztelés során talált hiba. A bug jegy prioritását a severity határozza meg (crash → Critical, UI-hiba → Medium, elírás → Low). Mobilfejlesztésben a 0,1% feletti crash rate kritikus hiba, azonnali javítást igényel.

Tech Debt / Chore — technikai feladatok a felhasználó számára látható hatás nélkül: könyvtárak frissítése (Dependency Bump), refaktorálás (Migráció ViewPager-ről ViewPager2-re), CI/CD beállítása, tesztek írása. A Tech Debt feladatokat gyakran alábecsülik, bár a Stripe 2025 adatai szerint a mobil csapat idejének akár 30%-a a technikai adósság karbantartására és törlesztésére megy el. A Tech Debt figyelmen kívül hagyása a hibák számának növekedéséhez és az új funkciók fejlesztésének lelassulásához vezet.

További típusok: Spike (kutató feladat — új technológia tanulmányozása, POC írása), Task (bármilyen, kódhoz nem kapcsolódó munka — dokumentáció, dizájn felülvizsgálat), Improvement (meglévő funkcionalitás javítása — képernyő betöltési idő optimalizálása). A Jira-ban az issue típusok projektenként konfigurálhatók. A mobil csapat szabványos készlete: Story, Bug, Task, Improvement, Epic. Epic — nagy téma, amely több történetet egyesít. Példa: „E-kereskedelem: kosár és rendelés leadása”.

A feladat életciklusa: létrehozástól lezárásig

Open (To Do) — a feladat létrejött, de még nem kezdődött el. Tartalmaz leírást, Elfogadási Kritériumbakat, prioritást. Ebben a státuszban a feladatnak át kell mennie a groomingon (tisztázás és becslés) a sprintbe kerülés előtt. In Progress — a fejlesztő elkezdte a munkát. Mobilfejlesztésben fontos a commitok és pull requestek összekapcsolása a feladattal: Jira-ban Smart Commits-on keresztül (APP-123 #comment hiba javítása), GitHub/GitLab-ban a PR leírásában lévő kulcsszavakon keresztül (Closes APP-123).

In Review — a kód elküldve felülvizsgálatra. Automatikus ellenőrzések: CI (Gradle build, lint, egységtesztek), SonarQube (kódminőség), Danger (changelog, tesztek). A fejlesztő nem veheti fel a következő feladatot, amíg a jelenlegi Review-ban van — ez megakadályozza a multitaskingot. QA / Testing — a tesztelő valós eszközökön ellenőriz (Android — különböző OS verziók és képernyőméretek, iOS — különböző iPhone modellek). Ha hibákat találnak, a feladat visszakerül In Progress-be egy megjegyzéssel.

Done (Closed) — a feladat befejeződött: a kód egyesítve a main/master ágba, átment a tesztelésen, készen áll a kiadásra. Néhány csapat hozzáadja a Deployed státuszt — a feladat csak a build áruházakban való megjelenése után jut el a felhasználóhoz. Fontos a feladatokat az eredményről szóló megjegyzéssel lezárni: melyik verzió, melyik PR, milyen metrikák változtak. A Linear (2025) adatai szerint azok a csapatok, amelyek az eredmény leírásával zárják le a feladatokat, 40%-kal ritkábban térnek vissza ugyanazokhoz a feladatokhoz.

Az életciklus tartalmazhatja a Blocked státuszt — a feladat külső függőség miatt nem hajtható végre (várjuk a dizájnt, a backend választ, a menedzser jóváhagyását). A blokkolt feladatoknak rendelkezniük kell egy megjegyzéssel az okról és a következő ellenőrzés dátumáról. A blokkolt feladatok heti felülvizsgálata segít azonosítani a rendszerszintű késéseket a fejlesztési folyamatban. A 2 hétnél hosszabb blokkolók eszkalációt igényelnek a termékmenedzser szintjére.

Feladat nyomonkövetési rendszerek

Jira — iparági szabvány a 10 fősnél nagyobb csapatok számára. Támogatja a Scrum és Kanban táblákat, fejlett workflow konfigurációt, egyéni mezőket, automatizálásokat, integrációt Bitbucket/GitHub-bal. Hátrányok: túlzottan összetett kis csapatoknak, lassú felület, bonyolult konfiguráció. Mobil projektekhez a Jira a következőkkel konfigurálható: Mobile-specific fields (Platform, OS version, Device model) plugin, TestFlight és Firebase Test Lab integráció, kiadási build-ek automatizálása. Jira — a bürokratikus folyamatokkal rendelkező vállalati projektek választása.

Linear — modern tracker termékcsapatok számára. Gyors felület, első osztályú billentyűparancs-támogatás, beépített Cycle (a sprint analógja), integráció GitHub-bal és Slack-kel. Előnyök: a feladatok gyors létrehozása CMD+K-n keresztül, automatikus fázisokba sorolás (Triaged → Backlog → Upcoming → Current → Completed), beépített dokumentáció és roadmaps. A Linear-t a gyorsaságot értékelő startupok és termékcsapatok választják. 2025-ben az új mobil projektek 40%-a használja a Linear-t.

Trello — egyszerű kanban tábla kis csapatoknak (2-5 fő). Kártyák ellenőrzőlistákkal, címkékkel, határidőkkel. Hátrány: nincsenek sprint-ek, korlátozott analitika, nehezen skálázható. YouGile — a Trello orosz megfelelője kanban táblákkal, chattel és videohívásokkal. Asana — tracker projektekre és idővonalakra fókuszálva. A tracker kiválasztása a csapat méretétől, költségvetésétől és preferenciáitól függ: Jira vállalati, Linear termékcsapatok, Trello/YouGile startupok számára. Fontos: az eszköznek egységesnek kell lennie az egész csapat számára — a tervezők, fejlesztők, tesztelők, menedzserek egy rendszerben dolgoznak.

Legjobb gyakorlatok a feladatok vezetéséhez

Írj Elfogadási Kritériumbakat — az elfogadási kritériumoknak konkrétnak és ellenőrizhetőnek kell lenniük. Rossz: „A bejelentkezési képernyő működik”. Jó: „A felhasználó megadja az e-mailt és jelszót, megnyomja a Bejelentkezés gombot. Ha az adatok helyesek — átirányítás a főképernyőre. Ha helytelenek — megjelenik a „Hibás e-mail vagy jelszó” hiba”. Az Elfogadási Kritériumbak (AC) szerződés a fejlesztő, a tesztelő és a termékmenedzser között. AC nélkül a feladat nem felel meg a Definition of Ready (DoR) feltételnek, és nem kerülhet a sprintbe.

Kapcsolj össze mindent. Commit-ok, PR-ek, tesztesetek, dizájn makettek (Figma), Slack megbeszélések — mindent kapcsolj a feladathoz. Jira-ban ez linkeken keresztül történik a megjegyzésekben, Linear-ban — a PR automatikus kapcsolásán keresztül. Egy kattintás szabálya: a feladattól a dizájnig/kódig/tesztekig — ne legyen több egy kattintásnál. A fejlesztő megnyitja a feladatot, és azonnal látja a Figma makettet, a PR linkjét és a teszteseteket. Ez a Linear (2025) adatai szerint 30%-kal gyorsítja a csapat új tagjainak betanulását.

Ne hozz létre szellemfeladatokat. A leírás, AC és prioritás nélküli feladat szemét. Ha a napi standupon senki sem emlékszik, miért hozták létre a feladatot — törölni vagy tisztázni kell. A 48 óra szabálya: ha egy feladat 48 órán át In Progress státuszban volt aktivitás nélkül — a fejlesztőnek megjegyzést kell hagynia a késés okairól. A Jira (2025) adatai szerint a 3 napnál tovább inaktív feladatok 60%-a végül végrehajtás nélkül záródik le.

Feladatok dekompozíciója: epicek, user story-k és alfeladatok

Epic — nagy funkcionális terület, amely több történetet egyesít. Példa: „Felhasználói onboarding” magában foglalja a „Üdvözlő képernyőt”, „Érdeklődési körök kiválasztását”, „Avatár feltöltését”, „Értesítések beállítását”. User Story — feladat a felhasználó szemszögéből. Formátum: „Mint [szerepkör], szeretném [cselekvés], hogy [érték]”. Példa: „Mint felhasználó, szeretnék biometriával bejelentkezni, hogy ne kelljen minden alkalommal jelszót beírnod”. A User Story-t a termékmenedzser vagy a terméktulajdonos írja.

Alfeladat (Sub-task) — a technikai munka dekompozíciója a Story / Task-on belül. Példa a „Profil képernyő” Story-ra: Sub-task 1: A képernyő UI-jának elkészítése (XML / SwiftUI), Sub-task 2: Összekapcsolás a ViewModel-lel, Sub-task 3: Egységtesztek írása, Sub-task 4: Snapshot tesztek, Sub-task 5: UI tesztek (Espresso / XCUITest). A dekompozíció szabálya: minden alfeladat 1-2 nap alatt elkészül. Ha a fejlesztő hosszabbra becsüli az alfeladatot — tovább bontjuk. Az alfeladatok a csapat belső technikáját képezik, nem láthatóak a termék backlogban. Az alfeladatok becsléseinek összege nem feltétlenül egyenlő a szülő Story becslésével (a munka egy része — kommunikáció, kód felülvizsgálat, tesztelés).

A dekompozíció piramisa: Epic (Negyedév / Félév) → Feature / Story (Sprint) → Task (1-3 nap) → Sub-task (Néhány óra). INVEST technika segít ellenőrizni a dekompozíció minőségét. Ha a feladat nem Independent (másoktól függ) — ez azt jelzi, hogy a dekompozíció helytelen. Ha a feladat nem Small (több mint 8 story point) — tovább kell bontani. Gyakori minta: Epic → 5-15 Stories → minden Story → 3-8 Sub-task. Az epic végső becslése = a Stories becsléseinek összege, de az első sprint általában 20-30%-os eltérést mutat a becslésekben.

Tipikus hibák a feladatokkal való munkában

Hiba 1: túl nagy feladatok. Egy 2 hetes feladat egy epic, amelyet dekomponálni kell. A nagy feladatok nem alkalmasak a napi nyomon követésre, hetekig lógnak In Progress-ben. Szabály: a feladat maximális mérete — 2-3 nap munka. Minden nagyobbat dekomponálni kell. Mellékhatás: a fejlesztő haladást érez, amikor hetente 2-3 feladatot zár le egy óriási helyett. Ez növeli a motivációt és a határidők kiszámíthatóságát.

Hiba 2: az Elfogadási Kritériumbak hiánya. A fejlesztő elkészítette a funkciót, a tesztelő ellenőrizte — minden rendben. Menedzser: „Hol van a szerkesztés gomb?” — „Nem írták a feladatban”. AC nélkül minden fél a maga módján értelmezi a feladatot. Eredmény: átdolgozás, konfliktusok, elszalasztott határidők. AC — szerződés: ha nincsenek kritériumok a feladatban — nem kész a sprintre. A grooming során elsőként az AC meglétét ellenőrzik. Ha AC nincs — a feladatot a Termékmenedzsernek küldik átdolgozásra.

Hiba 3: elfelejtjük a Tech Debt-et. A csapat csak Feature feladatokat csinál sprintről sprintre. Fél év után: a build 15 percig tart, a Gradle 3 főverzióval elavult, a tesztek a CI-ben a deprecation miatt megbuknak. Megoldás: a csapat idejének 20%-át Tech Debt-re tartalékolni (Google SRE „SLO-alapú hibaköltségvetés” gyakorlat). Legalább egy Tech Debt feladatot minden Feature sprinthez rendelj. Arány: minden 3 Feature feladatra — 1 Tech Debt vagy Bug. Ez megakadályozza a technikai adósság felhalmozódását és fenntartja a fejlesztési sebességet.