Vazifa va ticket — bu nima, kuzatish tizimlari va vazifalar bilan ishlash

Vazifa va ticket nima?

Vazifa (ing. task) — kuzatish tizimida qayd etilgan ish birligi. Tavsifi, prioriteti (Critical, High, Medium, Low), ijrochisi, muddati va statusi bor. Mobil ishlanmada vazifa “Profil ekranini avatar bilan qo'shish”, “Lenta paginatsiyasini amalga oshirish” yoki “targetSdk versiyasini 35 ga yangilash” bo'lishi mumkin. Har bir vazifa loyihaga, sprintga va aniq dasturchi yoki jamoaga bog'langan.

Ticket (ing. ticket) — kengroq tushuncha. Ticket xato hisoboti (“Android 14 da ekran aylantirilganda ilova qulab tushadi”), funksiya so'rovi (“Qorong'u temani qo'llab-quvvatlashni qo'shish”), texnik yordam murojaati (“Push bildirishnomasi kelmayapti”) yoki menejer vazifasi (“Oy uchun crash rate hisobotini tayyorlash”) bo'lishi mumkin. Vazifa va ticket o'rtasidagi farq noaniq: Jira-da ikkala tushuncha Issue-da birlashtirilgan. Asosiy farq: vazifa har doim ijrochisi bo'lgan ish, ticket triajgacha aniq ijrochisi bo'lmagan so'rov bo'lishi mumkin.

Scrum va Kanban-da vazifalar backlog-ning asosiy elementidir. Har bir vazifa INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) mezoniga javob berishi kerak. Mustaqil vazifalar istalgan tartibda amalga oshirilishi mumkin. Baholanishi mumkin — jamoa mehnat zichligini taxmin qila oladi. Kichik — bir sprintga sig'adi. Sinab ko'rilishi mumkin — aniq qabul mezonlari bor. Katta vazifalar (epiklar) barcha mezonlar bajarilgunga qadar kichikroq qismlarga bo'linadi.

Mobil ishlanmada vazifa turlari

Feature — ilovaning yangi funksionalligi. Misol: “Biometriya orqali kirish ekrani (Face ID / Touch ID)”. Feature vazifalari har doim user story bilan bog'liq va Qabul mezonlariga (Acceptance Criteria) ega. Baholash — story points (1, 2, 3, 5, 8, 13). Bug — ishlab chiqish yoki test jarayonida topilgan nuqson. Bug ticket-ning prioriteti severity bo'yicha aniqlanadi (crash → Critical, UI-bug → Medium, matn xatosi → Low). Mobil ishlanmada 0.1% dan yuqori crash rate tanqidiy xato hisoblanadi va zudlik bilan tuzatishni talab qiladi.

Tech Debt / Chore — foydalanuvchiga ko'rinmaydigan texnik vazifalar: kutubxonalarni yangilash (Dependency Bump), refaktoring (ViewPager dan ViewPager2 ga migratsiya), CI/CD sozlash, testlarni yozish. Tech Debt vazifalari ko'pincha kam baholanadi, ammo Stripe 2025 ma'lumotlariga ko'ra, mobil jamoaning 30% gacha vaqti texnik qarzni saqlash va to'lashga sarflanadi. Tech Debt-ni e'tiborsiz qoldirish xatolar sonining ko'payishiga va yangi funksiyalarni ishlab chiqishning sekinlashishiga olib keladi.

Qo'shimcha turlar: Spike (tadqiqot vazifasi — yangi texnologiyani o'rganish, POC yozish), Task (kodga tegishli bo'lmagan har qanday ish — hujjatlashtirish, dizayn ko'rib chiqish), Improvement (mavjud funksionallikni yaxshilash — ekran yuklanish vaqtini optimallashtirish). Jira-da issue turlari loyiha bo'yicha sozlanadi. Mobil jamoa uchun standart to'plam: Story, Bug, Task, Improvement, Epic. Epic — bir nechta hikoyalarni birlashtirgan katta mavzu. Misol: “E-tijorat: savat va buyurtma rasmiylashtirish”.

