Техники за пъргава оценка: Истинска оценка в гъвкав проект

agile estimation techniques

Истински оценки в гъвкав проект: Пълна представа с примери за пъргава оценка

Много е важно да се направи пъргава оценка на различни нива. Това се прави за правилно планиране, управление и оценка на общите усилия, които ще използваме за внедряване, тестване и доставяне на желания продукт на клиентите по отношение на времето в рамките на определените срокове.

При липса на оценки в Agile Project може да няма правилно планиране и управление, което може да завърши с доставка на нежелания продукт и по този начин да остане клиентът недоволен.

Оценките на сюжетни точки се правят в Agile проекти, като се използват различни техники като Planning Poker, Bucket System, Affinity Mapping и др. За тази цел се използват различни шаблони за оценка на различни нива като Agile Project Plan Template, Release Plan Template, Sprint Plan Template, RoadMap Template , Шаблон за потребителска история и т.н.

Какво ще научите:

• Въведение
• Оценки на исторически точки в Agile
• Препоръчан инструмент
• Различни ловки техники за оценка
  • # 1) Планиране на покер
  • # 2) Размери на тениска
  • # 3) Точково гласуване
  • # 4) Кофата система
  • # 5) Голям / Несигурен / Малък
  • # 6) Картиране на афинитета
  • # 7) Метод за поръчка
• Изчисляване на бюджета в пъргав
• Шаблони за оценка в Agile Development Project
  • 1) Шаблон на Agile план на проекта:
  • 2) Шаблон на Agile Plan Release:
  • 3) Agile шаблон за изоставане на продукти:
  • 4) Agile Sprint Backlog шаблон:
  • 5) Шаблон на Agile Test Plan:
  • 6) Шаблон за пъргава потребителска история:
  • 7) Agile Шаблон за пътна карта:
• Етапи на оценка в Agile Project
  • # 1) Предложение или оценка на ниво проект
  • # 2) Оценка на нивото на издаване
  • # 3) Оценка на нивото на спринта
• Заключение
• Препоръчително четене

Въведение

По-долу са дадени 3-те основни нива на Agile Estimation.

# 1) Проект или ниво на предложението е този, който използва бърз анализ на функционални точки по време на началните фази на разработването на проекта.

# 2) Ниво на издаване включва присвояване на точки от историята на потребителските истории, които могат да помогнат при определянето на реда на потребителските истории въз основа на приоритета и също така могат да помогнат при решаването кои истории могат да бъдат взети в текущата версия и кои могат да бъдат взети по-късно.

# 3) Ниво на спринт е този, при който потребителските истории се разбиват на задачите и се определят очакваните часове на задачите според тяхната сложност. Тук също дефинираме лицето, отговорно за задачата, заедно със статуса на задачите.

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

Оценки на исторически точки в Agile

Оценките на Story Points е сравнителен анализ за приблизителна оценка на елементите на натрупаните продукти с относително оразмеряване. Членовете на екипа за оценка на потребителските истории включват: Собственик на продукта, Scrum Master, Разработчици, Тестери и притежатели на залози.

По-долу са дадени няколко стъпки за постигане на окончателното решение за относително оразмеряване:

# 1) Анализирайте всички потребителски истории и идентифицирайте основната или референтната история. Важно е да правите относително оразмеряване. Тази история може да бъде избрана от текущия изоставащ продукт или този, който сме направили по-рано. Тази история трябва да бъде избрана като справочна история след съгласие на всички членове.

# две) Изберете друга история от текущия Продуктово изоставане и членовете на екипа са свободни да обсъждат всякакви въпроси или съмнения със собственика на продукта, като същевременно разбират изискванията на историята. Собственикът на продукта е отговорен за изясняване на всички техни въпроси и съмнения.

# 3) Направете списък с нещата, за които трябва да се погрижите, докато внедрявате потребителската история. Те могат да бъдат направени чрез писане на бележки в раздела за бележки на инструмента или чрез добавяне на точки в картата с разкази. Това се прави най-вече от Scrum Master.

# 4) По-долу са посочени няколко често срещани въпроса сред участниците:

• Дизайн: Какви са предварителните и задължителни знания, които трябва да имаме, преди да започнем да работим по тях?
• Кодиране: Колко кодиране е необходимо за внедряване на тази потребителска история. Попадали ли сме на подобна потребителска история по-рано?
• Единично тестване: Необходими ли са някакви фиктивни обекти за извършване на модулно тестване за тази потребителска история?
• Интеграционно тестване: Влияе ли тази история върху останалите функционалности на същия модул и други модули също?
• Изпитване за приемане: Какви са точките, за които трябва да се погрижите, за да доставите желания продукт по желание на клиентите?
• Експертиза: Някой от участниците правел ли е подобна история преди и е експерт в нея?

# 5) Направете относително оразмеряване на избраната история. Ако това изисква същото количество труд и усилия, тогава му задайте същото не. точки, както е присвоено на референтната история. Ако това изисква повече усилия, задайте му някаква по-висока стойност. Ако това изисква по-малко усилия, задайте му някаква по-ниска стойност.

# 6) Постигнете консенсус с всички участници, за да финализирате относителния размер за избраната потребителска история според дефиницията на готово.

шлюзът по подразбиране не е наличен постоянно

# 7) След като е направено относително оразмеряване на всички елементи на изоставането на продукта, уверете се, че ако всички потребителски истории със същия номер. точки, които са им определени, изискват същите усилия и размер, за да бъдат последователни.

Препоръчан инструмент

# 1) Agile Poker

Agile Poker е добре познато приложение за Jira за бързо и удобно планиране и оценки както за отдалечени, така и за разположени съвместно екипи.

Първите стъпки с Agile Poker са лесни и лесни, тъй като са вдъхновени от три стандартни за индустрията методологии за оценка: Planning Poker®, Wideband Delphi и Magic Estimation (известни също като Silent Grouping, Affinity Estimation, Swimlanes Sizing or Relative Estimations).

Различни ловки техники за оценка

Има много техники за извършване на оценки в Agile Project. Основните принципи за извършване на оценки включват относителна оценка, дискусии за получаване на повече информация за обекти, чиито оценки трябва да бъдат направени и гарантиране на ангажираността на целия екип за задачите, които са им възложени.

Съществуват главно 7 гъвкави техники за оценка на проекти:

# 1) Планиране на покер

• В тази техника за оценка всички хора, които трябва да направят оценките, седят в кръгъл кръг за сесията Planning Poker.
• Всеки оценител има набор от карти за планиране на покер със стойности: 0,1,2,3,5,8,13,20,40 и 100. Тези стойности представляват сюжетни точки или мярка, в която екипът оценява.
• В началото на сесията собственикът на продукта или клиентът чете историята на потребителя, описвайки всички негови характеристики и изисквания.
• След като историята бъде прочетена, се провеждат дискусиите между оценителите и със собственика на продукта / клиента. Оценителите могат да задават въпроси или да изясняват съмненията си със собственика на продукта.
• След дискусиите всички оценители са помолени да изберат една карта, за да оценят историята на потребителя. Ако всички оценители дават еднаква стойност, това става окончателната оценка.
• Ако стойностите са различни, оценителите, даващи най-високи и най-ниски стойности, обясняват своите мнения и защо са избрали тази стойност, докато не се постигне консенсус.
• Добра техника, когато малка не. на елементите се оценява в малък екип.

=> По-нататъшно подробно четене на Техника за планиране на покер оценка .

# 2) Размери на тениска

• Точно както при тениските, виждаме размери: XS (изключително малък), S (малък), M (среден), L (голям), XL (много голям). Подобен подход се следва и тук. Изделията се изчисляват в размери на тениски.
• Това е перфектна техника за груба оценка на голямото изоставане на предмети.
• Полезно, когато трябва да се направи бърза и груба оценка. По-късно тези размери могат да бъдат преобразувани в не според изискванията.
• Относителният размер (предимно среден) се решава след взаимно обсъждане и съгласие на членовете на екипа или оценителите. След това не се присвояват на елементите според относителния размер, присвоен на Среден размер.
• Недостатък: Това, което изглежда L на някого, може да изглежда XL за някого.
• Всички оценители присвояват собствен размер на елементите. След дискусии и разрешаване на несъответствията се постига консенсус за получаване на окончателната оценка.

# 3) Точково гласуване

