Әзірлеушілер тапсырмаларды бағалау үшін қандай әдістерді пайдаланады?

Бәріңе сәлем! Дамуды бастау үшін қажетті теория өте кең. Кейбір мамандарда (Java және басқа тілдердегі бэк-энд-әзірлеушілер) бұл көбірек, ал басқаларында (мысалы, JavaScript-тегі фронтенді әзірлеушілер - React Native) азырақ. Дегенмен, олардың екеуі де тек техникалық ғана емес, сонымен қатар «ұйымдастырушылық» білімнің үлкен қорына ие болуы керек. Бұл «ұйымдастырушылық» білім фронтенд пен бэкэнд әзірлеушілерінің қиылысу нүктелерінің бірі болып табылады. Бүгін мен осындай техникалық емес, ұйымдастырушылық білімдердің бір қыры туралы – тапсырманы бағалау (бағалау) туралы айтқым келеді . Мен тек Agile әдістемесінде (шын мәнінде ең танымал болып саналады) жұмыс істегендіктен, оның Scrum ішкі бөлімінде мен тапсырманы бағалауды Scrum контекстінде қарастырамын . Бағалау деп те аталатын бағалау қиын екенін бірден айтамын. Мен үшін әзірлеуші ​​ретінде бұл жұмыстың ең қиын/қалаусыз аспектілерінің бірі. Тапсырманы бағалауға әсер ететін көптеген әртүрлі факторларды ескеру қажет. Бұл ретте алдағы даму жоспарлары сіздің болжамдарыңызға негізделетін болады.

Рейтингті дұрыс алмасаңыз ше?

Егер әзірлеуші ​​тапсырмаға соңында жұмсалатын сағаттан көп уақыт жұмсаса, ол ең жақсы маман емес сияқты көрінуі мүмкін, өйткені бағалау өте дәл емес. Былайша айтқанда, аспандағы саусақ. Сонымен қатар, егер әзірлеуші ​​болжанған уақытқа инвестиция салмаса, ол тұтынушының өнімді/жаңа мүмкіндікті шығару жоспарларына қауіп төндіреді. Бұл бизнес, ал бизнес ақшаны білдіреді, ал мұндай пункцияны аз тұтынушылар ұнатады. Міне, сондықтан мен бағалауды ұнатпаймын, өйткені кейде тапсырманы орындаудың нақты уақытын анықтау өте қиын.

Уақыт қалай бағаланады?

Әдетте, бағалау сағаттармен немесе әңгіме нүктелерімен жүзеге асырылады. Мен өз басым әңгіме нүктелеріндегі бағалау процесіне әлдеқайда жақынмын . Егер сағат физикалық нәрсе болса, онда қате болуы мүмкін нәрсе, оқиғаның түйіндері басқа нәрсе туралы, неғұрлым дерексіз. Әдетте, бағдарламалық жасақтаманы әзірлеу топтары уақыт форматында бағалауды береді: сағаттар, күндер, апталар, айлар. Мұндай уақытты бағалау, ең алдымен, жеке тәжірибеге, болжамға немесе интуицияға негізделген. Бұл жағдайда әзірлеушілер тапсырмаға қарап, оған қанша уақыт кететінін айтады. Нәтижесінде, олар өте сирек дәл болады, өйткені жұмысты аяқтау мерзіміне әсер ететін факторлар тым көп. Сондықтан, Agile әдістемесі бойынша жұмыс істейтін көптеген командалар әңгіме нүктелерін пайдаланады. Оны анықтап көрейік.

Сюжеттік нүктелер дегеніміз не

Әңгіме нүктесі - бұл белгілі бір жұмыс саласын (функционалдық) толық жүзеге асыру үшін қажетті жалпы күш-жігерді бағалауды білдіретін өлшем бірлігі. Яғни, бұл салыстырмалы күрделілік . Командалар жұмыстың күрделілігіне, жұмыс көлеміне және тәуекелге немесе белгісіздікке негізделген әңгіме нүктелерін тағайындайды. Әдетте, бұл мәндер жұмысты неғұрлым тиімдірек кішірек бөліктерге бөлу үшін тағайындалады, осылайша белгісіздік жойылады. Уақыт өте келе бұл командаларға белгілі бір уақыт аралығында неге қол жеткізе алатынын түсінуге көмектеседі және жұмыстың келесі бағыттарын дәлірек жоспарлауға көмектеседі. Бұл сізге мүлдем қарама-қайшы болып көрінуі мүмкін, бірақ бұл абстракция шын мәнінде өте пайдалы: ол команданы жұмыстың күрделілігі туралы қатаңырақ шешім қабылдауға итермелейді. Жоспарлауда әңгіме нүктелерін пайдаланудың кейбір себептерін қарастырайық:

• уақыт аралықтарында бағалаудың дәлсіздігін болдырмауға болады;
• Уақыт бойынша бағалаудан айырмашылығы, үстеме шығындарды жақсырақ есепке алуға болады: топ мүшелері мен тұтынушы арасындағы байланыс, әртүрлі топтық талқылаулар мен жоспарлау, сондай-ақ күтпеген жағдайлар;
• Әр топ жұмысты әртүрлі шкала бойынша бағалайды, яғни олардың жылдамдығы (ұпаймен өлшенеді) әртүрлі болады;
• Әрбір оқиға нүктесін тағайындау үшін масштабты анықтау арқылы сіз көп дау-дамайсыз ұпайларды жылдам тарата аласыз.

Оқиға нүктелерін қалай пайдаланбауға болады

Өкінішке орай, әңгіме нүктелері көбінесе басқа мақсаттарда қолданылады. Әңгіме нүктелері адамдарды бағалау, егжей-тегжейлі мерзімдер мен ресурстарды анықтау үшін пайдаланылған кезде және өнімділік өлшемі ретінде қате қабылданған кезде кемшіліктер болуы мүмкін. Оның орнына, командалар оларды әрбір тапсырмадағы жұмыс көлемін/күрделілігін түсіну және басымдық беру үшін пайдалануы керек. Күрделі деп бағаланған бөліктерді спринттің соңына дейін аяқтау үшін алдымен орындау керек болуы мүмкін , бірақ жеңіліректерді кейінірек артқа жылжытуға болады. Scrum әдістемесі контекстінде спринттің не екенін еске сала кетейін : Бұл уақыт кезеңі әзірлеудің басында команда мен тапсырыс беруші арасындағы келісім бойынша анықталады. Бұл екі апта немесе бір ай немесе кез келген басқа кезең болуы мүмкін. Әдетте, тапсырманы бағалау спринттің аяғына дейін орындалған жұмыстың ықтимал көлемін жоспарлау үшін, аяқталған жұмыс тапсырыс берушіге жеткізілген кезде спринттің басында жүзеге асырылады. Бұл өнімді әзірлеудегі прогресті көруге, тұтынушыдан кері байланыс алуға және жобаның дамуын тұтынушының көзқарасына сәйкес реттеуге көмектеседі. Дегенмен, біз сәл шегініс жасаймыз: бағалауға оралайық. Тапсырмаларды тек бір әзірлеушінің бағалауы тым субъективті болар еді. Сондықтан, әдетте, бұл командалық жұмыс. Топты бағалаудың бірнеше әдістері бар. Бүгін біз олардың ең көп қолданылатынын қарастырамыз - Scrum poker . Бұл әдіс менеджерді қажет етеді, ол осы Scrum покерінің көшбасшысы сияқты болады . Бұл Scrum Master немесе PM маманданған адам болуы мүмкін .

Scrum Poker дегеніміз не

Scrum покер - немесе жоспарлау покері - келісімге қол жеткізуге негізделген бағалау әдісі. Негізінен алдағы жұмыстың күрделілігін немесе бағдарламалық жасақтаманы әзірлеу кезінде шешілетін тапсырмалардың салыстырмалы көлемін бағалау үшін қолданылады. Мен Scrum покері дамудағы кең таралған тәжірибе екенін бірден атап өтемін және сіз оның қандай аң екенін білуіңіз керек. Бұл процесс үшін біз әдетте белгілі бір тапсырманы топтық бағалауды ұйымдастыруға мүмкіндік беретін қандай да бір қолданбаны немесе веб-сайтты қолданамыз. Бұл қалай болады? Команда артта қалған элементті (жаңа тапсырма, функционалдылық) қабылдайды, ықтимал тұзақтар мен онымен байланысты басқа нюанстарды қысқаша талқылайды. Содан кейін әрбір қатысушы өзінің қиындық деңгейін көрсететін нөмірі бар картаны таңдайды. О, және бағалау кезінде әдеттегі қатарлар емес, Фибоначчи сандары қолданылады . Фибоначчи сандары скрам покерінде соншалықты танымал , өйткені олардың арасындағы алшақтық уақыт өте келе артады (пирамида деңгейлерін еске түсіреді). Күрделілігі зор міндеттер бар және әңгіменің аз санына қол жеткізу мүмкін емес. Әдеттен тыс карталарға түсініктеме:

соңғы нүктелердің белгісіз саны

шексіз ұзақ тапсырма

үзіліс қажет

Сирек кездесетін бағалау әдістері:

• футболка өлшемдерінде - S, M, L, XL
• немесе иттерде - чихуауа, пуг, такшунд, бульдог және т.б. (менің ойымша, бұл тапсырмаларды бағалаудың ең оғаш бірлігі =D)

