Agile Estimation Techniques: Правдива оцінка в Agile Project

agile estimation techniques

Правдиві оцінки в гнучкому проекті: повне розуміння з прикладами гнучкого оцінювання

Дуже важливо робити гнучку оцінку на різних рівнях. Це робиться для належного планування, управління та оцінки загальних зусиль, які ми збираємось використати для впровадження, тестування та доставки бажаного продукту Замовнику в терміни в зазначені терміни.

За відсутності оцінок в Agile Project, можливо, не буде належного планування та управління, що може закінчитися доставкою небажаного продукту і тим самим залишаючи клієнта незадоволеним.

Оцінки сюжетних оцінок проводяться в проектах Agile з використанням різних методів, таких як Planning Poker, Bucket System, Affinity Mapping тощо. Для цього використовуються різні шаблони оцінок на різних рівнях, такі як Agile шаблон плану проекту, шаблон плану випуску, шаблон плану спринту, шаблон дорожньої карти , Шаблон історії користувача тощо.

Що ви дізнаєтесь:

• Вступ
• Оцінки сюжетних балів у Agile
• Рекомендований інструмент
• Різні методи спритного оцінювання
  • # 1) Планування покеру
  • # 2) Розміри футболки
  • # 3) Точкове голосування
  • # 4) Ковшова система
  • # 5) Великий / Невизначений / Маленький
  • # 6) Картування спорідненості
  • # 7) Метод замовлення
• Розрахунок бюджету в Agile
• Шаблони оцінки в проекті Agile Development
  • 1) Швидкий шаблон плану проекту:
  • 2) Шаблон гнучкого плану випуску:
  • 3) Швидкий шаблон відставання товару:
  • 4) Швидкий шаблон відставання спринтів:
  • 5) Швидкий шаблон плану випробувань:
  • 6) Швидкий шаблон історії користувача:
  • 7) Швидкий шаблон дорожньої карти:
• Етапи оцінки в Agile Project
  • # 1) Оцінка пропозиції або рівня проекту
  • # 2) Оцінка рівня випуску
  • # 3) Оцінка рівня спринту
• Висновок
• Рекомендована література

Вступ

Нижче наведено 3 основні рівні Agile Estimation.

# 1) Рівень проекту або пропозиції - це той, який використовує швидкий аналіз функціональних точок на початкових етапах розробки проекту.

# 2) Рівень випуску включає в себе призначення точок історії історіям користувачів, які можуть допомогти визначити порядок історій користувачів на основі пріоритету, а також можуть вирішити, які історії можна взяти в поточному випуску, а які - пізніше.

# 3) Рівень спринту це той, де історії користувачів розбиваються на завдання, а завданням призначаються розрахункові години відповідно до їх складності. Тут ми також визначаємо особу, відповідальну за завдання, разом із статусом завдань.

Цю інформацію згодом можна використовувати для розрахунку бюджету проекту Agile. Розрахунок бюджету має вирішальне значення для того, щоб переконатись, що проект не перевищує бюджет через завдання до ітерації до і після або з інших причин.

Оцінки сюжетних балів у Agile

Оцінки Story Points - це порівняльний аналіз, який дозволяє приблизно оцінити відставання товарів із відносним розміром. Серед членів команди для оцінки історій користувачів є: власник продукту, майстер Scrum, розробники, тестувальники та власники ставок.

Нижче наведено кілька кроків для досягнення остаточного рішення щодо відносного розміру:

# 1) Проаналізуйте всі історії користувачів та визначте базову історію або посилання. Це важливо для відносного розміру. Цю історію можна вибрати з поточного відставання продукту або з того, що ми вже робили раніше. Цю історію слід обирати як довідкову за погодженням усіх членів.

# два) Виберіть іншу історію з поточного відставання продукту, і члени команди можуть вільно обговорювати будь-які питання чи сумніви з власником продукту, одночасно розуміючи вимоги історії. Власник продукту несе відповідальність за роз'яснення всіх своїх запитань та сумнівів.