• Това в основата си е метод за класиране, за да се определи реда на натрупване на продукти от истории с най-висок приоритет до истории с най-нисък приоритет. Това се прави, за да се изберат най-важните истории, които трябва да се продължат напред.
• За да започнете с това, публикувайте всички потребителски истории заедно с тяхното описание на стената или дъската с помощта на жълти лепенки или по начин, който ги отличава за получаване на гласовете.
• На всички заинтересовани страни се дават от 4 до 5 точки (предимно под формата на стикери, химикалки или маркери също могат да се използват за направата на точка).
• Всички заинтересовани страни са помолени да дадат своя глас за потребителските истории, които предпочитат.
• Собственикът на продукта поръчва артикулите за натрупване на продукти от най-предпочитания (един с най-много точки) до най-малко предпочитания (такъв с най-малко брой точки).
• Може да е така, когато малко заинтересовани страни са недоволни от взетия ред. В този случай потребителските истории са разделени в 3 групи след дискусиите: висок приоритет, нисък приоритет и среден приоритет. Потребителските истории с висок приоритет са публикувани на стената, за да получат гласовете. Това се прави, докато окончателният ред бъде постигнат със съгласието на всички заинтересовани страни.

# 4) Кофата система

• Добра техника е, когато голям не. на артикулите трябва да се изчисляват с големи не. на участниците. Той е по-бърз и по-разумен от Planning Poker.
• Създават се различни групи със стойности: 0,1,2,3,4,5,8,13,20,30,50,100, 200. Това може да бъде удължено, ако е необходимо. Тези групи не са нищо друго освен карти, представляващи стойности, подредени последователно на маса.
• Историите трябва да бъдат поставени в тях, където оценителят ги намери подходящи. Всички елементи, които трябва да бъдат оценени, са написани на картите.
• Изберете елемент на случаен принцип и го поставете в кофа 8. Това се използва само за справка. Изберете произволно друга история, обсъдете всички нейни характеристики и изисквания с групата и след консенсус я поставете в съответната кофа. По същия начин се избира и поставя трети елемент в подходяща кофа.
• Последователността на сегмента също може да бъде променена, в случай че групата почувства първия избран елемент, трябва да принадлежи на група 1 вместо група 8.
• Следва се подходът „разделяй и владей“. Всички останали елементи се разделят между всички участници. Всички участници могат да поставят елемента без одобрението на други участници.
• Елементите трябва да бъдат поставени правилно. Никой артикул не може да се поставя между кофите.
• Ако даден участник не разбира елемента за натрупване на продукти или ако останалите участници са приключили с поставянето на своите потребителски истории, потребителските истории могат да бъдат прехвърлени на останалите участници.
• Най-накрая проверката на здравословното състояние се извършва от всички участници. Ако някой от участниците открие грешна кофа, присвоена на елемент, той може да го уведоми на другите участници и да обсъди с тях. Това се прави, докато не се постигне консенсус за цялото изоставане на продуктите.
• Водещият трябва да направи проверка, че никой не премества предметите, освен ако не е направена проверка за здравословно състояние.
• Това се прави и за постигане на приоритетния ред на елементите с натрупани продукти.

# 5) Голям / Несигурен / Малък

• Това е груба версия и представлява опростяване на системата с кофи, където има само три размера: Голям, Малък и Несигурен.
• Участниците или оценителите са помолени да поставят предметите в една от категориите. Първо, избират се прости потребителски истории и се поставят в големите и малките категории. След това се поемат сложните предмети.
• Добра техника е, когато има съпоставими елементи в натрупаните продукти.

# 6) Картиране на афинитета

