Tapşırıq və ticket — bu nədir, izləmə sistemləri və tapşırıqlarla iş

Tapşırıq və ticket nədir?

Tapşırıq (ing. task) — izləmə sistemində qeydə alınmış iş vahididir. Təsviri, prioriteti (Critical, High, Medium, Low), icraçısı, son tarixi və statusu var. Mobil inkişafda tapşırıq “Avatar ilə profil ekranı əlavə etmək”, “Lent paginasiyasını tətbiq etmək” və ya “targetSdk versiyasını 35-ə yeniləmək” ola bilər. Hər tapşırıq layihəyə, sprinta və konkret proqramçıya və ya komandaya bağlıdır.

Ticket (ing. ticket) — daha geniş anlayışdır. Ticket səhv hesabatı (“Android 14-də ekran döndərildikdə tətbiq çökür”), funksiya sorğusu (“Qaranlıq temaya dəstək əlavə edin”), texniki dəstək müraciəti (“Push bildirişi gəlmir”) və ya menecer tapşırığı (“Ay üçün crash rate hesabatı hazırlayın”) ola bilər. Tapşırıq və ticket arasındakı fərq bulanıqdır: Jira-da hər iki anlayış Issue-də birləşdirilib. Əsas fərq: tapşırıq həmişə icraçısı olan işdir, ticket triaj anına qədər konkret icraçısı olmayan sorğu ola bilər.

Scrum və Kanban-da tapşırıqlar backlog-un əsas elementidir. Hər tapşırıq INVEST meyarına cavab verməlidir (Independent, Negotiable, Valuable, Estimable, Small, Testable). Müstəqil tapşırıqlar istənilən ardıcıllıqla yerinə yetirilə bilər. Qiymətləndirilə bilən — komanda əmək intensivliyini təxmin edə bilər. Kiçik — bir sprinta sığar. Test edilə bilən — dəqiq qəbul meyarları var. Böyük tapşırıqlar (epiklər) bütün meyarlar yerinə yetirilənə qədər daha kiçik hissələrə bölünür.

Mobil inkişafda tapşırıq növləri

Feature — tətbiqin yeni funksionallığı. Nümunə: “Biometriya ilə giriş ekranı (Face ID / Touch ID)”. Feature tapşırıqları həmişə user story ilə bağlıdır və Qəbul Meyarları (Acceptance Criteria) var. Qiymətləndirmə — story points (1, 2, 3, 5, 8, 13). Bug — inkişaf və ya test prosesində aşkar edilmiş qüsurdur. Bug ticket-in prioriteti severity ilə müəyyən edilir (crash → Critical, UI-bug → Medium, hərf səhvi → Low). Mobil inkişafda 0.1%-dən yüksək crash rate kritik səhvdir və dərhal düzəliş tələb edir.

Tech Debt / Chore — istifadəçiyə görünməyən texniki tapşırıqlar: kitabxanaların yenilənməsi (Dependency Bump), refaktorinq (ViewPager-dən ViewPager2-yə miqrasiya), CI/CD konfiqurasiyası, testlərin yazılması. Tech Debt tapşırıqları çox vaxt qiymətləndirilmir, halbuki Stripe 2025 məlumatlarına görə, mobil komandanın vaxtının 30%-ə qədəri texniki borcun saxlanmasına və ödənilməsinə sərf olunur. Tech Debt-i göz ardı etmək səhvlərin artmasına və yeni funksiyaların işlənməsinin yavaşlamasına gətirib çıxarır.

Əlavə növlər: Spike (tədqiqat tapşırığı — yeni texnologiyanı öyrənmək, POC yazmaq), Task (koda aid olmayan hər hansı iş — sənədləşmə, dizayn baxışı), Improvement (mövcud funksionallığın təkmilləşdirilməsi — ekran yüklənmə vaxtının optimallaşdırılması). Jira-da issue növləri layihə üzrə konfiqurasiya olunur. Mobil komanda üçün standart dəst: Story, Bug, Task, Improvement, Epic. Epic — bir neçə hekayəni birləşdirən böyük mövzu. Nümunə: “E-ticarət: səbət və sifarişin rəsmiləşdirilməsi”.

