Mobil inkişafda tapşırıqların qruminqi: mahiyyəti, məqsədləri və aparılma prosesi

Tapşırıqların qruminqi nədir?

Backlog Grooming (refinement) — Product Backlog tapşırıqlarının gələcək sprintlərə hazırlanması prosesi. Product Owner və tərtibat komandasının tapşırıqları nəzərdən keçirdiyi görüş: tələbləri dəqiqləşdirir, Acceptance Criteria əlavə edir, mürəkkəbliyi qiymətləndirir, asılılıqları və riskləri müəyyən edir. Scrum Guide-da məcburi „qruminq" hadisəsi yoxdur — bu, Scrum komandalarının Sprint Planning-də qeyri-müəyyənliyi azaltmaq üçün tətbiq etdiyi əlavə təcrübədir. Tövsiyə olunan tezlik — sprintdə 1 dəfə, 60 dəqiqədən çox olmamaqla.

„Daranma" (grooming) termini mahiyyəti əks etdirir: komanda backlogu „darayır", köhnəlmiş tapşırıqları təmizləyir, qeyri-müəyyən olanları dəqiqləşdirir və çox böyük olanları bölür. Mobil inkişafda qruminq xüsusilə vacibdir, çünki platforma spesifikası var: Android üçün tapşırıq iOS versiyasından mürəkkəbliyə görə fərqlənə bilər, targetSdk, compileSdk, API səviyyələri ilə uyğunluq nəzərə alınmalıdır. Qruminq olmadan Sprint Planning xaosa çevrilir: komanda tapşırıqları ilk dəfə görür və onları qiymətləndirə bilmir, bu da gözlənilməzliyə və müddətlərin pozulmasına gətirib çıxarır.

Qruminqin nəticəsi — Sprint Planning-ə hazır olan bir neçə tapşırıq: onların təsviri, Acceptance Criteria, qiymətləndirməsi var və Definition of Ready-ə uyğundur. Product Owner tapşırıqları prioritet sırası ilə qruminq etməlidir: cari sprinta ən yaxın olanlar — ən təfərrüatlı. 3-4 sprint qabaqdakı tapşırıqlar — yalnız epik səviyyəsində. Progressive Refinement texnikası: tapşırıq sprinta nə qədər yaxındırsa, təsviri bir o qədər təfərrüatlıdır. Cari sprintdəki tapşırıqlar üçün — full refinement (AC, dizayn, API spesifikasiyası). 2 sprint sonrakı tapşırıqlar üçün — story-level (tətbiq detalları olmadan user story). 3+ sprint sonrakı tapşırıqlar üçün — epic-level (yalnız ad və biznes dəyəri).

Definition of Ready: tapşırıq nə vaxt sprinta hazırdır

Definition of Ready (DoR) — tapşırığın Sprint Backlog-a daxil edilməzdən əvvəl cavab verməli olduğu meyarların yoxlama siyahısı. DoR — Product Owner və komanda arasında müqavilədir: PO zəmanət verir ki, inkişaf üçün bütün məlumatlar var, komanda zəmanət verir ki, tapşırığı qiymətləndirə və yerinə yetirə bilər. DoR universal deyil — hər komanda öz meyar dəstini müəyyən edir. DoR olmadan tapşırıq qeyri-müəyyən tələblərlə sprinta düşə bilər, bu da yenidən işləmələrə və müddətlərin pozulmasına səbəb olar.

Mobil inkişaf üçün tipik DoR: 1) Acceptance Criteria təsvir edilib (Given-When-Then formatında qəbul meyarları). 2) Figma-da dizayn maketi hazırdır (UI tapşırıqları üçün) bütün hallarla: default, loading, error, empty state. 3) API spesifikasiyası təsdiqlənib (OpenAPI/Swagger, sorğu və cavab nümunələri). 4) Story point-lərdə qiymətləndirmə var. 5) Digər tapşırıqlardan asılılıqlar müəyyən edilib. 6) Tapşırıq hazır olmayan xarici komponentlərdən asılı deyil. 7) Mobil spesifika: hədəf OS versiyaları, feature flag zərurəti, köhnə API səviyyələrinə dəstək müəyyən edilib.

