Груминг задатака у мобилном развоју: суштина, циљеви и процес спровођења

Шта је груминг задатака?

Backlog Grooming (refinement) — процес припреме задатака Product Backlog-а за будуће спринтове. Састанак на којем Product Owner и развојни тим прегледају задатке: прецизирају захтеве, додају Acceptance Criteria, процењују сложеност, идентификују зависности и ризике. У Scrum Guide-у не постоји обавезан догађај „груминг" — то је додатна пракса коју Scrum тимови уводе ради смањења неизвесности на Sprint Planning-у. Препоручена учесталост — 1 пут у спринту, не дуже од 60 минута.

Термин „чешљање" (grooming) одражава суштину: тим „чешља" бацклог, уклањајући zastarele задатке, прецизирајући нејасне и делећи превелике. У мобилном развоју груминг је посебно важан због платформске специфике: задатак за Android може се разликовати од iOS верзије по сложености, потребно је узети у обзир targetSdk, compileSdk, компатибилност са API нивоима. Без груминга Sprint Planning се претвара у хаос: тим први пут види задатке и не може их проценити, што води до непредвидивости и кашњења.

Резултат груминга — неколико задатака спремних за Sprint Planning: имају опис, Acceptance Criteria, процену и одговарају Definition of Ready. Product Owner треба да грумира задатке по редоследу приоритета: најближи текућем спринту — најдетaљнији. Задаци за 3-4 спринта унапред — само на нивоу епика. Техника Progressive Refinement: што је задатак ближи спринту, детaљнији је његов опис. За задатке у текућем спринту — full refinement (AC, дизајн, API спецификација). За задатке за 2 спринта — story-level (user story без детаља имплементације). За задатке за 3+ спринта — epic-level (само назив и пословна вредност).

Definition of Ready: када је задатак спреман за спринт

Definition of Ready (DoR) — контролна листа критеријума којима задатак мора да одговара пре укључивања у Sprint Backlog. DoR је уговор између Product Owner-а и тима: PO гарантује да су све информације за развој доступне, тим гарантује да може да процени и изврши задатак. DoR није универзалан — сваки тим одређује свој скуп критеријума. Без DoR-а задатак може да уђе у спринт са нејасним захтевима, што доводи до прерада и кашњења.

Типичан DoR за мобилни развој: 1) Acceptance Criteria су описани (критеријуми прихватања у формату Given-When-Then). 2) Дизајн макет је спреман у Figma-и (за UI задатке) са свим стањима: default, loading, error, empty state. 3) API спецификација је одобрена (OpenAPI/Swagger, примери захтева и одговора). 4) Процена у стори поенима постоји. 5) Зависности од других задатака су идентификоване. 6) Задатак не зависи од неготових спољних компоненти. 7) Мобилна специфика: одређене су циљне верзије ОС, потреба за feature flag-ом, подршка за старе API нивое.

Технике процене задатака

Planning Poker — најпопуларнија техника процене на грумингу. Сваки програмер добија шпил карата са Фибоначијевим бројевима (1, 2, 3, 5, 8, 13, 21). PO показује задатак и објашњава га. Након дискусије сви истовремено показују карту. Ако се процене значајно разликују (нпр. 3 и 13) — програмери објашњавају своју процену, након чега поново гласају. Итерације се понављају до консензуса. Смисао Planning Poker-а није у тачној процени, већ у откривању разлика у разумевању задатка.

T-Shirt Sizing — поједностављена техника за брзу процену: XS (1 SP), S (2), M (3), L (5), XL (8), XXL (13). Погодна за почетно сортирање бацклога када има много задатака и треба брзо проценити ред величине. Након T-Shirt Sizing-а спроводи се прецизнија процена кроз Planning Poker за задатке следећег спринта. Affinity Estimation — групно сортирање задатака по релативној сложености без бројева; задаци се распоређују на столу од најједноставнијих до најсложенијих, затим групишу у кластере, сваки кластер добија процену.

У мобилном развоју процена мора да узме у обзир платформску сложеност. Android задатак може бити процењен на 5 SP, а исти задатак за iOS — на 3 SP (или обрнуто). То је нормално: различите платформе имају различиту сложеност имплементације. Сaвет: процењујте сваку платформу одвојено ако је тим cross-платформски. Користите релативну скалу: основни задатак (нпр. екран са текстом и дугметом) = 1 SP. Све остало — у односу на њега. Према Scrum.org (2025), након 3-4 спринта тачност процене тима достиже ±20% стварне сложености.

Декомпозиција: како дробити велике задатке

Задаци већи од 8 SP морају бити декомпоновани на мање. Велики задаци се не могу извршити у једном спринту, тешко их је процењивати и не дају осећај напретка. Техника декомпозиције: поделите задатак по хоризонталним слојевима (UI → ViewModel → Repository → Network/DB) или по вертикалним пресецима (feature: један екран у целини). Хоризонтална декомпозиција је погоднија за мобилни развој: Sub-task 1 — израда UI (XML/Jetpack Compose/SwiftUI), Sub-task 2 — ViewModel + State, Sub-task 3 — Repository + Network, Sub-task 4 — Unit тестови.

Вертикална декомпозиција — сечење user story на мање приче са независном вредношћу. Пример: Epic „Корпа за куповину" → Story 1 „Додавање производа у корпу", Story 2 „Приказ корпе", Story 3 „Уклањање производа из корпе", Story 4 „Формирање поруџбине". Свака Story има своју пословну вредност и може бити објављена независно. SPoK (Story Points on Kano): рангирајте Stories по пословној вредности (Must-have, Should-have, Could-have) и реализујте по редоследу вредности.