• Добра техника, когато екипът е малък и не. на изоставащи елементи е по-малко.
• Първата стъпка е тихо относително оразмеряване: На стена от най-лявата страна се поставя карта с надпис „По-малък“, а от най-дясната карта с надпис „По-голям“. Собственикът на продукта предоставя подмножество от елементите на всички участници. Всички участници са помолени да оразмерят всеки елемент спрямо размерите на картите на стената, като се вземат предвид усилията, необходими за тяхното изпълнение. Това е самостоятелното решение на участника, без обсъждане с останалите членове на екипа. Собственикът на продукта или заинтересованата страна присъства, за да изясни съмненията на участника. Елементите на изоставането на продуктите, които са твърде двусмислени, за да бъдат разбрани от членовете на екипа за оценка, се поставят отделно. Отнема 5-20 минути.
• Редактиране на стена: Членовете на екипа могат да променят местоположението на предметите на стената. Те могат да обсъждат изискванията за проектиране и изпълнение с останалите членове на екипа. Тази дейност може да бъде затворена, когато на стената се случват малко промени. Отнема около 20-60 минути .
• Поставяне на елементи на правилните места: След дискусиите екипът поставя елементите с натрупани продукти на съответните и подходящи позиции. Тук можем да използваме оразмеряване на тениски, серия на Фибоначи и др., За да преценим относително размера на предметите.
• Предизвикателство на собственика на продукта: Собственикът на продукта може да открие някакво несъответствие в оценките, направени от екипа, и трябва да обсъди с екипа повече функции или изискванията за даден артикул. След дискусии се правят окончателни оценки.
• Експортиране в инструмент за управление на изоставане на проекти: За да сте сигурни, че информацията за крайните оценки не се губи, експортирайте я в инструмент за управление на натрупани продукти.

# 7) Метод за поръчка

• Добра техника, когато голяма не. от предмети и малки бр. от хората са там.
• Той дава точни относителни размери на елементите с изоставане в продукта.
• Изготвя се скала, варираща от ниска до висока. Всички елементи са поставени на случаен принцип върху него. Всеки участник е помолен да премести един елемент на везната наведнъж. Движението може да бъде едно нагоре, едно надолу или да предаде завоя на друг член.
• Това продължава, докато всички участници не са доволни и не искат да преместват нито един елемент от кантара.
• Това също така дава приоритетния ред на елементите с натрупани продукти.

Изчисляване на бюджета в пъргав

Изчисляването на бюджетите играе важна роля в Agile проектите. Това се прави, за да се гарантира какъв е действителният предоставен бюджет, какъв още бюджет е необходим и как ще разделим бюджета за различни елементи на натрупаните продукти.

Той използва данните, събрани от предишните проекти и използва математическата формула, за да получи прогнозния бюджет за текущия проект.

По-долу е дадена последователността от стъпки за изчисляване на бюджета в Agile проект:

# 1) Избройте всички изисквания на проекта и направете оценки за тях, използвайки Planning Poker, Bucket System, серия на Фибоначи и др. Всички членове на екипа трябва да се съгласят с направените оценки за изброените изисквания след ясен анализ и разбиране на потребителските истории. Оценките се правят въз основа на функциите, които трябва да бъдат внедрени в потребителска история.

# две) Определете продължителността на итерациите, наречени Спринтове, и елементите на изоставането на продуктите, възложени му. Обикновено е с продължителност от 2 до 3 седмици. Потребителските истории се избират в последователност, започвайки с потребителска история с максимален приоритет, преминавайки към по-малък приоритет и с най-малък приоритет на потребителска история в края. Това помага при вземането на решение кои потребителски истории трябва да бъдат взети в първия Sprint и кои истории могат да бъдат взети по-късно.

# 3) Подгответе изгорялата диаграма, за да дадете ясна картина на това колко остава да се свърши работа спрямо това колко време остава за изпълнение. По принцип дава скорост на напредък на пъргав екип. Дава ясна картина за това как се държи екипът и как се очаква да се държи.

Напредъкът на екипа се измерва по отношение на Изпълнени задачи, Оставащи усилия, Идеално изгаряне и Оставащи задачи, както е показано по-долу:

# 4) Добавете допълнителни разходи като покупка на оборудване, инструменти, поддръжка на инфраструктура, получаване на лицензи за използваните софтуерни инструменти, инструменти за управление на проекти, инсталиране и актуализации на антивирусни програми.

# 5) Добавете бюджети за пред и след итерация. Всички гъвкави членове трябва да са многофункционални, но има ограничения за това. Всичко, направено от член на екипа извън неговия опит, се счита за работа преди итерация или работа след итерация. Тази работа преди и след итерацията изисква допълнителен бюджет за изпълнение.