# 3) Складіть список речей, про які слід подбати, реалізуючи історію користувача. Це можна зробити, написавши нотатки в розділі нотаток інструменту, або додавши пункти маркера на картці історії. В основному це робить Scrum Master.

# 4) Нижче наведено декілька поширених запитань серед учасників:

• Дизайн: Які попередні та обов’язкові знання ми повинні мати перед початком роботи над цим?
• Кодування: Скільки кодування потрібно для реалізації цієї історії користувача. Чи ми раніше стикалися з якоюсь подібною історією користувача?
• Одиничне тестування: Чи потрібні будь-які фіктивні об’єкти для проведення модульного тестування для цієї історії користувача?
• Тестування інтеграції: Чи впливає ця історія на інші функції того самого модуля та інших модулів?
• Прийомне тестування: Які моменти слід подбати, щоб доставити бажаний товар за бажанням Клієнтів?
• Експертиза: Хтось із учасників вже робив подібну історію і є фахівцем у цьому?

# 5) Зробіть відносний розмір для вибраної історії. Якщо для цього потрібні однакові обсяги роботи та зусиль, тоді призначте їм той самий номер. балів, призначених еталонному матеріалу. Якщо це вимагає більше зусиль, призначте йому якесь вище значення. Якщо для цього потрібно менше зусиль, призначте йому якесь нижче значення.

# 6) Досягти консенсусу з усіма учасниками, щоб визначити відносний розмір для вибраної історії користувача відповідно до визначення готового.

що таке тестування функціональності на прикладі

# 7) Після відносного розміру всіх елементів відставання товару було зроблено, переконайтеся, що якщо всі історії користувачів із однаковим номером. пунктів, призначених їм, вимагають однакових зусиль та розміру, щоб бути послідовними.

Рекомендований інструмент

# 1) Agile Poker

Agile Poker це добре відомий додаток для Jira для швидкого та зручного планування та оцінок як для віддалених, так і для спільних команд.

Початок роботи з Agile Poker простий і легкий, оскільки він був натхненний трьома галузевими методологіями оцінки: Planning Poker®, широкосмуговим Delphi та Magic Estimation (також відомими як безшумне групування, оцінка спорідненості, розмір Swimlanes або відносні оцінки).

Різні методи спритного оцінювання

У 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. Це робиться для того, щоб переконатися, який фактично передбачений бюджет, який ще бюджет потрібен і як ми розподілимо бюджет для різних статей відставання товару.

Він використовує дані, зібрані з попередніх проектів, і використовує математичну формулу для отримання розрахункового бюджету поточного проекту.

Нижче наведена послідовність кроків для розрахунку бюджету в проекті Agile:

# 1) Перерахуйте всі вимоги проекту та виконайте кошториси для них, використовуючи Planning Poker, Bucket System, серію Фібоначчі тощо. Усі члени команди повинні узгодити оцінки, зроблені для перелічених вимог, після чіткого аналізу та розуміння історій користувачів. Оцінки проводяться на основі функцій, які слід впровадити в історію користувача.

# два) Визначте тривалість ітерацій, які називаються спринтами, та призначені їй елементи відставання товару. Зазвичай це 2-3 тижні. Історії користувачів вибираються в послідовності, починаючи з історії користувача максимального пріоритету, переходячи до меншого пріоритету та з найменш пріоритетною історією користувача в кінці. Це допомагає прийняти рішення про те, які історії користувачів потрібно взяти в першому Sprint, а які історії можна взяти пізніше.

# 3) Підготуйте згорілу діаграму, щоб дати чітке уявлення про те, скільки роботи ще потрібно виконати, проти того, скільки часу залишається для реалізації. В основному це дає показник прогресу спритної команди. Це дає чітке уявлення про те, як команда поводиться і як від неї очікують.

Прогрес команди вимірюється як виконані завдання, залишкові зусилля, ідеальне згортання та залишені завдання, як показано нижче:

# 4) Додайте додаткові витрати, такі як придбання обладнання, інструменти, підтримка інфраструктури, отримання ліцензій на використовувані програмні засоби, Інструменти управління проектами, встановлення та оновлення антивірусів.

# 5) Додайте бюджети попередньої та післяітераційної перевірки. Всі спритні члени повинні бути міжфункціональними, але це має обмеження. Все, що робить член команди поза його компетенцією, вважається роботою перед ітерацією або роботою після ітерації. Ці роботи до і після ітерації вимагають додаткового бюджету на впровадження.

# 6) Слідкуючи за прихованими ризиками. Ризики в проекті Agile включають: ризик перевищення бюджету проекту, відсутність членів команди, члени не мають чітких або повних знань, члени не мають необхідних навичок, терміни перетнуті тощо,.

Шаблони оцінки в проекті Agile Development

У проекті розвитку Agile існує безліч шаблонів оцінок, які підготовлені на різних рівнях. Єдина мета - чітко сформулювати кошториси, необхідні для реалізації вимоги чи пункту та відстеження її прогресу.

Основні шаблони наведені нижче:

1) Швидкий шаблон плану проекту:

Це дає високий рівень уявлення про те, скільки часу потрібно для надання характеристик вимог і який їх статус. У ньому також згадується особа, відповідальна за конкретне завдання.

(Примітка: Клацніть на будь-яке зображення для збільшення)

2) Шаблон гнучкого плану випуску:

Він надає деталі випуску завдань, що відповідають вимогам, а також їх статус та Спринт, в якому їх потрібно виконати.

3) Швидкий шаблон відставання товару:

Він описує повне відставання продукту, визначене для проекту. Тут детально описуються завдання Спринтів, а також статус, пріоритет, моменти сюжету та те, чи вони призначені Спринту, чи є якісь додаткові завдання, такі як дефекти тощо.

4) Швидкий шаблон відставання спринтів:

У ньому дається опис історій користувачів, згаданих у відставанні певного Sprint. Він надає загальну кількість балів історії, призначених для історії користувача, і те, як вони розбиті на різні завдання. Він також надає статус відповідних завдань і те, яка робота проводиться щодня для відповідних завдань.

5) Швидкий шаблон плану випробувань:

Він розбиває весь сценарій тесту на підсценарії. Він надає детальну інформацію про такі сценарії, як дата реалізації, очікуваний результат, фактичний результат, стан тощо.

У ньому також згадується Назва проекту, Сумісний браузер, Версія тестованої програми, Ідентифікатор тестового випадку для обраного сценарію, Написав, Перевірив, Опис тощо.

6) Швидкий шаблон історії користувача:

Він надає деталі, характерні для аналізу історії користувача, такі як Які ролі потрібні для тестування конкретної функціональності, яка попередня вимога (налаштоване середовище та включені посилання) та який очікуваний результат?

7) Швидкий шаблон дорожньої карти:

Це дає вказівки щодо проекту в компанії на короткострокову та довгострокову основі. Це допомагає визначити очікування в компанії. І огляд того, куди рухається проект.

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

У проекті Agile оцінки проводяться на 3 рівнях, як зазначено нижче:

• Рівень проекту / пропозиції: Загальний функціональний розмір усієї програми оцінюється за допомогою методу швидкого аналізу точок функцій (QFPA), коли доступні лише вимоги високого рівня.
• Рівень випуску: Точки сюжету присвоюються історіям користувачів, які допомагають у визначенні числа. випусків, запланованих в рамках проекту, та №. історій користувачів, які будуть взяті у випуску та спринті.
• Рівень спринту: Орієнтовні години призначаються завданням історій користувачів у спринті. Це робиться для того, щоб забезпечити цілеспрямованість розробки для доставки історій користувачів у спринті.

S1, S2, S3, S4, S5, S6 - спринти.

# 1) Оцінка пропозиції або рівня проекту

