Agile va Scrum: sprint, backlog, rollar va marosimlar

Qisqacha: Agile — 2001 yilgi manifestdagi qadriyatlar: ishlaydigan dastur, mijoz bilan hamkorlik, o'zgarishga tayyorlik. Scrum — Agile'ni amalga oshiradigan yengil freymvork: ish bir oydan oshmaydigan sprintlarda qilinadi, uchta mas'uliyat (Product Owner, Scrum Master, Developers), beshta marosim va uchta artefakt bor. Rasmiy manba — Scrum Guide (2020-yil noyabr). Unda story point ham, velocity ham yo'q — ular jamoalar qo'shgan amaliyot. Bu darsda kurs sinov reposidagi haqiqiy backlog'ni (epic va 16 story pointlik 6 ta sub-issue) o'qiymiz va vazifalar-api uchun o'z backlog qoralamangizni yozasiz.

Bu darsda

• Agile manifestining to'rt qadriyatini va Agile bilan Scrum farqini tushuntira olasiz.
• Scrum'ning mas'uliyatlari, marosimlari va artefaktlarini rasmiy matn bo'yicha aytib bera olasiz.
• Velocity bo'yicha prognozni hisoblaysiz va uning chegarasini tushunasiz.
• Scrum'ning buzilgan shakllarini taniysiz.
• vazifalar-api uchun Product Goal, tartiblangan backlog va Sprint Goal qoralamasini yozasiz.

Oldin bilishingiz kerak: Ingliz tilida yozish va gapirish, Jamoada muloqot: sinxron va asinxron, Issues, Projects va shablonlar, GitHub CLI (gh).

1. Nega bu kerak?

Tasavvur qiling: Toshkentdagi bir kompaniya "Bahor" choyxonasi uchun buyurtma tizimi yasamoqchi. Jamoa olti oylik reja tuzdi: avval hamma talablar yoziladi, keyin dizayn, keyin kod, oxirida test. To'rtinchi oyda egasi kelib aytadi: "Endi Click orqali to'lov kerak, bron esa Telegram bot orqali bo'lsin". Reja buzildi. Olti oyda yozilgan kodning yarmi keraksiz bo'lib chiqdi.

Bu — "sharshara" (waterfall) usulining tipik muammosi: hamma narsa oldindan rejalanadi, natija esa eng oxirida ko'rinadi. Xato kech topiladi, o'zgarish qimmatga tushadi.

Boshqa yo'l: har ikki haftada ishlaydigan kichik qism chiqarish. Birinchi ikki haftada — menyu va buyurtma. Egasi uni ko'radi va darhol aytadi: "To'lov kerak". Keyingi ikki hafta — to'lov. O'zgarish erta keladi, arzon tushadi.

Bu g'oya Agile (chaqqon) deyiladi. Scrum esa uni amalga oshirishning eng mashhur usuli.

Hayotiy o'xshatish: uzoq safar. Toshkentdan Samarqandga yo'l oldingiz. Sharshara usuli — xaritaga bir marta qarab, oxirigacha ko'zni yumib haydash. Agile — har 50 km da navigatorga qarash: yo'l yopilgan bo'lsa, burilasiz. Scrum esa aniq qoida beradi: qachon to'xtash, kim navigatorga qaraydi, qanday qaror qilinadi.

2. Agile manifesti

2.1 To'rt qadriyat