# 6) Следене на скритите рискове. Рисковете в проекта Agile включват: Риск проектът да надхвърли бюджета, Отсъствие на членове на екипа, Членовете не разполагат с ясни или пълни познания, Членовете нямат необходимите умения, крайните срокове са преминати и т.н.,

Шаблони за оценка в Agile Development Project

Има много шаблони за оценка, които са подготвени на различни нива в проекта за развитие на Agile. Единствената цел е ясно да се посочат прогнозите, необходими за изпълнение на дадено изискване или елемент и проследяване на неговия напредък.

Основните шаблони са посочени по-долу:

1) Шаблон на Agile план на проекта:

Той дава представа на високо ниво за това колко време е необходимо за предоставяне на характеристиките на изискванията и какъв е техният статус. Той също така споменава лицето, отговорно за конкретна задача.

(Забележка: Щракнете върху всяко изображение за увеличен изглед)

2) Шаблон на Agile Plan Release:

Той дава подробности за освобождаването на задачите, съответстващи на изискванията, заедно с техния статус и Sprint, в който трябва да бъдат изпълнени.

3) Agile шаблон за изоставане на продукти:

Той описва пълното изоставане на продукти, дефинирано за проекта. Той дава подробности за задачите на Спринтовете, заедно със състоянието, приоритета, точките на историята и дали те са назначени за Спринт или ако има някаква допълнителна задача като дефекти и т.н.

4) Agile Sprint Backlog шаблон:

Той дава описание на потребителските истории, споменати в изоставането на определен Sprint. Той дава общите точки на историята, присвоени на потребителска история и как те са разделени на различни задачи. Той също така дава статуса на съответните задачи и каква е работата, извършвана ежедневно за съответните задачи.

5) Шаблон на Agile Test Plan:

Той разбива целия тестов сценарий на под-сценарии. Той дава подробности за подсценариите като дата на изпълнение, очакван резултат, действителен резултат, състояние и т.н.

Той също така споменава името на проекта, съвместимия браузър, версията на тестваното приложение, идентификатор на тестовия случай за избран сценарий, написано от, тествано от, описание и др.

6) Шаблон за пъргава потребителска история:

Той дава подробности, специфични за анализа на потребителската история като Какви са ролите, необходими за тестване на конкретна функционалност, какво е предварително изискване (настроена среда и активирани връзки) и какъв е очакваният резултат?

7) Agile Шаблон за пътна карта:

Той дава насока към проекта в компанията, краткосрочно и дългосрочно. Помага за определяне на очакванията в рамките на компанията. И прегледът накъде се насочва проектът.

Етапи на оценка в Agile Project

В Agile Project оценките се извършват на 3 нива, както е посочено по-долу:

• Ниво на проект / предложение: Общият функционален размер на цялото приложение се изчислява с помощта на метода за бърз анализ на функционалните точки (QFPA), когато са налице само изисквания от високо ниво.
• Ниво на издаване: Историйните точки се присвояват на потребителските истории, които помагат при определяне на не. на изданията, планирани в рамките на даден проект и №. на потребителски истории, които да бъдат взети в издание и спринт.
• Ниво на спринт: Очакваните часове са определени за задачите на потребителските истории в рамките на спринт. Това се прави, за да се гарантира ангажираността на разработката за доставяне на потребителски истории с спринт.

S1, S2, S3, S4, S5, S6 са спринтове.

какво е ключът за мрежова сигурност?

# 1) Предложение или оценка на ниво проект

Това е оценка на много високо ниво за проекта. Той се фокусира върху общия брой изисквания в елемента Product Backlog. Функционални точки се използват за оценка на размера на софтуера / проекта, преди да бъде документирано подробно описание на функционалните изисквания.

Функционалните точки са универсално приетият начин за изчисляване на размера на софтуера. Той се фокусира върху функционалностите, открити в софтуерните проекти. Функционалната точка е метрика, която преобразува изискванията или потребителските истории в число.

По време на началните етапи на проекта се препоръчва да се възприеме метод за бърз анализ на функционални точки (QFPA).

Методът за бърз анализ на точката на функция е уникален подход за оценка на FP, когато са налични само изисквания на високо ниво.

Как да изчислим общия функционален размер?

