Scrum bilan ishlash

User Story

User Story - ishlab chiqilayotgan dasturiy ta'minot talablarini bayon qilishning samarali usuli. Ushbu hikoyalar dasturiy ta'minot foydalanuvchisi nomidan qisqacha tavsiyalarni o'z ichiga oladi.

Scrum metodologiyasida vazifa qo'yish odatda mijoz yoki dastur egasining vakolati hisoblanadi, shuning uchun ular rivojlanish jarayoniga ta'sir qilishning asosiy usuli hisoblanadi. Har bir User Story hajmi va murakkabligi cheklangan. Hikoyani kichik qog'oz varag'ida yozish odatda hajmni cheklaydi.

User Story'lar mijozning istaklarini hujjatlashtirish va bozor talablariga tezda javob berishga imkon beradi.

User Story'ni soddalashtirilgan talablar ko'rsatkichi deb hisoblash kerak, chunki unda qabul qilish testini o'tkazish tartibi yo'q. User Story tuzilishi qabul qilish tartibiga mos kelishi kerak. Bu User Story o'z maqsadiga erishishini kafolatlaydi.

Hikoya tuzilishi taxminan quyidagi ko'rinishga ega: “Foydalanuvchi sifatida <foydalanuvchi turi>, men <harakat>ni bajarishni xohlayman, natijaga ega bo'lishim uchun <natija>” (As a product owner I want …). Bunday tuzilma nafaqat oddiy, balki hamma uchun tushunarli.

User Story'larning afzalliklari:

• Hikoyalar hajmi kichik va ularni yaratish oson.
• Loyihani ishlab chiqish va qo'llab-quvvatlash bo'yicha barcha manfaatdor tomonlar bilan muhokama qilishga yordam beradi.
• Doimiy xizmat ko'rsatishni talab qilmaydi.
• Faqat foydalanilganda dolzarb.
• Mijoz bilan o'zaro aloqalarni yaxshilaydi.
• Loyihani kichik bosqichlarga bo'lish imkoniyatini beradi.
• Talablari yaxshi tushunilmagan loyihalar ustida ishlashni osonlashtiradi.
• Vazifalarni baholashni soddalashtiradi.

User Story'larning kamchiliklari:

• Oldindan kelishilmagan protseduralar asosida foydalanish bazasiga aylanishini murakkablashtirishi mumkin.
• Barcha jarayon davomida mijoz bilan yaqin aloqada bo'lishni talab qiladi, bu esa ish jarayonini murakkablashtirishi mumkin.
• Katta loyihalarda kengaytirishda kamchiliklarga ega.
• Dasturchilarning kasbiy darajasi bilan bevosita bog'liq.
• Muzokaralar boshlanishida qo'llaniladi, ammo muzokaralarning tugashi yoki tizim hujjatlari uchun qo'llanilmaydi.

Backlog

Mahsulot backlogi - bu ustuvorlik tartibida tuzilgan joriy vazifalar ro'yxati. Ro'yxat loyihaning yo'l xaritasi (roadmap) va undagi narsalar asosida tuziladi. Eng muhim vazifalar odatda ro'yxat boshida joylashadi. Bu qaysi ishni birinchi bo'lib bajarilishi kerakligini tushunish uchun zarur.

Dasturchilar jamoasi backlog vazifalari bajarilish tezligini mijozning xohishlaridan mustaqil ravishda, balki o'zlarining malakalari va o'tgan sprintlar tajribasiga asoslanib tanlashadi. Dasturchilarni "majbur qilish" qat'iyan tavsiya etilmaydi. Jamoa backlogdan topshiriqlarni o'zi tanlash imkoniyatlariga ko'ra tanlaydi. Amalga oshirish bevosita (Kanban) yoki bir nechta iteratsiyalarda (Scrum) o'tkaziladi.

Backlogning ikkita muhim sharti

