Груминг на задачи в мобилната разработка: същност, цели и процес на провеждане

Какво е груминг на задачи?

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

Терминът „разресване" (груминг) отразява същността: екипът „разресва" backlog-а, премахвайки остарели задачи, уточнявайки неясни и разделяйки твърде големи. В мобилната разработка грумингът е особено важен поради платформената специфика: задача за Android може да се различава от iOS версията по сложност, трябва да се вземат предвид targetSdk, compileSdk, съвместимост с API нива. Без груминг Sprint Planning се превръща в хаос: екипът вижда задачите за първи път и не може да ги оцени, което води до непредсказуемост и забавяния.

Резултат от груминга — няколко задачи, готови за Sprint Planning: те имат описание, Acceptance Criteria, оценка и отговарят на Definition of Ready. Product Owner трябва да грумира задачите в ред на приоритет: най-близките до текущия спринт — най-детайлизирани. Задачите за 3-4 спринта напред — само на ниво epics. Техника Progressive Refinement: колкото по-близо е задачата до спринта, толкова по-детайлно е нейното описание. За задачи в текущия спринт — 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) Оценка в story points съществува. 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). Подходяща за начално сортиране на backlog-а, когато задачите са много и трябва бързо да се оцени порядъкът на големина. След T-Shirt Sizing се извършва по-точна оценка чрез Planning Poker за задачите от следващия спринт. Affinity Estimation — групово сортиране на задачи по относителна сложност без числа; задачите се подреждат на масата от най-простите към най-сложните, след това се групират в клъстери, всеки клъстер получава оценка.

В мобилната разработка оценката трябва да отчита платформената сложност. Android задача може да бъде оценена на 5 SP, а същата задача за iOS — на 3 SP (или обратно). Това е нормално: различните платформи имат различна сложност на имплементация. Съвет: оценявайте всяка платформа отделно, ако екипът е cross-platform. Използвайте относителна скала: базова задача (напр. екран с текст и бутон) = 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 актуализира backlog-а: премахва остарели задачи, обединява дублиращи се, уточнява приоритети. Важно: грумингът не приключва работата на PO — между грумингите той трябва да подготви следващите задачи. Препоръчителен темп: PO подготвя 3-4 задачи за груминга, екипът ги обработва. Ако в backlog-а има повече от 50 задачи — PO трябва да извърши приоритизация (MoSCoW или Weighted Shortest Job First) преди груминга.

Как грумингът се различава от Sprint Planning

Груминг — е подготовка. На него няма задължения — задачата просто се уточнява и оценява. Sprint Planning — е задължение. Екипът избира задачи от подготвените на груминга и поема задължението да ги изпълни в спринта. Основни разлики: грумингът не е обвързан с конкретен спринт (refinement на backlog-а като цяло), на груминга няма 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 — скоростта на разработка ще намалее в следващите спринтове.