Groomingul sarcinilor în dezvoltarea mobilă: esența, scopurile și procesul de realizare

Ce este groomingul sarcinilor?

Backlog Grooming (refinement) — procesul de pregătire a sarcinilor Product Backlog-ului pentru sprinturile viitoare. O întâlnire în care Product Owner și echipa de dezvoltare parcurg sarcinile: clarifică cerințele, adaugă Acceptance Criteria, evaluează complexitatea, identifică dependențe și riscuri. În Scrum Guide nu există un eveniment obligatoriu «grooming» — este o practică suplimentară pe care echipele Scrum o introduc pentru a reduce incertitudinea la Sprint Planning. Frecvența recomandată — 1 dată pe sprint, cu durata de cel mult 60 de minute.

Termenul «pieptănare» (grooming) reflectă esența: echipa «pieptănă» backlogul, eliminând sarcinile învechite, clarificându-le pe cele neclare și divizându-le pe cele prea mari. În dezvoltarea mobilă, groomingul este deosebit de important datorită specificului platformei: o sarcină pentru Android se poate diferenția ca complexitate de versiunea iOS, trebuie luate în considerare targetSdk, compileSdk, compatibilitatea cu nivelurile API. Fără grooming, Sprint Planning se transformă în haos: echipa vede sarcinile pentru prima dată și nu le poate evalua, ceea ce duce la imprevizibilitate și întârzieri.

Rezultatul groomingului — câteva sarcini gata pentru Sprint Planning: au descriere, Acceptance Criteria, evaluare și corespund Definition of Ready. Product Owner trebuie să groomeze sarcinile în ordinea priorității: cele mai apropiate de sprintul curent — cele mai detaliate. Sarcinile pentru 3-4 sprinturi înainte — doar la nivel de epicuri. Tehnica Progressive Refinement: cu cât sarcina este mai aproape de sprint, cu atât descrierea ei este mai detaliată. Pentru sarcinile din sprintul curent — full refinement (AC, design, specificație API). Pentru sarcinile peste 2 sprinturi — story-level (user story fără detalii de implementare). Pentru sarcinile peste 3+ sprinturi — epic-level (doar numele și valoarea de business).

Definition of Ready: când sarcina este gata pentru sprint

Definition of Ready (DoR) — lista de verificare a criteriilor pe care sarcina trebuie să le îndeplinească înainte de includerea în Sprint Backlog. DoR este un contract între Product Owner și echipă: PO garantează că toate informațiile pentru dezvoltare există, echipa garantează că poate evalua și executa sarcina. DoR nu este universal — fiecare echipă își definește propriul set de criterii. Fără DoR, sarcina poate ajunge în sprint cu cerințe neclare, ceea ce duce la reluări și întârzieri.

DoR tipic pentru dezvoltarea mobilă: 1) Acceptance Criteria sunt descrise (criterii de acceptare în formatul Given-When-Then). 2) Designul este gata în Figma (pentru sarcinile UI) cu toate stările: default, loading, error, empty state. 3) Specificația API este aprobată (OpenAPI/Swagger, exemple de cereri și răspunsuri). 4) Evaluarea în story point-uri există. 5) Dependențele de alte sarcini sunt identificate. 6) Sarcina nu depinde de componente externe negata. 7) Specificul mobil: sunt definite versiunile țintă de OS, necesitatea feature flag, suportul pentru niveluri API vechi.

Tehnici de evaluare a sarcinilor

Planning Poker — cea mai populară tehnică de evaluare la grooming. Fiecare dezvoltator primește un set de cărți cu numere Fibonacci (1, 2, 3, 5, 8, 13, 21). PO arată sarcina și o explică. După discuție, toți arată cardul simultan. Dacă evaluările diferă semnificativ (de exemplu, 3 și 13) — dezvoltatorii își explică evaluarea, apoi votează din nou. Iterațiile se repetă până la consens. Scopul Planning Poker nu este evaluarea exactă, ci identificarea diferențelor de înțelegere a sarcinii.