2001 yilda 17 dasturchi uchrashib, qisqa matn yozdi — Agile manifesti (agilemanifesto.org, 2026-11-04 da ochib o'qildi). Asosiy qismi to'rt qator:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

O'zbekchasi:

Ko'pincha unutiladigan gap esa eng muhimi. "That is, while there is value in the items on the right, we value the items on the left more." — "O'ngdagilarning ham qiymati bor, lekin chapdagilarni ko'proq qadrlaymiz."

Ya'ni Agile "hujjat yozmaymiz" degani emas. vazifalar-api da README, ARXITEKTURA.md, ADR bor — ular ishlaydigan dasturga xizmat qiladi. Faqat hujjat dasturning o'rnini bosmaydi.

2.2 O'n ikki tamoyil

Manifest ortida 12 ta tamoyil bor (agilemanifesto.org/principles.html, 2026-11-04 da ochib o'qildi). Dasturchi uchun eng amaliylari:

• "Deliver working software frequently, from a couple of weeks to a couple of months" — ishlaydigan dasturni tez-tez, bir necha haftadan bir necha oygacha bo'lgan oraliqda yetkazing.
• "Working software is the primary measure of progress." — taraqqiyotning asosiy o'lchovi — ishlaydigan dastur. "Kodning 80 % yozildi" emas.
• "Welcome changing requirements, even late in development." — talab kech o'zgarsa ham, uni qabul qiling.
• "At regular intervals, the team reflects on how to become more effective…" — jamoa muntazam ravishda o'z ishini tahlil qiladi.
• "Simplicity — the art of maximizing the amount of work not done — is essential." — soddalik: qilinmaydigan ishni ko'paytirish san'ati.

Oxirgisi qiziq: eng yaxshi kod — yozilmagan kod. Keraksiz xususiyatdan voz kechish ham ish.

2.3 Agile — falsafa, Scrum — usul

Agile — qadriyatlar to'plami. U "har kuni 15 daqiqa uchrashing" demaydi. Uni amalga oshiradigan aniq usullar ko'p: Scrum, Kanban (Kanban, vazifa trekerlari va ish oqimi darsi), Extreme Programming (XP). "Biz Agile'miz" degan kompaniyadan doim so'rang: "Aniq qanday ishlaysizlar?"

Tekshirib ko'ring: Jamoa rahbari aytdi: "Biz Agile'miz, shuning uchun hujjat yozmaymiz." Manifestga ko'ra bu to'g'rimi?

3. Scrum: asoslar

3.1 Ta'rif

Scrum'ning yagona rasmiy manbai — Scrum Guide, oxirgi versiyasi 2020-yil noyabrdagi (scrumguides.org, 2026-11-04 da ochib o'qildi). Mualliflari — Ken Schwaber va Jeff Sutherland. Ta'rif:

"Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems."

"Scrum — odamlar, jamoalar va tashkilotlarga murakkab muammolar uchun moslashuvchan yechimlar orqali qiymat yaratishga yordam beradigan yengil freymvork." Kalit so'z — lightweight (yengil): qoidalar kam, qolganini jamoa o'zi tanlaydi.

3.2 Uch ustun va besh qadriyat

Scrum empirizmga tayanadi: bilim tajribadan keladi, qaror — ko'rilgan narsaga qarab. Guide uch ustunni nomlaydi — transparency, inspection, and adaptation:

• Shaffoflik — ish va muammolar hammaga ko'rinadi (issue'lar, doska).
• Tekshiruv — natijaga muntazam qaraladi (sprint oxirida).
• Moslashish — tekshiruvda nimadir noto'g'ri chiqsa, reja o'zgaradi.

Besh qadriyat: Commitment, Focus, Openness, Respect, and Courage — sodiqlik, diqqat, ochiqlik, hurmat va jasorat. Jasorat — masalan, "bu sprintga ulgurmaymiz" deb erta aytish (Ingliz tilida yozish va gapirish darsidagi heads-up).

3.3 Scrum jamoasi

Guide'ga ko'ra Scrum jamoasi odatda 10 yoki undan kam kishidan iborat va uchta mas'uliyat bor: the Developers, the Product Owner, and the Scrum Master.

E'tibor bering: Guide "rol" emas, mas'uliyat (accountability) deydi. Developers — faqat dasturchilar emas: testchi, dizayner ham shu guruhga kiradi. Scrum Master — boshliq emas. Guide aytadi: "Scrum Masters are true leaders who serve the Scrum Team and the larger organization" — jamoaga xizmat qiladigan yetakchi.

