Mahsulot tafakkuri: talablarni tushunish — user story, qabul mezonlari, MVP va MoSCoW

Qisqacha: Kod — maqsad emas, foydalanuvchi muammosini hal qilish vositasi. Mahsulot tafakkuri — kod yozishdan oldin "nega?" deb so'rash: qaysi muammo, kim uchun, qanday bilamizki hal bo'ldi. Javoblar talab hujjatiga yoziladi: muammo, foydalanuvchi hikoyalari (user story), tekshiriladigan qabul mezonlari, oldindan aytilgan chekka holatlar, ustuvorlik (MoSCoW) va muvaffaqiyat o'lchovi. Kanon tajribasida bitta shunday hujjat oltita issue'ni tug'dirdi va PR #18 bilan loyihaga kirdi.

Bu darsda

• So'rovdagi yechimni emas, muammoni topasiz: "nega?" deb so'rash.
• Foydalanuvchi hikoyasini va Berilgan / Qachonki / Unda qabul mezonlarini yozasiz.
• Chekka holatlarni oldindan topasiz va mezonni testga aylantirasiz.
• MVP'ni MoSCoW bilan ajratasiz va muvaffaqiyat hamda qarshi metrikani tanlaysiz.
• Kurs loyihasiga talab hujjatini qo'shib, PR ochasiz.

Oldin bilishingiz kerak: Estimatsiya va vazifani kichik qismlarga bo'lish, Agile va Scrum, Kanban, vazifa trekerlari va ish oqimi, Yaxshi PR tayyorlash.

1. Nega bu kerak?

Oldingi darsda takrorlanuvchi vazifalarni oltita qismga bo'ldik va 16 story point deb baholadik. Lekin bir savol berilmadi: bu xususiyat umuman kerakmi?

Tasavvur qiling: jamoa ikki sprint ishladi. Takrorlash tayyor, testlar yashil, CHANGELOG yozilgan. Bir oydan keyin analitika ko'rsatadi: faol foydalanuvchilarning juda kichik qismi xususiyatni yoqqan. Ish yaxshi qilingan, lekin noto'g'ri ish qilingan.

Bunday holat kamdan-kam emas. Sabab — so'rov yechim shaklida keladi: "takrorlash tugmasini qo'shing". Dasturchi tugmani qo'shadi. Hech kim so'ramaydi: "Qaysi muammo? Uni qanchasi boshdan kechiradi? Hal bo'lganini qanday bilamiz?"

Mahsulot tafakkuri (product thinking) — shu savollarni kod yozishdan oldin berish odati. U faqat mahsulot menejerining ishi emas. Dasturchi talab ichidagi qarama-qarshilikni, yetishmagan chekka holatni va arzonroq yechimni birinchi bo'lib ko'radi. Chunki u tizimni ichidan biladi.

Hayotiy o'xshatish: shifokor. Bemor keladi: "Menga antibiotik yozing". Yaxshi shifokor darhol yozmaydi. U so'raydi: "Nima bezovta qilyapti? Qachondan beri?" Bemor yechimni aytdi, shifokor esa muammoni qidiradi. Ba'zan dori umuman kerak emas bo'lib chiqadi.

2. "Nega?" deb so'rash

2.1 Yechim va muammo

So'rovni ikki qismga ajrating:

Muammo topilgach, yechim bir nechta bo'lishi mumkin: takrorlash, vazifadan nusxa olish tugmasi, shablonlar. Eng arzon va to'g'ri yechimni endi tanlasa bo'ladi.

2.2 Besh marta "nega"

Ildiz sababni topishning sodda usuli — ketma-ket "nega?" deb so'rash. Odatda besh savol yetadi (Toyota ishlab chiqarish tizimidan kelgan usul, sinalmagan, 2026-11). Misol:

1. Nega takrorlash kerak? — Foydalanuvchi bir xil vazifani qayta yozadi.
2. Nega qayta yozadi? — Hisobot har hafta kerak, eskisi bajarilgan bo'lib qolgan.
3. Nega eskisidan foydalanmaydi? — Bajarilgan vazifani qayta ochib bo'lmaydi.
4. Nega bu yomon? — Unutadi: ro'yxatda dushanba hisoboti yo'q.
5. Nega unutish muhim? — Ro'yxatga ishonch yo'qoladi va u ilovani tashlaydi.

Beshinchi javob — asl muammo: ro'yxatga ishonch. Endi "qabul mezoni" ham aniqroq: vazifa o'zi, o'z vaqtida va bitta nusxada paydo bo'lishi kerak.