Tapşırıqların qiymətləndirilməsi texnikaları

Planning Poker — qruminqdə ən populyar qiymətləndirmə texnikası. Hər tərtibatçı Fibonaççi rəqəmləri (1, 2, 3, 5, 8, 13, 21) olan kartlar dəstini alır. PO tapşırığı göstərir və izah edir. Müzakirədən sonra hamı eyni anda kartı göstərir. Qiymətlər çox fərqlidirsə (məsələn, 3 və 13) — tərtibatçılar öz qiymətlərini izah edir, sonra yenidən səs verirlər. İterasiyalar konsensusa qədər təkrarlanır. Planning Poker-in məqsədi dəqiq qiymətləndirmə deyil, tapşırığın anlaşılmasındakı fərqləri aşkar etməkdir.

T-Shirt Sizing — sürətli qiymətləndirmə üçün sadələşdirilmiş texnika: XS (1 SP), S (2), M (3), L (5), XL (8), XXL (13). Backlogun ilkin çeşidlənməsi üçün uyğundur, tapşırıqlar çox olduqda və böyüklük sırasını tez qiymətləndirmək lazım gəldikdə. T-Shirt Sizing-dən sonra növbəti sprintin tapşırıqları üçün Planning Poker vasitəsilə daha dəqiq qiymətləndirmə aparılır. Affinity Estimation — rəqəmsiz tapşırıqların nisbi mürəkkəbliyə görə qrup şəklində çeşidlənməsi; tapşırıqlar stolda ən sadədən ən mürəkkəbə düzülür, sonra klasterlərə qruplaşdırılır, hər klaster qiymətləndirmə alır.

Mobil inkişafda qiymətləndirmə platforma mürəkkəbliyini nəzərə almalıdır. Android tapşırığı 5 SP, eyni tapşırıq iOS üçün 3 SP (və ya əksinə) qiymətləndirilə bilər. Bu normaldır: müxtəlif platformalar müxtəlif tətbiq mürəkkəbliyinə malikdir. Məsləhət: komanda cross-platformadırsa, hər platformanı ayrı qiymətləndirin. Nisbi şkaladan istifadə edin: əsas tapşırıq (məsələn, mətn və düymə olan ekran) = 1 SP. Qalan hər şey — ona nisbətən. Scrum.org (2025) məlumatlarına görə, 3-4 sprintdən sonra komandanın qiymətləndirmə dəqiqliyi faktiki mürəkkəbliyin ±20%-nə çatır.

Dekompozisiya: böyük tapşırıqları necə bölmək

8 SP-dən böyük tapşırıqlar daha kiçiklərə dekompozisiya edilməlidir. Böyük tapşırıqları bir sprintdə yerinə yetirmək mümkün deyil, onları qiymətləndirmək çətindir və irəliləyiş hissi vermir. Dekompozisiya texnikası: tapşırığı üfüqi təbəqələrə (UI → ViewModel → Repository → Network/DB) və ya şaquli kəsiklərə (feature: bir ekran tam olaraq) bölün. Üfüqi dekompozisiya mobil inkişaf üçün daha uyğundur: Sub-task 1 — UI düzümü (XML/Jetpack Compose/SwiftUI), Sub-task 2 — ViewModel + State, Sub-task 3 — Repository + Network, Sub-task 4 — Vahid testləri.

Şaquli dekompozisiya — user story-ni müstəqil dəyərə malik daha kiçik hekayələrə bölmək. Nümunə: Epic „Alış-veriş səbəti" → Story 1 „Məhsulun səbətə əlavə edilməsi", Story 2 „Səbətin göstərilməsi", Story 3 „Məhsulun səbətdən silinməsi", Story 4 „Sifarişin rəsmiləşdirilməsi". Hər Story öz biznes dəyərinə malikdir və müstəqil buraxıla bilər. SPoK (Story Points on Kano): Stories-ləri biznes dəyərinə görə sıralayın (Must-have, Should-have, Could-have) və dəyər sırası ilə reallaşdırın.

