Kanban, vazifa trekerlari va ish oqimi: doska, WIP limit va cycle time

Qisqacha: Kanban — ish oqimini ko'rinadigan qilish va bir vaqtda boshlangan ishlar sonini (WIP) cheklash strategiyasi. Doska ustunlari — ish holatlari, karta — bitta ish. Asosiy o'lchovlar: WIP, throughput, ishning yoshi va cycle time (boshlanishdan tugashgacha). GitHub Projects'da ustun limiti faqat ogohlantiradi, ishni to'xtatmaydi — limitni jamoa intizomi ushlab turadi. Bu darsda vazifalar-api uchun 16 ta label yaratamiz va holat: label'larini doskaga aylantiramiz, haqiqiy vaqt belgilaridan cycle time hisoblaymiz va kanon issue'sidagi buzilgan tanani tahlil qilamiz.

Bu darsda

• Kanban'ning uch amaliyotini va ish oqimi ta'rifining qismlarini tushuntira olasiz.
• WIP limit nega kerakligini va uni qanday tekshirishni ko'rsatasiz.
• Lead time, cycle time, throughput va ishning yoshini haqiqiy issue tarixidan hisoblaysiz.
• GitHub Issues/Projects, Jira va Linear'ni solishtirasiz.
• User story, qabul mezonlari va bug report bilan yaxshi ticket yozasiz.
• O'z repo'ngizda doska uchun 16 ta label yaratasiz.

Oldin bilishingiz kerak: Agile va Scrum, Issues, Projects va shablonlar, GitHub CLI (gh), Date asoslari.

1. Nega bu kerak?

Dushanba kuni Aziz vazifalar-api da migratsiyani boshladi. Seshanba kuni Nodira so'radi: "Testlarni ko'rib bera olasizmi?" — Aziz uni ham oldi. Chorshanba — shoshilinch xato. Payshanba — README. Juma kuni Aziz'da beshta boshlangan ish bor, birortasi tugamagan. Har biri "80 % tayyor". Foydalanuvchi uchun natija — nol.

Muammo dangasalikda emas. Muammo — bir vaqtda juda ko'p ish. Har almashishda kontekst yo'qoladi: qaysi branch, qaysi test, qayerda qolgan edim? Ishlar navbatda kutadi va hammasi sekinlashadi.

Kanban ikki oddiy savolni doimiy qiladi:

1. Hozir kim nima ustida ishlayapti — ko'rinyaptimi?
2. Boshlangan ishlar soni — cheklanganmi?

Hayotiy o'xshatish: choyxonadagi oshpaz. Uning plitasida to'rtta qozon joyi bor. Beshinchi buyurtma kelsa, u yangi qozon qo'ymaydi — avval bittasini tugatadi. Shuning uchun har osh vaqtida chiqadi. Agar u o'nta qozonni birdan qo'ysa, hammasi kuyadi. Kanban — dasturchining "to'rtta qozon" qoidasi.

2. Kanban nima

2.1 Rasmiy ta'rif