Tapşırığın həyat dövrü: yaradılmadan bağlanmaya qədər

Open (To Do) — tapşırıq yaradılıb, lakin başlanmayıb. Təsviri, Qəbul Meyarları, prioriteti var. Bu statusda tapşırıq sprinta daxil olmamışdan əvvəl grooming-dən (dəqiqləşdirmə və qiymətləndirmə) keçməlidir. In Progress — proqramçı işə başlayıb. Mobil inkişafda commit və pull request-ləri tapşırığa bağlamaq vacibdir: Jira-da Smart Commits vasitəsilə (APP-123 #comment səhvin düzəldilməsi), GitHub/GitLab-da PR təsvirində açar sözlərlə (Closes APP-123).

In Review — kod baxışa göndərilib. Avtomatik yoxlamalar: CI (Gradle build, lint, vahid testləri), SonarQube (kod keyfiyyəti), Danger (changelog, testlər). Proqramçı cari tapşırıq Review-də olarkən növbəti tapşırığı götürə bilməz — bu, çoxşaxəliliyin qarşısını alır. QA / Testing — tester real cihazlarda yoxlayır (Android — müxtəlif OS versiyaları və ekran ölçüləri, iOS — müxtəlif iPhone modelləri). Səhvlər aşkar edilərsə, tapşırıq şərhlə In Progress-ə qaytarılır.

Done (Closed) — tapşırıq tamamlandı: kod main/master-a birləşdirildi, testdən keçdi, buraxılışa hazırdır. Bəzi komandalar Deployed statusu əlavə edir — tapşırıq istifadəçiyə yalnız mağazalarda yığım dərc edildikdən sonra çatır. Tapşırıqları nəticə ilə bağlı şərhlə bağlamaq vacibdir: hansı versiya, hansı PR, hansı metrikalar dəyişib. Linear (2025) məlumatlarına görə, nəticənin təsviri ilə tapşırıqları bağlayan komandalar eyni tapşırıqlara 40% daha az qayıdır.

Həyat dövrü Blocked statusunu əhatə edə bilər — tapşırıq xarici asılılıq səbəbindən yerinə yetirilə bilməz (dizaynı gözləyirik, backend cavabı, menecer təsdiqi). Blocked tapşırıqlar səbəb və növbəki yoxlama tarixi ilə şərh olmalıdır. Həftəlik Blocked tapşırıqların nəzərdən keçirilməsi inkişaf prosesində sistem gecikmələrini aşkar etməyə kömək edir. 2 həftədən uzun blokerlər məhsul meneceri səviyyəsinə eskalasiya tələb edir.

Tapşırıq izləmə sistemləri

Jira — 10 nəfərdən çox komandalar üçün sənaye standartı. Scrum və Kanban lövhələrini, qabaqcıl workflow konfiqurasiyasını, fərdi sahələri, avtomatlaşdırmaları, Bitbucket/GitHub ilə inteqrasiyanı dəstəkləyir. Çatışmazlıqlar: kiçik komandalar üçün artıqlıq, yavaş interfeys, mürəkkəb konfiqurasiya. Mobil layihələr üçün Jira aşağıdakılarla konfiqurasiya olunur: Mobile-specific fields (Platform, OS version, Device model) plagin, TestFlight və Firebase Test Lab ilə inteqrasiya, buraxılış yığımlarının avtomatlaşdırılması. Jira — bürokratik prosesləri olan korporativ layihələrin seçimi.

Linear — məhsul komandaları üçün müasir treker. Sürətli interfeys, klaviatura qısa yollarının birinci dərəcəli dəstəyi, daxili Cycle (sprint analoqu), GitHub və Slack ilə inteqrasiya. Üstünlüklər: CMD+K vasitəsilə tapşırıqların sürətli yaradılması, fazalara avtomatik bölüşdürülmə (Triaged → Backlog → Upcoming → Current → Completed), daxili sənədləşmə və roadmaps. Linear sürəti qiymətləndirən startaplar və məhsul komandaları tərəfindən seçilir. 2025-ci ildə Linear yeni mobil layihələrin 40%-i tərəfindən istifadə olunur.

Trello — kiçik komandalar (2-5 nəfər) üçün sadə kanban lövhəsi. Yoxlama siyahıları, etiketlər, müddətləri olan kartlar. Çatışmazlıq: sprintlər yoxdur, məhdud analitika, miqyaslama çətindir. YouGile — kanban lövhələri, çat və videozəngləri olan Trello-nun rus analoqu. Asana — layihələrə və vaxt cədvəllərinə diqqət yetirən treker. Treker seçimi komanda ölçüsündən, büdcədən və üstünlüklərdən asılıdır: enterprise üçün Jira, məhsul komandaları üçün Linear, startaplar üçün Trello/YouGile. Vacib: alət bütün komanda üçün vahid olmalıdır — dizaynerlər, proqramçılar, testerlər, menecerlər bir sistemdə işləyirlər.

Tapşırıqların aparılması üçün ən yaxşı təcrübələr

Qəbul Meyarlarını (Acceptance Criteria) yazın — qəbul meyarları konkret və yoxlanıla bilən olmalıdır. Pis: “Giriş ekranı işləyir”. Yaxşı: “İstifadəçi e-poçt və şifrə daxil edir, Daxil ol düyməsini sıxır. Məlumatlar düzgündürsə — əsas ekrana keçid. Səhvdirsə — “Yanlış e-poçt və ya şifrə” xətası göstərilir”. Qəbul Meyarları (AC) proqramçı, tester və məhsul meneceri arasında müqavilədir. AC olmadan tapşırıq Definition of Ready (DoR) meyarına cavab vermir və sprinta daxil olmamalıdır.

Hər şeyi bağlayın. Commit-lər, PR-lər, test ssenariləri, dizayn maketləri (Figma), Slack-də müzakirələr — hər şey tapşırığa bağlanmalıdır. Jira-da bu, şərhlərdə linklər vasitəsilə, Linear-da — PR-in avtomatik bağlanması ilə edilir. Bir klik qaydası: tapşırıqdan dizayna/koda/testlərə — bir klikdən çox olmamalıdır. Proqramçı tapşırığı açır və dərhal Figma-da maketi, PR linkini və test ssenarilərini görür. Bu, Linear (2025) məlumatlarına görə, komandanın yeni üzvlərinin onboardingini 30% sürətləndirir.

Xəyali tapşırıqlar yaratmayın. Təsviri, AC-si və prioriteti olmayan tapşırıq zibildir. Əgər gündəlik stand-up-da heç kim tapşırığın nə üçün yaradıldığını xatırlamırsa — onu silmək və ya dəqiqləşdirmək lazımdır. 48 saat qaydası: tapşırıq 48 saat ərzində In Progress statusunda aktivlik olmadan qalıbsa — proqramçı gecikmə səbəbləri haqqında şərh yazmalıdır. Jira (2025) məlumatlarına görə, 3 gündən çox hərəkətsiz qalan tapşırıqların 60%-i sonda yerinə yetirilmədən bağlanır.

Tapşırıqların dekompozisiyası: epiklər, user story-lər və alt tapşırıqlar

Epic — çoxlu hekayələri birləşdirən böyük funksional sahə. Nümunə: “İstifadəçi onboardingi” “Salamlama ekranı”, “Maraqların seçilməsi”, “Avatar yükləmə”, “Bildirişlərin qurulması”-nı əhatə edir. User Story — istifadəçi baxımından tapşırıq. Format: “[Kimi] olaraq, [hərəkət] etmək istəyirəm ki, [dəyər] olsun”. Nümunə: “İstifadəçi olaraq, hər dəfə şifrə daxil etməmək üçün biometriya ilə daxil olmaq istəyirəm”. User Story məhsul meneceri və ya məhsul sahibi tərəfindən yazılır.

Alt tapşırıq (Sub-task) — Story / Task daxilində texniki işin dekompozisiyası. Story “Profil ekranı– üçün nümunə: Sub-task 1: Ekranın UI-nı hazırlamaq (XML / SwiftUI), Sub-task 2: ViewModel ilə əlaqələndirmək, Sub-task 3: Vahid testlər yazmaq, Sub-task 4: Snapshot testləri, Sub-task 5: UI testləri (Espresso / XCUITest). Dekompozisiya qaydası: hər alt tapşırıq 1-2 günə tamamlanır. Proqramçı alt tapşırığı daha uzun qiymətləndirirsə — daha da bölürük. Alt tapşırıqlar komandanın daxili texnikasıdır, məhsul backlog-unda görünmür. Alt tapşırıqların qiymətlərinin cəmi valideyn Story-nin qiymətinə bərabər olmaya bilər (işin bir hissəsi — kommunikasiya, kod baxışı, testləşdirmə).

Dekompozisiya piramidası: Epic (Rüb / Yarım il) → Feature / Story (Sprint) → Task (1-3 gün) → Sub-task (Bir neçə saat). INVEST texnikası dekompozisiyanın keyfiyyətini yoxlamağa kömək edir. Tapşırıq Independent deyilsə (başqalarından asılıdırsa) — bu, dekompozisiyanın səhv olduğuna işarədir. Tapşırıq Small deyilsə (8 story point-dən çox) — daha da bölmək lazımdır. Common pattern: Epic → 5-15 Stories → hər Story → 3-8 Sub-task. Epikin yekun qiyməti = Stories-in qiymətlərinin cəmi, lakin ilk sprint adətən qiymətlərdə 20-30% xəta verir.

Tapşırıqlarla işdə tipik səhvlər

Səhv 1: çox böyük tapşırıqlar. 2 həftəlik tapşırıq dekompozisiya tələb edən epikdir. Böyük tapşırıqlar gündəlik izləməyə uyğun deyil, həftələrlə In Progress-də asılı qalır. Qayda: maksimum tapşırıq ölçüsü — 2-3 günlük iş. Daha böyük olan hər şey — dekompozisiya edin. Yan təsir: proqramçı bir nəhəng tapşırıq əvəzinə həftədə 2-3 tapşırığı bağlayaraq irəliləyiş hiss edir. Bu, motivasiyanı və müddətlərin proqnozlaşdırılmasını artırır.

Səhv 2: Qəbul Meyarlarının (Acceptance Criteria) olmaması. Proqramçı funksiyanı etdi, tester yoxladı — hər şey ok. Menecer: “Redaktə düyməsi haradadır?” — “Tapşırıqda yazılmayıb”. AC olmadan hər tərəf tapşırığı özünə görə başa düşür. Nəticə: yenidən işləmə, münaqişələr, pozulmuş müddətlər. AC — müqavilə: tapşırıqda meyarlar yoxdursa — sprinta hazır deyil. Grooming-də ilk növbədə AC-nin mövcudluğu yoxlanılır. AC yoxdursa — tapşırıq Product Manager tərəfindən dəqiqləşdirməyə göndərilir.

Səhv 3: Tech Debt-i unutmaq. Komanda sprintdən sprinta yalnız Feature tapşırıqları edir. Yarım ildən sonra: yığım 15 dəqiqə çəkir, Gradle 3 əsas versiya köhnəlib, testlər CI-da deprecation səbəbindən uğursuz olur. Həll: komanda vaxtının 20%-ni Tech Debt-ə ayırmaq (Google SRE “SLO-based error budget” təcrübəsi). Hər Feature sprintinə ən azı bir Tech Debt tapşırığı qeyd edin. Nisbət: hər 3 Feature tapşırığına — 1 Tech Debt və ya Bug. Bu, texniki borcun yığılmasının qarşısını alır və inkişaf sürətini qoruyur.