Ishlab chiquvchilar vazifalarni baholash uchun qanday usullardan foydalanadilar?

Hammaga salom! Rivojlanishni boshlash uchun talab qilinadigan nazariya juda keng. Ba'zi mutaxassislarda (Java va boshqa tillardagi backend dasturchilari) undan ko'proq, boshqalarda (masalan, JavaScript-dagi frontend ishlab chiquvchilari - React Native) biroz kamroq. Biroq, ularning ikkalasi ham nafaqat texnik, balki "tashkiliy" bilimlarning katta zaxirasiga ega bo'lishi kerak. Ushbu "tashkiliy" bilim frontend va backend ishlab chiquvchilari uchun kesishish nuqtalaridan biridir. Bugun men bunday texnik bo'lmagan, tashkiliy bilimlarning bir tomoni haqida - vazifani baholash (baholash) haqida gapirmoqchiman . Va men faqat Agile metodologiyasida (aslida eng ommabop deb hisoblanadigan) ishlaganim uchun uning Scrum bo'limida men Scrum kontekstida vazifalarni baholashni ko'rib chiqaman . Men darhol aytamanki, baholash, shuningdek, baholash deb ataladigan narsa qiyin. Shaxsan men uchun ishlab chiquvchi sifatida bu ishning eng qiyin/istalmagan jihatlaridan biri. Vazifani baholashga ta'sir qilishi mumkin bo'lgan turli xil omillarni hisobga olish kerak. Shu bilan birga, keyingi rivojlanish rejalari sizning prognozlaringizga asoslanadi.

Reytingni to'g'ri olmasangiz nima bo'ladi?

Agar ishlab chiquvchi topshiriqni bajarish uchun oxirida sarflanganidan ko'ra ko'proq soat sarflasa, u eng yaxshi mutaxassis emasdek tuyulishi mumkin, chunki hisob-kitob juda noto'g'ri edi. Shunday qilib aytganda, osmondagi barmoq. Shu bilan birga, agar ishlab chiquvchi prognoz qilingan vaqtga sarmoya kiritmasa, u mijozning mahsulot / yangi xususiyatni chiqarish rejalarini xavf ostiga qo'yadi. Bu biznes, biznes esa pul demakdir va bunday ponksiyon kam mijozlarga yoqadi. Shuning uchun men taxmin qilishni yoqtirmayman, chunki ba'zida vazifani bajarish uchun aniq vaqtni aniqlash juda qiyin.

Vaqt qanday baholanadi?

Qoida tariqasida, baholash soat yoki hikoya nuqtalarida amalga oshiriladi. Shaxsan men hikoya nuqtalarida baholash jarayoniga yaqinroqman . Agar soat jismoniy narsa bo'lsa, unda xato bo'lishi mumkin bo'lgan narsa, hikoya nuqtalari biroz boshqa narsa haqida, mavhumroq. Odatda, dasturiy ta'minotni ishlab chiqish guruhlari vaqt formatida hisob-kitoblarni beradi: soatlar, kunlar, haftalar, oylar. Bunday vaqtni hisoblash, birinchi navbatda, shaxsiy tajribaga, taxminlarga yoki sezgiga asoslanadi. Bunday holda, ishlab chiquvchilar shunchaki vazifaga qarashadi va ularga qancha vaqt ketishini taxmin qilishadi. Natijada, ular juda kamdan-kam hollarda aniq bo'ladi, chunki ishni bajarish muddatiga ta'sir qiladigan omillar juda ko'p. Shuning uchun, Agile metodologiyasi bo'yicha ishlaydigan ko'plab jamoalar hikoya nuqtalaridan foydalanadilar. Keling, buni aniqlaylik.

Hikoya nuqtalari nima