Vazifaning hayot sikli: yaratilishdan yopilishgacha

Open (To Do) — vazifa yaratilgan, lekin boshlanmagan. Tavsifi, Qabul mezonlari, prioriteti bor. Bu statusda vazifa sprintga kirishdan oldin grooming (aniqlashtirish va baholash) dan o'tishi kerak. In Progress — dasturchi ishni boshladi. Mobil ishlanmada commit va pull request-larni vazifaga bog'lash muhim: Jira-da Smart Commits orqali (APP-123 #comment xatoni tuzatish), GitHub/GitLab-da PR tavsifida kalit so'zlar orqali (Closes APP-123).

In Review — kod ko'rib chiqishga yuborilgan. Avtomatik tekshiruvlar: CI (Gradle build, lint, birlik testlari), SonarQube (kod sifati), Danger (changelog, testlar). Dasturchi joriy vazifa Review da bo'lganida keyingi vazifani ololmaydi — bu ko'p vazifalilikning oldini oladi. QA / Testing — tester haqiqiy qurilmalarda tekshiradi (Android — turli OS versiyalari va ekran o'lchamlari, iOS — turli iPhone modellari). Agar xatolar topilsa, vazifa sharh bilan In Progress ga qaytariladi.

Done (Closed) — vazifa tugallandi: kod main/master ga birlashtirildi, testdan o'tdi, chiqarishga tayyor. Ba'zi jamoalar Deployed statusini qo'shadi — vazifa foydalanuvchiga faqat do'konlarda build chop etilgandan keyin yetib boradi. Vazifalarni natija haqida sharh bilan yopish muhim: qaysi versiya, qaysi PR, qanday ko'rsatkichlar o'zgargan. Linear (2025) ma'lumotlariga ko'ra, vazifalarni natija tavsifi bilan yopadigan jamoalar bir xil vazifalarga 40% kamroq qaytadi.

Hayot sikli Blocked statusini o'z ichiga olishi mumkin — vazifa tashqi bog'liqlik tufayli bajarilmaydi (dizaynni kutmoqdamiz, backend javobi, menejer tasdiqi). Blocked vazifalar sabab va keyingi tekshirish sanasi bilan sharhlangan bo'lishi kerak. Haftalik Blocked vazifalarni ko'rib chiqish ishlab chiqish jarayonida tizimli kechikishlarni aniqlashga yordam beradi. 2 haftadan uzoq blokerlar mahsulot menejeri darajasiga eskalatsiyani talab qiladi.

Vazifalarni kuzatish tizimlari

Jira — 10 kishidan ortiq jamoalar uchun sanoat standarti. Scrum va Kanban taxtalarini, ilg'or workflow sozlamalarini, maxsus maydonlarni, avtomatlashtirishlarni, Bitbucket/GitHub bilan integratsiyani qo'llab-quvvatlaydi. Kamchiliklari: kichik jamoalar uchun ortiqchalik, sekin interfeys, murakkab konfiguratsiya. Mobil loyihalar uchun Jira quyidagilar bilan sozlanadi: Mobile-specific fields (Platform, OS version, Device model) plagini, TestFlight va Firebase Test Lab bilan integratsiya, reliz buildlarini avtomatlashtirish. Jira — byurokratik jarayonlarga ega korporativ loyihalarning tanlovi.

Linear — mahsulot jamoalari uchun zamonaviy treker. Tez interfeys, klaviatura yorliqlarining birinchi darajali qo'llab-quvvatlashi, o'rnatilgan Cycle (sprint analogi), GitHub va Slack bilan integratsiya. Afzalliklari: CMD+K orqali vazifalarni tez yaratish, fazalarga avtomatik taqsimlash (Triaged → Backlog → Upcoming → Current → Completed), o'rnatilgan hujjatlashtirish va yo'l xaritalari. Linear tezlikni qadrlaydigan startaplar va mahsulot jamoalari tomonidan tanlanadi. 2025 yilda yangi mobil loyihalarning 40% Linear dan foydalanadi.