T-Shirt Sizing — o tehnică simplificată pentru evaluare rapidă: XS (1 SP), S (2), M (3), L (5), XL (8), XXL (13). Este potrivită pentru sortarea inițială a backlogului când sunt multe sarcini și trebuie estimat rapid ordinul de mărime. După T-Shirt Sizing se efectuează o evaluare mai precisă prin Planning Poker pentru sarcinile sprintului următor. Affinity Estimation — sortarea de grup a sarcinilor după complexitatea relativă fără numere; sarcinile se așează pe masă de la cele mai simple la cele mai complexe, apoi se grupează în clustere, fiecare cluster primind o evaluare.

În dezvoltarea mobilă, evaluarea trebuie să țină cont de complexitatea platformei. O sarcină Android poate fi evaluată la 5 SP, iar aceeași sarcină pentru iOS — la 3 SP (sau invers). Este normal: platforme diferite au complexități de implementare diferite. Sfat: evaluați fiecare platformă separat dacă echipa este cross-platformă. Utilizați o scară relativă: sarcina de bază (de exemplu, un ecran cu text și buton) = 1 SP. Tot restul — relativ la ea. Conform Scrum.org (2025), după 3-4 sprinturi, acuratețea evaluării echipei atinge ±20% din complexitatea reală.

Decompoziția: cum să divizăm sarcinile mari

Sarcinile mai mari de 8 SP trebuie decompozate în altele mai mici. Sarcinile mari nu pot fi realizate într-un singur sprint, sunt greu de evaluat și nu oferă senzația de progres. Tehnica de decompoziție: împărțiți sarcina pe straturi orizontale (UI → ViewModel → Repository → Network/DB) sau pe felii verticale (feature: un ecran în întregime). Decompoziția orizontală este mai potrivită pentru dezvoltarea mobilă: Sub-task 1 — realizarea UI (XML/Jetpack Compose/SwiftUI), Sub-task 2 — ViewModel + State, Sub-task 3 — Repository + Network, Sub-task 4 — Teste unitare.

Decompoziția verticală — tăierea user story în povești mai mici cu valoare independentă. Exemplu: Epic «Coșul de cumpărături» → Story 1 «Adăugarea produsului în coș», Story 2 «Afișarea coșului», Story 3 «Ștergerea produsului din coș», Story 4 «Finalizarea comenzii». Fiecare Story are propria valoare de business și poate fi lansată independent. SPoK (Story Points on Kano): ordonați Stories după valoarea de business (Must-have, Should-have, Could-have) și implementați în ordinea valorii.

Lista de verificare a decompoziției la grooming: 1) Sarcina este mai mare de 8 SP? → Decompozați. 2) Există Acceptance Criteria? → Dacă nu — adăugați. 3) Depinde de alte sarcini? → Identificați și înregistrați dependențele. 4) Conține incertitudine? → Adăugați Spike (cercetare) înaintea sarcinii principale. 5) Este necesar design? → Verificați pregătirea machetelor. Regula INVEST: Independent (independentă de altele), Negotiable (se poate discuta), Valuable (valoroasă pentru business), Estimable (se poate evalua), Small (mică), Testable (testabilă). Dacă sarcina nu îndeplinește INVEST — nu este gata pentru sprint.

Procesul de grooming: pas cu pas

Pasul 1: Încălzirea (5 minute). Scrum Master reamintește scopul groomingului și DoR. Echipa se uită la tablă, PO arată care sarcini vor fi discutate. Pasul 2: Revizuirea sarcinilor (30 de minute). PO prezintă succesiv sarcinile de la sfârșitul sprintului curent și începutul următorului. Pentru fiecare sarcină: nume, descriere, Acceptance Criteria (dacă există), link către design, specificația API. Echipa pune întrebări de clarificare: «Există machetă pentru starea goală?», «Ce metodă HTTP?», «Care este iOS minimum deployment target?».

Pasul 3: Evaluarea (15 minute). Echipa evaluează sarcina prin Planning Poker sau T-Shirt Sizing. Dacă diferența > 2 SP — discută cauzele și votează din nou. Regula: dacă sarcina nu poate fi evaluată (cerințe neclare, lipsă design) — este trimisă înapoi la PO pentru revizuire și va veni la următorul grooming cu clarificări. Nu evaluați sarcini cu necunoscute — acest lucru duce garantat la erori în sprint. Pasul 4: Înregistrarea rezultatelor (10 minute). PO înregistrează evaluările în Jira/Linear, actualizează descrierea sarcinii și stabilește prioritățile.

