nmk

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

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

Організація безперервного потоку роботи за допомогою Kanban-дошки. Проєктування Workflow, встановлення WIP-лімітів (Work In Progress) та аналіз ефективності за метриками Cycle Time та Lead Time.

Мета: Навчитись візуалізувати потік роботи команди, визначати вузькі місця (bottlenecks) за допомогою обмежень незавершеної роботи та розраховувати базові метрики Agile-команд.

Технологічний стек: Trello / Jira Software (рекомендується для практики) або Google Docs / Microsoft Word / Miro (для моделювання дошки).

Завдання

Уявіть, що ви працюєте в команді підтримки IT-продукту (L3 Support або DevOps). У вас немає жорстких 2-тижневих спринтів. Задачі (баги, налаштування серверів) “падають” щодня. Ваша мета — налагодити рівномірний процес (flow), щоб програмісти не “вигорали” від мультитаскінгу, а задачі не губилися.

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

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

Спроєктувати Workflow Kanban-дошки (мінімум 5-6 колонок).
Встановити обґрунтовані WIP-ліміти.
Розрахувати Lead Time та Cycle Time для заданого сценарію.

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

Крок 1. Проєктування Kanban-дошки (Workflow)

Проста дошка “To Do -> In Progress -> Done” не підходить для серйозної IT-команди, бо не показує, ДЕ саме застрягає задача (на написанні коду чи на перевірці тестувальником).

Створіть у своєму звіті (або зробіть скріншот з Trello) власну дошку. У неї мають бути такі колонки (ви можете придумати свої назви):

Backlog (Черга всіх ідей).
Selected for Development (Готові до роботи, затверджені).
In Progress (Хтось зараз пише код).
Code Review (Інший програміст перевіряє код).
Testing (Тестувальник перевіряє роботу).
Done (Готово).

У звіт випишіть усі назви ваших колонок по порядку.

Крок 2. Встановлення WIP-лімітів (Work In Progress)

WIP-ліміт — це максимальна кількість карток (задач), яка може одночасно знаходитися в одній колонці. Суть Kanban — не брати нову задачу, поки не закінчиш стару.

Для вашої дошки (з Кроку 1) встановіть WIP-ліміти над кожною активною колонкою (Backlog і Done зазвичай не мають лімітів). Обґрунтуйте кожне число. Уявіть, що у вашій команді є: 3 Розробника та 1 Тестувальник (QA).

Приклад у звіті:

In Progress (WIP: 3) — тому що у нас 3 розробника, і кожен має робити лише 1 задачу одночасно (заборона мультитаскінгу).
Testing (WIP: X) — поясніть, який ліміт ви поставите для 1 тестувальника і чому.
Code Review (WIP: Y) — поясніть свою логіку (наприклад, щоб задачі довго не висіли в очікуванні перевірки).

Крок 3. Розрахунок метрик Lead Time та Cycle Time

Прочитайте наступний сценарій:

Замовник створив заявку (Ticket #105) “Кнопка оплати не працює” у понеділок, 1 числа о 10:00. Картка потрапила в Backlog. У середу, 3 числа о 10:00, програміст взяв її в роботу (перемістив у In Progress). Програміст писав код до п’ятниці (5 числа о 10:00), після чого перевів картку в Code Review. Того ж дня (п’ятниця, 5 числа, о 18:00), задачу перевірив QA і перевів у Done.

На базі цього сценарію розрахуйте у годинах чи днях (можете округлювати до діб):

Lead Time (Час виконання): Час від моменту появи ідеї (або заявки) до повної доставки клієнту (від створення до Done). Вимірює клієнт.
Cycle Time (Час циклу): Час, який розробники фактично витратили на роботу (від In Progress до Done). Вимірює команда.

Запишіть розрахунки та фінальні цифри у звіт.

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

Якщо програміст закінчив писати код своєї задачі, але колонка “Testing” повністю заповнена (досягнуто WIP-ліміт), що повинен робити цей програміст згідно з філософією Kanban?
У чому різниця між метрикою Lead Time та Cycle Time? Яка з них завжди більша (або дорівнює іншій)?
Що таке Bottleneck (“вузьке місце”) на Kanban-дошці і як WIP-ліміти допомагають його виявити?
Чи обов’язково розбивати роботу на 2-тижневі Спринти в методології Kanban?
Чому практика мультитаскінгу (коли один розробник одночасно робить 5 задач) вважається шкідливою і як Kanban з нею бореться?

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

У репозиторії курсу на GitHub додати файл lab_04.md.
В цей файл перенести результати виконання Кроків 1, 2 і 3 (Опис колонок дошки, обґрунтування значень WIP-лімітів, результати математичного розрахунку Lead та Cycle Time).
Додати скріншот вашої створеної дошки (з Trello/Jira/Miro), якщо ви її створювали візуально (за бажанням).
У файлі lab_04.md дати письмові відповіді на всі 5 контрольних запитань.
Завантажити зміни на GitHub та надіслати посилання викладачу.