Trello — kichik jamoalar (2-5 kishi) uchun oddiy kanban taxtasi. Tekshirish ro'yxatlari, yorliqlar, muddatlari bo'lgan kartalar. Kamchiligi: sprintlar yo'q, cheklangan analitika, masshtablash qiyin. YouGile — kanban taxtalari, chat va videoqo'ng'iroqlari bilan Trello-ning rus analogi. Asana — loyihalar va vaqt jadvallariga e'tibor qaratgan treker. Treker tanlash jamoa hajmi, byudjet va afzalliklarga bog'liq: enterprise uchun Jira, mahsulot jamoalari uchun Linear, startaplar uchun Trello/YouGile. Muhim: vosita butun jamoa uchun yagona bo'lishi kerak — dizaynerlar, dasturchilar, testerlar, menejerlar bitta tizimda ishlaydi.

Vazifalarni yuritishning eng yaxshi amaliyotlari

Qabul mezonlarini (Acceptance Criteria) yozing — qabul mezonlari aniq va tekshirilishi mumkin bo'lishi kerak. Yomon: “Kirish ekrani ishlaydi”. Yaxshi: “Foydalanuvchi email va parolni kiritadi, Kirish tugmasini bosadi. Agar ma'lumotlar to'g'ri bo'lsa — asosiy ekranga o'tish. Noto'g'ri bo'lsa — “Noto'g'ri email yoki parol” xatosi ko'rsatiladi”. Qabul mezonlari (AC) dasturchi, tester va mahsulot menejeri o'rtasidagi shartnomadir. AC bo'lmasa, vazifa Definition of Ready (DoR) mezoniga javob bermaydi va sprintga kirmasligi kerak.

Hamma narsani bog'lang. Commitlar, PRlar, test stsenariylari, dizayn maketlari (Figma), Slack muhokamalari — hammasi vazifaga bog'langan bo'lishi kerak. Jira-da bu sharhlardagi linklar orqali, Linear-da — PRni avtomatik bog'lash orqali amalga oshiriladi. Bir bosish qoidasi: vazifadan dizayn/kod/testlargacha — bir bosishdan ko'p bo'lmasligi kerak. Dasturchi vazifani ochadi va darhol Figma-da maketni, PR linkini va test stsenariylarini ko'radi. Bu, Linear (2025) ma'lumotlariga ko'ra, jamoa yangi a'zolarining onboardini 30% tezlashtiradi.

Xayoliy vazifalar yaratmang. Tavsifi, AC va prioriteti bo'lmagan vazifa axlatdir. Agar kundalik stand-upda hech kim vazifa nima uchun yaratilganini eslamasa — uni o'chirish yoki aniqlashtirish kerak. 48 soat qoidasi: agar vazifa 48 soat davomida In Progress statusida faolliksiz qolsa — dasturchi kechikish sabablari haqida sharh yozishi kerak. Jira (2025) ma'lumotlariga ko'ra, 3 kundan ortiq harakatsiz qolgan vazifalarning 60% oxirida bajarilmasdan yopiladi.

Vazifalarni dekompozitsiyasi: epiklar, user story-lar va kichik vazifalar

Epic — ko'plab hikoyalarni birlashtirgan katta funksional soha. Misol: “Foydalanuvchi onbordingi” “Salomlashish ekrani”, “Qiziqishlarni tanlash”, “Avatarni yuklash”, “Bildirishnomalarni sozlash” ni o'z ichiga oladi. User Story — foydalanuvchi nuqtai nazaridan vazifa. Format: “[ Rol] sifatida, [harakat] qilishni xohlayman, [qiymat] bo'lishi uchun”. Misol: “Foydalanuvchi sifatida, har safar parol kiritmaslik uchun biometriya orqali kirishni xohlayman”. User Story mahsulot menejeri yoki mahsulot egasi tomonidan yoziladi.

