Задатак и тикет — шта је то, системи за праћење и рад са задацима

Шта је задатак и тикет?

Задатак (од енгл. task) — јединица рада забиљежена у систему за праћење. Садржи опис, приоритет (Critical, High, Medium, Low), извршиоца, рок и статус. У мобилном развоју, задатак може бити „Додавање екрана профила са аватаром”, „Имплементација пагинације фида” или „Ажурирање верзије targetSdk на 35”. Сваки задатак је везан за пројекат, спринт и конкретног програмера или тим.

Тикет (од енгл. ticket) — шира суштина. Тикет може бити пријава грешке („Апликација се руши при ротацији екрана на Android 14”), захтјев за функцију („Додавање подршке за тамну тему”), обраћање техничкој подршци („Пусх обавијештење не стиже”) или задатак од менаџера („Припрема извјештаја о стопи рушења за мјесец”). Разлика између задатка и тикета је замагљена: у Jira оба појма су обједињена у Issue. Кључна разлика: задатак је увијек рад са извршиоцем, тикет може бити захтјев без конкретног извршиоца до момента тријаже.

У Scrum и Kanban, задаци су основни елемент бекалога. Сваки задатак треба да испуњава критеријум INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable). Независни задаци се могу реализовати било којим редослиједом. Процјењиви — тим може процијенити радни напор. Мали — уклапају се у један спринт. Тестирабилни — имају јасне критеријуме прихватања. Велики задаци (епици) се дијеле на мање док се не испуне сви критеријуми.

Врсте задатака у мобилном развоју

Feature — нова функционалност апликације. Примјер: „Екран за пријаву путем биометрије (Face ID / Touch ID)”. Feature задаци су увијек повезани са причом корисника и имају Критеријуме прихватања. Процјена — у story points (1, 2, 3, 5, 8, 13). Bug — дефект пронађен у процесу развоја или тестирања. Приоритет баг тикета одређује се severity (crash → Critical, UI-баг → Medium, штампарска грешка → Low). У мобилном развоју, стопа рушења изнад 0.1% је критична грешка и захтијева хитну поправку.

Tech Debt / Chore — технички задаци без видљивог ефекта за корисника: ажурирање библиотека (Dependency Bump), рефакторисање (Миграција са ViewPager на ViewPager2), подешавање CI/CD, писање тестова. Tech Debt задаци се често потцјењују, иако према подацима Stripe 2025, до 30% времена мобилног тима одлази на одржавање и отплату техничког дуга. Игнорисање Tech Debt-а доводи до пораста броја грешака и успоравања развоја нових функција.

Додатне врсте: Spike (истраживачки задатак — проучавање нове технологије, писање POC-а), Task (било који рад који се не односи на код — документација, преглед дизајна), Improvement (побољшање постојеће функционалности — оптимизација времена учитавања екрана). У Jira, врсте issues-а се подешавају по пројекту. Стандардни скуп за мобилни тим: Story, Bug, Task, Improvement, Epic. Epic — велика тема која обједињује више прича. Примјер: „Е-трговина: корпа и оформпљавање поруџбине”.

Животни циклус задатка: од креирања до затварања