Mahsulot backlogining asosi yo'l xaritasi, takliflar va bajarish shartlaridan iborat. Epiklarda shartlar va User Storylar mavjud. Keling, odatiy yo'l xaritasining misolini batafsil ko'rib chiqaylik.

"Kosmosdagi jamoalar" veb-saytini yaratish - yo'l xaritasidan birinchi taklif. Uni epiklarga (rasmda ular yashil, ko'k va havorang rangda ko'rsatilgan) va har bir epik uchun User Storylarga bo'lish kerak.

Dasturiy ta'minot mijoz bir nechta User Storylardan bitta ro'yxat tuzadi. Agar kerak bo'lsa, u hikoyalarning bajarish tartibini o'zgartirishi mumkin, shunda dasturchilar avval eng muhim epik bilan shug'ullanishadi (chapda) yoki qanday qilib imtiyozli chiptalarni bron qilishni tekshiradi. Buni amalga oshirish uchun epiklar hikoyalarini amalga oshirish kerak (o'ngda). Ikkala variantni ham quyida ko'rishingiz mumkin.

Buyurtmachisi qaysi omillar asosida ustuvorliklarni belgilashi kerak?

• Foydalanuvchilar uchun dolzarbligi.
• Aloqa mavjudligi.
• Rivojlanish murakkabligi.
• Vazifalar orasidagi bog'liqlik ("B"ni bajarish uchun avval "A"ni qilish kerak).

Ishdagi ustuvorliklarni buyurtmachisi belgilaydi, lekin bu haqda boshqalar ham o'z fikrlarini bildirishlari mumkin. Backlog muvaffaqiyati, shu jumladan, mijoz va dasturchilar fikridan ham bog'liq. Kollektiv kuch bilan ular natijalarni yaxshilashga va tayyor mahsulotni o'z vaqtida yetkazib berishga muvaffaq bo'lishlari mumkin.

Backlogni qanday olib borish kerak

Agar backlog allaqachon yaratilgan bo'lsa, keyinchalik uni kelajakdagi ishlar davomida davriy ravishda o'zgartirish kerak bo'ladi. Dasturiy ta'minot buyurtmachisi har bir yangi iteratsiyani rejalashtirishdan oldin backlogning to'g'ri tuzilganligiga ishonch hosil qilishi kerak. Bu oxirgi iteratsiya tahlilidan so'ng ustuvorliklarni aniqlashtirish yoki biror narsani o'zgartirishga yordam beradi. Agile'da backlogni to'g'rilash ba'zan "grooming" yoki "tartibga solish" yoki "backlog olib borish" deb ataladi.

Agar backlog allaqachon nisbatan katta bo'lsa, buyurtmachisi vazifalarni qisqa va uzoq muddatli amalga oshirish uchun guruhlash kerak. Qisqa muddatli vazifalarni diqqat bilan o'rganish kerak, ularga ushbu maqomni berishdan oldin. User Storyni tuzish, jamoa ichidagi barcha nozik tomonlarni aniqlash kerak.

Uzoq muddatli vazifalarga kelganda, dasturchilarning o'z bahosini berishlari juda muhimdir. Bu ustuvorliklarni belgilashni osonlashtiradi. Ehtimol, nimadir o'zgaradi, lekin jamoa vazifalarni yaxshiroq tushunadi va ishni tezda davom ettiradi.

Backlog - bu mijoz va dasturchilar jamoasi o'rtasidagi muhim qism. Buyurtmachisi har doim yangi talablar yoki mijozlar sharhlarini ko'rib chiqib, ustuvorliklarni o'zgartirishi mumkin.

Ish paytida o'zgartirishlarni kiritishdan qochish tavsiya etiladi. Bu ish jarayoniga va dasturchilarning hissiy holatiga yomon ta'sir ko'rsatadi.

Sprint