4. Artefaktlar va majburiyatlar

Scrum'da uchta artefakt (ish natijasi yoki rejasi) bor. Har biriga bitta majburiyat (commitment) bog'langan — u artefaktning maqsadini aniq qiladi.

4.1 Product Backlog

Backlog (navbatdagi ishlar ro'yxati) — tartiblangan. Eng yuqoridagisi — eng qimmatli va eng aniq. Pastdagilari xira bo'lishi mumkin. Ularni aniqlashtirish — refinement: Guide'ga ko'ra, "the act of breaking down and further defining Product Backlog items into smaller more precise items" — elementlarni kichikroq va aniqroq qismlarga bo'lish. Vazifani qismlarga bo'lishni Estimatsiya va vazifani kichik qismlarga bo'lish darsida batafsil o'rganamiz.

4.2 Sprint Goal

Guide: "The Sprint Goal is the single objective for the Sprint." — sprintning yagona maqsadi. "6 ta issue'ni yopish" — maqsad emas, ro'yxat. Maqsad: "Foydalanuvchi vazifani haftalik takrorlanadigan qila oladi". Issue'lar maqsadga xizmat qiladi. Biri chiqmay qolsa, jamoa maqsadni saqlab, rejani o'zgartiradi.

4.3 Definition of Done

Definition of Done (DoD) — "tayyor" so'zining aniq ta'rifi. Guide: "a formal description of the state of the Increment when it meets the quality measures required for the product" — increment mahsulot sifat talablariga javob berganidagi holatning rasmiy tavsifi.

DoD bo'lmasa, "tayyor" har kimda boshqacha: biri uchun "kod yozildi", boshqasi uchun "testdan o'tdi va hujjatlandi". Kanon epic issue'sidagi DoD (sinov reposidagi issue #1 dan aynan):

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

Uchala shart ham tekshiriladi: test, hujjat, buyruq natijasi. "Men tayyor deb o'ylayman" — DoD emas.

Diqqat: Kanon label'laridan birining tavsifida DoR (Definition of Ready — "boshlashga tayyor" ta'rifi) yozilgan: holat: tayyor — "Backlog: boshlashga tayyor (DoR)". Scrum Guide 2020 da DoR yo'q — faqat Definition of Done bor. Guide faqat "Sprint Planning'da tanlashga tayyor" elementlar haqida gapiradi, ta'rif bermaydi. DoR — ko'p jamoalar qo'shadigan amaliyot. U foydali, lekin "Scrum talab qiladi" deb aytmang.

5. Marosimlar

5.1 Sprint va to'rt marosim

Scrum'da beshta marosim (event) bor. Birinchisi — sprintning o'zi, qolgan to'rttasi uning ichida. Guide bo'yicha vaqt chegaralari (bir oylik sprint uchun; qisqaroq sprintda odatda kamroq):

flowchart LR
  PB["Product Backlog"] --> SP["Sprint Planning"]
  SP --> SB["Sprint Backlog"]
  SB --> D["Daily Scrum<br/>har kuni"]
  D --> I["Increment"]
  I --> R["Sprint Review"]
  R --> RT["Retrospective"]
  RT --> PB

Diagrammaga qarang: bu — aylana. Review natijasi backlog'ni o'zgartiradi, retro esa jamoaning ishlash usulini. Keyin yangi sprint.

5.2 Sprint Planning

Uch savol: nega bu sprint qimmatli (Sprint Goal), backlog'dan nima olinadi va qanday bajariladi. PO maqsadni taklif qiladi, Developers qancha ish sig'ishini aytadi. Natija — Sprint Backlog.

5.3 Daily Scrum

15 daqiqalik kundalik uchrashuv — standup. Uni, uch savolli qolipni va asinxron shaklini Jamoada muloqot darsida o'rgangansiz. Bu yerda Scrum'ga xos bitta gap: "The Developers can select whatever structure and techniques they want" — tuzilmani Developers o'zi tanlaydi, asosiysi — Sprint Goal'ga qanday yaqinlashish. Standup — boshliqqa hisobot emas, jamoaning o'zaro rejalashuvi.