Qruminqdə dekompozisiya yoxlama siyahısı: 1) Tapşırıq 8 SP-dən böyükdür? → Dekompozisiya edin. 2) Acceptance Criteria var? → Yoxdursa — əlavə edin. 3) Digər tapşırıqlardan asılıdır? → Asılılıqları müəyyən edin və qeyd edin. 4) Qeyri-müəyyənlik ehtiva edir? → Əsas tapşırıqdan əvvəl Spike (tədqiqat) əlavə edin. 5) Dizayn lazımdır? → Maketlərin hazırlığını yoxlayın. INVEST qaydası: Independent (digərlərindən asılı olmayan), Negotiable (müzakirə edilə bilən), Valuable (biznes üçün dəyərli), Estimable (qiymətləndirilə bilən), Small (kiçik), Testable (test edilə bilən). Tapşırıq INVEST-ə cavab vermirsə — sprinta hazır deyil.

Qruminq prosesi: addım-addım

Addım 1: İsitmə (5 dəqiqə). Scrum Master qruminqin məqsədini və DoR-u xatırladır. Komanda lövhəyə baxır, PO hansı tapşırıqların müzakirə olunacağını göstərir. Addım 2: Tapşırıqların nəzərdən keçirilməsi (30 dəqiqə). PO ardıcıl olaraq cari sprintin sonundan və növbəti sprintin əvvəlindən tapşırıqları təqdim edir. Hər tapşırıq üçün: ad, təsvir, Acceptance Criteria (varsa), dizayn linki, API spesifikasiyası. Komanda dəqiqləşdirici suallar verir: „Boş vəziyyət üçün maket varmı?", „Hansı HTTP metodu?", „iOS minimum deployment target nədir?".

Addım 3: Qiymətləndirmə (15 dəqiqə). Komanda tapşırığı Planning Poker və ya T-Shirt Sizing vasitəsilə qiymətləndirir. Fərq > 2 SP olarsa — səbəbləri müzakirə edir və yenidən səs verirlər. Qayda: tapşırıq qiymətləndirilə bilmirsə (tələblər aydın deyil, dizayn yoxdur) — PO tərəfindən işlənməyə göndərilir və dəqiqləşdirmələrlə növbəti qruminqə gəlir. Naməlum olan tapşırıqları qiymətləndirməyin — bu, sprintdə mütləq səhvə səbəb olacaq. Addım 4: Nəticələrin qeydiyyatı (10 dəqiqə). PO qiymətləri Jira/Linear-da qeyd edir, tapşırığın təsvirini yeniləyir və prioritetlər təyin edir.

Qruminqin nəticələri: Sprint Planning-ə tam hazır 3-7 tapşırıq (DoR, qiymətləndirmə, dizayn, API ilə). PO backlogu yeniləyir: köhnəlmiş tapşırıqları silir, təkrarlananları birləşdirir, prioritetləri dəqiqləşdirir. Vacib: qruminq PO-nun işini bitirmir — qruminqlər arasında növbəti tapşırıqları hazırlamalıdır. Tövsiyə olunan temp: PO qruminq üçün 3-4 tapşırıq hazırlayır, komanda onları işləyir. Backlogda 50-dən çox tapşırıq varsa — PO qruminqdən əvvəl prioritetləşdirmə aparmalıdır (MoSCoW və ya Weighted Shortest Job First).

Qruminq Sprint Planning-dən nə ilə fərqlənir

Qruminq — hazırlıqdır. Burada öhdəlik yoxdur — tapşırıq sadəcə dəqiqləşdirilir və qiymətləndirilir. Sprint Planning — öhdəlikdir. Komanda qruminqdə hazırlanmış tapşırıqlardan seçir və onları sprintdə yerinə yetirmək öhdəliyi götürür. Əsas fərqlər: qruminq konkret sprinta bağlı deyil (ümumi backlog refinement), qruminqdə Sprint Goal yoxdur, qruminq sprintin istənilən vaxtı keçirilə bilər. Sprint Planning — ciddi şəkildə sprintin əvvəlində və həmişə Sprint Goal-a gətirib çıxarır.

