nmk

Лабораторна робота №7 (2 години)

Тема: Оцінка часу та Planning Poker

Практика оцінювання тривалості (Estimation) IT-задач двома протилежними підходами: відносною Agile-оцінкою у Story Points (на базі чисел Фібоначчі) та математичним розрахунком часу за класичним методом PERT.

Мета: Навчитися визначати складність розробки функціоналу без прив’язки до точних годин (Story Points) та проводити триточкову оцінку ймовірності (PERT) для складних τεχνічних завдань у Waterfall-проєктах.

Технологічний стек: Google Docs / Microsoft Word / Excel (для PERT-розрахунків).

Завдання

Програмування важко оцінити в годинах. Дизайнер може швидко намалювати кнопку, але підключення її до стороннього API може зайняти непередбачуваний час. Вам необхідно застосувати дві різні техніки оцінки до трьох уявних (або реальних з вашого проєкту) задач.

Перелік завдань:

  1. Визначити еталонну задачу (Story Point = 1).
  2. Оцінити 3 задачі у Story Points, аргументувавши вибір числа Фібоначчі.
  3. Оцінити 1 задачу за методом PERT (розрахувати Очікуваний час та Стандартне відхилення).

Хід виконання роботи

Крок 1. Відносна оцінка: Вибір еталону (Story Point)

В Agile (Scrum) ми не питаємо програміста “Скільки годин це займе?”. Ми запитуємо: “Наскільки ця задача більша за найпростішу?”. Оцінка базується на послідовності Фібоначчі: 1, 2, 3, 5, 8, 13, 21. (Більше 21 брати не варто — таку задачу треба розбивати на менші).

Спочатку оберіть зі свого проєкту найпростішу, тривіальну задачу, яку повністю зрозуміло як робити. Наприклад: “Змінити колір фону в шапці сайту” або “Додати поле ‘По батькові’ у форму реєстрації”. Присвойте їй значення 1 Story Point (SP).

Опишіть вашу еталонну задачу (1 SP) у звіті.

Крок 2. Оцінка задач у Story Points (Симуляція Planning Poker)

Тепер оберіть з вашого Беклогу (що був створений в Лаб №3) або придумайте 3 різні за складністю задачі (наприклад: одну середню, одну складну, одну дуже складну).

Для кожної задачі дайте оцінку в числах Фібоначчі (порівнюючи її з вашим еталоном “1 SP”). У звіті заповніть наступну структуру для всіх 3-х задач:

Задача 1: [Назва задачі]

Крок 3. Триточкова оцінка PERT (Program Evaluation and Review Technique)

Метод PERT використовується у серйозних, дорогих проєктах. Він вимагає від програміста назвати 3 цифри замість однієї.

Уявіть дуже складну технічну задачу: “Міграція бази даних користувачів зі старого сервера на новий хмарний AWS”.

Ви, як розробник, оцінили її так:

Використовуючи формули розподілу Бета, розрахуйте:

  1. Очікуваний час (E): E = (O + 4*M + P) / 6
  2. Стандартне відхилення (SD): SD = (P - O) / 6

Наведіть детальний розрахунок цих двох формул у вашому звіті. Як PM, яку кількість годин ви запишете в план проєкту після цього розрахунку?

Контрольні запитання

  1. Чому при грі в “Planning Poker” (коли команда оцінює задачу) всі розробники показують свої карти з оцінками одночасно, а не називають їх по черзі?
  2. Які три фактори (окрім суто витраченого часу) зазвичай включають у себе Story Points (наприклад, Складність… що ще?)
  3. Чому в послідовності оцінок Planning Poker використовують числа Фібоначчі (1, 2, 3, 5, 8, 13, 21), а не просто підряд (1, 2, 3, 4, 5, 6, 7)?
  4. Що означає цифра “Стандартне відхилення” (SD) у методі PERT? Що означає для керівника проєкту, якщо це відхилення дуже велике (наприклад, 15 годин)?
  5. Який з цих двох методів (Story Points чи PERT) ви б обрали для проєкту зі створення сайту-візитки для перукарні, а який — для розробки ПЗ автопілота автомобіля? Чому?

Вимоги до звіту

  1. У репозиторії курсу на GitHub додати файл lab_07.md.
  2. В цей файл перенести результати виконання Кроків 1, 2 і 3 (Опис еталонної задачі, оцінка 3-х задач у Story Points з аргументацією, математичні розрахунки за PERT).
  3. У файлі lab_07.md дати письмові відповіді на всі 5 контрольних запитань.
  4. Завантажити зміни на GitHub та надіслати посилання викладачу.