Sprint - bu oldindan kelishilgan ish hajmini bajarish kerak bo'lgan qisqa vaqt. Sprintlar Scrum va Agile metodologiyalariga asoslangan. To'g'ri sprintlar tanlovi agile-jamoaga sifatli dasturiy ta'minotni ishlab chiqishda yordam beradi.

"Scrum yordamida mahsulotni bir nechta iteratsiyalar orqali aniqlangan davomiylikda - sprintlar orqali ishlab chiqish mumkin. Bu katta loyihalarni kichik vazifalarga bo'lishga yordam beradi," deydi Megan Kuk, Atlassian kompaniyasidagi Jira yo'nalishini boshqaruvchi.

Scrum-da sprintlarni rejalashtirish va bajarish qanday amalga oshiriladi?

Scrum metodologiyasi mualliflari fikriga ko'ra, kelajakdagi sprintni rejalashtirish uchun barcha ishtirokchilar alohida yig'ilishga to'planishlari kerak. Ushbu tadbirda jamoa a'zolari sprintda nima qilish kerakligini va uni qanday amalga oshirish yaxshiroq bo'lishini aniqlashlari kerak.

Ishchi vazifalar ro'yxatini aniqlashda dasturiy ta'minot buyurtmachisi, Scrum-master va dasturchilar ishtirok etadi. Buyurtmachisi sprintning maqsadini va backlogdagi vazifalarni tushuntiradi.

So'ngra jamoa sprint davomida vazifalarni bajarish rejasini ishlab chiqadi. Ushbu reja tanlangan ishchi vazifalar bilan birgalikda sprint backlogi deb ataladi. Rejalashtirish bo'yicha yig'ilishdan so'ng jamoa ishga kirishadi. Dasturchilar backlogdan vazifalarni tanlashadi va har bir vazifa bajarilganda uning holati "Ishda"dan "Tayyor"ga o'zgaradi.

Sprint davomida jamoa har kuni Scrum yig'ilishlari (staldups) o'tkazadi, unda joriy muammolar va ish holati muhokama qilinadi. Ushbu yig'ilishlar sprint tugashiga ta'sir qilishi mumkin bo'lgan qiyinchiliklarni aniqlash uchun zarur.

Agar sprint yakunlangan bo'lsa, jamoa natijalarni (demo) ko'rsatadi. Loyihaning har bir ishtirokchisi natijalar bilan tanishishi mumkin. Tanishuv, tayyor kodning ish muhitiga birlashishidan oldin o'tkazilishi kerak.

Sprintlar tsiklini retrospektiva tugatadi. Unda jamoa kelajakdagi sprintda yaxshilanishi kerak bo'lgan sohalarni aniqlaydi.

Nimani e'tiborda ushlab turish va nimalar qilmaslik kerak

Ko'pchilik yangi jamoalar o'z ish jarayonlariga ilk marta sprintlar kiritishda qiyinchiliklarga duch kelishadi. Muammolardan qochish uchun, quyidagi birinchi darajali e'tibor talab qiladigan harakatlar ro'yxatini o'rganishni tavsiya qilamiz.

Nimani qilish kerak:

• Jamoa sprintning maqsadini va muvaffaqiyatga erishish yo'lini tushunishiga ishonch hosil qiling. Bu barcha birgalikda muvaffaqiyatli natijaga erishish uchun kerak.
• Sizda aniq va tushunarli backlog bo'lishi kerak. Agar backlog noto'g'ri olib borilgan bo'lsa, bu ish jarayoniga salbiy ta'sir ko'rsatadigan muammo bo'lishi mumkin.
• Yozgi ta'til va boshqa omillarni hisobga olgan holda, ishingiz sur'atini to'g'ri baholaganligingizga ishonch hosil qiling.
• Sprintni rejalashtirishda faol ishtirok eting. Jamoa a'zolarini hikoyalar, xatolar va vazifalar uchun rejani kengaytirishga rag'batlantiring.
• Razrabotchilar muammolarni hal qilolmagan vazifalardan voz keching.
• Reja tasdiqlangandan so'ng, loyihani boshqarish dasturiga ma'lumot kiritish yuklatilgan xodimga tayinlang (Jira kartochkalari yoki boshqalar).