Це дуже висока оцінка проекту. Він зосереджується на загальній кількості вимог у пункті «Відставання товару». Функціональні точки використовуються для оцінки розміру програмного забезпечення / проекту до того, як буде задокументований детальний опис функціональних вимог.

Функціональні точки - це загальновизнаний спосіб обчислення розміру програмного забезпечення. Основна увага приділяється функціональним можливостям програмних проектів. Точка функції - це метрика, яка перетворює вимоги або історії користувачів у число.

На початкових етапах проекту рекомендується застосувати метод швидкого аналізу функціональних точок (QFPA).

Метод швидкого аналізу точок функцій - це унікальний підхід для оцінки FP, коли доступні лише вимоги високого рівня.

Як розрахувати загальний функціональний розмір?

• Розуміти всі функціональні можливості програми за допомогою експертів доменів.
• Визначте та перелічіть усі можливі функціональні можливості програми.
• Функції зберігання даних класифікуються на Внутрішні логічні файли (дані, що зберігаються всередині програми) та Файли зовнішнього інтерфейсу (дані, що використовуються лише для довідкових цілей).
• Функції транзакцій класифікуються на Зовнішні входи (дані, що надходять із зовнішніх джерел до програми), Зовнішні виходи (похідні дані надходять із програми назовні) та Зовнішні запити (дані, отримані з одного або декількох Зовнішніх входів та Зовнішніх виходів).
• Розрахуйте розмір FP для кожної функції, обчислюючи її середню складність.
• Підсумуйте розмір FP всіх функцій, щоб отримати загальний функціональний розмір програми.
• Принаймні дві особи, які мають досвід у аналізі ПЗ, повинні самостійно підрахувати, зіставити результати та вирішити розбіжності.

Приклад для оцінки рівня проекту:

Нижче наведено перелік вимог до проекту, як у Відставанні продукту:

• Користувач повинен мати можливість входу на веб-сайт, вказавши ім’я користувача та пароль.
• Після успішного входу користувач повинен бути переведений на головну сторінку з визначеними правою та лівою панелями.
• Користувач повинен мати можливість вийти з програми.
• Дійсний користувач має можливість змінити пароль, надавши поточні дані.

Команда використовує швидку оцінку FP для оцінки розміру проекту.

Далі проводиться аналіз:

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

Нижче наведені кроки для оцінки розміру проекту за допомогою швидкого аналізу точок функцій:

КРОК 1: Перелічіть усі функції даних

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

КРОК 2: Перелічіть усі транзакційні функції

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

КРОК №3: Виведення передбачуваного розміру проекту у функціональних точках

UFP = FP даних + FP транзакції

UFP = 10 + 12 = 22 UFP