Kichik vazifa (Sub-task) — Story / Task ichidagi texnik ishning dekompozitsiyasi. Story “Profil ekrani” uchun misol: Sub-task 1: Ekran UI sini tayyorlash (XML / SwiftUI), Sub-task 2: ViewModel bilan bog'lash, Sub-task 3: Birlik testlarini yozish, Sub-task 4: Snapshot testlari, Sub-task 5: UI testlari (Espresso / XCUITest). Dekompozitsiya qoidasi: har bir kichik vazifa 1-2 kunda tugallanadi. Agar dasturchi kichik vazifani uzoqroq baholasa — yanada bo'lamiz. Kichik vazifalar jamoaning ichki texnikasi bo'lib, mahsulot backlogida ko'rinmaydi. Kichik vazifalar baholari yig'indisi ota-ona Story bahosiga teng bo'lishi shart emas (ishning bir qismi — kommunikatsiya, kod ko'rib chiqish, testlash).

Dekompozitsiya piramidasi: Epic (Chorak / Yarim yil) → Feature / Story (Sprint) → Task (1-3 kun) → Sub-task (Bir necha soat). INVEST texnikasi dekompozitsiya sifatini tekshirishga yordam beradi. Agar vazifa Independent bo'lmasa (boshqalarga bog'liq) — bu dekompozitsiya noto'g'riligining belgisidir. Agar vazifa Small bo'lmasa (8 story pointdan ko'p) — yanada bo'lish kerak. Oddiy pattern: Epic → 5-15 Stories → har bir Story → 3-8 Sub-task. Epikning yakuniy bahosi = Stories baholari yig'indisi, lekin birinchi sprint odatda baholarda 20-30% xatoga ega.

Vazifalar bilan ishlashda odatiy xatolar

Xato 1: juda katta vazifalar. 2 haftalik vazifa dekompozitsiya talab qiladigan epikdir. Katta vazifalar kundalik kuzatishga mos kelmaydi, haftalar davomida In Progress da osilib qoladi. Qoida: maksimal vazifa hajmi — 2-3 kunlik ish. Kattaroq hamma narsa — dekompozitsiya qiling. Yon ta'sir: dasturchi bitta ulkan vazifa o'rniga haftasiga 2-3 vazifani yopib, taraqqiyotni his qiladi. Bu motivatsiyani va muddatlarning bashorat qilinishini oshiradi.

Xato 2: Qabul mezonlarining (Acceptance Criteria) yo'qligi. Dasturchi funksiyani qildi, tester tekshirdi — hammasi ok. Menejer: “Tahrirlash tugmasi qayerda?” — “Vazifada yozilmagan”. AC bo'lmasa, har bir tomon vazifani o'zicha tushunadi. Natija: qayta ishlash, nizolar, buzilgan muddatlar. AC — shartnoma: vazifada mezonlar bo'lmasa — sprintga tayyor emas. Groomingda birinchi navbatda AC mavjudligi tekshiriladi. AC bo'lmasa — vazifa Product Manager tomonidan tuzatishga yuboriladi.

Xato 3: Tech Debt ni unutish. Jamoa sprintdan sprintga faqat Feature vazifalarini qiladi. Yarim yildan keyin: yig'ish 15 daqiqa davom etadi, Gradle 3 asosiy versiyaga eskirgan, testlar CI da deprecation sababli muvaffaqiyatsiz bo'ladi. Yechim: jamoa vaqtining 20% ni Tech Debt ga ajratish (Google SRE “SLO-based error budget” amaliyoti). Har bir Feature sprintiga kamida bitta Tech Debt vazifasi qo'ying. Nisbat: har 3 Feature vazifasiga — 1 Tech Debt yoki Bug. Bu texnik qarzning to'planishining oldini oladi va ishlab chiqish tezligini saqlaydi.