Rezultatele groomingului: 3-7 sarcini complet gata pentru Sprint Planning (cu DoR, evaluare, design, API). PO actualizează backlogul: elimină sarcinile învechite, îmbină duplicatele, clarifică prioritățile. Important: groomingul nu încheie munca PO — între groominguri trebuie să pregătească următoarele sarcini. Ritmul recomandat: PO pregătește 3-4 sarcini pentru grooming, echipa le procesează. Dacă în backlog sunt mai mult de 50 de sarcini — PO trebuie să efectueze prioritizarea (MoSCoW sau Weighted Shortest Job First) înainte de grooming.

Cum diferă groomingul de Sprint Planning

Groomingul — este pregătirea. Nu există obligații — sarcina este pur și simplu clarificată și evaluată. Sprint Planning — este un angajament. Echipa selectează sarcinile dintre cele pregătite la grooming și își asumă angajamentul de a le finaliza în sprint. Diferențele principale: groomingul nu este legat de un sprint specific (refinement general al backlogului), la grooming nu există Sprint Goal, groomingul poate avea loc în orice moment al sprintului. Sprint Planning — strict la începutul sprintului și duce întotdeauna la Sprint Goal.

La grooming, sarcinile doar se evaluează, dar nu se iau în sprint. La Planning, sarcinile sunt selectate din pool-ul pregătit. Fără grooming, Sprint Planning durează 6-8 ore (în loc de 4), deoarece echipa vede sarcinile pentru prima dată și nu le poate evalua rapid. Regula 80/20: 80% din sarcinile la Sprint Planning trebuie să fie complet pregătite (au trecut grooming), 20% — pot fi noi (buguri urgente, hotfixuri). Dacă la Planning sunt mai mult de 20% sarcini neevaluate — groomingul a fost insuficient.

Greșeli tipice ale groomingului

Greșeala 1: grooming o dată pe lună. Echipa acumulează 3-4 sprinturi de sarcini, încearcă să clarifice totul în 2 ore. Rezultat: jumătate din sarcini rămân neevaluate, Planning durează toată ziua. Soluția: groomingul trebuie să fie regulat — 1 dată pe sprint, 60 de minute. Dacă sunt multe sarcini — adăugați un al doilea grooming la mijlocul sprintului. Mai bine să groomezi mai puține sarcini, dar calitativ, decât multe — dar superficial. Ritmul: 3-5 sarcini la un grooming, fiecare primește o discuție completă și evaluare.

Greșeala 2: evaluare fără context. PO arată sarcina «Realizarea ecranului coșului» fără design, fără API, fără AC. Echipa evaluează «cu ochiul» — 13 SP. La Planning se dovedește că de fapt este 5 SP (pentru că ecranul este simplu). Soluția: sarcina nu se evaluează dacă nu există design sau API. PO are obligația să pregătească materialele înainte de grooming. Regula: «Nu există machetă — nu există evaluare». Excepția: sarcinile Spike — cercetarea incertitudinii, se evaluează separat fără design (2-5 SP în funcție de complexitatea cercetării).

Greșeala 3: groomingul se transformă în Planning. Echipa începe să distribuie sarcinile pe executanți și să discute cine va face ce. Soluția: reamintiți că groomingul este pentru clarificare, nu pentru distribuire. Distribuirea — la Daily după începerea sprintului. Groomingul răspunde la întrebarea «ce facem?», Planning — «când facem?», Daily — «cine face?». Amestecarea acestor întrebări într-o singură întâlnire reduce eficiența fiecăreia. Scrum Master trebuie să oprească discuția de Planning și să redirecționeze atenția asupra clarificării sarcinii.

Greșeala 4: ignorarea Tech Debt-ului. La grooming se discută doar funcționalități noi, sarcinile tehnice sunt ignorate. După 3-4 sprinturi, datoria tehnică se acumulează la un nivel critic. Soluția: la fiecare grooming, cel puțin 1 sarcină Tech trebuie să treacă prin evaluare. Proporția: la 3 feature-uri → 1 sarcină tehnică. Utilizați metrica Tech Debt Ratio: raportul sarcinilor Tech la sarcinile Feature în sprint. Valoarea țintă: 0.25-0.3 (25-30% din timp pentru datoria tehnică). Dacă ratio este sub 0.2 — viteza de dezvoltare va scădea în sprinturile următoare.