• Разберете всички функционалности на дадено приложение с помощта на експерти по домейни.
• Идентифицирайте и избройте всички възможни функционалности на дадено приложение.
• Функциите за съхранение на данни се класифицират във вътрешни логически файлове (данни, съхранявани вътрешно в приложението) и външни интерфейсни файлове (данни, използвани само за справка).
• Функциите на транзакциите се класифицират на външни входове (данни, идващи от външни източници към приложението), външни изходи (производни данни преминават от приложението навън) и външни запитвания (данни, извлечени от един или повече външни входове и външни изходи).
• Изчислете размера на FP за всяка функция, като изчислите средната й сложност.
• Обобщете FP размера на всички функции, за да получите общия функционален размер на приложението.
• Най-малко двама души с опит в FP анализа трябва да изчисляват независимо, да съвпадат резултатите и да разрешат разликите.

Пример за оценка на ниво проект:

По-долу е списъкът с изисквания за даден проект, както в Product Backlog:

• Потребителят трябва да може да влезе в уебсайта, като предостави потребителско име и парола.
• След успешно влизане, потребителят трябва да бъде отведен на главната страница с десни и леви панели.
• Потребителят трябва да има възможност да излезе от приложението.
• Валидният потребител има възможност да промени паролата, като предостави текущи идентификационни данни.

Екипът използва бърза оценка на FP, за да оцени размера на проекта.

Следва анализът:

• Функцията за съхранение на данни тук съхранява потребителски идентификационни данни, за да влезете и да промените паролата.
• Тъй като идентификационните данни се съхраняват в границите на приложението, те се съхраняват в ILF (вътрешни логически файлове).
• Функциите за транзакции включват:
  • Потребителско влизане и показване на главната страница.
  • Потребителско излизане и показване на екрана за излизане.
  • Възможност за промяна на паролата.

По-долу са изпълнени стъпките за оценка на размера на проекта, като се използва бърз анализ на функционални точки:

СТЪПКА # 1: Избройте всички функции за данни

UFP (Ненастроена функционална точка) е взета от таблицата на Капер Джоунс.

СТЪПКА 2: Избройте всички транзакционни функции

UFP (Ненастроена функционална точка) е взета от таблицата на Капер Джоунс.

СТЪПКА # 3: Извеждане на прогнозния размер на проекта във функционални точки

UFP = FP за данни + FP за транзакция

UFP = 10 + 12 = 22 UFP