Usulning cheklovi ham bor: u bitta zanjir beradi, haqiqatda esa sabablar ko'p bo'lishi mumkin. Shuning uchun "nega" — suhbat boshlash vositasi, isbot emas.

2.3 Taxminni o'lchashga aylantirish

Kanon talab hujjati muammodan boshlanadi va bir muhim gapni ochiq yozadi (telefon uchun qatorlar bo'lindi, matn aynan):

Taxmin: faol foydalanuvchilarning sezilarli qismi buni qiladi.
**Bu raqam hali o'lchanmagan** — birinchi qadam: `vazifa_hodisalari`
dan bir xil matnli `yaratildi` hodisalari 7/30 kun oralig'ida
takrorlanishini sanash (SQL so'rovi 4-bo'limda). Raqam kichik
chiqsa — xususiyat qilinmaydi.

Uch narsaga e'tibor bering. "Sezilarli qism" — taxmin ekani yashirilmagan. Birinchi ish — kod emas, o'lchov. Va eng muhimi — to'xtash sharti: raqam kichik chiqsa, xususiyat qilinmaydi. Bu jumla 16 SP'lik ishni bekorga qilishdan saqlashi mumkin.

Diqqat — biz shunday xato qildik: kanon hujjati o'zi bilan zid chiqdi. Muammo bo'limida o'lchov vazifa_hodisalari dan qilinadi deyilgan. Chekka holatlar bo'limida esa tan olingan: hodisalar jadvalida vazifa matni yo'q — bu 31-qismdagi qaror edi. O'lchovni vazifalar jadvalidan qilish kerak, bu esa maxfiylik savolini ochadi. Hujjat ikkala gapni ham qoldirdi — birinchi bo'lim tuzatilmadi. Saboq: hujjatni oxirigacha yozgach, boshini qayta o'qing. O'lchov rejasini esa sxemaga qarab tekshiring.

Tekshirib ko'ring: Rahbar: "Eksport tugmasini PDF formatida qo'shing". Muammoni topish uchun qanday ikkita savol berasiz?

3. Foydalanuvchi hikoyasi

3.1 Shakl

Foydalanuvchi hikoyasi (user story) — talabni foydalanuvchi tilida yozishning qisqa shakli:

<kim> sifatida men <nima> qilmoqchiman, toki <nega>.

Har qismning vazifasi bor. "Kim" — kimning muammosi ekanini eslatadi. "Nima" — imkoniyat, lekin texnik yechim emas. "Toki" — eng muhim qism: qiymat. "Toki" yozilmasa, hikoya oddiy buyruqqa aylanadi.

Kanon hujjatidagi uch hikoya:

1. Vazifa egasi sifatida men vazifani "har hafta dushanba" deb
   belgilamoqchiman, toki uni har safar qayta yozmay.
2. Vazifa egasi sifatida men takrorlanuvchi vazifani bajarganimda
   keyingisi o'zi paydo bo'lishini xohlayman, toki ro'yxatim doim
   to'g'ri tursin.
3. Vazifa egasi sifatida men takrorlashni to'xtatmoqchiman, eski
   bajarilganlar esa tarixda qolsin.

Uchinchi hikoyada "toki" o'rniga "esa" turibdi — qiymat ochiq aytilmagan, lekin sharti aniq: tarix saqlansin. Bunday kichik farqlar review'da tuzatiladi.

3.2 Hikoya — suhbatga taklif

Hikoya to'liq spetsifikatsiya emas. U suhbat uchun eslatma: kim, nima va nega haqida kelishib olish uchun. Tafsilot keyingi bo'limdagi qabul mezonlarida bo'ladi. Oldingi darsdagi INVEST ro'yxatini eslang: yaxshi hikoya "muhokamaga ochiq" (Negotiable) bo'ladi.

Agile Alliance bu suhbatni "uch do'st" (three amigos) amaliyoti deb ataydi: biznes (qaysi muammo), dasturlash (qanday quriladi) va test (nima buzilishi mumkin) nuqtai nazarlari ishni birga ko'rib chiqadi (agilealliance.org, 2026-11-04). Kichik jamoada uch rolni ikki odam ham bajarishi mumkin — muhimi, uch savol berilsin.

Tekshirib ko'ring: "Dasturchi sifatida men vazifalar jadvaliga takror jsonb ustunini qo'shmoqchiman." Bu hikoyaning nimasi yomon?

4. Qabul mezonlari

4.1 Berilgan / Qachonki / Unda

Hikoya "nima va nega" ni aytadi. Qabul mezonlari (acceptance criteria) — "qachon tayyor?" savoliga tekshiriladigan javob. Ommabop shakli uch qadamdan iborat. Inglizchada Given / When / Then — Cucumber vositasining Gherkin tilidan (cucumber.io, 2026-11-04):

• Berilgan (Given) — boshlang'ich holat;
• Qachonki (When) — hodisa yoki foydalanuvchi harakati;
• Unda (Then) — kutilgan, kuzatiladigan natija.

Gherkin 70 dan ortiq tilga tarjima qilingan, lekin jamoalar odatda bitta tilni tanlaydi. Kanon hujjati o'zbekcha so'zlarni ishlatdi. Birinchi hikoya uchun mezon (qatorlar bo'lindi, matn aynan):

- **1-hikoya:** Berilgan — "Hisobot" vazifasi; qachonki
  `PATCH /v1/vazifalar/:id` ga `takror: { tur: "haftalik", kun: 1 }`
  yuborsam; unda javobda `takror` maydoni va `keyingiMuddat`
  (Asia/Tashkent bo'yicha keyingi dushanba 00:00) bor.
- **2-hikoya:** 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.

Ikkinchi mezondagi qavs ichidagi gapga qarang: "ikki marta bosilsa ham — bitta". Bu — Idempotency-Key darsidagi g'oya, endi talab tilida. Oldingi darsda aynan shu gap 4-issue'ni eng xavfli va 5 SP qildi. Mezon bahoga to'g'ridan-to'g'ri ta'sir qiladi.

4.2 Mezondan testga

Yaxshi mezonni deyarli so'zma-so'z testga aylantirish mumkin. Birinchi mezondagi "Asia/Tashkent bo'yicha keyingi dushanba 00:00" ni olamiz. Bu kanon kodi emas — 3-issue hali ochiq. Bu bizning misolimiz: mezon kodda qanday ko'rinishini ko'rsatadi.

Toshkent — UTC+5, yozgi vaqt yo'q, shuning uchun siljish doimiy. Funksiya siljish parametrini oladi: to'g'ri chaqiruvda — Toshkent, solishtirish uchun — 0 (UTC). Uch holatni sinaymiz:

const SOAT = 60 * 60 * 1000;
const TOSHKENT = 5 * SOAT; // UTC+5, yozgi vaqt yo'q

function keyingiDushanba(hozir, siljish) {
  const m = new Date(hozir.getTime() + siljish);
  const kun = m.getUTCDay(); // 0 — yakshanba, 1 — dushanba
  const qadam = (8 - kun) % 7 || 7;
  const tun = Date.UTC(
    m.getUTCFullYear(), m.getUTCMonth(), m.getUTCDate() + qadam,
  );
  return new Date(tun - siljish);
}

const toshkentda = (d) =>
  new Date(d.getTime() + TOSHKENT).toISOString().slice(0, 16);

const holatlar = [
  "2026-11-04T10:00:00+05:00", // chorshanba
  "2026-11-09T00:00:00+05:00", // dushanba, yarim tun
  "2026-11-09T03:00:00+05:00", // dushanba tongi
];
for (const h of holatlar) {
  const hozir = new Date(h);
  const togri = toshkentda(keyingiDushanba(hozir, TOSHKENT));
  const utc = toshkentda(keyingiDushanba(hozir, 0));
  console.log(h.slice(0, 16), "→", togri, "| UTC bilan:", utc);
}

Konsolda:

2026-11-04T10:00 → 2026-11-09T00:00 | UTC bilan: 2026-11-09T05:00
2026-11-09T00:00 → 2026-11-16T00:00 | UTC bilan: 2026-11-09T05:00
2026-11-09T03:00 → 2026-11-16T00:00 | UTC bilan: 2026-11-09T05:00

Chiqishni qatorma-qator o'qiymiz:

• Chorshanba: to'g'ri javob — dushanba 00:00. UTC versiyasi esa dushanba 05:00 deydi: UTC yarim tuni Toshkentda ertalab beshda. Mezon "00:00" degan — UTC versiyasi mezondan o'tmaydi.
• Dushanba yarim tun: biz "keyingi" so'zini "bugun emas, keyingi hafta" deb o'qidik — 16-noyabr. Bu talqin. Mezon buni aytmaydi — hujjatga qo'shilishi kerak bo'lgan savol.
• Dushanba tongi: eng xavfli holat. UTC bo'yicha hali yakshanba, shuning uchun UTC versiyasi "keyingi dushanba — bugun 05:00" deydi, ya'ni ikki soatdan keyin. Foydalanuvchi uchun bu xato: vazifa shu kunning o'zida yana paydo bo'ladi.

Kodning ikki qatorini tushuntiramiz. (8 - kun) % 7 || 7 — dushanbagacha necha kun qolgani; dushanbaning o'zida 0 chiqadi va || uni 7 ga almashtiradi. Date.UTC oy oxirini o'zi hal qiladi: 30-noyabrga 2 kun qo'shilsa — 2-dekabr. Sana va mintaqa mavzusi Intl.DateTimeFormat darsida chuqurroq.

Saboq: bitta jumladagi "Asia/Tashkent bo'yicha" ikki so'zi uchta test holatini tug'dirdi va bitta ochiq savolni ko'rsatdi. Mezon qanchalik aniq bo'lsa, kod shunchalik kam taxmin qiladi.

5. Chekka holatlarni oldindan aytish

5.1 Kanon ro'yxati

Chekka holat (edge case) — odatiy yo'ldan chetdagi, kamdan-kam, lekin haqiqiy vaziyat. Ularni kod yozilgandan keyin emas, oldin topish arzon. Kanon hujjatidagi ro'yxat:

- Oyning 31-kuni → 30 kunlik oyda oxirgi kun; 29-fevral — kabisa
  bo'lmagan yilda 28-fevral.
- Foydalanuvchi muddatdan bir necha marta o'tib ketgan (3 hafta
  kirmagan) — 3 ta nusxa emas, **bitta** (keyingi muddat bugundan
  hisoblanadi).
- Vazifa o'chirilsa (yumshoq) — takrorlash ham to'xtaydi; tiklansa —
  qayta yoqilmaydi (aniq qaror).
- Vaqt mintaqasi: muddat foydalanuvchi mintaqasida, bazada —
  `timestamptz`.

Uchinchi bandga qarang: "tiklansa — qayta yoqilmaydi (aniq qaror)". Bu texnik fakt emas, mahsulot qarori. Ikkala variant ham mantiqiy edi. Muhimi — qaror yozildi va 5-issue'ga o'tdi. Yozilmagan bo'lsa, dasturchi uni kod ichida jimgina o'zi qabul qilardi.

5.2 Chekka holatlarni qanday qidirish

Har talabni quyidagi savollar bilan "silkiting":

Yana ikki yo'nalish bor: huquq (boshqa foydalanuvchining vazifasi) va hajm (10 000 ta takrorlanuvchi vazifa). Kanon ikkinchisini "doiradan tashqarida" bo'limida yopdi: boshqa foydalanuvchiga takroriy vazifa — hozir yo'q.

Hujjat bo'limlari va ulardan nima chiqqanini bitta rasmda ko'ramiz:

flowchart TD
  M["Muammo va o'lchov"] --> H["Hikoyalar"]
  H --> Q["Qabul mezonlari"]
  Q --> C["Chekka holatlar"]
  C --> W["MoSCoW: MVP"]
  W --> B["6 issue, 16 SP"]
  Q --> T["Testlar"]
  C --> T
  B --> P["PR'lar"]
  T --> P

Diagrammaga qarang: mezon va chekka holatlar ikki joyga oqadi — issue'larga ham, testlarga ham. Hujjat — kod uchun ham, test uchun ham manba.

6. MVP va MoSCoW

6.1 MVP

MVP (minimum viable product) — eng kichik ishlaydigan mahsulot: haqiqiy foydalanuvchiga berib, taxminni tekshirish mumkin bo'lgan eng kam narsa. G'oya Eric Ries'ning "The Lean Startup" kitobi orqali keng tarqalgan (2011, sinalmagan, 2026-11).

MVP — "yomon qilingan mahsulot" emas. Bu — tor, lekin to'liq qilingan mahsulot. O'xshatish: yangi oshxona butun menyuni emas, uchta taomni ochadi. Uchala taom esa haqiqiy, issiq va mazali. Mijozlar kelsa — menyu kengayadi.

6.2 MoSCoW

Nimani MVP'ga olishni qanday hal qilish kerak? Mashhur usullardan biri — MoSCoW. DSDM loyiha freymvorkidan (agilebusiness.org, 2026-11-04):

• Must — kafolatlangan eng kichik to'plam: bularsiz yechim ma'nosiz;
• Should — muhim, lekin hayotiy emas: tushirib qoldirsa og'riydi, ammo ishlaydi;
• Could — istalgan, ta'siri kichikroq: vaqt yetmasa, birinchi bo'lib shu tushadi;
• Won't (this time) — shu safar qilinmaydi, deb kelishilgan.

Kanon hujjatidagi jadval:

Ostida bir qator: "MVP — faqat Must. Should — birinchi fikr-mulohazadan keyin." RRULE — kalendar dasturlaridagi takrorlash qoidalari standarti: "har oyning ikkinchi seshanbasi" kabi murakkab qoidalar. To'liq RRULE — alohida katta ish. Uni Won't'ga yozish keyingi muhokamalarni tejaydi: kimdir "Google Calendar'dagidek qilaylik" desa, javob tayyor.

6.3 Must qancha bo'lishi kerak

DSDM manbasi muhim chegarani aytadi: Must ishi odatda umumiy ishning 60 % idan oshmasin. Qolgan 40 % — Should va Could — ehtiyot qism (contingency) vazifasini bajaradi: rejadagi, lekin kerak bo'lsa tushirib qoldiriladigan ish. Asosiy ehtiyot — Could; manba unga taxminan 20 % ni tavsiya qiladi. Vaqt yetmasa, Could tushadi, va'da esa buzilmaydi.

Bu — oldingi darsdagi «Muddat bo'yicha muzokara» bo'limidagi "doira" dastagining amaliy ko'rinishi. Must 100 % bo'lsa, birinchi kechikishning o'zida va'da buziladi. Buni 2-mashqda hisoblaysiz.

Tekshirib ko'ring: Rahbar MoSCoW jadvaliga qarab: "Hammasi muhim, hammasini Must qiling" dedi. Nima deysiz?

7. Muvaffaqiyatni qanday bilamiz

Xususiyat chiqdi. U ishladimi? "Testlar yashil" — bu kod ishlaganini aytadi, muammo hal bo'lganini emas. Talab hujjatida o'lchov oldindan yoziladi:

- Takrorlanuvchi vazifa qo'ygan faol foydalanuvchilar ulushi
  (30 kun); qo'lda takror yozilgan vazifalar soni kamayishi
  (1-bo'limdagi so'rov bilan, oldin/keyin).
- Qarshi metrika: noto'g'ri yaratilgan nusxalar (bir muddatga 2 ta)
  — 0 bo'lishi kerak (alert).

Ikki xil metrikaga e'tibor bering:

• Muvaffaqiyat metrikasi — muammo kamayganini ko'rsatadi: qo'lda takror yozish kamaydimi? "Oldin/keyin" degan so'z muhim: o'lchov xususiyatdan oldin boshlanishi kerak. Aks holda solishtiradigan narsa bo'lmaydi.
• Qarshi metrika (counter-metric) — yaxshilanish boshqa joyni buzmayaptimi? Bu yerda — ikki marta yaratilgan nusxalar. Ular 0 bo'lishi kerak va oshsa, darhol signal (alert) beriladi.

Qarshi metrika nega kerak? Bitta raqamga qaralsa, uni "yaxshilash" oson. Masalan, takrorlanuvchi vazifalar ulushi ortishi mumkin, chunki xato tufayli nusxalar ko'payyapti. Ikkinchi raqam birinchisini halol tutadi. Metrikalarni yig'ish texnikasi — Observability va Analitika darslarida.

8. Doiradan tashqarida

Hujjatning oxirgi bo'limi qisqa, lekin juda foydali:

Frontend o'zgarishlari (alohida epic), push eslatmalar, jamoaviy
(38-qism `jamoa`) vazifalar.

"Nima qilmaymiz" ro'yxati uch narsani beradi. Review'da "push eslatma qani?" degan savolga javob tayyor. Doira jimgina kengaymaydi: har yangi "kichik qo'shimcha" alohida qaror talab qiladi. Va kelajak ishlar unutilmaydi — ular yozilgan, faqat hozir emas.

9. Loyiha qadami: talab hujjati va PR

9.1 Hujjat tuzilmasi

Kurs loyihasiga yangi fayl qo'shiladi: docs/talablar/takrorlanuvchi-vazifalar.md. Uning bo'limlari — shu darsning tartibi:

Davomi:

Hujjat boshidagi sarlavha qismi (kanon faylidan, qatorlar bo'lindi, matn aynan):

# Talab hujjati: takrorlanuvchi vazifalar

- **Holat:** muhokamada · **Muallif:** mahsulot + backend ·
  **Sana:** 2026-11-04
- **Bog'liq issue:** epic "Takrorlanuvchi vazifalar"
  (sinov repo, `tur: epic`)

"Holat: muhokamada" — hujjat tirik: qabul qilinsa, "qabul qilingan" bo'ladi. To'liq faylni kurs sinov reposida o'qing: github.com/Sarvarbek0704/ilmhamroh-git-sinov, vazifalar-api/docs/talablar/ papkasi. Oldingi darsdagi qismlar jadvali shu hujjatning "qismlar va baho" bo'limiga kiradi. Bitta farq bor: kanon bu bo'limni "Bo'laklash" deb nomlagan, biz kursda bu so'zni faqat ma'lumotlar bazasi sharding'i uchun ishlatamiz. O'z faylingizda "Qismlar va baho" deb yozing.

9.2 Branch, commit, PR

Jamoa workflow'lari darsidagi GitHub flow bo'yicha:

git switch main
git pull
git switch -c docs/talab-takrorlanuvchi
git add docs/talablar/takrorlanuvchi-vazifalar.md
git commit -m "docs: takrorlanuvchi vazifalar — talab hujjati"
git push -u origin docs/talab-takrorlanuvchi

Kanonda birinchi push GitHub tomonida yiqildi (kanon chiqishidan, faqat natija qatori):

 ! [remote rejected] docs/talab-takrorlanuvchi -> docs/talab-takrorlanuvchi (Internal Server Error)

"Masofaviy server rad etdi: ichki server xatosi." Bu sizning xatongiz emas, GitHub'ning vaqtinchalik nosozligi. 9 soniyadan keyin xuddi shu buyruq o'tdi:

 * [new branch]      docs/talab-takrorlanuvchi -> docs/talab-takrorlanuvchi

Jamoa workflow'lari darsidagi qoida shu yerda ham ishladi: xato kelsa, holatni tekshirib, qayta urining.

PR tavsifi — Yaxshi PR tayyorlash darsidagi shablon bo'yicha. Kanon tavsifining "Nega" va "Qanday tekshirildi" qismlari:

## Nega

Epic #1 va sub-issue'lar (#2–#7) shu hujjatdan. Kod yozishdan oldin
"nega" va "qachon tayyor" kelishib olinadi.

Refs #1

## Qanday tekshirildi

- [x] `npm run check` yashil (faqat hujjat)
- 1-bo'limdagi "takror yoziladigan vazifalar ulushi" raqami
  O'LCHANMAGAN — hujjatda shunday deyilgan; birinchi ish — o'lchov.

Refs #1 ga e'tibor bering — Closes #1 emas. Issues darsidan bilasiz: Closes PR merge bo'lganda issue'ni yopadi. Epic esa hujjat bilan tugamaydi — oltita sub-issue hali ochiq. Refs faqat bog'laydi.

"Qanday tekshirildi" da ham o'lchanmagan raqam yana bir bor aytilgan. Review qiluvchi buni birinchi qatorda ko'radi.

gh pr create --base main --head docs/talab-takrorlanuvchi \
  --title "docs: takrorlanuvchi vazifalar — talab hujjati" \
  --body-file pr.md
gh pr merge docs/talab-takrorlanuvchi --squash --delete-branch

Kanonda bu PR #18 bo'ldi va squash bilan qo'shildi:

#18 MERGED ca2a135

Hash sizda boshqacha bo'ladi. Hujjat o'zgarishi kodga tegmasa ham, kanon bosqich tekshiruvini yurgizdi: tip, lint, build — 0, Vitest — 346 ta o'tdi, 1 ta o'tkazib yuborildi. Hujjat PR'i ham main ni buzmasligi kerak — masalan, nisbiy havola buzilsa.

9.3 Kanban: ish boshlandi

Hujjat qabul qilingach, birinchi qism ishga olinadi. Kanon #2 ni "tayyor" ustunidan "jarayonda" ga o'tkazdi:

gh issue edit 2 --remove-label "holat: tayyor" \
  --add-label "holat: jarayonda"

Kanban darsidagi WIP chegarasi (2) shu yerda ishlay boshlaydi. Endi jamlanma ham to'g'ri — "total":6.

10. Ko'p uchraydigan xatolar

10.1 Yechimni talab deb yozish

"Takror jsonb ustuni qo'shilsin" — bu talab emas, yechim. Davosi: hujjatning birinchi bo'limi doim muammo va kimning muammosi.

10.2 Tekshirib bo'lmaydigan mezon

"Takrorlash qulay bo'lsin" — test yozib bo'lmaydi. Davosi: Berilgan / Qachonki / Unda shaklida aniq kirish va aniq natija.

10.3 Chekka holatlar kodda "o'zi hal bo'ladi"

O'chirilgan vazifa tiklansa nima bo'ladi — dasturchi buni kod ichida jimgina tanlaydi. Davosi: mahsulot qarorini hujjatga yozing.

10.4 O'lchovsiz chiqarish

Xususiyat chiqdi, lekin "oldin" raqami yo'q — muvaffaqiyatni isbotlab bo'lmaydi. Davosi: o'lchovni xususiyatdan oldin boshlang.

10.5 Hujjat o'zi bilan zid

Kanon xatosi: muammo bo'limida bir jadval, chekka holatlar bo'limida boshqa jadval. Davosi: yozib bo'lgach hujjatni boshidan qayta o'qing, o'lchov so'rovini haqiqiy sxemaga qarab tekshiring.

10.6 Epic'ni Closes bilan yopib qo'yish

Hujjat PR'iga Closes #1 yozilsa, merge'da epic yopiladi, oltita sub-issue esa ochiq qoladi. Davosi: hujjat va qism PR'larida — Refs, faqat oxirgi qism PR'ida o'z sub-issue'si uchun Closes.

11. Mashqlar

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

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

• Hikoyaning qiymatni aytadigan qismi qaysi so'z bilan boshlanadi? —
• Qabul mezonida boshlang'ich holat —
• DSDM bo'yicha Must ishi odatda necha foizdan oshmasin? —
• Yaxshilanish boshqa joyni buzmayotganini kuzatadigan metrika —
• Epic'ni yopmasdan PR'ni bog'laydigan kalit so'z —

2-mashq (o'rta): MVP'ning ehtiyot qismi bormi

mvpniTekshir(talablar, chegara = 60) funksiyasini yozing. talablar — { nom, tur, sp } obyektlari, tur — "Must", "Should", "Could" yoki "Won't". Funksiya "Must <m> / <jami> SP = <foiz> % — <xulosa>" satrini qaytarsin; xulosa — foiz chegaradan oshmasa "ehtiyot bor", oshsa "xavfli". Foizni Math.round bilan butun qiling. SP'lar — bizning misolimiz, kanon MoSCoW jadvaliga baho qo'ymagan. Ikki holatni sinang: Won't'siz to'liq reja va faqat dastlabki to'rt talab.

Ishora: filter va reduce (Massiv metodlari); Won't dagi apostrof tufayli satrni qo'shtirnoqqa oling.

function mvpniTekshir(talablar, chegara = 60) {
  const jami = talablar.reduce((s, t) => s + t.sp, 0);
  const must = talablar
    .filter((t) => t.tur === "Must")
    .reduce((s, t) => s + t.sp, 0);
  const ulush = Math.round((must / jami) * 100);
  const xulosa = ulush <= chegara ? "ehtiyot bor" : "xavfli";
  return `Must ${must} / ${jami} SP = ${ulush} % — ${xulosa}`;
}

const reja = [
  { nom: "kunlik / haftalik / oylik", tur: "Must", sp: 5 },
  { nom: "bajarilganda keyingisi", tur: "Must", sp: 5 },
  { nom: "to'xtatish", tur: "Must", sp: 2 },
  { nom: "har 2 haftada", tur: "Should", sp: 3 },
  { nom: "frontendda belgi", tur: "Should", sp: 2 },
  { nom: "ish kunlari", tur: "Could", sp: 3 },
  { nom: "RRULE to'liq", tur: "Won't", sp: 13 },
];
console.log(mvpniTekshir(reja.filter((t) => t.tur !== "Won't")));
console.log(mvpniTekshir(reja.slice(0, 4)));

Must 12 / 20 SP = 60 % — ehtiyot bor
Must 12 / 15 SP = 80 % — xavfli

3-mashq (qiyin): oylik takror — mezondan testga

oylikKeyingi(bugun, kun) funksiyasini yozing. bugun — { yil, oy, kun } (oy 1 dan 12 gacha), kun — takror kuni (1–31). Funksiya bugundan keyingi muddatni "YYYY-MM-DD" satrida qaytarsin. Kanon chekka holatlari: oyda bunday kun bo'lmasa — oyning oxirgi kuni; 29-fevral faqat kabisa yilda. Keyin funksiyani jadval bo'yicha sinang — har qator "Berilgan bugun, takror kuni; Unda kutilgan sana". Har natija oldida ok yoki XATO, kutilgan … chiqsin.

Ishora: oydagi kunlar soni — new Date(Date.UTC(yil, oy, 0)).getUTCDate(). Date.UTC da oy 0 dan boshlanadi, shuning uchun 1 dan boshlanadigan oy bilan "keyingi oyning 0-kuni" — joriy oyning oxirgi kuni. Ikki xonali raqam — padStart (Kesish, bo'lish va to'ldirish).

const oyKunlari = (yil, oy) =>
  new Date(Date.UTC(yil, oy, 0)).getUTCDate();

function oylikKeyingi(bugun, kun) {
  let { yil, oy } = bugun;
  let kerakli = Math.min(kun, oyKunlari(yil, oy));
  if (kerakli <= bugun.kun) {
    oy += 1;
    if (oy === 13) {
      oy = 1;
      yil += 1;
    }
    kerakli = Math.min(kun, oyKunlari(yil, oy));
  }
  const ikki = (n) => String(n).padStart(2, "0");
  return `${yil}-${ikki(oy)}-${ikki(kerakli)}`;
}

const mezonlar = [
  [{ yil: 2026, oy: 1, kun: 15 }, 31, "2026-01-31"],
  [{ yil: 2026, oy: 1, kun: 31 }, 31, "2026-02-28"],
  [{ yil: 2028, oy: 1, kun: 31 }, 31, "2028-02-29"],
  [{ yil: 2026, oy: 2, kun: 28 }, 31, "2026-03-31"],
  [{ yil: 2026, oy: 4, kun: 30 }, 31, "2026-05-31"],
  [{ yil: 2026, oy: 12, kun: 31 }, 31, "2027-01-31"],
  [{ yil: 2026, oy: 11, kun: 4 }, 10, "2026-11-10"],
];
for (const [bugun, kun, kutilgan] of mezonlar) {
  const javob = oylikKeyingi(bugun, kun);
  const belgi = javob === kutilgan ? "ok" : `XATO: ${kutilgan}`;
  const { yil, oy } = bugun;
  console.log(`${yil}-${oy}-${bugun.kun}, ${kun}: ${javob} ${belgi}`);
}

2026-1-15, 31: 2026-01-31 ok
2026-1-31, 31: 2026-02-28 ok
2028-1-31, 31: 2028-02-29 ok
2026-2-28, 31: 2026-03-31 ok
2026-4-30, 31: 2026-05-31 ok
2026-12-31, 31: 2027-01-31 ok
2026-11-4, 10: 2026-11-10 ok

12. Real ishda

• Qayerda uchraydi: PRD (product requirements document), "one-pager", RFC — kompaniyaga qarab nomi har xil, mazmuni shu darsdagidek. Kattaroq texnik qarorlar uchun hujjatlar Design doc va RFC darsida — kursda keyinroq.
• Dasturchi roli: kuchli jamoalarda dasturchi talab muhokamasida qatnashadi va "bu chekka holat-chi?", "buni qanday o'lchaymiz?" degan savollarni beradi. Bu ko'nikma o'rta darajadan katta darajaga o'tishda ko'p so'raladi.
• Vositalar: talablar Notion, Confluence, Google Docs yoki repo ichidagi Markdown'da yuritiladi. Repo ichida bo'lsa — PR orqali review qilinadi, xuddi kod kabi.
• Intervyu savollari: "Noaniq talab kelsa nima qilasiz?", "MVP nima, misol keltiring", "Xususiyat muvaffaqiyatli bo'lganini qanday bilasiz?", "Qabul mezoni va Definition of Done farqi nima?"

Xulosa

• Kod — vosita: avval muammo, kimning muammosi va qanday o'lchanishi.
• So'rovdagi yechimni muammoga qaytaring: "nega?" deb so'rang.
• Hikoya — "kim, nima, toki"; qabul mezoni — Berilgan / Qachonki / Unda, tekshiriladigan.
• Chekka holatlar va mahsulot qarorlari — kod yozishdan oldin, hujjatda.
• MVP — faqat Must; Must ~60 % dan oshmasin, qolgani ehtiyot qism.
• Muvaffaqiyat metrikasi oldin/keyin o'lchanadi, qarshi metrika uni halol tutadi.

Keyingi dars: Open source: hissa qo'shish va litsenziyalar — kurs loyihasiga MIT litsenziyasini qo'shamiz, litsenziyalar muvofiqligini tekshiramiz va boshqa loyihaga birinchi PR'ni yuboramiz.

Manbalar

• Agile Alliance — Three Amigos: https://www.agilealliance.org/glossary/three-amigos/ (2026-11-04)
• Agile Alliance — INVEST: https://www.agilealliance.org/glossary/invest/ (2026-11-04)
• Cucumber — Gherkin reference (Given / When / Then): https://cucumber.io/docs/gherkin/reference/ (2026-11-04)
• Agile Business Consortium — MoSCoW Prioritisation (DSDM): https://www.agilebusiness.org/dsdm-project-framework/moscow-prioritisation.html (2026-11-04)
• Eric Ries — The Lean Startup (2011): MVP (sinalmagan, 2026-11)
• Toyota Production System — "5 Whys" usuli (sinalmagan, 2026-11)
• Kanon tajribasi (IlmHamroh, 2026-11-04): vazifalar-api talab hujjati, PR #18 (kurs sinov reposi), push va merge chiqishlari. JS bloklar va mashq yechimlari — biz ishga tushirdik (2026-11-04).