Estimatsiya va vazifani kichik qismlarga bo'lish: story point va planning poker

Qisqacha: Estimatsiya — ish qancha davom etishini oldindan taxmin qilish. U katta ishni kichik qismlarga bo'lishdan boshlanadi: "takrorlanuvchi vazifalar" degan bitta katta ishni hech kim aniq baholay olmaydi, uning oltita kichik qismini esa baholasa bo'ladi. Qismlar soatda emas, nisbiy o'lchovda — story point bilan baholanadi va jamoa ularni planning poker o'yinida kelishib oladi. Kanon tajribasida bitta xususiyat 6 ta issue'ga bo'lindi, jami 16 story point; eng xavfli qism alohida belgilandi va birinchi qilinadigan bo'ldi.

Bu darsda

• Katta ishni mustaqil, tekshiriladigan qismlarga bo'lasiz (dekompozitsiya).
• Story point va soat farqini tushuntirasiz, Fibonachchi shkalasidan foydalanasiz.
• Planning poker raundini o'tkazasiz va kelishmovchilikni to'g'ri o'qiysiz.
• Noaniqlik uchun ehtiyot vaqt qo'yasiz: uch nuqtali baho va kritik yo'l.
• "90 % tayyor" tuzog'ini va muddat bo'yicha muzokarani tushuntirasiz.
• Kurs loyihasidagi epic'ni GitHub'da sub-issue'larga bo'lasiz.

Oldin bilishingiz kerak: Agile va Scrum, Kanban, vazifa trekerlari va ish oqimi, Issues, Projects va shablonlar, GitHub CLI (gh).

1. Nega bu kerak?

Dushanba kuni rahbar so'raydi: "Takrorlanuvchi vazifalar qachon tayyor bo'ladi? 'Har dushanba hisobot' degan vazifa o'zi paydo bo'lsin." Aziz o'ylab ko'radi: bitta ustun qo'shish, bitta funksiya yozish. "Ikki kunda", deydi.

Ikki hafta o'tadi. Ayon bo'ladiki, 31-kunli oylar bor. Fevral 28 yoki 29 kunlik. Foydalanuvchi uch hafta kirmasa, uchta nusxa yaratilmasligi kerak. Tugmani ikki marta bossa — ikkita nusxa chiqmasligi kerak. Bularning har biri test, migratsiya va hujjat talab qiladi. "Ikki kun" va'da bo'lib qolgan edi, endi esa ishonch yo'qolgan.

Aziz yolg'on gapirmadi. U ishni ko'rmasdan baholadi. Bu darsning asosiy g'oyasi shu: vaqtni to'g'ri baholash ishni kichik qismlarga bo'lishdan boshlanadi.

Hayotiy o'xshatish: uy ta'miri. "Oshxonani ta'mirlash qancha turadi?" degan savolga usta darhol javob bermaydi. U ro'yxat tuzadi: eski plitkani olish, devorni tekislash, quvurni almashtirish, yangi plitka. Har bandni alohida baholaydi va "quvur ichida nima chiqishi noma'lum" deb ehtiyot uchun qo'shimcha kun va pul qo'shadi. Dasturchi ham shunday ishlaydi.

2. Estimatsiya nima va nima emas

2.1 Baho, maqsad va va'da

Estimatsiya (estimation) — ishning hajmi yoki davomiyligi haqidagi asosli taxmin. Uni yana ikki narsadan ajrating (Steve McConnell, "Software Estimation", 2006, sinalmagan, 2026-11):

Ko'p janjal shu uchtasini aralashtirishdan chiqadi. Rahbar maqsadni aytadi, dasturchi uni baho deb qabul qiladi va va'da beradi. Aslida tartib boshqacha: avval baho, keyin maqsad bilan solishtirish, farq bo'lsa — muzokara. Muzokarani «Muddat bo'yicha muzokara» bo'limida ko'ramiz.

2.2 Noaniqlik konusi

Ish boshida biz kam narsa bilamiz, shuning uchun baho xato bo'ladi. Talablar aniqlashgan sari xato kichrayadi. Bu manzara noaniqlik konusi (cone of uncertainty) deb ataladi. Dasturlash uchun uni Barry Boehm (1981) chizgan, nomini esa McConnell bergan (1997). Ularga ko'ra g'oya bosqichida haqiqiy hajm bahodan 4 marta kichik yoki 4 marta katta chiqishi mumkin (Wikipedia, "Cone of Uncertainty", 2026-11-04 da o'qildi; kitoblarning o'zi ochilmadi).

Raqamni yodlash shart emas. Xulosa muhim: erta baho — oraliq, bitta raqam emas. "Ikki kun" emas, "2 kundan 2 haftagacha, bo'lishdan keyin aniqroq aytaman". Bunday javob professional eshitiladi, chunki u haqiqatni aytadi.

Tekshirib ko'ring: Rahbar "1-dekabrgacha bo'lishi shart" dedi. Bu baho, maqsad yoki va'dami? Dasturchi birinchi navbatda nima qilishi kerak?

3. Dekompozitsiya — ishni kichik qismlarga bo'lish

3.1 Nega kichik qism yaxshi baholanadi

Dekompozitsiya (decomposition) — katta ishni mustaqil bajariladigan kichik qismlarga bo'lish. Uch sabab bor:

• Ko'rinmagan ish ko'rinadi. "Takrorlanuvchi vazifalar" deganda migratsiya, chekka holatlar, idempotentlik, hujjat ko'rinmaydi. Ro'yxat tuzganda ular chiqadi.
• Xatolar bir-birini qisman yopadi. Bitta katta bahoda xato 100 % gacha bo'lishi mumkin. Oltita kichik bahoda ba'zisi oshadi, ba'zisi kamayadi.
• Taraqqiyot o'lchanadi. "6 tadan 2 tasi yopildi" — aniq. "Taxminan yarmi tayyor" — his.

3.2 Gorizontal va vertikal bo'lish

Bo'lishning ikki yo'li bor. Gorizontal — qatlam bo'yicha: "baza", "backend", "frontend". Vertikal — foydalanuvchi qiymati bo'yicha: "haftalik takrorlash ishlaydi" (baza + API + test birga).

Amalda ikkalasi aralashadi. Kanon rejasida birinchi ikki qism — poydevor (migratsiya va toza funksiya), qolganlari esa ular ustiga qiymat qo'shadi.

3.3 Kanon tajribasi: bitta epic — oltita issue

Kurs loyihasida keyingi xususiyat — takrorlanuvchi vazifalar. Kanon uni epic (bir nechta issue'dan iborat katta ish) sifatida ochdi va oltita qismga bo'ldi. Epic va backlog tushunchalarini Agile va Scrum darsida ko'rgansiz. Bo'lish jadvali (kanon talab hujjatidan):

Jadvalni o'qiymiz. Har qator — bitta PR'ga sig'adigan ish. "Bog'liq" ustuni qaysi ishni qaysi biridan keyin boshlash mumkinligini aytadi. SP — story point, uni keyingi bo'limda tushuntiramiz.

Bog'liqliklarni diagrammada ko'rish osonroq. Qalin chegarali tugunlar — eng uzun zanjir:

flowchart LR
  I1["1 migratsiya · 2"] --> I3["3 API · 3"]
  I2["2 keyingiMuddat · 3"] --> I3
  I1 --> I4["4 keyingi nusxa · 5"]
  I2 --> I4
  I4 --> I5["5 o'chirish · 2"]
  I3 --> I6["6 hujjat · 1"]
  I4 --> I6
  I5 --> I6
  classDef kritik stroke-width:3px
  class I2,I4,I5,I6 kritik

Diagrammaga qarang: 1 va 2 bir vaqtda boshlanishi mumkin — ular hech kimga bog'liq emas. 4-issue esa ikkalasini kutadi. 6-issue hammaning oxirida. Ikki dasturchi bo'lsa, biri migratsiyani, ikkinchisi funksiyani oladi.

Kanon jadvali ostida yana ikki gap bor. Birinchisi: "4-issue (konkurentlik) — eng xavfli, birinchi spike sifatida". Spike — javobi noma'lum savolni o'rganish uchun qisqa, vaqti cheklangan tajriba: kod emas, bilim beradi. Ikki marta bosilganda ikkita nusxa chiqmasligini qanday ta'minlash — bu loyihada ilgari hal qilinmagan savol. Uni birinchi o'rganish butun rejani himoya qiladi. Ikkinchi gap — "90 % tayyor" haqida, uni alohida bo'limda ko'ramiz.

3.4 Qism qachon yetarlicha kichik

Yaxshi qism uchun mashhur tekshiruv ro'yxati — INVEST (Bill Wake, 2003; agilealliance.org, 2026-11-04): mustaqil (Independent), muhokamaga ochiq (Negotiable), qiymatli (Valuable), baholanadigan (Estimable), kichik (Small), tekshiriladigan (Testable). Dasturchi uchun eng amaliy ikkitasi:

• Kichik: bitta odam 1–3 kunda tugatadi, PR'i Yaxshi PR tayyorlash darsidagi hajmga sig'adi.
• Tekshiriladigan: "qachon tayyor" savoliga testli javob bor. "Kodni yaxshilash" — tekshirilmaydi. "31-kun → oy oxiri, test bilan" — tekshiriladi.

Qism baholanmasa — demak, u hali yetarlicha tushunilmagan. Davo — spike yoki yana bo'lish.

Tekshirib ko'ring: "Backend qismi" degan issue 13 SP olgan. Undagi ish: migratsiya, API, testlar. INVEST bo'yicha qaysi harflar buzilgan va nima qilish kerak?

4. Story point va soat

4.1 Nisbiy o'lcham

Story point (SP) ning qisqa ta'rifini Agile va Scrum darsida ko'rgansiz: ishning nisbiy hajmi — murakkablik, ish miqdori va noaniqlik birga. Endi uni amalda ishlatamiz. Savol "bu necha soat?" emas, "bu o'sha ishdan necha barobar katta?".

O'xshatish: bozorda tarvuzlarni tarozisiz tanlash. Qaysi biri og'irroq ekanini qo'lda ancha aniq sezasiz, lekin "4.3 kilogramm" deb aytish qiyin. Odam nisbatni mutlaq raqamdan yaxshiroq baholaydi.

Amalda jamoa bitta tanish ishni etalon qiladi: "kanon loyihasidagi hujjat yangilash — 1 SP". Keyin har yangi ishni shu bilan solishtiradi. keyingiMuddat() — etalondan uch barobar ko'p ish va chekka holatlar ko'p — 3 SP.

4.2 Fibonachchi shkalasi

Story point odatda Fibonachchi ketma-ketligiga o'xshash shkalada beriladi: 1, 2, 3, 5, 8, 13. Nega 4 yoki 7 yo'q? Chunki katta ishda bunday aniqlik — o'z-o'zini aldash. 7 va 8 ni farqlay olmaysiz, 5 va 8 ni esa farqlaysiz. Shkala katta ishda noaniqlik katta ekanini o'zi ko'rsatadi.

Ko'p jamoalarda qoida bor: 8 va undan katta baho — "bo'lish kerak" degan signal. Kanon rejasidagi eng katta qism — 5 SP.

Rejani kod bilan tekshiramiz: jami SP, shkalada yo'q baho va bo'linishi kerak bo'lgan katta qismlar.

const SHKALA = [1, 2, 3, 5, 8, 13];

function rejaniTekshir(issuelar) {
  const jami = issuelar.reduce((s, i) => s + i.sp, 0);
  const izohlar = [];
  for (const i of issuelar) {
    if (!SHKALA.includes(i.sp)) {
      izohlar.push(`${i.nom}: ${i.sp} shkalada yo'q`);
    }
    if (i.sp >= 8) {
      izohlar.push(`${i.nom}: ${i.sp} SP — bo'ling`);
    }
  }
  return { jami, izohlar };
}

const kanon = [
  { nom: "migratsiya", sp: 2 },
  { nom: "keyingiMuddat()", sp: 3 },
  { nom: "API: PATCH takror", sp: 3 },
  { nom: "keyingi nusxa", sp: 5 },
  { nom: "o'chirish/tiklash", sp: 2 },
  { nom: "hujjat", sp: 1 },
];
const qoralama = [
  { nom: "takrorlanuvchi vazifalar", sp: 13 },
  { nom: "testlar", sp: 4 },
];
console.log(rejaniTekshir(kanon));
console.log(rejaniTekshir(qoralama));

Konsolda:

{ jami: 16, izohlar: [] }
{
  jami: 17,
  izohlar: [
    "takrorlanuvchi vazifalar: 13 SP — bo'ling",
    "testlar: 4 shkalada yo'q"
  ]
}

Kanon rejasi — 16 SP, izoh yo'q. "Qoralama" — ishni bo'lmasdan baholashga urinish: bitta 13 SP'lik ulkan qism va shkaladan tashqari "4". Yana bir narsaga e'tibor bering: "testlar" alohida qism bo'lib qolgan. Bu gorizontal bo'lish belgisi — test har qismning ichida bo'lishi kerak. Satrda apostrof bor, shuning uchun Node uni qo'shtirnoqda chiqardi.

Kanon rejasidagi baholarni ustunlarda solishtiramiz:

Eng baland ustun — eng ko'p noaniqlik. Reja aynan shundan boshlanadi.

4.3 SP soatga aylanmaydi

Eng ko'p uchraydigan nosozlik: "1 SP = 4 soat" deb jadval tuzish. Shu zahoti SP soatning boshqa nomiga aylanadi va nisbiy o'lchovning foydasi yo'qoladi. Yana yomoni — jamoalarni SP bo'yicha solishtirish. Bir jamoaning 5 SP'si boshqasining 13 SP'si bo'lishi mumkin. Bu normal, chunki etalon har jamoada o'zi.

SP vaqtga faqat o'tmish orqali bog'lanadi: jamoa oldingi sprintlarda o'rtacha nechta SP tugatgani — velocity. Uni Agile va Scrum darsida ko'rgansiz. Masalan, jamoa sprintiga 20 SP sig'sa, 16 SP'lik epic bitta sprintga sig'ishi mumkin. Lekin kritik yo'lni ham hisobga oling — buni pastda ko'ramiz.

Tekshirib ko'ring: Aziz jamoasida etalon ish 1 SP. Nodira boshqa jamoadan keldi va "bizda shu ish 3 SP edi" deydi. Kim haq?

5. Planning poker

5.1 Qoidalar

Bitta odam baholasa, uning ko'r nuqtalari bahoga kiradi. Planning poker — jamoa birga baholaydigan usul. Tartib (mountaingoatsoftware.com, 2026-11-04):

1. Mahsulot egasi qismni o'qiydi, jamoa savol beradi.
2. Har kim kartani yashirincha tanlaydi: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. Yana "?" — "tushunmadim", cheksizlik — "bu juda katta", qahva — "tanaffus".
3. Hamma kartalar bir vaqtda ochiladi.
4. Baholar farq qilsa, avval eng past va eng yuqori baho bergan odam gapiradi.
5. Muhokamadan keyin qayta ovoz. Yetarli umumiy tushuncha bo'lganda baho yoziladi.

Nega bir vaqtda ochiladi? Agar tajribali dasturchi birinchi bo'lib "3" desa, qolganlar ham 3 atrofida aytadi. Bu langar effekti: birinchi eshitilgan raqam boshqalarning fikrini o'ziga tortadi. Yashirin ovoz har kimning haqiqiy fikrini chiqaradi.

5.2 Kelishmovchilik — ma'lumot

Manba ta'kidlaydi: kelishmovchilikni yo'qotiladigan muammo deb emas, ma'lumot deb qabul qiling. O'rtachani darhol olish ham noto'g'ri — u odamlar nega har xil o'ylaganini yashiradi.

Misol. 4-issue ("keyingi nusxa") ovozga qo'yildi. Aziz — 2, Nodira — 8, Sardor — 3. Aziz tushuntiradi: "bitta INSERT qo'shiladi". Nodira tushuntiradi: "ikki marta bosilsa ikkita nusxa chiqadi. Parallel so'rovlar testi kerak, hodisa va outbox bir tranzaksiyada bo'lishi kerak". Aziz buni o'ylamagan edi. Ikkinchi raundda — 5, 5, 5. Nodiraning bilimi butun jamoaga o'tdi. Bu — planning poker'ning asosiy foydasi, raqamning o'zi emas.

To'liq bir xil raqam shart emas — baho qaysi qaror uchun kerak bo'lsa, shunga yetarli kelishuv bo'lsa bas. Manbaga ko'ra uch raunddan ko'p ketsa, bu odatda qism aniqlashtirish, yana bo'lish yoki mahsulot egasining qarorini kutayotganini bildiradi. Majburlab qo'yilgan raqam foyda bermaydi.

Maslahat: Masofadan ishlaydigan jamoalar planning poker'ni onlayn vositalarda yoki oddiy chatda o'tkazadi: har kim raqamni shaxsiy xabarda yuboradi, hamma yuborgach bittasi e'lon qiladi. Asosiy shart — kartalar bir vaqtda ochilsin.

6. Noaniqlik uchun ehtiyot vaqt

6.1 Uch nuqtali baho

Bitta raqam noaniqlikni yashiradi. Uch nuqtali baho (three-point estimate) uni ochiq ko'rsatadi. Har qism uchun uch raqam so'raladi:

• o — optimistik: hammasi omadli ketsa;
• m — eng ehtimoliy;
• p — pessimistik: bilgan xavflar ro'y bersa.

PERT usulida baho (o + 4m + p) / 6, noaniqlik o'lchovi (p − o) / 6. Bu yerda soat yoki kun ishlatiladi — kunlik reja uchun. Misolni kanon rejasidagi ikki qismga qo'llaymiz. Kunlardagi raqamlar — bizning misolimiz, kanon faqat SP bilan baholagan.

function uchNuqtali(o, m, p) {
  return {
    baho: +((o + 4 * m + p) / 6).toFixed(1),
    sigma: +((p - o) / 6).toFixed(1),
  };
}
console.log("keyingi nusxa:", uchNuqtali(1, 2, 6));
console.log("hujjat:", uchNuqtali(0.5, 0.5, 1));

Konsolda:

keyingi nusxa: { baho: 2.5, sigma: 0.8 }
hujjat: { baho: 0.6, sigma: 0.1 }

"Keyingi nusxa"da eng ehtimoliy baho 2 kun. Lekin pessimistik 6 kun bo'lgani uchun PERT bahosi 2.5 kunga chiqdi. Noaniqlik esa hujjatnikidan o'n barobar katta: p − o — 5 kun va 0.5 kun (yaxlitlangan 0.8 va 0.1 bu farqni biroz kichraytirib ko'rsatadi). Bu raqam spike'ni qaysi qismga qilish kerakligini aytadi. toFixed(1) satr qaytaradi, oldidagi + uni yana songa aylantiradi.

6.2 Kritik yo'l

Jami 16 SP — ishning hajmi. Lekin muddatni hajmdan tashqari bog'liqliklar ham belgilaydi. Diagrammadagi qalin zanjir — 2 → 4 → 5 → 6, jami 11 SP. Bu kritik yo'l: undagi har bir kechikish butun epic'ni kechiktiradi.

Amaliy xulosa: o'nta dasturchi bo'lsa ham, epic 11 SP'dan tez tugamaydi. 4-issue 2-issue'ni kutadi, 5-issue esa 4-issue'ni. Odam qo'shish faqat kritik yo'ldan tashqaridagi ishlarni tezlashtiradi. Kritik yo'lni kod bilan topishni 3-mashqda qilasiz.

6.3 Ehtiyot vaqtni qayerga qo'yish

Ehtiyot vaqt (buffer) — noaniqlik uchun bahoga ataylab qo'shilgan vaqt. Xuddi yo'lga chiqishdan oldin "tiqin bo'lsa" deb 15 daqiqa erta chiqishdek. Ehtiyot vaqt har qismga yashirincha qo'shilsa, u "Parkinson qonuni" bo'yicha yeyiladi: ish unga berilgan vaqtni to'ldiradi. Yaxshiroq usul — uni ochiq va bitta joyda saqlash:

• qismlar baholanadi, ustiga umumiy ehtiyot vaqt yoziladi: "11 SP kritik yo'l + noaniq 4-issue uchun bitta spike";
• spike natijasidan keyin baho yangilanadi va rahbarga aytiladi;
• reja qismlarida "Must" va "Could" ajratiladi — vaqt yetmasa, nimadan voz kechish oldindan ma'lum. Buni Mahsulot tafakkuri darsida MoSCoW bilan qilamiz.

Tekshirib ko'ring: Rahbar "ikki dasturchi qo'shaman, epic ikki barobar tez tugaydi" dedi. Kanon rejasi bo'yicha bu to'g'rimi?

7. "90 % tayyor" tuzog'i

Dasturchidan so'raysiz: "Qalay?" — "90 % tayyor". Bir haftadan keyin ham — "90 %". Ikki haftadan keyin ham. Tanishmi?

Dasturchilar orasida eski hazil bor: kodning birinchi 90 % i vaqtning 90 % ini oladi. Qolgan 10 % i esa yana 90 % ini oladi (Tom Cargill, Bell Labs; Jon Bentley'ning 1985-yil sentabrdagi "Programming Pearls" rukni orqali mashhur bo'lgan; Wikipedia, 2026-11-04). Sabab — "oxirgi 10 %" ichida eng og'ir ishlar yashiringan: chekka holatlar, testlar, review izohlari, migratsiya, hujjat.

Davo — foizni emas, holatni o'lchash. Kanon talab hujjatida qoida aynan shunday yozilgan:

"90 % tayyor" tuzog'i: issue faqat qabul mezonlari testda o'tganda
yopiladi, "kod yozildi" — tayyor emas.

Epic'ning tayyorlik ta'rifi (Definition of Done) ham issue tanasida yozildi:

**Tayyor (DoD):** hamma sub-issue yopilgan; qabul mezonlari testda
o'tadi; API.md va CHANGELOG yangilangan; `npm run check` yashil.

(Ikkala parcha telefon uchun ikki qatorga bo'lindi, matn aynan.) Endi "qalay?" savoliga javob — "6 tadan 2 tasi yopildi, 4-issue review'da". Bu ikkilik holatlar: issue yo yopilgan, yo yo'q. Yarim yopilgan issue bo'lmaydi.

Shu sababli qismlar kichik bo'lishi kerak. 13 SP'lik bitta issue uch hafta "jarayonda" turadi va holati faqat foizda aytiladi. Oltita kichik issue esa har ikki-uch kunda bittadan yopiladi.

8. Muddat bo'yicha muzokara

8.1 Uch dastak

Baho maqsadga sig'madi: bahoingiz 16 SP, ya'ni taxminan ikki sprint, rahbarga esa bir sprintda kerak. Nima qilish mumkin? Uchta dastak bor:

• Doira (scope): kamroq qilish. Masalan, faqat kunlik va haftalik takror, oylik keyinroq.
• Vaqt: muddatni surish.
• Odamlar: qo'shish — kritik yo'l tufayli cheklangan foyda beradi.

To'rtinchi "dastak" ham bor, lekin u taqiqlangan: sifat. "Testlarni keyin yozamiz" — bu muddatni qarzga olish. Qarz albatta qaytadi, foizi bilan.

flowchart TD
  B["Baho: 16 SP"] --> S{"Maqsadga sig'adimi?"}
  S -->|ha| V["Va'da"]
  S -->|yo'q| D["Doirani qisqartirish"]
  S -->|yo'q| M["Muddatni surish"]
  S -->|yo'q| Q["Sifatdan voz kechish"]
  D --> V
  M --> V
  Q -.->|taqiq| X["Texnik qarz"]

Diagrammadagi uzuq chiziq — o'tmaslik kerak bo'lgan yo'l.

8.2 "Yo'q" demasdan "yo'q" deyish

Muzokarada "yo'q, bo'lmaydi" deyish suhbatni yopadi. Variantlar berish uni ochadi. Aziz shunday javob berishi mumkin:

"Bahom — 16 story point, bu bizning tezligimizda ikki sprint. Bir sprintga sig'dirishning ikki yo'li bor. Birinchisi: kunlik va haftalik takrorni beramiz, oylik keyingi sprintda. Ikkinchisi: hammasini beramiz, lekin 15-dekabrda. Testsiz chiqarishni taklif qilmayman — ikki marta yaratilgan nusxalar foydalanuvchi ma'lumotini buzadi. Qaysi biri sizga muhimroq?"

Bu javobda to'rt narsa bor: baho asosi bilan, ikki variant, nega uchinchisi yo'qligi va tanlovni biznesga qaytarish. Rahbar ham doira, ham muddat haqida qaror qabul qiladigan odam — dasturchi esa ularning narxini aytadigan odam.

Diqqat: Yomon yangilikni erta ayting. Spike 4-issue 5 SP emas, 8 SP ekanini ko'rsatsa — shu kuni ayting, sprint oxirida emas. Jamoada muloqot darsidagi "yomon xabar erta" qoidasi estimatsiyada eng ko'p ishlaydi.

9. Loyiha qadami: epic'ni sub-issue'larga bo'lish

Bu darsda loyiha kodi o'zgarmaydi — ish GitHub'da: epic issue va oltita sub-issue. Talab hujjatini keyingi darsda yozamiz va commit ham o'sha yerda bo'ladi. Hozircha commit qilmang.

9.1 Epic va sub-issue'lar

Sub-issue — GitHub'da issue ichidagi kichik issue. Ota issue tavsifi ostida bolalari ro'yxati turadi. GitHub hujjatiga ko'ra bitta ota issue'ga 100 tagacha sub-issue qo'shiladi, ichma-ich daraja esa 8 tagacha (docs.github.com, "Adding sub-issues", 2026-11-04). "Nechtasi yopilgan" jamlanmasini kanon API orqali o'qidi — pastda ko'rasiz. Brauzerda ham qo'shsa bo'ladi, biz esa gh bilan qilamiz.

tur: epic, sp: 2 kabi label'lar Kanban darsida yaratilgan. Ularni qayta yaratmaymiz — epic va sub-issue'lar esa aynan shu darsning ishi. Kanon buyruqlari (repo nomi login/vazifalar-api ga almashtirildi, bitta uzun buyruq qatorlarga bo'lindi):

R=login/vazifalar-api
gh issue create -R $R --title "epic: takrorlanuvchi vazifalar" \
  --body-file epic.md --label "tur: epic" \
  --label "ustuvorlik: o'rta" --label "holat: tayyor"

https://github.com/login/vazifalar-api/issues/1

Epic tanasida — hikoya, talab hujjatiga havola, "jami 16 SP" va tayyorlik ta'rifi. Keyin har qism uchun alohida issue. Birinchisi:

T="feat: migratsiya: vazifalar.takror jsonb + CHECK (expand)"
gh issue create -R $R --title "$T" --body-file s1.md \
  --label "tur: xususiyat" --label "sp: 2" --label "holat: tayyor"

https://github.com/login/vazifalar-api/issues/2

Qolgan beshtasi ham shunday — #3 dan #7 gacha, har biri o'z sp: label'i bilan. "Expand" so'zi Zero-downtime: expand-contract darsidan: avval ixtiyoriy ustun qo'shiladi, eski kod buzilmaydi.

9.2 Issue'ni epic'ga ulash: raqam emas, id

Endi oltita issue epic'ning bolasi bo'lishi kerak. Buning uchun GitHub REST API'da sub-issues endpoint'i bor. Kanon buyrug'i:

id=$(gh api repos/$R/issues/2 --jq .id)
gh api -X POST repos/$R/issues/1/sub_issues \
  -F sub_issue_id=$id --jq '.number'

1

Ikkinchi qatorga e'tibor bering. API issue raqamini (2) emas, uning ichki id sini so'raydi. Ikkalasi har xil narsa: raqam — repo ichidagi tartib (#2), id — GitHub bo'ylab yagona katta son. Javobdagi 1 — ota issue raqami: endpoint yangilangan epic'ni qaytardi. Biz kurs sinov reposidan faqat o'qib tekshirdik (2026-11-04):

gh api repos/$R/issues/2 --jq '"number=\(.number) id=\(.id)"'
gh api repos/$R/issues/2/parent --jq '"parent: #\(.number) \(.title)"'

number=2 id=6189525139
parent: #1 epic: takrorlanuvchi vazifalar

9.3 Natija va jamlanma

Oltita ulashdan keyin kanon epic'ni tekshirdi. Ro'yxat to'liq chiqdi, lekin jamlanma boshqacha:

#2 feat: migratsiya: vazifalar.takror jsonb + CHECK (expand) [tur: xususiyat, holat: tayyor, sp: 2]
#3 feat: domen: keyingiMuddat() — toza funksiya va chekka holat testlari [tur: xususiyat, holat: tayyor, sp: 3]
#4 feat: API: PATCH takror (Zod) va javobda keyingiMuddat; OpenAPI surati [tur: xususiyat, holat: tayyor, sp: 3]
#5 feat: bajarilganda keyingi nusxa — tranzaksiyada, idempotent [tur: xususiyat, holat: tayyor, sp: 5]
#6 feat: o'chirish/tiklash qoidasi va hodisalar [tur: xususiyat, holat: tayyor, sp: 2]
#7 feat: hujjat: API.md va CHANGELOG [tur: xususiyat, holat: tayyor, sp: 1]
{"completed":0,"percent_completed":0,"total":5}

Ro'yxatda 6 ta issue, total esa 5 — bu kechikishni Agile va Scrum darsida ko'rgansiz: 15 soatcha keyin "total":6 qaytdi. Bunday xulq eventual consistency (oxir-oqibat izchillik) deyiladi: hisoblagich alohida, kechikib yangilanadi. Saboq o'sha: skriptda ro'yxatni o'zingiz sanang.

Story point'larni ham label'lardan yig'ish mumkin. Biz kurs sinov reposida qayta yurgizdik (2026-11-04, faqat o'qish):

gh api repos/$R/issues/1/sub_issues --jq '[.[].labels[].name
  | select(startswith("sp: ")) | ltrimstr("sp: ")
  | tonumber] | add'

16

Talab hujjatidagi 16 SP bilan bir xil — reja va treker bir-biriga mos.

Kanondagi #2 tanasi | ajratgichi tufayli buzilganini Kanban darsida ko'rgansiz. Saboq: issue'lar ommaviy yaratilganda, birortasini brauzerda ochib tekshiring.

Maslahat: Kurs sinov reposida epic'ni oching — github.com/Sarvarbek0704/ilmhamroh-git-sinov/issues/1. Sub-issue'lar ro'yxati va progress satri u yerda ko'rinadi. Repo arxivda — faqat o'qish uchun.

GitHub Projects'da raqamli maxsus maydon (number field) qo'shib, story point'ni unda ham yuritsa bo'ladi — hujjat aynan "vazifa murakkabligi uchun raqamli maydon" misolini beradi (docs.github.com, "About Projects", 2026-11-04). Kanonda Projects sinalmagan — sinov tokenida project ruxsati yo'q edi. Label usuli istalgan repoda ishlaydi.

10. Ko'p uchraydigan xatolar

10.1 Bahoni va'da deb qabul qilish

"Ikki kun dedingiz-ku!" Davosi: bahoni doim oraliq bilan ayting va shartini qo'shing — "bo'lgandan keyin aniqlashtiraman".

10.2 SP'ni soatga aylantirish

"1 SP = 4 soat" jadvali paydo bo'lsa, SP o'z ma'nosini yo'qotadi. Davosi: soat kerak bo'lsa, uch nuqtali bahoni alohida yuriting.

10.3 O'rtachani olish

Ovozlar 2, 8, 3 — "o'rtacha 4.3, demak 5". Nodiraning bilimi muhokamasiz yo'qoldi. Davosi: avval eng past va eng yuqori ovoz egasi gapiradi.

10.4 Faqat "baxtli yo'l"ni baholash

Chekka holatlar, testlar, review, hujjat baholanmagan. Davosi: tayyorlik ta'rifini bahodan oldin o'qing — baho DoD'gacha bo'lgan hamma ishni qamrab olsin.

10.5 sub_issue_id ga issue raqami

API raqamni emas, id ni kutadi. Davosi: avval gh api repos/$R/issues/N --jq .id bilan id ni oling — kanon skripti aynan shunday qildi.

10.6 Spike'ning vaqti cheklanmagan

"Konkurentlikni o'rganib chiqaman" — va bir hafta o'tdi. Davosi: spike'ga aniq vaqt qo'ying (masalan, yarim kun) va natijasini yozma qayd qiling: savol, topilgan javob, yangilangan baho.

11. Mashqlar

Mashqlar kurs/mashqlar/32/17-estimatsiya/ da. 2- va 3-mashq yechimlari Node 24.21.0 da tekshirilgan (biz ishga tushirdik).

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

• Katta ishni kichik, mustaqil qismlarga bo'lish —
• Story point shkalasida 5 dan keyingi qiymat —
• Planning poker'da kartalar qanday ochiladi? Hammasi bir
• Javobi noma'lum savol uchun vaqti cheklangan tajriba —
• Kanon rejasidagi kritik yo'l uzunligi, SP'da —

2-mashq (o'rta): planning poker raundi

raundniBaholash(ovozlar) funksiyasini yozing. ovozlar — obyekt: kalit — ism, qiymat — karta (1, 2, 3, 5, 8, 13 yoki "?"). Qoidalar (bizning jamoa kelishuvimiz):

• kimdir "?" bersa — "savol bor: <ismlar> — avval tushuntiring";
• eng past va eng yuqori karta shkalada qo'shni yoki teng bo'lsa — "kelishildi: <eng yuqori> SP";
• aks holda — "muhokama: <past ism> (<karta>) va <yuqori ism> (<karta>)".

Ishora: Object.entries obyektni [ism, karta] juftlariga aylantiradi (Object.* metodlari); kartalarni shkaladagi o'rni bo'yicha solishtiring — SHKALA.indexOf(karta).

const SHKALA = [1, 2, 3, 5, 8, 13];

function raundniBaholash(ovozlar) {
  const juftlar = Object.entries(ovozlar);
  if (juftlar.some(([, k]) => k === "?")) {
    const kim = juftlar.filter(([, k]) => k === "?").map(([i]) => i);
    return `savol bor: ${kim.join(", ")} — avval tushuntiring`;
  }
  const tartib = juftlar.sort(
    (a, b) => SHKALA.indexOf(a[1]) - SHKALA.indexOf(b[1]),
  );
  const [pastIsm, past] = tartib[0];
  const [yuqoriIsm, yuqori] = tartib[tartib.length - 1];
  const oraliq = SHKALA.indexOf(yuqori) - SHKALA.indexOf(past);
  if (oraliq <= 1) return `kelishildi: ${yuqori} SP`;
  return `muhokama: ${pastIsm} (${past}) va ${yuqoriIsm} (${yuqori})`;
}

console.log(raundniBaholash({ Aziz: 3, Nodira: 3, Sardor: 3 }));
console.log(raundniBaholash({ Aziz: 3, Nodira: 5, Sardor: 3 }));
console.log(raundniBaholash({ Aziz: 2, Nodira: 8, Sardor: 3 }));
console.log(raundniBaholash({ Aziz: 5, Nodira: "?", Sardor: 5 }));

kelishildi: 3 SP
kelishildi: 5 SP
muhokama: Aziz (2) va Nodira (8)
savol bor: Nodira — avval tushuntiring

3-mashq (qiyin): kritik yo'lni toping

kritikYol(issuelar) funksiyasini yozing. Har issue — { n, sp, bogliq }, bogliq — oldin tugashi kerak bo'lgan issue raqamlari. Funksiya SP bo'yicha eng uzun zanjirni qaytarsin: { yol: [raqamlar], sp }. Kanon rejasi bilan sinang va jami hajm, kritik yo'l hamda "ikki dasturchi bilan kamida necha SP" ni chiqaring — bu kritik yo'l va yarim hajmning kattasi.

Ishora: har issue uchun "shu issue bilan tugaydigan eng uzun zanjir" = uning SP'si + bog'liqlari orasidagi eng uzun zanjir. Natijani Map da eslab qoling, aks holda bir zanjir ko'p marta hisoblanadi (Map). Funksiya o'zini chaqiradi — rekursiya.

function kritikYol(issuelar) {
  const xarita = new Map(issuelar.map((i) => [i.n, i]));
  const eslab = new Map();

  function engUzun(n) {
    if (eslab.has(n)) return eslab.get(n);
    const i = xarita.get(n);
    let oldingi = { yol: [], sp: 0 };
    for (const b of i.bogliq) {
      const t = engUzun(b);
      if (t.sp > oldingi.sp) oldingi = t;
    }
    const natija = {
      yol: [...oldingi.yol, n],
      sp: oldingi.sp + i.sp,
    };
    eslab.set(n, natija);
    return natija;
  }

  let eng = { yol: [], sp: 0 };
  for (const i of issuelar) {
    const t = engUzun(i.n);
    if (t.sp > eng.sp) eng = t;
  }
  return eng;
}

const reja = [
  { n: 1, sp: 2, bogliq: [] },
  { n: 2, sp: 3, bogliq: [] },
  { n: 3, sp: 3, bogliq: [1, 2] },
  { n: 4, sp: 5, bogliq: [1, 2] },
  { n: 5, sp: 2, bogliq: [4] },
  { n: 6, sp: 1, bogliq: [3, 4, 5] },
];
const jami = reja.reduce((s, i) => s + i.sp, 0);
const { yol, sp } = kritikYol(reja);
console.log(`jami: ${jami} SP`);
console.log(`kritik yo'l: ${yol.join(" → ")} (${sp} SP)`);
console.log(`ikki dasturchi: kamida ${Math.max(sp, jami / 2)} SP`);

jami: 16 SP
kritik yo'l: 2 → 4 → 5 → 6 (11 SP)
ikki dasturchi: kamida 11 SP

12. Real ishda

• Qayerda uchraydi: sprint rejalash, backlog'ni aniqlashtirish (refinement), har "qachon tayyor?" savoli. Trekerlarda baho uchun maydon bor yoki qo'shiladi.
• #NoEstimates: ba'zi jamoalar baholamaydi — ishni bir xil kichik o'lchamga bo'lib, sonini sanaydi. Bu ham dekompozitsiyaga tayanadi.
• Kattaroq ishlar: kvartal rejasida "futbolka o'lchami" (S, M, L, XL) ishlatiladi — story point'dan ham qo'polroq, lekin tezroq.
• Intervyu savollari: "Vazifani qanday baholaysiz?", "Story point nima, nega soat emas?", "Bahongizdan oshib ketsangiz nima qilasiz?", "Rahbar imkonsiz muddat qo'ysa-chi?"

Xulosa

• Baho, maqsad va va'da — uch xil narsa; erta baho — oraliq, bitta raqam emas.
• Estimatsiya dekompozitsiyadan boshlanadi: kichik, mustaqil, tekshiriladigan qismlar.
• Story point — jamoa ichidagi nisbiy o'lcham; 8 va undan kattasi — bo'lish signali.
• Planning poker: kartalar bir vaqtda ochiladi, kelishmovchilik — ma'lumot.
• Muddatni kritik yo'l belgilaydi: kanon rejasi 16 SP, kritik yo'l 11 SP.
• "90 % tayyor" yo'q: issue qabul mezonlari testda o'tganda yopiladi.

Keyingi dars: Mahsulot tafakkuri: talablarni tushunish — bugungi oltita issue qayerdan kelganini ko'ramiz: muammo, foydalanuvchi hikoyalari, qabul mezonlari va MoSCoW. Talab hujjatini yozib, commit qilamiz.

Manbalar

• Mountain Goat Software — Planning Poker: https://www.mountaingoatsoftware.com/agile/planning-poker (2026-11-04)
• Agile Alliance — INVEST: https://www.agilealliance.org/glossary/invest/ (2026-11-04)
• GitHub Docs — Adding sub-issues: https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/adding-sub-issues (2026-11-04)
• GitHub Docs — REST API endpoints for sub-issues: https://docs.github.com/en/rest/issues/sub-issues (2026-11-04)
• GitHub Docs — About Projects: https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects (2026-11-04)
• Wikipedia — Cone of Uncertainty: https://en.wikipedia.org/wiki/Cone_of_Uncertainty (2026-11-04)
• Steve McConnell — Software Estimation: Demystifying the Black Art (Microsoft Press, 2006): baho, maqsad va va'da (kitob ochilmadi, 2026-11)
• Wikipedia — Ninety–ninety rule (Tom Cargill; Jon Bentley, Programming Pearls, Communications of the ACM, 1985-sentabr): https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule (2026-11-04)
• Kanon tajribasi (IlmHamroh, 2026-11-04): gh 2.92.0; talab hujjati, epic #1 va sub-issue'lar #2–#7 (kurs sinov reposi). Sub-issue'lar, SP yig'indisi va id chiqishlari, JS bloklar va mashq yechimlari — biz ishga tushirdik (2026-11-04).