FP = UFP * VFP = 22 * ​​1 = 22 FP (Ако приемем, че VFP (коефициент на корекция на стойността = 1)

Производителност = 16 FP / месец (нормален стандарт)

Усилие = FP / Производителност = 22/16-месечен месец = 1,37 човек-месец

# 2) Оценка на нивото на издаване

Оценките на нивото на издаване се правят по време на планирането на изданието. Това е следващата дейност след оценка на ниво проект. Приоритетните изисквания са взети от Натрупването на продукти, което е под формата на потребителски истории.

Потребителските истории се изчисляват по точки на историята по време на планирането на изданието, което се фокусира върху оценката на размера на софтуера, който ще бъде доставен за тази версия. По този начин не се планира брой издания и общ брой сюжетни точки във всяко издание.

Историческата точка всъщност представлява относителното усилие, необходимо за внедряване на функция или функционалност, в сравнение с другите функции. По същество е за оразмеряване на продуктите с натрупани продукти.

Оценката на историята се извършва въз основа на:

• Сложността на функцията, която ще бъде внедрена.
• Опит и технически умения на всички членове.

S1, S2, S3, S4, S5 са спринтове.

Стъпки за присвояване на исторически точки към потребителска история:

• Всички членове на екипа се събират около маса, разглеждайки потребителските истории, присъстващи в Sprint Backlog.
• Решава се значението на една сюжетна точка и съответните усилия.
• Един от членовете на екипа чете потребителска история и след това моли членовете на екипа да определят относителните точки на историята.
• Ако има значителна разлика между точките от историята, зададени от членовете на екипа, те дават обяснение за точките от историята, които са назначили, като по този начин постигат консенсус в края.
• Процесът се повтаря 3-4 пъти, докато няма съществена разлика между оценките, дадени от членовете на екипа.
• Оразмеряването на истории помага да се определи колко истории ще бъдат взети в рамките на спринт и освобождаване.

Пример за оценка на нивото на издаване:

Това включва създаване на приоритетен списък с потребителски истории, наречен Product Backlog. Собственикът на продукта създава натрупвания на продукти и предоставя бизнес стойност за всеки от елементите, изброени в него.

Можем да използваме методите по-долу за оценка на исторически точки:

• Числово оразмеряване: 1 до 10
• Оразмеряване на тениска: Всяко изискване се класифицира като изключително малко (XS), малко (S), средно (M), голямо (L), много голямо (XL).
• Серия на Фибоначи: Оценка, направена чрез последователността на Фибоначи (1,2,3,5,8,13,21,34, ...)

Оценка на горните потребителски истории чрез последователността на Фибоначи:

# 3) Оценка на нивото на спринта

Оценките на нивото на спринта се правят по време на планирането на спринта. Елементите с най-висок приоритет на продуктите се вземат и разделят на различни задачи като Детайлиране, Проектиране, Анализ, Разработка, Създаване на тестови случаи, Изпълнение на тестови случаи, Тестване за приемане от потребителя и др

Задачите се изчисляват като приблизителни часове, т.е. времето, необходимо за изпълнението на тази задача за съответната потребителска история. Подходът отдолу нагоре се използва за оценките на Задачите, където бизнес изискванията се разбиват на дейности на ниско ниво и на всяка дейност се присвояват прогнозни часове.

Целта на оценките е да се знае колко потребителски истории може да се ангажира екипът за разработка към Sprint. Разработката трябва да отговаря на ангажимента, а собствениците на продукти трябва да са уверени, че екипът ще изпълни ангажимента.

С стъпки за задаване на прогнозни часове на задачите:

• Членовете на екипа вземат потребителските истории, след което се иска да оценят действителните усилия, изразени в часове или дни, за задачите, съответстващи на историята на потребителя.
• Ако има разногласия в тези оценки сред членовете на екипа, те го обсъждат и стигат до консенсус.
• Ако някоя задача е повече от шест часа, тя се разделя на по-малки задачи.
• Ако има две или повече задачи с очаквани часове по-малко от две, те се комбинират, за да образуват нова задача.

Пример за оценка на нивото на спринт:

Има две части на срещата за планиране на спринта:

• Първа част: Фокусът е върху изясняване на изискванията за потребителски истории, избрани от натрупването на продукти.
• Втора част: Фокусът е върху разбиването на изискванията към задачите и оценката на часовете, необходими за изпълнението им. Трябва да бъдат включени всички задачи, необходими, за да се направи продуктът Backlog продукт доставим. Задачите трябва да са малки. В идеалния случай задачата не трябва да надвишава шест часа.

Заключение

Оценките в Agile проекта играят важна роля, за да осигурят правилното ръководство, планиране и управление. Той предоставя стъпки за това как да започнете проекта в бъдеще.

Техниките за оценка на сюжетни точки като Планиране на покер, Bucket System и т.н. използват карти или точки с отпечатани стойности или числа и след това присвояват тези номера. на потребителските истории за оценка на относителния размер.

Единствената цел е да зададете елементите в приоритетен ред от максимален приоритет до минимален приоритет. Относителните размери, изчислени за елементите с натрупани продукти, помагат при изчисляването или изчисляването на бюджета, необходим за проекта.

Надявам се, че бихте получили чудесна представа за оценки на гъвкави проекти. Чувствайте се свободни да изразите мисли за този урок в раздела за коментари по-долу.

Препоръчително четене

• Как да улесним процеса на гъвкаво оценяване с планирането на покер
• Agile Vs Waterfall: Коя е най-добрата методология за вашия проект?
• Техники за оценка на софтуерни тестове (Пълно ръководство за оценка на тестовите усилия)
• VersionOne Tutorial: Всичко в едно Agile Ръководство за инструменти за управление на проекти
• Урок за портфолио на Jira: Плъгин за управление на портфолио на Agile за JIRA (Преглед)
• ТОП 10 най-добри гъвкави инструменти за управление на проекти през 2021 г.
• Основа за успешно Agile пътуване: Как да изберем правилния метод, инструменти и техники
• 4 стъпки към разработване на гъвкавия начин на тестване за успешен преход към пъргав процес