Qruminqdə tapşırıqlar yalnız qiymətləndirilir, lakin sprinta götürülmür. Planning-də tapşırıqlar hazırlanmış hovuzdan seçilir. Qruminq olmadan Sprint Planning 6-8 saat çəkir (4 əvəzinə), çünki komanda tapşırıqları ilk dəfə görür və onları tez qiymətləndirə bilmir. 80/20 qaydası: Sprint Planning-də tapşırıqların 80%-i tam hazır olmalıdır (qruminqdən keçmiş), 20%-i yeni ola bilər (təcili buglar, hotfix). Planning-də qiymətləndirilməmiş tapşırıqlar 20%-dən çox olarsa — qruminq kifayət deyildi.

Qruminqin tipik səhvləri

Səhv 1: ayda bir dəfə qruminq. Komanda 3-4 sprintlik tapşırıq yığır, hamısını 2 saata dəqiqləşdirməyə çalışır. Nəticə: tapşırıqların yarısı qiymətləndirilməmiş qalır, Planning bütün günü çəkir. Həlli: qruminq müntəzəm olmalıdır — sprintdə 1 dəfə, 60 dəqiqə. Tapşırıqlar çoxdursa — sprintin ortasında ikinci qruminq əlavə edin. Az tapşırığı keyfiyyətlə qruminq etmək, çoxu — səthi etməkdən yaxşıdır. Temp: bir qruminqdə 3-5 tapşırıq, hər biri tam müzakirə və qiymətləndirmə alır.

Səhv 2: kontekstsiz qiymətləndirmə. PO tapşırığı „Səbət ekranını reallaşdır" dizaynsız, APİ-siz, AC-siz göstərir. Komanda „gözlə" qiymətləndirir — 13 SP. Planning-də məlum olur ki, əslində 5 SP-dir (çünki ekran sadədir). Həlli: dizayn və ya API yoxdursa, tapşırıq qiymətləndirilmir. PO qruminqdən əvvəl materialları hazırlamalıdır. Qayda: „Maket yoxdur — qiymətləndirmə yoxdur". İstisna: Spike-tapşırıqlar — qeyri-müəyyənliyin tədqiqi, onlar dizaynsız ayrıca qiymətləndirilir (tədqiqatın mürəkkəbliyindən asılı olaraq 2-5 SP).

Səhv 3: qruminq Planning-ə çevrilir. Komanda tapşırıqları ifaçılara bölməyə və kimin nə edəcəyini müzakirə etməyə başlayır. Həlli: xatırladın ki, qruminq dəqiqləşdirmə üçündür, bölgü üçün deyil. Bölgü — sprint başladıqdan sonra Daily-də. Qruminq „nə etməli?" sualına, Planning „nə vaxt etməli?" sualına, Daily „kim edir?" sualına cavab verir. Bu sualları bir görüşdə qarışdırmaq hər birinin effektivliyini azaldır. Scrum Master Planning müzakirəsini dayandırıb diqqəti tapşırığın dəqiqləşdirilməsinə yönəltməlidir.

Səhv 4: Tech Debt-in göz ardı edilməsi. Qruminqdə yalnız yeni funksiyalar müzakirə olunur, texniki tapşırıqlar göz ardı edilir. 3-4 sprintdən sonra texniki borc kritik səviyyəyə çatır. Həlli: hər qruminqdə ən azı 1 Tech tapşırığı qiymətləndirilməlidir. Nisbət: 3 funksiyaya → 1 texniki tapşırıq. Tech Debt Ratio metrikiyasından istifadə edin: sprintdə Tech tapşırıqlarının Feature tapşırıqlarına nisbəti. Hədəf dəyər: 0.25-0.3 (vaxtın 25-30%-i texniki borca). Ratio 0.2-dən aşağı olarsa — inkişaf sürəti növbəti sprintlərdə düşəcək.