5.4 Sprint Review

Jamoa natijani manfaatdor tomonlarga ko'rsatadi va birga keyingi qadamni muhokama qiladi. Guide: "The Sprint Review is a working session" — bu ishchi uchrashuv, taqdimot emas. Va muhim gap: "The Sprint Review should never be considered a gate to releasing value." Ya'ni reliz review'ni kutmaydi — vazifalar-api GitHub flow'da har merge'dan keyin chiqishi mumkin (Jamoa workflow'lari).

5.5 Sprint Retrospective

Guide: "The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness." — maqsad: sifat va samaradorlikni oshirish yo'llarini rejalash. Oddiy shakli — uch savol: nima yaxshi o'tdi, nima yomon, keyingi sprintda bitta nimani o'zgartiramiz.

vazifalar-api kanonidan haqiqiy retro mavzusi bo'lardi: "Yangi branch'ning birinchi push'i GitHub'da ikki marta Internal Server Error oldi. Harakat: skriptga 3 urinish qo'shamiz." Kanon aynan shunday qildi. Retro'dan chiqqan harakat aniq va tekshiriladigan bo'lsin.

Tekshirib ko'ring: Ikki haftalik sprintning uchinchi kunida mijoz butunlay boshqa xususiyat so'radi. Sprintni kim bekor qila oladi?

6. Story point va velocity

6.1 Ular Guide'da yo'q

Story point (SP) — ishning nisbiy hajmi: murakkablik, hajm va noaniqlik birga. Soat emas. Ko'pincha Fibonachchi qatori bilan: 1, 2, 3, 5, 8. Velocity (tezlik) — jamoa bir sprintda yopgan story pointlar yig'indisi.

Scrum Guide 2020 matnida story point ham, velocity ham uchramaydi. Guide prognoz uchun burn-down, burn-up kabi usullarni tilga oladi, lekin hech birini majburiy qilmaydi. SP va velocity — jamoalar Scrum'ga qo'shgan eng mashhur amaliyot. Ularni qanday baholashni Estimatsiya va vazifani kichik qismlarga bo'lish darsida o'rganamiz.

6.2 Kanon backlog'ini sanaymiz

vazifalar-api ning "takrorlanuvchi vazifalar" epic'i oltita sub-issue'ga bo'lingan. Ularning SP baholari — kanon talab hujjatidan:

Grafikka qarang: eng katta qism — #5 (5 SP). Kanon uni "eng xavfli" deb belgilagan: ikki marta bosilganda bitta nusxa yaratilishi kerak — konkurentlik. Jami SP ni JavaScript bilan hisoblaymiz (reduce):

const backlog = [
  { issue: 2, nom: "migratsiya", sp: 2 },
  { issue: 3, nom: "keyingiMuddat()", sp: 3 },
  { issue: 4, nom: "API: PATCH takror", sp: 3 },
  { issue: 5, nom: "keyingi nusxa", sp: 5 },
  { issue: 6, nom: "o'chirish/tiklash", sp: 2 },
  { issue: 7, nom: "hujjat", sp: 1 },
];
const jami = backlog.reduce((s, b) => s + b.sp, 0);
const eng = backlog.reduce((a, b) => (b.sp > a.sp ? b : a));
console.log("jami SP:", jami);
console.log("eng katta:", `#${eng.issue} ${eng.nom} (${eng.sp})`);

Konsolda:

jami SP: 16
eng katta: #5 keyingi nusxa (5)

16 SP — kanon talab hujjatidagi yig'indi bilan bir xil. Agar jamoa odatda sprintda ~9 SP yopsa, epic taxminan ikki sprint oladi. Buni 2-mashqda hisoblaysiz.

6.3 Velocity — prognoz, maqsad emas