FP = UFP * VFP = 22 * ​​1 = 22 FP (припускаючи VFP (коефіцієнт коригування значення = 1)

10 найкращих кадрових агентств у світі

Продуктивність = 16 FP / місяць (нормальний стандарт)

Зусилля = FP / Продуктивність = 22/16-місячний місяць = 1,37-місячний чоловік

# 2) Оцінка рівня випуску

Оцінки рівня випуску проводяться під час планування випуску. Це наступна діяльність після оцінки рівня проекту. Пріоритетні вимоги взяті з відставання продукту, яке є у формі Історій користувачів.

Історії користувачів оцінюються з точки зору сюжетів під час планування випуску, який зосереджується на оцінці розміру програмного забезпечення, яке буде доставлено для цього випуску. Таким чином, не планується жодного випуску та загальної кількості сюжетних балів у кожному випуску.

Історія в основному представляє відносні зусилля, необхідні для реалізації функції або функціональності, порівняно з іншими функціями. В основному він призначений для визначення елементів відставання товару.

Оцінка сюжетних балів проводиться на основі:

• Складність реалізованої функції.
• Досвід та технічні навички всіх членів.

S1, S2, S3, S4, S5 - це спринти.

Кроки для призначення точок історії для історії користувача:

• Усі члени команди збираються за столом, переглядаючи історії користувачів, присутні в списку спринтів.
• Вирішено значення однієї сюжетної точки та відповідних зусиль.
• Один із членів команди зачитує історію користувача, а потім просить членів команди призначити відносні очки історії.
• Якщо між історіями, призначеними членами команди, є суттєва різниця, вони дають пояснення для пунктів історії, які вони призначили, тим самим досягаючи консенсусу в кінці.
• Процес повторюється 3-4 рази, поки не буде суттєвої різниці між оцінками, даними членами команди.
• Розмір історій допомагає визначити, скільки історій буде зроблено протягом спринту та випуску.

Приклад для оцінки рівня випуску:

Сюди входить створення пріоритетного списку Історій користувачів, який називається Відставання товарів. Власник продукту створює відставання товару та надає ділову цінність для кожного з перелічених у ньому елементів.

Ми можемо використовувати наведені нижче методи для оцінки очок:

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

Оцінка вищезазначених історій користувачів за допомогою послідовності Фібоначчі:

# 3) Оцінка рівня спринту

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

Завдання оцінюються в розрахункових годинах, тобто часу, необхідному для виконання цього завдання для відповідної історії користувача. Підхід знизу вгору використовується для оцінки Завдання, де бізнес-вимоги розбиті на низькорівневі види діяльності, і кожному виду діяльності присвоюються розрахункові години.

Мета оцінок - дізнатись, скільки історій користувачів команда розробників може призначити для Sprint. Розробка повинна відповідати зобов'язанням, а власники продуктів повинні бути впевнені, що команда виконає зобов'язання.

S кроки для призначення передбачуваних годин для завдань:

• Члени команди підбирають історії користувачів. Потім їх просять оцінити фактичні зусилля, в годинах або днях, для виконання завдань, що відповідають історії користувача.
• Якщо в цих оцінках є розбіжності серед членів команди, вони обговорюють це і приходять до консенсусу.
• Якщо якесь завдання триває більше шести годин, воно ділиться на менші завдання.
• Якщо є два або більше завдань із розрахунковими годинами менше двох, тоді вони об’єднуються, щоб сформувати нове завдання.

Приклад для оцінки рівня спринту:

Є дві частини зустрічі з планування спринту:

• Перша частина: Основна увага приділяється уточненню вимог до історій користувачів, вибраних із відставання продуктів.
• Друга частина: Основна увага приділяється розбиванню вимог на завдання та оцінці годин, необхідних для їх виконання. Повинні бути включені всі завдання, необхідні для того, щоб забезпечити достатній товар. Завдання повинні бути невеликими. В ідеалі завдання не повинно тривати більше шести годин.

Висновок

Оцінки в проекті Agile відіграють важливу роль для забезпечення належного керівництва, планування та управління. Він надає кроки щодо подальшої реалізації проекту.

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

Єдина мета - встановити елементи в порядку пріоритету від максимального пріоритету до мінімального пріоритету. Відносні розміри, розраховані для елементів відставання товару, допомагають оцінити або розрахувати бюджет, необхідний для проекту.

Сподіваюся, ви отримали б глибоке розуміння оцінок гнучких проектів. Не соромтеся висловлювати свої думки щодо цього підручника у розділі коментарів нижче.

Рекомендована література

• Як полегшити рухливий процес оцінки за допомогою планування покеру
• Agile Vs Waterfall: яка найкраща методологія для вашого проекту?
• Методи оцінки тестування програмного забезпечення (Повний посібник з оцінки тестових зусиль)
• Підручник з VersionOne: Посібник із інструментів гнучкого управління проектами «все в одному»
• Підручник з портфоліо Jira: Плагін Agile Project Portfolio Management для JIRA (огляд)
• ТОП 10 найкращих інструментів гнучкого управління проектами у 2021 році
• Підґрунтя для успішної спритної подорожі: як правильно вибрати метод, інструменти та методи
• 4 кроки до розробки гнучкого мислення для тестування для успішного переходу до гнучкого процесу