Контролна листа декомпозиције на грумингу: 1) Задатак већи од 8 SP? → Декомпоновати. 2) Постоје Acceptance Criteria? → Ако не — додати. 3) Зависи од других задатака? → Идентификовати и записати зависности. 4) Садржи неизвесност? → Додати Spike (истраживање) пре главног задатка. 5) Потребан дизајн? → Проверити спремност макета. Правило INVEST: Independent (независан од других), Negotiable (може се дискутовати), Valuable (вредан за посао), Estimable (може се проценити), Small (мали), Testable (тестирабилан). Ако задатак не испуњава INVEST — није спреман за спринт.

Процес груминга: корак по корак

Корак 1: Загревање (5 минута). Scrum Master подсећа на циљ груминга и DoR. Тим гледа на таблу, PO показује који задаци ће бити дискутовани. Корак 2: Преглед задатака (30 минута). PO редом представља задатке са краја текућег и почетка следећег спринта. За сваки задатак: назив, опис, Acceptance Criteria (ако постоје), линк ка дизајну, API спецификација. Тим поставља питања за појашњење: „Да ли постоји макет за празно стање?", „Који HTTP метод?", „Који iOS minimum deployment target?".

Корак 3: Процена (15 минута). Тим процењује задатак кроз Planning Poker или T-Shirt Sizing. Ако је разлика > 2 SP — дискутују узроке и поново гласају. Правило: ако задатак не може бити процењен (нејасни захтеви, нема дизајна) — шаље се на дораду PO-у и долази на следећи груминг са појашњењима. Не процењујте задатке са непознаницама — то гарантовано води грешкама у спринту. Корак 4: Запис резултата (10 минута). PO бележи процене у Jira/Linear, ажурира опис задатка и поставља приоритете.

Резултати груминга: 3-7 потпуно спремних за Sprint Planning задатака (са DoR, проценом, дизајном, API). PO ажурира бацклог: уклања zastareле задатке, спаја дупликате, прецизира приоритете. Важно: груминг не завршава рад PO-а — између груминга треба да припреми следеће задатке. Препоручени темпо: PO припрема 3-4 задатка за груминг, тим их обрађује. Ако у бацклогу има више од 50 задатака — PO треба да спроведе приоритизацију (MoSCoW или Weighted Shortest Job First) пре груминга.

Чим се груминг разликује од Sprint Planning-а

Груминг — је припрема. На њему нема обавеза — задатак се само прецизира и процењује. Sprint Planning — је обавеза. Тим бира задатке од припремљених на грумингу и преузима обавезу да их изврши у спринту. Основне разлике: груминг није везан за конкретан спринт (refinement бацклога у целини), на грумингу нема Sprint Goal-а, груминг се може одржавати у било које време спринта. Sprint Planning — стриктно на почетку спринта и увек води до Sprint Goal-а.

На грумингу задаци се само процењују, али се не узимају у спринт. На Planning-у задаци се бирају из припремљеног пула. Без груминга Sprint Planning траје 6-8 сати (уместо 4), јер тим први пут види задатке и не може их брзо проценити. Правило 80/20: 80% задатака на Sprint Planning-у треба да буде потпуно спремно (прошли груминг), 20% — могу бити нови (хитни багови, hotfix). Ако је на Planning-у више од 20% неопроцењених задатака — груминг је био недовољан.

Типичне грешке груминга

Грешка 1: груминг једном месечно. Тим накупља 3-4 спринта задатака, покушава да све прецизира за 2 сата. Резултат: половина задатака остаје непроцењена, Planning траје цео дан. Решење: груминг мора бити редовни — 1 пут у спринту, 60 минута. Ако има много задатака — додајте други груминг средином спринта. Боље грумирати мање задатака, али квалитетно, него много — али површно. Темпо: 3-5 задатака по једном грумингу, сваки добија потпуну дискусију и процену.

Грешка 2: процена без контекста. PO показује задатак „Реализовати екран корпе" без дизајна, без API, без AC. Тим процењује „на око" — 13 SP. На Planning-у се испоставља да је заправо 5 SP (јер је екран једноставан). Решење: задатак се не процењује ако нема дизајна или API-ја. PO је дужан да припреми материјале пре груминга. Правило: „Нема макета — нема процене". Изузетак: Spike задаци — истраживање неизвесности, процењују се одвојено без дизајна (2-5 SP у зависности од сложености истраживања).

Грешка 3: груминг се претвара у Planning. Тим почиње да распоређује задатке извршиоцима и дискутује ко ће шта радити. Решење: подсетити да је груминг за прецизирање, а не за расподелу. Расподела — на Daily-у након почетка спринта. Груминг одговара на питање „шта радити?", Planning — „када радити?", Daily — „ко ради?". Мешање ових питања на једном састанку смањује ефикасност сваког од њих. Scrum Master треба да заустави Planning дискусију и усмери фокус на прецизирање задатка.

Грешка 4: игнорисање Tech Debt-а. На грумингу се дискутују само нове функције, технички задаци се игноришу. Након 3-4 спринта технички дуг се накупља до критичног нивоа. Решење: на сваком грумингу најмање 1 Tech задатак мора да прође процену. Пропорција: на 3 функције → 1 технички задатак. Користите метрику Tech Debt Ratio: однос Tech задатака према Feature задацима у спринту. Циљна вредност: 0.25-0.3 (25-30% времена на технички дуг). Ако је ratio испод 0.2 — брзина развоја ће опадати у следећим спринтовима.