Open (To Do) — задатак креиран, али није започет. Садржи опис, Критеријуме прихватања, приоритет. У овом статусу, задатак треба да прође груминг (разјашњавање и процјену) прије уласка у спринт. In Progress — програмер је започео рад. У мобилном развоју важно је повезивати комите и pull request-e са задатком: у Jira путем Smart Commits (APP-123 #comment поправка грешке), у GitHub/GitLab путем кључних ријечи у опису PR (Closes APP-123).

In Review — код послат на ревизију. Аутоматске провјере: CI (Gradle build, lint, јединични тестови), SonarQube (квалитет кода), Danger (changelog, тестови). Програмер не може да преузме сљедећи задатак док је тренутни у Review — то спречава мултитаскинг. QA / Testing — тестер провјерава на стварним уређајима (Android — различите верзије ОС-а и величине екрана, iOS — различити модели iPhone-а). Ако су пронађене грешке — задатак се враћа у In Progress са коментаром.

Done (Closed) — задатак завршен: код спојен у main/master, прошао тестирање, спреман за објављивање. Неки тимови додају статус Deployed — задатак стиже до корисника тек након објављивања билда у продавницама. Важно је затварати задатке са коментаром о резултату: која верзија, који PR, које метрике су се промијениле. Према подацима Linear (2025), тимови који затварају задатке са описом резултата се 40% рјеђе враћају истим задацима.

Животни циклус може укључивати статус Blocked — задатак се не може извршити због спољне зависности (чекамо дизајн, одговор са бекенда, одобрење менаџера). Blocked задаци треба да имају коментар са разлогом и датумом сљедеће провјере. Недељни преглед Blocked задатака помаже у идентификацији системских кашњења у процесу развоја. Блокери дужи од 2 недеље захтијевају ескалацију на ниво менаџера производа.

Системи за праћење задатака

Jira — стандард индустрије за тимове од 10 људи. Подржава Scrum и Kanban табле, напредно подешавање радног тока, прилагођена поља, аутоматизације, интеграцију са Bitbucket/GitHub. Недостаци: сувишност за мале тимове, спор интерфејс, сложена конфигурација. За мобилне пројекте, Jira се подешава помоћу: плагина Mobile-specific fields (Platform, OS version, Device model), интеграције са TestFlight и Firebase Test Lab, аутоматизације креирања издања. Jira — избор корпоративних пројеката са бирократским процесима.

Linear — савремени тракер за производне тимове. Брз интерфејс, првокласна подршка за пречице на тастатури, уграђени Cycle (аналог спринта), интеграција са GitHub и Slack. Предности: брзина креирања задатака путем CMD+K, аутоматска расподјела по фазама (Triaged → Backlog → Upcoming → Current → Completed), уграђена документација и мапе пута. Linear бирају стартапи и производни тимови који цијене брзину рада. У 2025. години, 40% нових мобилних пројеката користи Linear.

Trello — једноставна канбан табла за мале тимове (2-5 људи). Картице са листама за провјеру, ознакама, роковима. Недостатак: нема спринтова, ограничена аналитика, тешко скалирање. YouGile — руски аналог Trello-а са канбан таблама, четом и видео позивима. Asana — тракер са фокусом на пројекте и временске планове. Избор тракера зависи од величине тима, буџета и преференција: Jira за enterprise, Linear за производне тимове, Trello/YouGile за стартапе. Важно: алат треба да буде јединствен за цијели тим — дизајнери, програмери, тестери, менаџери раде у једном систему.

Најбоље праксе вођења задатака

Пишите Критеријуме прихватања — критеријуми прихватања треба да буду конкретни и провјерљиви. Лоше: „Екран за пријаву ради”. Добро: „Корисник уноси е-маил и лозинку, притиска Пријава. Ако су подаци тачни — прелазак на главни екран. Ако су нетачни — приказује се грешка „Погрешан е-маил или лозинка””. Критеријуми прихватања (AC) су уговор између програмера, тестера и менаџера производа. Без AC, задатак не испуњава Definition of Ready (DoR) и не треба да улази у спринт.

Повезујте све. Комити, PR-ови, тест случајеви, дизајн макете (Figma), дискусије у Slack-у — све треба да буде везано за задатак. У Jira се то ради путем линкова у коментарима, у Linear — кроз аутоматско повезивање PR-а. Правило једног клика: од задатка до дизајна/кода/тестова — не више од једног клика. Програмер отвара задатак и одмах види макету у Figma, линк ка PR-у и тест случајеве. Ово убрзава онбординг нових чланова тима за 30% према подацима Linear (2025).

Не креирајте задатке-духове. Задатак без описа, без AC и без приоритета — смеће. Ако на дневном стендапу нико не памти зашто је задатак креиран — треба га обрисати или разјаснити. Правило 48 сати: ако је задатак био у статусу In Progress без активности 48 сати — програмер треба да остави коментар о разлозима кашњења. Према подацима Jira (2025), 60% задатака који мирују дуже од 3 дана на крају се затвара без извршења.

Декомпозиција задатака: епици, приче корисника и подзадаци

Epic — велика функционална област која обједињује више прича. Примјер: „Онбординг корисника” укључује „Екран добродошлице”, „Избор интересовања”, „Учитавање аватара”, „Подешавање обавијештења”. User Story — задатак из перспективе корисника. Формат: „Као [улога], желим да [акција] да бих [вриједност]”. Примјер: „Као корисник, желим да се пријавим путем биометрије да не бих уносио лозинку сваки пут”. User Story пише менаџер производа или власник производа.

Подзадатак (Sub-task) — декомпозиција техничког рада унутар Story / Task. Примјер за Story „Екран профила”: Sub-task 1: Израда UI екрана (XML / SwiftUI), Sub-task 2: Повезивање са ViewModel, Sub-task 3: Писање јединичних тестова, Sub-task 4: Snapshot тестови, Sub-task 5: UI тестови (Espresso / XCUITest). Правило декомпозиције: сваки подзадатак се завршава за 1-2 дана. Ако програмер процјењује подзадатак дуже — дијелимо даље. Подзадаци су интерна техника тима, нису видљиви у бекалогу производа. Збир процјена подзадатака није обавезно једнак процјени родитељске Story (дио рада — комуникација, code review, тестирање).

Пирамида декомпозиције: Epic (Квартал / Полугодиште) → Feature / Story (Sprint) → Task (1-3 дана) → Sub-task (Неколико сати). Техника INVEST помаже у провјери квалитета декомпозиције. Ако задатак није Independent (зависи од других) — то је сигнал да је декомпозиција неправилна. Ако задатак није Small (више од 8 стори поена) — треба дијелити даље. Уобичајени образац: Epic → 5-15 Stories → свака Story → 3-8 Sub-task-ова. Коначна процјена епика = збир процјена Stories, али први спринт обично даје одступање од 20-30% у процјенама.

Типичне грешке при раду са задацима

Грешка 1: превелики задаци. Задатак од 2 недеље рада је епик који треба декомпоновати. Велики задаци се не могу уклопити у дневно праћење, висе у In Progress недјељама. Правило: максимална величина задатка — 2-3 дана рада. Све веће — декомпоновати. Нус-ефекат: програмер осјећа напредак затварајући 2-3 задатка недјељно умјесто једног џиновског. То повећава мотивацију и предвидљивост рокова.

Грешка 2: недостатак Критеријума прихватања. Програмер је направио функцију, тестер провјерио — све у реду. Менаџер: „А гдје је дугме за уређивање?” — „У задатку није написано”. Без AC свака страна разумије задатак на свој начин. Резултат: прерада, конфликти, промашени рокови. AC — уговор: ако у задатку нема критеријума — није спреман за спринт. На грумингу се прво провјерава постојање AC. Ако AC нема — задатак се шаље на дораду Product Manager-у.

Грешка 3: заборављамо на Tech Debt. Тим ради само Feature задатке спринт за спринтом. Након пола године: компілација траје 15 минута, Gradle је застарио за 3 главне верзије, тестови падају на CI због deprecation. Рјешење: резервисати 20% времена тима за Tech Debt (Google SRE пракса „SLO-based error budget”). Заведите барем један Tech Debt задатак на сваки Feature спринт. Пропорција: на свака 3 Feature задатка — 1 Tech Debt или Bug. Ово спречава акумулацију техничког дуга и одржава брзину развоја.