Kanban'ning qisqa rasmiy qo'llanmasi — The Kanban Guide (kanbanguides.org, v2025.5, 2025-yil may; 2026-11-04 da ochib o'qildi). Ta'rif:

"Kanban is a strategy for optimizing the flow of value through a process."

"Kanban — jarayon orqali qiymat oqimini yaxshilash strategiyasi." Scrum'dan farqi: sprint, rol va marosim yo'q. Kanban mavjud jarayoningizning ustiga qo'yiladi — Scrum jamoasi ham uni ishlatishi mumkin.

Uch amaliyot (Guide'dan):

• "Defining and visualizing a workflow" — ish oqimini aniqlash va ko'rinadigan qilish;
• "Actively managing items in a workflow" — oqimdagi ishlarni faol boshqarish;
• "Improving a workflow" — oqimni yaxshilash.

2.2 Ish oqimi ta'rifi

Guide'ga ko'ra jamoa ish oqimi ta'rifini (Definition of Workflow) yozadi. Unda kamida oltita narsa bo'ladi. Ularni vazifalar-api kanoni bilan solishtiramiz:

SLE (service level expectation — xizmat darajasi kutilmasi) — "ish odatda qancha vaqtda tugaydi" degan prognoz. Guide'ga ko'ra u ikki qismdan iborat: vaqt va ehtimol. Masalan: "issue'larning 85 % i 3 kunda yoki tezroq yopiladi". Kanonda SLE yozilmagan — buning uchun hali yetarli tarix yo'q. Bu ochiq qolgan narsa, uni yashirmaymiz.

Diqqat: Kanban Guide 2025 versiyasida "WIP limit" atamasi ishlatilmaydi. Guide WIP'ni nazorat qilishni talab qiladi, usulini esa jamoaga qoldiradi. Ustunga raqamli limit qo'yish — eng ko'p uchraydigan usul, lekin yagona emas.

3. Doska

3.1 Kanon label'lari — ustunlar

Doskaning ustunlari — to'rtta holat: label'i. Ularni shu darsning «Loyiha qadami» bo'limida yaratasiz; kurs sinov reposida ular allaqachon bor. Ma'nosi:

Birinchi qatorga e'tibor bering. Jamoada muloqot darsidagi issue shablonlari (xato.yml, taklif.yml) yangi issue'ga o'zi holat: saralash label'ini qo'yadi:

labels: ["tur: xato", "holat: saralash"]

Ya'ni doskaning kirish eshigi — shablon. Yangi ish hech qachon "holatsiz" bo'lmaydi.

Sinov reposidagi doska hozir shunday (o'z gh so'rovimiz, faqat o'qish, 2026-11-04):

flowchart LR
  subgraph S["saralash"]
    s0["—"]
  end
  subgraph T["tayyor"]
    t1["#1 epic"]
    t2["#3 #4 #5 #6 #7"]
    t3["#8 good first issue"]
  end
  subgraph J["jarayonda 1/2"]
    j1["#2 migratsiya"]
  end
  subgraph R["review"]
    r0["—"]
  end
  S --> T --> J --> R

Doskaga qarang: tayyor ustuni to'la, jarayonda — bitta ish, limit 2. Bu sog'lom holat: navbat bor, lekin boshlangan ish kam.

3.2 Doskani gh bilan o'qish

Projects bo'lmasa ham, doskani label bo'yicha so'rov bilan ko'rish mumkin. Biz sinov reposida shunday skriptni yurgizdik (repo nomi login/vazifalar-api ga almashtirildi):

R=login/vazifalar-api
for h in saralash tayyor jarayonda review; do
  n=$(gh issue list -R $R --label "holat: $h" --json number \
      --jq 'map("#\(.number)") | join(" ")')
  echo "holat: $h -> ${n:--}"
done

holat: saralash -> -
holat: tayyor -> #8 #7 #6 #5 #4 #3 #1
holat: jarayonda -> #2
holat: review -> -

${n:--} — o'zgaruvchi bo'sh bo'lsa, - chiqaradi. Bitta ustunni yana bir so'rov bilan tekshiramiz: holat: label'i umuman yo'q issue'lar.

gh issue list -R $R --state all --limit 30 --json number,labels \
  --jq '.[] | select([.labels[].name | startswith("holat:")]
        | any | not) | "#\(.number)"'

#16
#10

Ikki issue doskada umuman yo'q. #10 — review taklifidan ochilgan ish (Ingliz tilida yozish va gapirish darsidagi "opened #10 to track it"). #16 — LICENSE topilmasi, u yopilgan ham. Ular doskaga tushmagan, chunki shablon orqali emas, buyruq bilan yaratilgan va holat: qo'yilmagan. Saboq: doska faqat unga tushgan ishni ko'rsatadi. Kirish eshigini bitta qiling — shablon yoki avtomat.

4. WIP limit

4.1 Nega cheklash tezlashtiradi

WIP (work in progress — boshlangan, lekin tugamagan ish). Guide ta'rifi: "The number of work items started but not finished." — boshlangan, lekin tugamagan ishlar soni.

Paradoks: kamroq ishni boshlasangiz, ish tezroq tugaydi. Sababi — navbat. Bir ishchi to'rtta ishni navbat bilan qilsa, har biri to'rt barobar uzoq "ochiq" turadi.

Buni hisoblash uchun yana ikki so'z kerak. Throughput (o'tkazuvchanlik) — vaqt birligida tugagan ishlar soni, masalan "haftada 5 ta issue". Cycle time — bitta ish boshlangandan tugaguncha o'tgan vaqt (uni «Oqim o'lchovlari» bo'limida batafsil ko'ramiz). Navbat nazariyasidagi Little qonuni ularni bog'laydi: o'rtacha cycle time ≈ o'rtacha WIP ÷ throughput. Qonun uzoq muddatli o'rtachalar uchun to'g'ri (Wikipedia, "Little's law", 2026-11-04 da o'qildi); Kanban Guide'da u yo'q. Misol: haftada 5 ta ish tugatasiz, ochiq ishlar 10 ta — o'rtacha ish 2 hafta yuradi. Throughput o'zgarmasa, WIP ikki barobar oshsa — har ish ikki barobar uzoq kutadi.

Limitning ikkinchi foydasi — u muammoni ko'rsatadi. review ustuni to'lsa, yangi ish boshlab bo'lmaydi. Jamoa majbur: avval review qilish kerak. Shunda "review 3 kun kutyapti" muammosi yashirinib qolmaydi.

4.2 Limitni kod bilan tekshiramiz

Kanon jarayonda label'iga limit yozgan, lekin GitHub uni tekshirmaydi. Oddiy tekshiruvchi — haqiqiy doska ma'lumoti bilan:

const LIMIT = { jarayonda: 2, review: 2 };

function wipniTekshir(doska) {
  return Object.entries(LIMIT).map(([ustun, limit]) => {
    const soni = doska[ustun].length;
    const belgi = soni > limit ? "OSHDI" : "ok";
    return `${ustun}: ${soni}/${limit} ${belgi}`;
  });
}

const doska = {
  saralash: [],
  tayyor: [8, 7, 6, 5, 4, 3, 1],
  jarayonda: [2],
  review: [],
};
console.log(wipniTekshir(doska));

// Aziz bir vaqtda yana ikkita issue oldi
doska.tayyor = doska.tayyor.filter((n) => n !== 3 && n !== 4);
doska.jarayonda.push(3, 4);
console.log(wipniTekshir(doska));

Konsolda:

[ 'jarayonda: 1/2 ok', 'review: 0/2 ok' ]
[ 'jarayonda: 3/2 OSHDI', 'review: 0/2 ok' ]

Birinchi qator — sinov reposining hozirgi holati. Ikkinchisi — Aziz «Nega bu kerak?» bo'limidagidek ishlarni yig'ib oldi. Bunday tekshiruvni CI yoki bot har kuni yurgizib, jamoa chatiga yozishi mumkin.

4.3 GitHub Projects'da limit

GitHub Projects'ning Board ko'rinishida ustunga limit qo'yish mumkin. GitHub hujjatiga ko'ra (docs.github.com, 2026-11-04 da ochib o'qildi): ustun nomi yonidagi menyu → Set column limit → raqam → Save. Lekin hujjat aniq aytadi: "Setting a limit does not restrict anyone from adding cards that would exceed the column's limit" — limit hech kimga ortiqcha karta qo'shishni taqiqlamaydi. Limitdan oshsa, ustun faqat rang bilan belgilanadi.

Xulosa: limit — vosita emas, kelishuv. Uni jamoa ushlab turadi.

Tekshirib ko'ring: review ustunida 4 ta PR turibdi (limit 2). Aziz o'z ishini tugatib, PR ochdi. Kanban bo'yicha u endi nima qilishi kerak — yangi issue olishimi?

5. Oqim o'lchovlari

5.1 To'rt o'lchov

Kanban Guide to'rtta majburiy o'lchovni nomlaydi:

Yana bir atama ko'p uchraydi — lead time (yetkazish vaqti): so'rov paydo bo'lgandan (issue yaratilgandan) tugaguncha. Cycle time esa faqat ish boshlangandan sanaladi. Farq — navbatda kutgan vaqt. Lead time Kanban Guide'da yo'q, lekin mijoz uchun aynan u muhim: "so'raganimdan qancha vaqtda oldim?"

flowchart LR
  A["issue yaratildi"] --> B["holat: jarayonda"]
  B --> C["issue yopildi"]
  A -. "lead time" .-> C
  B -. "cycle time" .-> C

5.2 Haqiqiy issue'lardan hisoblaymiz

Biz sinov reposidan ikki issue tarixini o'qidik (faqat GET):

gh api "repos/$R/issues/2/timeline" \
  --jq '.[] | select(.event=="labeled" or .event=="unlabeled")
        | "\(.created_at) \(.event) \(.label.name)"'
gh issue view 16 -R $R --json createdAt,closedAt \
  --jq '"\(.createdAt) \(.closedAt)"'

2026-11-03T19:18:20Z labeled tur: xususiyat
2026-11-03T19:18:21Z labeled holat: tayyor
2026-11-03T19:18:21Z labeled sp: 2
2026-11-04T10:32:33Z labeled holat: jarayonda
2026-11-04T10:32:33Z unlabeled holat: tayyor
2026-11-04T10:16:13Z 2026-11-04T10:47:39Z

Vaqtlar UTC'da (Z). #2 holat: tayyor da 15 soatdan ortiq kutdi, keyin ish boshlandi. #16 yaratilib, 31 daqiqada yopildi. Hisobni kodga o'tkazamiz:

const DAQIQA = 60_000;

function daqiqa(boshi, oxiri) {
  return Math.round((new Date(oxiri) - new Date(boshi)) / DAQIQA);
}

// #16: issue yaratildi -> yopildi (lead time)
console.log("#16 lead time:",
  daqiqa("2026-11-04T10:16:13Z", "2026-11-04T10:47:39Z"), "daqiqa");

// #2: "holat: jarayonda" qo'yildi -> hali ochiq (yoshi)
const bugun = "2026-11-04T15:00:00Z";
const yoshi = daqiqa("2026-11-04T10:32:33Z", bugun);
console.log("#2 yoshi:", (yoshi / 60).toFixed(1), "soat");

Konsolda:

#16 lead time: 31 daqiqa
#2 yoshi: 4.5 soat

bugun qotirilgan — natija har ishga tushirishda bir xil chiqsin. Haqiqiy botda new Date() bo'ladi.

5.3 Natijani halol o'qish

Bu raqamlar nimani ko'rsatmaydi?

• #16 ning cycle time'i o'lchanmaydi. Unda holat: jarayonda hech qachon bo'lmagan — boshlanish nuqtasi yo'q. 31 daqiqa — lead time. Guide nega "boshlanish va tugash nuqtasini aniqlang" deb talab qilgani shu yerda ko'rinadi.
• #2 hali tugamagan. Uning cycle time'i yo'q, faqat yoshi bor. Yoshi o'sib borayotgan ish — e'tibor signali.
• Ikkita issue — statistika emas. Throughput va SLE uchun haftalar davomidagi o'nlab ish kerak. Kanon tarixida bunday ma'lumot yo'q.

Tekshirib ko'ring: Issue 10 kun oldin yaratilgan, 2 kun oldin holat: jarayonda bo'lgan va bugun yopildi. Lead time va cycle time qancha? Farq nimani bildiradi?

6. Vazifa trekerlari

6.1 Uchta mashhur vosita

Vazifa trekeri (issue tracker) — ishlar ro'yxati, holati va tarixi saqlanadigan tizim. Uchta keng tarqalgani:

Jadvaldagi ma'lumot — vositalar sahifalaridan umumiy tavsif (linear.app, atlassian.com/software/jira — 2026-11-04 da ochildi; vositalarning o'zi kursda sinalmagan). Kursda ishlatilgani — faqat GitHub Issues. Qaysi vositani tanlash — jamoaning ishi. Kanban tamoyillari uchalasida bir xil: ustunlar, limit, o'lchovlar.

6.2 GitHub Projects — kanonda sinalmadi

Issues, Projects va shablonlar darsida Projects'ning Board ko'rinishini ko'rgansiz. Kanon uni ishlatmoqchi edi, lekin bunday bo'ldi. Biz takrorladik (akkaunt nomi login ga almashtirildi):

gh api -i user 2>&1 | grep -i '^x-oauth-scopes'
gh project list --owner login

X-Oauth-Scopes: gist, read:org, repo, workflow
error: your authentication token is missing required scopes [read:project]
To request it, run:  gh auth refresh -s read:project

"Autentifikatsiya tokeningizda kerakli ruxsat yo'q: read:project." Birinchi qator token ruxsatlarini ko'rsatadi: repo bor, project yo'q. Issue va label'lar uchun repo yetadi, Projects uchun alohida ruxsat kerak. Xabarning o'zi yechimni aytadi: gh auth refresh -s read:project (yozish uchun — -s project). Kanon akkaunt sozlamasiga tegmadi, shuning uchun Projects bo'limi sinalmagan: undagi interfeys ma'lumotlari — GitHub hujjatidan.

O'z repo'ngizda gh auth refresh -s project qilib, Board'ni sinab ko'rishingiz mumkin — bu sizning akkauntingiz qarori.

7. Yaxshi ticket

7.1 User story

Ticket — trekerdagi bitta ish yozuvi (GitHub'da — issue). Xususiyat uchun eng keng tarqalgan shakl — user story (foydalanuvchi hikoyasi): "kim, nima, nega". Kanon taklif.yml shablonidagi qolip:

**Hikoya:** … sifatida men … xohlayman, toki …

Kanon epic'idagi haqiqiy hikoya: "Vazifa egasi sifatida men vazifani "har hafta" deb belgilamoqchiman, toki uni qayta-qayta yozmay." Uch qismi aniq: kim (vazifa egasi), nima (har hafta), nega (qayta yozmaslik). "Nega" qismi eng muhimi — u yechim o'zgarsa ham maqsadni saqlaydi.

7.2 Qabul mezonlari

Qabul mezonlari (acceptance criteria) — ish qachon tayyor ekanini aytadigan tekshiriladigan shartlar. Ko'p ishlatiladigan shakl — Berilgan / Qachonki / Unda (inglizchasi Given / When / Then). Kanon talab hujjatidan (loyihaning keyingi bosqichi, Mahsulot tafakkuri darsida to'liq yoziladi):

Berilgan — haftalik vazifa; qachonki uni bajarilgan qilsam; unda
bitta yangi vazifa keyingi muddat bilan yaratiladi (ikki marta
bosilsa ham — bitta: idempotentlik), eskisi bajarilgan bo'lib qoladi.

Bu shartni testga aylantirish mumkin: "ikki marta bosilsa — bitta nusxa". "Tez ishlashi kerak" yoki "qulay bo'lsin" — mezon emas, chunki tekshirib bo'lmaydi.

7.3 Bug report

Xato haqida ticket uchun kanonda alohida shablon bor — xato.yml. Uning majburiy maydonlari: takrorlash qadamlari, kutilgan natija, haqiqiy natija, versiya yoki commit. Ularning inglizcha nomlarini Ingliz tilida yozish va gapirish darsida ko'rdik. Shablonda bitta qo'shimcha ham bor:

  - type: markdown
    attributes:
      value: "Xavfsizlik zaifligi bo'lsa — bu yerga EMAS, SECURITY.md dagi yo'l bilan."

Ochiq issue — hammaga ko'rinadi. Zaiflikni u yerda yozish — hujumchiga yo'l ko'rsatish.

7.4 Kanon xatosi: buzilgan ticket

Endi o'z xatoimizni ko'rsatamiz. Sinov reposidagi #2 issue'ning haqiqiy tanasi (biz o'qidik):

Yangi ustun ixtiyoriy (NULL), CHECK — faqat {tur: kunlik

Taxmin: 2 SP. Bog'liq: haftalik|oylik, kun?}. Prisma migratsiyasi va sql/ fayl aynan; drift 0.|-sub-issue.

Epic: takrorlanuvchi vazifalar (sub-issue).

Matn buzilgan: CHECK sharti ikkiga bo'linib ketgan, "Bog'liq" qatoriga tananing yarmi tushgan. Bu issue bilan ishlaydigan dasturchi "migratsiya nimaga bog'liq?" degan savolga javob topa olmaydi.

Sabab. Kanon sub-issue'larni skript bilan yaratdi. Ma'lumotlar | bilan ajratilgan faylda edi: sarlavha|SP|tana|bog'liqlik. Lekin tananing ichida ham | bor edi: {tur: kunlik|haftalik|oylik}. Biz buni kichik skriptda takrorladik (skript qisqartirilgan, chiqishdan ikki qator):

while IFS='|' read -r t sp body dep; do
  echo "tana:     $body"
  echo "bog'liq:  $dep"
done < sub.txt

tana:     CHECK — faqat {tur: kunlik
bog'liq:  haftalik|oylik, kun?}.|

read satrni | bo'yicha bo'ldi. Tana birinchi | da kesildi, qolgan hamma narsa oxirgi o'zgaruvchiga — dep ga tushdi. Aynan GitHub'dagi buzuq matn.

Oqibati va saboq:

• Ticket yaratildi, lekin hech kim o'qib chiqmadi — xato faqat bu darsni yozayotganda topildi. Avtomatik yaratilgan ticketni ham bir marta ochib ko'ring.
• Ajratuvchi belgi ma'lumot ichida uchramasligi kerak. TAB yoki JSON xavfsizroq. Tuzatishni 3-mashqda yozasiz.
• Yana bir mayda nuqson: hamma sub-issue sarlavhasi feat: bilan, hatto #7 "hujjat: API.md va CHANGELOG" ham. To'g'risi — docs:.

Issue arxivdagi repoda — tuzatilmaydi. Biz uni yashirmaymiz: haqiqiy jamoada ham shunday xatolar bo'ladi, muhimi — topilganda tan olish.

8. Loyiha qadami: doska uchun label'lar

8.1 16 ta label yaratamiz

Endi doskani o'z repo'ngizda qurasiz. Kanon bitta buyruqlar zanjiri bilan 16 ta label yaratdi: tur, holat (doska ustunlari), ustuvorlik va story point. Quyida u telefon uchun bo'lingan va repo nomi login/vazifalar-api ga almashtirilgan; mazmun aynan:

R=login/vazifalar-api
gh label create -R $R 'tur: xato' -c d73a4a -d 'Xato'
gh label create -R $R 'tur: xususiyat' -c a2eeef \
  -d 'Yangi imkoniyat'
gh label create -R $R 'tur: hujjat' -c 0075ca -d 'Hujjat'
gh label create -R $R 'tur: epic' -c 5319e7 \
  -d 'Bir nechta issuedan iborat katta ish'
gh label create -R $R 'holat: saralash' -c fbca04 \
  -d 'Yangi, hali baholanmagan'
gh label create -R $R 'holat: tayyor' -c 0e8a16 \
  -d 'Backlog: boshlashga tayyor (DoR)'
gh label create -R $R 'holat: jarayonda' -c 1d76db \
  -d 'Ishlanmoqda (WIP limit: 2)'
gh label create -R $R 'holat: review' -c c5def5 \
  -d 'PR ochiq, review kutmoqda'
gh label create -R $R 'ustuvorlik: yuqori' -c b60205
gh label create -R $R "ustuvorlik: o'rta" -c d93f0b
gh label create -R $R 'ustuvorlik: past' -c c2e0c6
for p in 1 2 3 5 8; do
  gh label create -R $R "sp: $p" -c ededed \
    -d 'Story point (Fibonachchi)'
done
gh label list -R $R --limit 50 | wc -l

Kanon chiqishi:

26

Nega 26, 16 emas? Repoda GitHub'ning 10 ta sukut label'i ham bor (bug, documentation, good first issue va boshqalar) — biz sinov reposida gh label list bilan tekshirdik. 10 + 16 = 26. Kanon sukut label'larni o'chirmadi — good first issue keyinroq kerak bo'ladi.

Label guruhlari nimaga xizmat qiladi:

• holat: — doska ustunlari («Kanon label'lari — ustunlar» bo'limidagi jadval). jarayonda tavsifida WIP limiti yozilgan — limit hammaning ko'z oldida tursin.
• tur: — ish turi; commit turlari bilan mos (feat ↔ tur: xususiyat). Issue shablonlari ham shu nomlarni ishlatadi.
• ustuvorlik: — Product Owner tartibining qo'pol shakli (Agile va Scrum).
• sp: — faqat Fibonachchi qiymatlari: 4 yoki 7 degan label yo'q, ataylab.

Label allaqachon bo'lsa, gh label create xato beradi. Skriptni qayta ishga tushirmoqchi bo'lsangiz, --force bayrog'i mavjud label'ning rangi va tavsifini yangilaydi (cli.github.com qo'llanmasi, 2026-11-04; kanonda ishlatilmagan).

Agile va Scrum darsida yozgan backlog qoralamangiz shu label'lar bilan Estimatsiya va vazifani kichik qismlarga bo'lish darsida issue'larga aylanadi.

8.2 Kartani surish — kanonda shunday bo'ldi

Ish boshlanganda karta tayyor dan jarayonda ga o'tadi. Label'lar bilan bu ikki amal — eskisini olib tashlash, yangisini qo'yish. Kanon sinov reposida #2 migratsiyani shunday o'tkazdi (talab hujjati qo'shilgandan keyin; repo nomi almashtirildi):

gh issue edit 2 -R $R --remove-label 'holat: tayyor' \
  --add-label 'holat: jarayonda'
gh issue list -R $R --label 'holat: jarayonda' \
  --json number,title --jq '.[] | "#\(.number) \(.title)"'
gh api repos/$R/issues/1 --jq '.sub_issues_summary'

Kanon chiqishi:

https://github.com/login/vazifalar-api/issues/2
{"completed":0,"percent_completed":0,"total":6}

Qiziq: o'rtadagi gh issue list hech narsa chiqarmadi — label endigina qo'yilgan edi. Bu buyruq GitHub qidiruviga tayanadi, qidiruv esa yangilanishga biroz vaqt oladi. Biz keyinroq qayta so'radik — holat: jarayonda -> #2 («Doskani gh bilan o'qish» bo'limi). Agile va Scrum darsidagi sub_issues_summary kechikishi bilan bir xil saboq: yozgandan keyin darhol o'qilgan ro'yxatga to'liq ishonmang.

Issue tarixida ikkala hodisa bir soniyada: 10:32:33Z labeled holat: jarayonda va unlabeled holat: tayyor. Shu vaqt — #2 ning cycle time boshlanishi.

Bu buyruqni hozir yurgizmang: sizda hali issue'lar yo'q. Birinchi vazifani Mahsulot tafakkuri darsida boshlaganingizda kartani o'zingiz shunday surasiz.

8.3 Hali commit qilmang

Bu darsda repodagi fayllar o'zgarmadi — label'lar GitHub'da yashaydi. Epic havola qiladigan talab hujjati Mahsulot tafakkuri darsida yoziladi va commit o'sha yerda.

O'z repo'ngizda tavsiya: CONTRIBUTING.md dagi "Ish oqimi" bo'limini o'qing va har qadamga mos holat: label'ini yozib qo'ying — masalan, "PR ochganda holat: review". Qoidaning yozma shakli — Guide talab qiladigan "o'tish qoidalari"ning o'zi.

9. Ko'p uchraydigan xatolar

9.1 Doska — o'lik rasm

Kartalar haftalab surilmaydi, haqiqiy holat chatda. Doska faqat yangilanib tursa foydali. Yechim: holat o'tishini avtomatlashtiring (PR ochilsa — review, merge — yopiladi) yoki standup'da doskaga qarab gapiring.

9.2 Limitsiz "jarayonda"

Limit yozilmagan yoki hamma uni e'tiborsiz qoldiradi. Belgisi — jarayonda ustuni eng uzuni. Yechim — limit va kundalik tekshiruv («Limitni kod bilan tekshiramiz» bo'limi).

9.3 Boshlanish nuqtasi yo'q

#16 kabi — issue to'g'ridan yopiladi, jarayonda bo'lmaydi. Cycle time o'lchanmaydi. Yechim: "ish boshlandi" belgisini aniq kelishing va unga amal qiling.

9.4 Bitta ticket — bir nechta ish

"Login, ro'yxatdan o'tish va parolni tiklash" — bitta issue'da. U hech qachon "tayyor" bo'lmaydi. Har biri — alohida ticket, kerak bo'lsa epic ostida.

9.5 Tekshirib bo'lmaydigan mezon

"Tez ishlasin", "chiroyli bo'lsin". Yechim — raqam yoki aniq holat: "javob 300 ms dan kam", "Berilgan / Qachonki / Unda".

9.6 Ajratuvchi ma'lumot ichida

Kanon xatosi («Kanon xatosi: buzilgan ticket» bo'limi). Ajratuvchi ma'lumotda uchramasin, natijani bir marta o'qing.

10. Mashqlar

Mashqlar kurs/mashqlar/32/16-kanban/ da. 2-mashq yechimi Node 24.21.0 da, 3-mashq yechimi Git Bash'da (GNU bash) tekshirilgan (biz ishga tushirdik).

1-mashq (oson): bo'shliqlarni to'ldiring

• Boshlangan, lekin tugamagan ishlar soni —
• Ish boshlangandan tugaguncha o'tgan vaqt —
• Issue yaratilgandan tugaguncha o'tgan vaqt —
• GitHub Projects'da ustun limitidan oshsa, karta qo'shish taqiqlanadimi? (ha/yo'q) —
• Kanon issue shablonlari yangi issue'ga qo'yadigan holat label'i — holat:

2-mashq (o'rta): issue tarixidan cycle time

oqimniOlch(hodisalar, bugun) funksiyasini yozing. hodisalar — issue tarixi: { vaqt, event, label } (GitHub timeline shakli, qisqartirilgan). Boshlanish — birinchi labeled hodisasi holat: jarayonda bilan, tugash — closed. Natija satr: tugagan bo'lsa cycle time N soat, ochiq bo'lsa yoshi N soat (ochiq), boshlanish yo'q bo'lsa — yopilgan issue uchun boshlanish nuqtasi yo'q, ochiq uchun boshlanmagan. Soat — bir xona aniqlikda. Ma'lumot: #2 va #16 — sinov reposidan haqiqiy, "namuna" — o'quv uchun o'ylab topilgan. Ishora: find — shartga mos birinchi element (HOF metodlari); ikki sana farqi millisekundda (Date asoslari).

const h = (vaqt, event, label) => ({ vaqt, event, label });

function oqimniOlch(hodisalar, bugun) {
  const boshi = hodisalar.find(
    (x) => x.event === "labeled" && x.label === "holat: jarayonda");
  const oxiri = hodisalar.find((x) => x.event === "closed");
  if (!boshi) {
    return oxiri ? "boshlanish nuqtasi yo'q" : "boshlanmagan";
  }
  const soat = (a, b) => (new Date(b) - new Date(a)) / 3_600_000;
  if (oxiri) {
    const c = soat(boshi.vaqt, oxiri.vaqt).toFixed(1);
    return `cycle time ${c} soat`;
  }
  return `yoshi ${soat(boshi.vaqt, bugun).toFixed(1)} soat (ochiq)`;
}

const issue2 = [
  h("2026-11-03T19:18:21Z", "labeled", "holat: tayyor"),
  h("2026-11-04T10:32:33Z", "labeled", "holat: jarayonda"),
  h("2026-11-04T10:32:33Z", "unlabeled", "holat: tayyor"),
];
const namuna = [
  h("2026-11-05T09:00:00Z", "labeled", "holat: jarayonda"),
  h("2026-11-05T15:30:00Z", "labeled", "holat: review"),
  h("2026-11-06T11:00:00Z", "closed"),
];
const issue16 = [
  h("2026-11-04T10:16:14Z", "labeled", "tur: hujjat"),
  h("2026-11-04T10:47:40Z", "closed"),
];
const bugun = "2026-11-06T10:32:33Z";
console.log("#2:", oqimniOlch(issue2, bugun));
console.log("namuna:", oqimniOlch(namuna, bugun));
console.log("#16:", oqimniOlch(issue16, bugun));

#2: yoshi 48.0 soat (ochiq)
namuna: cycle time 26.0 soat
#16: boshlanish nuqtasi yo'q

3-mashq (qiyin): kanon xatosini tuzating

«Kanon xatosi: buzilgan ticket» bo'limidagi skriptni tuzating. Yangi skript:

1. Ikki sub-issue ma'lumotini sub.tsv ga yozadi — ajratuvchi TAB. Birinchisining tanasi | belgisini o'z ichiga oladi: CHECK — faqat {tur: kunlik|haftalik|oylik, kun?}., bog'liqligi bo'sh. Ikkinchisi: API: PATCH takror, 3 SP, Strict sxema, 422 xatolar., bog'liqlik 1, 2.
2. Har qatordan s1.md, s2.md yasaydi: tana, bo'sh qator, Taxmin: N SP. va bog'liqlik bo'lsa — Bog'liq: … -sub-issue. (kanon shakli).
3. Har faylni chiqaradi va tekshiradi: s1.md da kunlik|haftalik|oylik butunligicha bormi (grep -c), "Bog'liq" qaysi faylda.

Ishora: printf '%s\t%s\t%s\t%s\n' … — argumentlar ko'p bo'lsa, format takrorlanadi, ya'ni bitta printf ikki qator yozadi. O'qish: while IFS=$'\t' read -r t sp body dep. GitHub'ga hech narsa yubormang — faqat fayllar.

mkdir -p tanalar && cd tanalar
printf '%s\t%s\t%s\t%s\n' \
  "migratsiya: vazifalar.takror jsonb" 2 \
  "CHECK — faqat {tur: kunlik|haftalik|oylik, kun?}." "" \
  "API: PATCH takror" 3 "Strict sxema, 422 xatolar." "1, 2" \
  > sub.tsv

i=0
while IFS=$'\t' read -r t sp body dep; do
  i=$((i+1))
  bog=""
  [ -n "$dep" ] && bog=" Bog'liq: $dep-sub-issue."
  printf '%s\n\nTaxmin: %s SP.%s\n' "$body" "$sp" "$bog" > "s$i.md"
  echo "--- s$i.md (feat: $t)"
  cat "s$i.md"
done < sub.tsv

echo "--- tekshiruv"
grep -c "kunlik|haftalik|oylik" s1.md
grep "Bog'liq" s*.md

--- s1.md (feat: migratsiya: vazifalar.takror jsonb)
CHECK — faqat {tur: kunlik|haftalik|oylik, kun?}.

Taxmin: 2 SP.
--- s2.md (feat: API: PATCH takror)
Strict sxema, 422 xatolar.

Taxmin: 3 SP. Bog'liq: 1, 2-sub-issue.
--- tekshiruv
1
s2.md:Taxmin: 3 SP. Bog'liq: 1, 2-sub-issue.

11. Real ishda

• Qayerda uchraydi: deyarli har IT jamoada doska bor — Jira, Linear, GitHub Projects, Trello yoki YouTrack. Support va DevOps jamoalari ko'pincha sof Kanban ishlatadi: ish oqimi uzluksiz, sprint ma'nosiz.
• Scrum + Kanban: ko'p jamoalar sprint marosimlarini saqlab, doskada WIP limit qo'yadi. Kanban Guide buni taqiqlamaydi.
• O'lchovlar hisobotlarda: cycle time grafigi va cumulative flow diagram — Jira va boshqa vositalarda tayyor hisobot sifatida bor (sinalmagan, 2026-11).
• Intervyu savollari: "Kanban va Scrum farqi?", "WIP limit nega kerak?", "Lead time va cycle time farqi?", "Yaxshi bug report qanday bo'ladi?"

Xulosa

• Kanban — oqimni ko'rinadigan qilish, WIP'ni nazorat qilish va oqimni yaxshilash; sprint va rollar yo'q.
• Ish oqimi ta'rifi: ish birligi, boshlanish/tugash nuqtasi, holatlar, WIP nazorati, o'tish qoidalari, SLE — kanonda SLE yo'q.
• WIP limit — kelishuv: GitHub Projects ustun limiti faqat ogohlantiradi.
• O'lchovlar: WIP, throughput, ishning yoshi, cycle time; lead time — navbat bilan birga; boshlanish nuqtasisiz cycle time o'lchanmaydi.
• Yaxshi ticket: user story ("… sifatida men … xohlayman, toki …"), Berilgan/Qachonki/Unda mezonlari, takrorlash qadamli bug report.
• Avtomatik yaratilgan ticketni ham o'qing — kanondagi IFS='|' xatosi shuni ko'rsatdi.

Keyingi dars: Estimatsiya va vazifani kichik qismlarga bo'lish — epic'ni 16 story pointga qanday bo'ldik: dekompozitsiya, planning poker, noaniqlik uchun ehtiyot vaqt va "90 % tayyor" tuzog'i.

Manbalar

• The Kanban Guide (v2025.5, 2025-yil may): https://kanbanguides.org/english/ (2026-11-04 da ochib o'qildi)
• GitHub Docs — Customizing the board layout (column limit): https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/customizing-the-board-layout (2026-11-04 da ochib o'qildi)
• GitHub Docs — About Projects: https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects (2026-11-04; Projects kanonda sinalmagan)
• GitHub CLI — gh label create: https://cli.github.com/manual/gh_label_create (2026-11-04)
• GitHub REST API — Timeline events: https://docs.github.com/en/rest/issues/timeline (2026-11-04)
• Little qonuni: https://en.wikipedia.org/wiki/Little%27s_law (2026-11-04)
• Jira: https://www.atlassian.com/software/jira; Linear: https://linear.app/ (2026-11-04 da ochildi; vositalar sinalmagan)
• Kanon tajribasi (IlmHamroh, 2026-11-04): gh 2.92.0; sinov reposida 16 label (gh label list — 26, sukut label'lar bilan), #2 ni jarayonda ga o'tkazish, issue #2 tanasi. Doska so'rovlari, issue tarixlari, token ruxsatlari, IFS takrori, 2- va 3-mashq yechimlari — biz ishga tushirdik (2026-11-04).