Спазвайте крайните си срокове: методи, които разработчиците използват за оценка на усилията

Здравейте всички! Има колосално количество теория, която трябва да знаете, за да започнете в разработката на софтуер. Някои специалисти (например бекенд разработчици, които използват Java и други езици) знаят повече за него, докато други (например фронтенд разработчици, които използват JavaScript и React Native) може да знаят малко по-малко. Въпреки това и двете групи трябва да притежават голямо количество не само технически, но и „организационни“ знания. Това „организационно“ знание е една област на припокриване за разработчиците на преден и бекенд интерфейс. Днес искам да говоря за един аспект на това нетехническо, организационно познание. Днес ще говорим за оценка на усorята . Защото имам опит само с използването на Agile методологията(която се счита за най-популярната), по-конкретно Scrum рамката, ще разгледам оценката на усorята в контекста на Scrum . Още в началото трябва да кажа, че оценката на усorята е трудна. За мен това е един от най-предизвикателните/неприятните аспекти на работата ми като разработчик. Има много различни фактори, които трябва да имате предвид, които могат да повлияят на оценката ви за усorята, необходими за дадена задача. Освен това бъдещите планове за развитие ще се основават на вашите оценки.

Ами ако предоставите лоша оценка?

Ако програмист прогнозира много повече часове за дадена задача, отколкото в крайна сметка са изразходвани за задачата, техният опит може да бъде поставен под съмнение, тъй като оценката е била толкова неточна. С други думи, това беше странно предположение. В същото време, ако разработчикът не свърши работата в предвиденото време, той застрашава плановете на клиента да пусне продукта or новата функция. Това е бизнес, а бизнесът е пари. Малко клиенти ще бъдат доволни от такъв фиш. Всъщност, това е причината, поради която не харесвам оценката — защото понякога е изключително трудно да се определи точно времето, необходимо за изпълнение на задача.

Как да направите прогноза за времето

По правило оценките се правят в часове or сюжетни точки. Личното ми предпочитание е да направя процеса на оценка, като използвам исторически точки . Трудно е да се сбърка за конкретни физически обекти, но сюжетните точки са малко по-абстрактни. Екипите за разработка на софтуер обикновено предоставят прогнози като количество време: часове, дни, седмици, месеци. Тези оценки на времето се основават предимно на личен опит, догадки и/or интуиция. В този случай разработчиците просто разглеждат задачата и изразяват предположението си колко време ще им отнеме. В резултат на това тези оценки много рядко са точни, тъй като има твърде много фактори, които могат да повлияят на продължителността на работата. Ето защо много екипи, които използват методологията Agile , използват и исторически точки. Нека се потопим!

Какво представляват сюжетните точки?

Историческата точка е мерна единица за изразяване на оценка на общото усorе, необходимо за пълното внедряване на определена част от функционалността. Тоест, говорим за роднинасложност. Екипите дават оценка в сюжетни точки въз основа на сложността на работата, обема на работа и риска or несигурността. Тези стойности обикновено се присвояват за по-ефективно разделяне на работата на по-малки части, като по този начин се елиминира неяснотата. С течение на времето това помага на екипите да разберат Howво могат да постигнат за даден период от време и им помага по-точно да планират следващите части от работа. Това може да ви звучи напълно контраинтуитивно, но тази абстракция е наистина удобна: тя кара екипа да взема трудни решения относно сложността на работата. Нека да разгледаме някои от причините да използвате исторически точки, когато планирате:

• Можете да избегнете неточни оценки на времето.
• За разлика от оценките, напequalsи в единици време, историческите точки ви позволяват да отчетете режийните разходи: комуникации между членовете на екипа и клиента, различни екипни дискусии и дейности по планиране, Howто и непредвидени ситуации.
• Всеки екип ще оцени работата си с различни скали, което означава, че капацитетът им (измерен в точки) ще бъде различен.
• Като дефинирате скала за присвояване на всяка точка от историята, можете бързо да разпределите точките без много спорове.

Как да НЕ използвате сюжетни точки

За съжаление, сюжетните точки често се злоупотребяват. Историческите точки могат да бъдат подвеждащи, когато се използват за оценка на хората, определяне на подробни срокове и ресурси и когато се бъркат с мярка за изпълнение. Вместо това екипите трябва да ги използват, за да разберат обхвата/сложността на всяка задача и да определят приоритети. Може би частите, които се считат за по-трудни, трябва да се справят първо, така че да могат да бъдат напequalsи преди края на спринта , като евентуално преместите по-лесните задачи за по-късно. Нека ви напомня Howво е спринт в контекста на Scrum методологията: Продължителността на този период се определя при започване на разработката и се съгласува между екипа и клиента. Това може да бъде период от две седмици or месец, or всеки друг период. По правило оценките на усorята се правят в началото на всеки спринт, за да се планира работата, която може да бъде завършена до края на спринта, когато завършената работа бъде доставена на клиента. Демонстрацията ви помага да видите напредъка си в разработването на продукта, да получите обратна връзка от клиента и да коригирате траекторията на проекта според визията на клиента. Но малко се отклонихме. Да се ​​върнем на прогнозите. Би било твърде субективно само един разработчик да предоставя оценки за всички задачи. Така че този процес обикновено е екипно усorе. Има доста техники, които екипите могат да използват за генериране на прогнози. Днес ще разгледаме най-популярната техника: Scrum Poker . Тази техника изисква мениджър, който ще действа като модератор на scrum покера . Това може да е някой, който е scrum master or евентуално PM .

Какво е Scrum покер?