Velocity faqat shu jamoa uchun ma'noli. Bir jamoaning 30 SP si boshqa jamoaning 10 SP sidan "yaxshi" emas — ular boshqa o'lchov birligida o'lchaydi. Rahbar velocity'ni KPI qilib, "keyingi sprintda 20 % ko'proq" desa, nima bo'ladi? Jamoa baholarni shishiradi: 3 SP lik ish 5 bo'ladi. Velocity o'sadi, ish esa o'sha-o'sha. Raqam ma'nosini yo'qotadi.

7. Scrum'ning buzilgan shakllari

Guide qat'iy gapiradi: "The Scrum framework, as outlined herein, is immutable." va "Scrum exists only in its entirety" — Scrum faqat to'liq holida mavjud. Qismini olib, qolganini tashlasangiz, natijani "Scrum" deb atash noto'g'ri. Amalda eng ko'p uchraydigan buzilishlar:

Bunday holatni ba'zan "Scrum-but" deyishadi: "Biz Scrum qilamiz, lekin retro o'tkazmaymiz". Intervyuda "jamoangizda Scrum qanday ishlaydi?" degan savolga shu jadvaldagi belgilarni bilib javob bersangiz, tajribangiz ko'rinadi.

Tekshirib ko'ring: Jamoada daily har kuni 45 daqiqa davom etadi, har kim boshliqqa navbat bilan hisobot beradi. Guide'ning qaysi ikki qoidasi buzilgan?

8. Loyiha qadami: Product Backlog qoralamasi

8.1 Nima rejalaymiz

vazifalar-api uchun keyingi katta xususiyat — takrorlanuvchi vazifalar ("har dushanba hisobot", "har oy elektr to'lovi"). Uni Scrum'cha rejalaymiz:

• epic (bir nechta issue'dan iborat katta ish) — bitta yozuv, DoD bilan;
• epic qismlari — har biriga SP bahosi va bog'liqlik;
• tartib — PO belgilaydi: eng qimmatli va eng aniq — tepada.

Bu darsda GitHub'da hech narsa yaratmaymiz. Avval rejani qog'ozda (Markdown faylda) yozamiz. Label'larni Kanban, vazifa trekerlari va ish oqimi darsida, epic va sub-issue'larni esa Estimatsiya va vazifani kichik qismlarga bo'lish darsida GitHub'da yaratasiz. Shunda har amal o'z mavzusi yonida turadi.

8.2 Kursning sinov reposida shunday ko'rinadi

Oldin natijaga qaraylik. Kanon backlog'ni kurs sinov reposida GitHub issue'lari sifatida qurdi (github.com/Sarvarbek0704/ilmhamroh-git-sinov/issues/1): epic #1 va uning oltita sub-issue'si #2–#7. Epic'ning sub-issue ro'yxati (kanon chiqishi, gh api orqali):

#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}

Scrum ko'zi bilan o'qiymiz:

• Ro'yxat — Product Backlog'ning bir qismi: tartiblangan, har element kichik va aniq.
• sp: N label'lari — story point bahosi; jami 16 SP.
• holat: tayyor — "boshlashga tayyor" belgisi; yuqoridagi DoR ogohlantirishini eslang.
• Epic tavsifida — «Definition of Done» bo'limidagi DoD.

Oxirgi qatorga e'tibor bering: ro'yxatda 6 ta sub-issue, jamlanmada esa "total":5. Kanon jamlanmani 15 soatcha keyin qayta so'radi — "total":6. GitHub jamlanmani fonda, biroz kechikib hisoblaydi (eventual consistency — "oxir-oqibat mos keladigan" holat). Saboq: yangi yaratilgan narsa haqidagi jamlanma raqamiga darhol ishonmang — ro'yxatning o'zini tekshiring.

8.3 O'z backlog qoralamangiz

Endi o'zingiz yozasiz. Repo'ngiz ichida emas, alohida joyda (masalan ~/rejalar/backlog.md) fayl oching — u keyingi ikki darsda issue matniga aylanadi. Namuna — kanon epic va sub-issue'lari asosida:

# Product Goal
vazifalar-api foydalanuvchisi takroriy ishlarni qo'lda yozmaydi.

## Epic: takrorlanuvchi vazifalar
Hikoya: vazifa egasi sifatida men vazifani "har hafta" deb
belgilamoqchiman, toki uni qayta-qayta yozmay.
DoD: hamma sub-issue yopilgan; qabul mezonlari testda o'tadi;
API.md va CHANGELOG yangilangan; npm run check yashil.

## Backlog (tartib — PO)
| # | Qism | SP | Bog'liq |
|---|---|---|---|
| 1 | migratsiya: takror jsonb + CHECK | 2 | — |
| 2 | domen: keyingiMuddat() + testlar | 3 | — |
| 3 | API: PATCH takror, keyingiMuddat | 3 | 1, 2 |
| 4 | bajarilganda keyingi nusxa | 5 | 1, 2 |
| 5 | o'chirish/tiklash qoidasi | 2 | 4 |
| 6 | hujjat: API.md, CHANGELOG | 1 | 3–5 |

## 1-sprint
Sprint Goal: foydalanuvchi API orqali vazifani takrorlanadigan
qila oladi va keyingi muddatni ko'radi.
Tanlandi: 1, 2, 3 (8 SP).

Faylda uchta Scrum artefaktining izi bor: Product Goal (backlog majburiyati), tartiblangan backlog va Sprint Goal. SP baholari hozircha kanondan olingan — ularni qanday topishni Estimatsiya darsida o'rganasiz.

Bu darsda repodagi fayllar o'zgarmaydi. Epic tavsifi havola qiladigan talab hujjatini Mahsulot tafakkuri darsida yozamiz va commit o'sha yerda bo'ladi — hozir commit qilmang.

8.4 Sprint Planning — qog'ozda

Birinchi Sprint Planning qanday o'tardi? Faraz qilaylik, jamoa sprintda ~9 SP yopadi.

• Sprint Goal: "Foydalanuvchi API orqali vazifani takrorlanadigan qila oladi va keyingi muddatni ko'radi."
• Tanlanadi: migratsiya (2), keyingiMuddat() (3), API (3) — jami 8 SP. Kanon issue raqamlarida — #2, #3, #4. Ular maqsadga to'g'ri xizmat qiladi.
• Keyingi sprintga: "keyingi nusxa" (5 SP, eng xavfli), o'chirish/tiklash, hujjat.

Nega "keyingi nusxa" birinchi sprintga kirmadi? U 9 SP ga sig'mas edi, va u migratsiya hamda keyingiMuddat() ga bog'liq. Bog'liqlik va sig'imni hisobga oladigan rejalashni 3-mashqda kod bilan yozasiz.

9. Ko'p uchraydigan xatolar

9.1 "Agile = rejasiz"

Agile rejadan voz kechmaydi — rejani qisqa oraliqda qayta ko'radi. Sprint Planning — reja. Sprint Goal — majburiyat.

9.2 Sprint o'rtasida maqsadni almashtirish

Har kuni yangi "shoshilinch" ish qo'shilsa — sprint ma'nosini yo'qotadi. Yangi ish backlog'ga tushadi, tartibni PO belgilaydi.

9.3 Story point = soat

"3 SP = 3 soat" deb hisoblash SP g'oyasini buzadi. SP — nisbiy: "bu ish anavi 2 SP likdan taxminan ikki barobar murakkab".

9.4 DoD yo'q

Sprint oxirida "deyarli tayyor" ishlar. Davosi — yozma DoD, kanon epic'idagidek: test, hujjat, npm run check.

9.5 Jamlanma raqamiga ishonish

sub_issues_summary kechikadi — «Kursning sinov reposida shunday ko'rinadi» bo'limida ko'rdik. Avtomatlashtirishda ro'yxatni o'zi sanang.

10. Mashqlar

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

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

• Scrum Guide'ga ko'ra sprint uzunligi — bir yoki kamroq
• Daily Scrum davomiyligi (daqiqa) —
• Sprintni bekor qila oladigan yagona mas'uliyat — Product
• Increment'ning majburiyati — Definition of
• Scrum Guide 2020 da uchramaydigan, lekin jamoalar ko'p ishlatadigan tezlik o'lchovi —

2-mashq (o'rta): velocity bo'yicha prognoz

prognoz(bajarilgan, qolganSP) funksiyasini yozing. bajarilgan — oxirgi sprintlarda yopilgan SP lar massivi. Funksiya qaytarsin: ortacha (bir xona aniqlikda), taxmin — o'rtacha tezlik bilan nechta sprint kerak, optimistik — eng tez sprint bilan, pessimistik — eng sekin bilan. Sprint soni butun: Math.ceil. Ishora: yig'indi — reduce; eng katta va kichik — Math.max(...massiv) (spread); bir xona — Number(x.toFixed(1)).

function prognoz(bajarilgan, qolganSP) {
  const ortacha =
    bajarilgan.reduce((s, v) => s + v, 0) / bajarilgan.length;
  const sprint = (v) => Math.ceil(qolganSP / v);
  return {
    ortacha: Number(ortacha.toFixed(1)),
    taxmin: sprint(ortacha),
    optimistik: sprint(Math.max(...bajarilgan)),
    pessimistik: sprint(Math.min(...bajarilgan)),
  };
}

console.log(prognoz([8, 11, 9], 16));
console.log(prognoz([8, 11, 9], 40));
console.log(prognoz([20, 4, 12], 40));

{ ortacha: 9.3, taxmin: 2, optimistik: 2, pessimistik: 2 }
{ ortacha: 9.3, taxmin: 5, optimistik: 4, pessimistik: 5 }
{ ortacha: 12, taxmin: 4, optimistik: 2, pessimistik: 10 }

3-mashq (qiyin): bog'liqlik bilan Sprint Planning

sprintlargaBol(backlog, sigim) funksiyasini yozing. backlog — tartiblangan ro'yxat: { issue, sp, bogliq }, bogliq — oldin tayyor bo'lishi kerak bo'lgan issue raqamlari. Har sprint uchun backlog'ni boshidan o'qing va elementni oling, agar: (1) uning hamma bog'liqliklari oldingi sprintlarda yoki shu sprintda allaqachon olingan bo'lsa va (2) sprintdagi SP yig'indisi sigim dan oshmasa. Sprintga hech narsa sig'masa — { xato: "sig'maydi", qolgan: [issue raqamlari] }. Natija — "#2 #3 = 5 SP" ko'rinishidagi satrlar massivi. Ma'lumot — kanon talab hujjatidagi qismlar jadvali. Ishora: tayyorlarni Set da saqlang; every va some — massiv metodlari (HOF metodlari).

function sprintlargaBol(backlog, sigim) {
  const tayyor = new Set();
  const qolgan = [...backlog];
  const sprintlar = [];
  while (qolgan.length > 0) {
    const sprint = [];
    let sp = 0;
    for (const b of [...qolgan]) {
      const ochiq = b.bogliq.every((d) => tayyor.has(d) ||
        sprint.some((s) => s.issue === d));
      if (ochiq && sp + b.sp <= sigim) {
        sprint.push(b);
        sp += b.sp;
        qolgan.splice(qolgan.indexOf(b), 1);
      }
    }
    if (sprint.length === 0) {
      return {
        xato: "sig'maydi",
        qolgan: qolgan.map((b) => b.issue),
      };
    }
    sprint.forEach((s) => tayyor.add(s.issue));
    sprintlar.push(`${sprint.map((s) => "#" + s.issue).join(" ")}`
      + ` = ${sp} SP`);
  }
  return sprintlar;
}

const backlog = [
  { issue: 2, sp: 2, bogliq: [] },
  { issue: 3, sp: 3, bogliq: [] },
  { issue: 4, sp: 3, bogliq: [2, 3] },
  { issue: 5, sp: 5, bogliq: [2, 3] },
  { issue: 6, sp: 2, bogliq: [5] },
  { issue: 7, sp: 1, bogliq: [4, 5, 6] },
];
console.log(sprintlargaBol(backlog, 9));
console.log(sprintlargaBol(backlog, 6));
console.log(sprintlargaBol(backlog, 4));

[ '#2 #3 #4 = 8 SP', '#5 #6 #7 = 8 SP' ]
[ '#2 #3 = 5 SP', '#4 = 3 SP', '#5 = 5 SP', '#6 #7 = 3 SP' ]
{ xato: "sig'maydi", qolgan: [ 5, 6, 7 ] }

11. Real ishda

• Qayerda uchraydi: Scrum — O'zbekiston va dunyodagi IT kompaniyalarda eng ko'p tilga olinadigan usul. Vakansiyalarda "Agile/Scrum tajribasi" ko'p yoziladi. Ko'p jamoalar esa gibrid ishlaydi: Scrum marosimlari + Kanban doskasi.
• Vositalar: Jira (sprint, backlog, velocity hisobotlari), Linear (cycles), GitHub Projects (iteration maydoni). Keyingi darsda ularni solishtiramiz.
• Sertifikatlar: Scrum.org (PSM), Scrum Alliance (CSM) — Scrum Master va PO uchun. Dasturchiga majburiy emas. Undan foydaliroq ish — Guide'ni bir marta to'liq o'qish: u qisqa va bepul.
• Intervyu savollari: "Scrum'da qanday rollar bor?", "Sprint Review va Retrospective farqi?", "Velocity nima va uni qanday ishlatmaslik kerak?", "Sprint o'rtasida talab o'zgarsa nima qilasiz?"

Xulosa

• Agile — qadriyatlar (2001 manifesti): ishlaydigan dastur, hamkorlik, o'zgarishga javob; o'ngdagilar ham qiymatli.
• Scrum — Agile'ning yengil freymvorki: sprint ≤ 1 oy; PO, Scrum Master, Developers; jamoa odatda ≤ 10 kishi.
• Marosimlar: Sprint Planning, Daily Scrum (15 daqiqa), Sprint Review, Retrospective; artefaktlar — Product Backlog, Sprint Backlog, Increment va ularning majburiyatlari.
• Story point va velocity Scrum Guide'da yo'q — ular prognoz vositasi, KPI emas; prognozni oraliq bilan ayting.
• Backlog avval qog'ozda: Product Goal, tartib, SP, Sprint Goal; kanon backlog'i — epic #1 va 6 sub-issue, jami 16 SP; sub_issues_summary kechikadi — ro'yxatni o'zi tekshiring.

Keyingi dars: Kanban, vazifa trekerlari va ish oqimi — backlog uchun label'larni GitHub'da yaratamiz, holat: label'larini doska ustunlariga aylantiramiz, WIP limit qo'yamiz, cycle time'ni o'lchaymiz va yaxshi ticket yozamiz.

Manbalar

• The Scrum Guide (2020-yil noyabr), Ken Schwaber va Jeff Sutherland: https://scrumguides.org/scrum-guide.html (2026-11-04 da ochib o'qildi)
• Manifesto for Agile Software Development (2001): https://agilemanifesto.org/ (2026-11-04 da ochib o'qildi)
• Principles behind the Agile Manifesto: https://agilemanifesto.org/principles.html (2026-11-04 da ochib o'qildi)
• GitHub Docs — Adding sub-issues: https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/adding-sub-issues (2026-11-04 da ochib o'qildi: bitta ota issue'ga 100 tagacha sub-issue, 8 darajagacha ichma-ich)
• Kanon tajribasi (IlmHamroh, 2026-11-04): gh 2.92.0; sinov reposidagi epic #1 va sub-issue'lar #2–#7, sub_issues_summary 5 → 6. 2- va 3-mashq yechimlari — biz tekshirdik (2026-11-04).