Nimani qilmaslik kerak:

• Ko'p hikoyalardan foydalanib, ish sur'atini xolisona baholang va sprintda bajarilmaydigan vazifalarni tayinlamang.
• Ish sifati haqida qayg'uring. Koddagi sifat nazorati va xatolarni tuzatish uchun yetarli vaqt bor-yo'qligini tekshiring.
• Jamoaning barcha a'zolari sprint mazmunini aniq tushunayotganiga ishonch hosil qiling. Tezlikka intilmang. Jamoaning barcha a'zolari birgalikda harakat qilishi kerak.
• Razrabotchilarga ortiqcha ish yuklamang. Tez orada yana bir sprint bo'ladi.
• Agar jamoa yuklanish yoki deadline haqida xavotir bildirsa, ularning fikrini inobatga oling. Muammolarni hal qiling va kerak bo'lsa ularni to'g'rilang.

Scrum board

Scrum doskasi - bu Scrum jamoasining qanday ishlayotganini ko'rsatadigan vosita. Bunday doskada ma'lumotni qog'ozda, devorda yoki elektron shaklda (JIRA, Trello) ko'rsatish mumkin.

Scrum doskasi kamida uchta ustundan iborat: “qilish kerak”, “ishda” va “tayyor”. Sizga doskaning misolini ko'rsatuvamiz:

Scrum doskasida rejalashtirishda tasdiqlangan backlogdagi barcha ma'lumot mavjud. Odatda, biznes vazifa kartochkalari doskaga ustuvorlik bo'yicha yuqoridan pastga qotiriladi. Ularni kod ustida ishlash, dizayn va boshqa konkret ish turlariga ajratish mumkin.

Ushbu ishlardan bir qismi tugallangandan so'ng, kartochka qo'shni ustunga o'tkaziladi. Jamoaning ishlashidagi progressni ko'rsatish uchun Burndown Chartda kunlar bo'yicha "qolgan ishlar" ko'rsatadi.

Flapchatli doskadan ham foydalanish mumkin. Unda ish nomlari qog'oz yopishtiruvchilariga yoziladi va doskaga yopishtiriladi. Ish tugallangandan so'ng stikerlar boshqa ustunga ko'chiriladi.

Burndown chart

Vazifalar sönmesi diagrammasi (Burndown chart) bajarilgan va qolgan ishlar miqdorini ko'rsatadi. U har kuni yangilanadi va barcha qiziqqan tomonlar uchun foydalanish mumkin. Grafik sprint ustida ishlashda progressni ko'rsatish uchun kerak.

Diagrammaning ikki turi mavjud:

• Sprintdagi ish progressini ko'rsatadigan burndown chart.
• Mahsulot chiqishigacha bo'lgan ish progressini ko'rsatadigan burndown chart (bir nechta sprintlardan olingan ma'lumotlar to'plami).

Diagramma misoli:

Ushbu misolda psixologiya ishlatiladi: diagramma bajarilgan vazifalar sonini emas, balki qolgan (qilinmagan) vazifalar miqdorini ko'rsatadi.

Ya'ni, agar jamoa 100 ta vazifadan 90 tasini bajargan bo'lsa, allaqachon hammasi bajarilganligi haqida noto'g'ri fikr paydo bo'lishi mumkin. Axir, 90 dan 100 ta vazifaga o'tish progressni sezilarli darajada o'zgartirmaydi.

Agar qolgan vazifalar sonini ko'rsatsa, qanday bo'lmasin ularni har safar ozayib borishini sezmaslik mumkin emas. Bu loyihada ishtirok etayotganlarni ongsiz ravishda maqsadga erishishni tezlashtiradi - doskada bajarilmagan vazifalar qolmasligi kerak.