Содан кейін команда әртүрлі әзірлеушілер бір мәселеге берген бағалауларды салыстырады, егер олар келіссе, тамаша! Егер жоқ болса, бағалаудағы (дәлелдер) айырмашылықтардың себептерін талқылау қажет. Осыдан кейін біз бірігіп бір бағалауға келе аламыз, онымен барлығы плюс немесе минус келіседі. Неліктен покер тіпті маңызды бағдарламалық жасақтама жобасын жоспарлау үшін қолданылады? Өйткені, бұл біртүрлі. Шын мәнінде, мұндай геймификация команда мүшелерін өз нәтижелерін әріптестерімен бір уақытта көрсетуді сұрай отырып, өз бетінше ойлауға итермелейді. Бұл өз кезегінде басқа топ мүшелерінің көзқарастарына тәуелді болудан сақтайды. Әйтпесе, тәжірибесі аз әзірлеушілер тәжірибелі топ мүшелерінің бағалауларына қарап, оларға сенеді, бұл өз бағалауының пайдалылығын жоққа шығарады. Бірақ нәтижелердің бір мезгілде ашылуымен бұл іс жүзінде мүмкін емес. Scrum Poker жоспарлау қолданбасының мысалы Atlassian .

Тапсырманы бағалау мысалы

Сіздің командаңыз әңгіме нүктелерінде бағалаудың белгілі бір шкаласын анықтады деп елестетіп көрейік: Scrum Poker тапсырманы орындауға кіріседі және сіз оны келесідей бағалайсыз:

• Сіз бұрын-соңды ұқсас функционалдылықты жүзеге асырумен жұмыс істемегенсіз - +3
• орташа өлшемді тапсырманың функционалдығы - +2
• тапсырманы орындау күрделілігі жоғары – +3
• осы функционалдылық үшін жазу сынақтарының жоғары күрделілігі - +3

Нәтижесінде сіз 11 сюжеттік ұпай аласыз, бірақ мұндай карта жоқ болғандықтан, сіз 13 ұсынасыз. Сіздің басқа әріптесіңіз тапсырманы бағалайды:

• бұрын ұқсас мәселемен жұмыс істеген - +1
• орташа өлшемді тапсырманың функционалдығы - +2
• тапсырманы орындау орташа күрделілікке ие - +2
• осы функционалдылық үшін жазу сынақтарының орташа күрделілігі - +2

Нәтижесінде ол 7 сюжетті ұпай алады, бірақ Фибоначчи сандарында мұндай нәрсе жоқ және ол мүмкіндігінше жақын саны бар картаны орналастырады - 8. Команданың басқа мүшелері, тиісінше, өздерінің субъективті көзқарастарына негізделген баға береді. Әрі қарай, сіз өз нәтижелеріңізді көрсетесіз және әріптестеріңіздің барлығы дерлік 13 бағасын бергенін білесіз, тек бір әзірлеушіге 8 бергеннен басқа. Бұл жағдайда оған сөз беріледі және ол себептерін айтады. Және олар, мысалы, келесідей: ол бұрын бірдей мәселемен жұмыс істеді және бұл көрінгендей қиын емес, және соңында ол команданың қалған мүшелерін шешімін 13-тен 8 әңгімеге өзгертуге сендіреді. кім осы тапсырманы қолға алса, соны түсінеді деп көмектесетінін айтады. Немесе, ақырында, ол мұны өзі жасайды. Жалпы алғанда, оның дәлелдерін басқалар тыңдайды ма, жоқ па маңызды емес, өйткені бұл тапсырмаға қандай да бір баға беріледі, ал команда келесі тапсырмамен танысуға көшеді. Бірінші рет бағалаулар, сондай-ақ келесі уақыт кезеңінде (спринт) орындауды жоспарлап отырған жұмыс көлемін бағалау дәл емес болады. Өйткені, бұл бағалаулар дәл бағалау негізінде жасалады. Біраз уақыттан кейін, шамамен үш айдан кейін, команда тапсырмаларды дәлірек бағалай бастайды және команда бір спринтте орындай алатын жұмыстың орташа көлемі көрінетін болады. Бірақ бұл жұмыс көлемін жалпы жоспарлау, бұл уақыт туралы көбірек және бұл жағдайда әсер ететін көптеген әртүрлі факторлар болуы мүмкін. Мысалы, әзірлеушілердің бірі екі аптаға демалысқа кетті. Яғни, жоспарланған жұмыстың белгілі бір көлемін сызып тастау керек (жоспарланған функционалдылық). Немесе командаға жаңа әзірлеуші ​​келді, бірақ оған толық сенудің қажеті жоқ, өйткені... onboarding деп аталатын жобаға бейімделу үшін қажетті уақытты ескеру қажет . Бұл жобаның күрделілігіне байланысты аптасына екі апта, плюс немесе минус болуы мүмкін. Міне, бүгінгі күні мен проблеманы бағалау сияқты білімнің техникалық емес бөлігінде сіздің біліміңізді аздап жақсарттым деп үміттенемін. Егер сіз осы тақырыпқа, сондай-ақ Scrum егжей-тегжейіне тереңірек үңілгіңіз келсе, мен сізге Джефф Сазерлендтің «SCRUM» кітабын оқуға кеңес беремін. Мен оның салдары үшін кепілдік бере алмаймын, өйткені одан кейін сізде Scrum Master болуға тітіркендіргіш ниет пайда болуы мүмкін =D