Scrum покерът or покерът за планиране е техника за оценка, която се основава на постигане на споразумение. Използва се главно за оценка на сложността на предстоящата работа or относителния размер на задачите за разработка на софтуер. Веднага ще кажа, че scrum pokerе обичайна практика за разработка на софтуер и трябва да знаете за Howво става въпрос. Обикновено включва приложение or уебсайт за улесняване на съвместното създаване на прогноза за определена задача от екип. How става това Екипът взема нещо от изоставането (нова задача, няHowва функционалност) и накратко обсъжда възможни клопки и други нюанси, свързани с това. След това всеки участник избира карта с номер, който отразява неговата оценка за сложност. О, още нещо, когато правим тези оценки, ние използваме числа в редицата на Фибоначи , а не обикновени числа. Числата на Фибоначи са популярни в scrum покера, тъй като между тях има все по-голяма празнина (наподобяваща нивата на пирамида). Някои задачи ще бъдат изключително сложни и няма да можем да се измъкнем с малък брой сюжетни точки. Има някои необичайни карти, които имат следните значения:

Неизвестен брой крайни точки

Безкрайно дълга задача

Нужда от почивка

По-рядко срещаните методи за оценка използват:

• Размери на тениските — S, M, L, XL
• Породи кучета - чихуахуа, мопс, дакел, булдог и така нататък (лично аз смятам, че това е най-странната мерна единица за оценка на усorята =D)

След това екипът сравнява оценките, дадени от различни разработчици за една и съща задача. Ако са съгласни, тогава страхотно! Ако не, тогава трябва да се обсъдят причините (аргументите) за различните оценки. След това екипът работи заедно, за да формира единна оценка, която всички приемат, повече or по-малко. Така че защо покерът дори се използва за планиране на сериозни софтуерни проекти? Трябва да признаете, че това е странно. Факт е, че този вид геймификация насърчава членовете на екипа да мислят независимо, като ги приканва да разкриват оценките си едновременно с техните съотборници. Това от своя страна избягва създаването на ситуация, в която някои членове на екипа зависят от мненията на другите. Ако не беше напequalsо по този начин, тогава по-малко опитните разработчици биха разгледали и се съсредоточor върху оценките, предоставени от по-опитни членове на екипа, и това би направило собствените им оценки по-малко полезни. Но едновременното показване на оценките прави това по същество невъзможно. Atlassian предлагаscrum покер приложение за използване в процеса на планиране.

Пример за оценка на усorята

Да предположим, че вашият екип е създал следната скала за присвояване на точки от историята на оценките: Scrum покер се играе за всяка задача и вие предоставяте оценка, Howто следва:

• Никога преди не сте прилагали подобна функционалност: +3
• Функционалността е средна по размер: +2
• Изпълнението ще бъде много сложно: +3
• Писането на тестове за функционалността ще бъде много сложно: +3

Добавяйки всеки компонент, вие получавате общо 11 точки история, но няма такава карта, така че вие ​​предлагате 13. Колега предлага следната оценка за задачата:

• Той е работил с подобна задача преди: +1
• Функционалността е средна по размер: +2
• Изпълнението ще бъде със средна сложност: +2
• Писането на тестове за функционалността ще бъде със средна сложност: +2

Неговият междинен резултат е 7 исторически точки, но това число не съществува в серията на Фибоначи, така че той изпраща картата с най-приблизителното число — 8. Други членове на екипа също правят своите оценки въз основа на своите субективни възгледи. След това всеки показва картите си и установявате, че почти всичките ви колеги са дали оценка 13, с изключение на един разработчик, който е предложил 8. В този случай му е позволено да говори с причините за по-ниската си оценка. Да предположим, че предлага следното оправдание: преди това е работил върху същата задача и тя не е толкова трудна, колкото може да изглежда. В крайна сметка той убеждава останалата част от екипа да променят решението си от 13 на 8 сюжетни точки, като казва, че ще помогне на всеки, който в крайна сметка поеме тази задача. Или може би ще го направи сам. Във всеки случай не няма meaning дали другите приемат неговите аргументи or не, защото по един or друг начин оценка ще бъде присвоена на задачата и екипът ще премине към разглеждане на следващата. Първоначално прогнозите ще бъдат неточни, Howто и прогнозите за количеството работа, която планирате да свършите през следващия период от време (спринт). В крайна сметка тези оценки са напequalsи с помощта на оценки. След известно време, може би три месеца по-късно, екипът ще започне да оценява времето, необходимо за задачите, по-точно и средният обем работа, който екипът е в състояние да извърши в спринта, ще стане очевиден. Но това е процес, за да се направи общ план за обхвата на работа. Той се фокусира главно върху времето, но в този случай може да има много различни релевантни фактори. Да предположим например, че разработчик отиде на почивка за две седмици. Ще трябва да намалите определено количество планирана работа (планирана функционалност). Или да предположим, че нов разработчик се е присъединил към екипа, но все още не е напълно в крак с времето, така че трябва да й дадете време да се запознае с проекта чрезпроцес на включване . Това може да отнеме две седмици, повече or повече седмица, в зависимост от сложността на проекта. Това е всичко за днес! Надявам се, че леко подобрих знанията ви за оценка на усorята, необходим нетехнически аспект на разработката на софтуер. Ако искате да навлезете по-дълбоко в тази тема и в детайлите на схватката, горещо ви препоръчвам да прочетете книгата „SCRUM“ от Джеф Съдърланд. Не мога да давам обещания за последствията, защото след като го прочетете ще имате досадно желание да станете scrum master =D