Hikoya nuqtasi - bu ishning ma'lum bir sohasini (funktsionalligini) to'liq amalga oshirish uchun zarur bo'lgan umumiy harakatlarni baholashni ifodalovchi o'lchov birligi. Ya'ni, bu shunday nisbiy murakkablik . Guruhlar ishning murakkabligi, ish hajmi va xavf yoki noaniqlik asosida hikoya nuqtalarini belgilaydilar. Odatda, bu qiymatlar ishni yanada samaraliroq kichikroq qismlarga ajratish va shu bilan noaniqlikni yo'q qilish uchun tayinlanadi. Vaqt o'tishi bilan bu jamoalarga ma'lum vaqt ichida nimaga erishish mumkinligini tushunishga yordam beradi va keyingi ish yo'nalishlarini aniqroq rejalashtirishga yordam beradi. Bu sizga mutlaqo zid bo'lib tuyulishi mumkin, ammo bu mavhumlik aslida juda foydali: u jamoani ishning murakkabligi haqida qattiqroq qarorlar qabul qilishga undaydi. Keling, rejalashtirishda hikoya nuqtalaridan foydalanishning ba'zi sabablarini ko'rib chiqaylik:

• vaqt oralig'ida noto'g'ri baholashning oldini olish mumkin;
• Vaqt o'tishi bilan taxmin qilishdan farqli o'laroq, qo'shimcha xarajatlarni yaxshiroq hisobga olish mumkin: jamoa a'zolari va mijoz o'rtasidagi aloqalar, jamoaning turli muhokamalari va rejalashtirish, shuningdek, kutilmagan vaziyatlar;
• Har bir jamoa ishni boshqa shkala bo'yicha baholaydi, ya'ni ularning tezligi (ballarda o'lchangan) har xil bo'ladi;
• Har bir hikoya nuqtasini belgilash uchun o'lchovni belgilash orqali siz ko'p tortishuvlarsiz ballarni tezda taqsimlashingiz mumkin.

Qanday qilib hikoya nuqtalaridan foydalanmaslik kerak

Afsuski, hikoya nuqtalari ko'pincha boshqa maqsadlarda ishlatiladi. Hikoya nuqtalari odamlarni baholash, batafsil muddatlar va resurslarni aniqlash uchun foydalanilganda va ular noto'g'ri ishlash o'lchovi sifatida qabul qilinganda noto'g'ri bo'lishi mumkin. Buning o'rniga, jamoalar har bir vazifadagi ish hajmini/murakkabligini tushunish va ustuvorliklarni belgilash uchun ulardan foydalanishlari kerak. Ehtimol, qiyinroq deb baholangan qismlar birinchi bo'lib bajarilishi kerak, shunda ular sprint tugaguniga qadar tugallanishi mumkin , ammo osonroqlari keyinroq orqaga surilishi mumkin. Scrum metodologiyasi kontekstida sprint nima ekanligini eslatib o'taman : Ushbu muddat qancha davom etishi rivojlanish boshida jamoa va mijoz o'rtasidagi kelishuv bilan belgilanadi. Bu ikki hafta yoki bir oy yoki boshqa davr bo'lishi mumkin. Qoidaga ko'ra, topshiriqni baholash sprintning boshida, bajarilgan ish mijozga topshirilganda, sprint oxirigacha bajarilgan ishlarning mumkin bo'lgan hajmini rejalashtirish uchun amalga oshiriladi. Bu sizga mahsulotni ishlab chiqishdagi muvaffaqiyatlaringizni ko'rishga, mijozdan fikr-mulohazalarni olishga va loyihani ishlab chiqishni mijozning qarashlariga muvofiq sozlashga yordam beradi. Ammo shunga qaramay, biz biroz chetga chiqamiz: keling, taxminga qaytaylik. Vazifalarni faqat bitta ishlab chiquvchi tomonidan baholash juda sub'ektiv bo'ladi. Shuning uchun, qoida tariqasida, bu jamoaviy ish. Jamoani baholash uchun bir nechta texnikalar mavjud. Bugun biz ulardan eng ko'p foydalanilganini ko'rib chiqamiz - Scrum poker . Ushbu texnika, bu Scrum pokerining lideri kabi bo'lgan menejerni talab qiladi . Bu Scrum Master yoki PM bo'yicha ixtisoslashgan shaxs bo'lishi mumkin .

Scrum Poker nima

Scrum poker - yoki rejalashtirish pokeri - bu kelishuvga erishishga asoslangan baholash usuli. Asosan oldindagi ishlarning murakkabligini yoki dasturiy ta'minotni ishlab chiqishda hal qilinishi kerak bo'lgan vazifalarning nisbiy hajmini baholash uchun ishlatiladi. Men darhol ta'kidlaymanki, Scrum poker rivojlanishda keng tarqalgan amaliyotdir va siz bu qanday hayvon ekanligini aniq bilishingiz kerak. Ushbu jarayon uchun biz odatda ma'lum bir vazifani jamoaviy baholashni tashkil qilish imkonini beruvchi qandaydir dastur yoki veb-saytdan foydalanamiz. Bu qanday sodir bo'ladi? Jamoa orqada qolgan elementni (yangi vazifa, funksionallik) oladi, mumkin bo'lgan tuzoqlarni va u bilan bog'liq boshqa nuanslarni qisqacha muhokama qiladi. Keyin har bir ishtirokchi o'zining qiyinchilik darajasini ko'rsatadigan raqamga ega kartani tanlaydi. Oh, va taxmin qilishda odatiy seriyalar emas, balki Fibonachchi raqamlari ishlatiladi . Fibonachchi raqamlari scrum pokerda juda mashhur , chunki ular orasidagi bo'shliq vaqt o'tishi bilan ortadi (piramida darajalarini eslatadi). Juda katta murakkablikka ega bo'lgan vazifalar mavjud va oz sonli hikoya nuqtalariga erishib bo'lmaydi. Noodatiy kartalar uchun tushuntirish:

so'nggi nuqtalarning noma'lum soni

cheksiz uzoq vazifa

tanaffus kerak

Baholashning kamdan-kam usullari:

• futbolka o'lchamlarida - S, M, L, XL
• yoki itlarda - chihuahua, pug, dachshund, bulldog va boshqalar (mening fikrimcha, bu vazifalarni baholash uchun eng g'alati birlik =D)

Keyin jamoa bir xil muammoga turli ishlab chiquvchilar tomonidan berilgan baholarni solishtiradi va agar ular rozi bo'lsa, ajoyib! Agar yo'q bo'lsa, baholashdagi (argumentlar) farqlarning sabablarini muhokama qilish kerak. Shundan so'ng, biz birgalikda bitta hisob-kitobga kelishimiz mumkin, bu bilan hamma, ortiqcha yoki minus rozi bo'ladi. Xo'sh, nima uchun poker hatto jiddiy dasturiy ta'minot loyihasini rejalashtirish uchun ishlatiladi? Axir, bu qandaydir g'alati. Darhaqiqat, bunday o'yinlashtirish jamoa a'zolarini mustaqil fikrlashga undaydi, ularning natijalarini jamoadoshlari bilan bir vaqtda ko'rsatishni so'raydi. Bu, o'z navbatida, boshqa jamoa a'zolarining qarashlariga bog'liqlikdan qochadi. Aks holda, kam tajribali ishlab chiquvchilar ko'proq tajribali jamoa a'zolarining baholashlariga qaraydilar va ularga tayanadilar, bu esa o'z baholashlarining foydaliligini inkor etadi. Ammo natijalarning bir vaqtning o'zida ochilishi bilan bu aslida mumkin emas. Scrum Poker rejalashtirish ilovasiga misol Atlassian dan .

Vazifani baholashga misol

Tasavvur qilaylik, sizning jamoangiz hikoya nuqtalarida baholash uchun ma'lum bir shkalani aniqladi: Scrum Poker vazifani bajarishda boshlanadi va siz uni quyidagicha baholaysiz:

• siz ilgari hech qachon shunga o'xshash funktsiyani amalga oshirish bilan ishlamagansiz - +3
• o'rta o'lchamdagi vazifaning funksionalligi - +2
• vazifani amalga oshirish yuqori murakkablikka ega - +3
• Ushbu funksionallik uchun yozish testlarining yuqori murakkabligi - +3

Natijada, siz 11 hikoya ball olasiz, lekin bunday karta yo'qligi sababli siz 13 ta taklif qilasiz. Boshqa bir hamkasbingiz vazifani baholaydi:

• ilgari shunga o'xshash muammo bilan ishlagan - +1
• o'rta o'lchamdagi vazifaning funksionalligi - +2
• vazifani bajarish o'rtacha murakkablikka ega - +2
• Ushbu funksionallik uchun yozish testlarining o'rtacha murakkabligi - +2

Natijada, u 7 ta hikoya ball oladi, lekin Fibonachchi raqamlarida bunday narsa yo'q va u eng yaqin raqam bilan kartani joylashtiradi - 8. Boshqa jamoa a'zolari, shunga ko'ra, o'zlarining sub'ektiv qarashlari asosida baho berishadi. Keyin, siz o'z natijalaringizni ko'rsatasiz va deyarli barcha hamkasblaringiz 13 baho berganligini aniqlaysiz, faqat bitta ishlab chiquvchi 8 ball berganidan tashqari. Bunday holda, unga so'z beriladi va u sabablarni aytadi. Va ular, masalan, shunday: u ilgari bir xil muammo bilan ishlagan va bu ko'rinadigan darajada qiyin emas va oxirida u jamoaning qolgan a'zolarini o'z yechimini 13 dan 8 tagacha o'zgartirishga ishontiradi. Bu vazifani kim o'z zimmasiga olsa, yordam beradi, deb ishora qiladi. Yoki, oxir-oqibat, u buni o'zi qiladi. Va umuman olganda, boshqalar uning dalillarini tinglaydimi yoki yo'qmi, muhim emas, chunki u yoki bu vazifaga reyting beriladi va jamoa keyingisi bilan tanishishga o'tadi. Birinchi marta hisob-kitoblar noto'g'ri bo'ladi, shuningdek, keyingi vaqt oralig'ida (sprint) amalga oshirishni rejalashtirgan ish hajmining hisob-kitoblari ham noto'g'ri bo'ladi. Axir bu hisob-kitoblar aniq hisob-kitoblar asosida amalga oshiriladi. Bir muncha vaqt o'tgach, taxminan uch oy, jamoa vazifalarni aniqroq baholashni boshlaydi va jamoa har bir sprintda bajarishi mumkin bo'lgan o'rtacha ish hajmi ko'rinadi. Ammo bu ish ko'lamini umumiy rejalashtirish, bu ko'proq vaqtga bog'liq va bu holda ta'sir ko'rsatadigan juda ko'p turli xil omillar bo'lishi mumkin. Misol uchun, ishlab chiquvchilardan biri ikki hafta davomida ta'tilga chiqdi. Ya'ni, siz rejalashtirilgan ishlarning ma'lum miqdorini (rejalashtirilgan funksionallik) kesib tashlashingiz kerak. Yoki jamoaga yangi dasturchi keldi, lekin siz unga to'liq ishonishingiz shart emas, chunki... loyihaga moslashish uchun zarur bo'lgan vaqtni hisobga olishingiz kerak, deb ataladi onboarding . Bu loyihaning murakkabligiga qarab haftada ikki hafta, ortiqcha yoki minus bo'lishi mumkin. Bugun hammasi shu, umid qilamanki, muammoni baholash kabi bilimning texnik bo'lmagan qismida sizning bilimlaringizni biroz yaxshiladim. Agar siz ushbu mavzuga, shuningdek, Scrum tafsilotlariga chuqurroq kirmoqchi bo'lsangiz, sizga Jeff Sazerlendning "SCRUM" kitobini o'qishni maslahat beraman. Men oqibatlariga kafolat berolmayman, chunki undan keyin sizda Scrum Master bo'lish istagi paydo bo'lishi mumkin =D