nmk

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

Тема: Моделювання процесів Scrum

Практичне застосування Scrum-фреймворку: розподіл ролей, формування списку вимог (Product Backlog), планування спринта (Sprint Planning) та симуляція щоденного мітингу (Daily Scrum).

Мета: Закріпити теоретичні знання про гнучку методологію Scrum через практичне створення її ключових артефактів (Backlog, Sprint) для навчального проєкту.

Технологічний стек: Google Docs / Microsoft Word / Trello (за бажанням, для візуалізації беклогу).

Завдання

У цій роботі ви продовжите розвивати ідею проєкту, обрану в Лабораторній роботі №1 (або можете придумати нову ідею програмного продукту). Вам необхідно “зіграти” в Scrum: розподілити базові ролі вашої уявної команди, створити загальний список вимог до продукту і спланувати один тиждень розробки.

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

  1. Визначити 3 ключові ролі Scrum для вашого проєкту.
  2. Створити Product Backlog (мінімум 10 елементів).
  3. Провести Sprint Planning і сформувати Sprint Backlog.
  4. Змоделювати проведення одного Daily Scrum (щоденного мітингу).

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

Крок 1. Розподіл Scrum-ролей

Уявіть, що ви починаєте розробку вашого проєкту (наприклад, мобільного додатку для кафе). У довільній формі опишіть, хто у вашому проєкті виконує ключові ролі згідно з класичним Scrum Guide:

  1. Product Owner (Власник продукту): Хто ця людина (можете вигадати ім’я та посаду), на чому вона зосереджена і чим допомагає розробникам?
  2. Scrum Master: Які його основні обов’язки у вашому конкретному проєкті (від чого він захищає команду)?
  3. Development Team (Команда розробки): Скільки людей? Які в них технічні спеціалізації?

Запишіть цю інформацію у звіт.

Крок 2. Формування Product Backlog (Беклог продукту)

Product Owner (Ви) має скласти список усього, що потрібно зробити, щоб проєкт став успішним. На цьому етапі вимоги можна писати просто звичайними реченнями (не обов’язково у форматі User Stories).

Створіть таблицю з 10 рядків. Кожен рядок — це окрема “фіча” (вимога) до вашого продукту. Обов’язково відсортуйте (пріоритезуйте) ці 10 пунктів у таблиці: найважливіші фічі (без яких продукт не працює) повинні бути нагорі (номери 1, 2, 3), а найменш важливі чи “гарні додаткові фішки” (наприклад, зміна теми додатку) — внизу.

Пріоритет Назва фічі / Вимога Короткий опис, що має робити система
1 Авторизація користувача Можливість увійти за допомогою email та пароля
… … …
10 Темна/світла тема Перемикач інтерфейсу в налаштуваннях профілю

Крок 3. Створення Sprint Backlog (Беклог спринту)

Уявіть, що ви проводите мітинг Sprint Planning. Ви вирішуєте, що ваш перший Спринт буде тривати 2 тижні.

З вашого щойно створеного Product Backlog-у оберіть 3 або 4 найважливіші верхні задачі, які команда зобов’язується зробити за ці 2 тижні.

Створіть у звіті заголовок Sprint Backlog (Спринт 1) і перерахуйте обрані задачі. Під цим списком напишіть Мету Спринту (Sprint Goal) — одне речення, яке пояснює, ЩО саме ви покажете замовнику в кінці цих двох тижнів. (Приклад мети: “Створити базовий каркас додатку, в якому користувач може зареєструватися та побачити головне меню”).

Крок 4. Симуляція Daily Scrum

Уявіть, що йде 3-й день вашого поточного Спринту. Команда збирається на 15-хвилинний мітинг біля дошки. Кожен розробник повинен відповісти на 3 класичні запитання Scrum.

Для звіту напишіть пряму мову (відповіді) від імені двох уявних розробників (назвіть їх наприклад Розробник Олена і QA-інженер Іван). Вони мають відповісти на:

  1. Що я зробив вчора (щоб допомогти команді досягти Мети Спринту)?
  2. Що я зроблю сьогодні?
  3. Які є перешкоди (Blockers) на моєму шляху? (Хтось із них має обов’язково озвучити якусь проблему, яку повинен буде вирішувати Scrum Master).

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

  1. Хто з команди (яка роль) має виняткове право додавати нові вимоги в Product Backlog або змінювати їх пріоритет? Кому НЕ можна цього робити?
  2. Чим відрізняється Product Backlog від Sprint Backlog?
  3. Що має зробити команда розробників, якщо посеред розпочатого Спринту замовник телефонує і вимагає терміново додати “ще ось цю зелену кнопочку”?
  4. Яка основна мета проведення короткого щоденного мітингу (Daily Scrum)? Чому там заборонено влаштовувати годинні технічні дискусії?
  5. Назвіть 4 обов’язкові події (Events / мітинги) у Scrum-фреймворку, окрім самого Спринту.

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

  1. У створеному репозиторії курсу на GitHub (або в існуючому, додавши новий файл) створити файл lab_03.md.
  2. В цей файл перенести результати виконання Кроків 1, 2, 3 і 4 (Розподіл ролей, таблицю Product Backlog, Sprint Backlog + Мету спринту, та короткий “сценарій” Daily Scrum).
  3. У файлі lab_03.md дати письмові відповіді на всі 5 контрольних запитань.
  4. Завантажити зміни на GitHub та надіслати посилання викладачу.