nmk

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

Тема: Моніторинг та звітність розробки (Agile Metrics)

Практика використання інструментів трекінгу для аналізу прогресу команди. Розуміння графіків Burn-down Chart, метрики Velocity (Швидкості команди) та пошук “вузьких місць” (Bottlenecks) на дошці.

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

Технологічний стек: Теоретичний аналіз даних (Google Sheets / Excel) + скріншоти графіків.

Завдання

Заповнена дошка в Jira — це лише інструмент управління сьогоденням. Для прогнозування майбутнього PM використовує звіти та метрики. У цій роботі ви виступите в ролі Scrum Master / PM, який аналізує поточний стан Спринта та робить висновки.

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

  1. Проаналізувати та пояснити графік Burn-down Chart (Діаграма згоряння задач).
  2. Розрахувати Velocity (Швидкість) вашої навчальної команди для наступних Спринтів.
  3. Провести аналіз гіпотетичного “вузького місця” (Bottleneck) на Kanban-дошці.

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

Крок 1. Аналіз Burn-down Chart

Burn-down Chart — це основний графік у Scrum. Він показує, скільки роботи (у Story Points або годинах) залишилося зробити до кінця Спринта. Ідеальний графік — це пряма лінія, що рівномірно йде вниз (від загальної кількості балів до нуля в останній день).

Ваше завдання: Знайдіть в Інтернеті зображення реального (не ідеально рівного) графіка Burn-down Chart (з Jira, Trello або іншої системи), де видно певні проблеми під час Спринта (наприклад: лінія довгий час йшла горизонтально, або наприкінці стався різкий спад).

  1. Вставте цей скріншот у звіт.
  2. Напишіть міні-аналітику (3-4 речення): Що пішло не так у цьому Спринті згідно з графіком? (Наприклад: “З 3-го по 6-й день задачі не закривалися, можливо, був заблокований тестовий сервер. Або команда взяла забагато задач і не встигла все закінчити”).

Крок 2. Розрахунок Velocity (Швидкості команди)

Velocity — це середня кількість Story Points (або задач), які команда здатна повністю завершити за 1 Спринт. Це єдиний спосіб реалістично планувати наступні релізи.

Ваше завдання: Уявіть статистику вашої команди за останні 3 Спринти (по 2 тижні кожен):

  1. Запишіть ці гіпотетичні дані у звіт.
  2. Розрахуйте поточний Average Velocity (Середню швидкість) вашої команди (формула: середнє арифметичне реально виконаних балів за останні 3 спринти).
  3. Кейс: Замовник хоче, щоб у Sprint 4 ви додали нову складну фічу, яка оцінена в 45 Story Points. Як Project Manager, що ви йому відповісте, спираючись на розрахований вами Velocity? Напишіть 1 речення вашої аргументованої відповіді.

Крок 3. Виявлення вузьких місць (Bottlenecks)

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

Ваше завдання: Опишіть у звіті вирішення наступної проблеми:

На вашій Kanban-дошці зараз така ситуація:

У вас в команді: 4 розробники і 1 QA Engineer.

Запитання для звіту:

  1. Де утворюється вузьке місце і чому воно виникло?
  2. Яке правило (з Лабораторної №4 про Kanban) було порушено, раз виникла така ситуація?
  3. Практичне рішення: як розв’язати цю проблему зараз, не наймаючи нового тестувальника? (Що змусити робити розробників, у яких закінчилися їхні задачі в колонці In Progress?).

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

  1. Що таке Burn-up Chart (Діаграма згоряння нагору) і чим вона візуально та інформаційно відрізняється від Burn-down Chart?
  2. Чому метрику Velocity категорично заборонено використовувати для порівняння двох різних команд (наприклад: Команда А робить 50 Story Points, а Команда Б - 20, отже Команда А працює краще)?
  3. Що показує звіт Sprint Report у системі Jira (які три списки задач він зазвичай включає після завершення Спринта)?
  4. Як правило WIP limits (Work In Progress Limits) допомагає автоматично виявляти вузькі місця на Kanban-дошці?
  5. Якщо графік Burn-down в середині Спринта раптово пішов вгору (лінія піднялася вище, ніж була вчора) — яка типова ситуація на проєкті це спричинила?

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

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