nmk

Лекція №9 (4 години). Моніторинг виконання прогресу, інструменти управління та дошки задач

План лекції

Відстеження прогресу команди в Agile: Velocity, Burndown та Burnup charts.
Управління змінами в проєкті: формальний процес (Change Request) vs Agile-адаптивність.
Огляд сучасних систем управління проєктами: Jira Software, Trello, Asana.
Управління знаннями та документацією (Confluence).
Принципи налаштування Kanban та Scrum дошок для розробників.
Інтеграція PM-інструментів із системами контролю версій (GitHub, GitLab) та системами CI/CD.

Перелік умовних скорочень

KPI (Key Performance Indicator) — ключовий показник ефективності;
Velocity — швидкість команди в Agile (вимірюється в Story Points);
CI/CD (Continuous Integration / Continuous Deployment) — безперервна інтеграція та розгортання;
CR (Change Request) — запит на зміну;
WIP (Work In Progress) — незавершені (в узяті в роботу) завдання.

Вступ

“Як справи з проєктом?” — просте запитання клієнта, яке часто вганяє Project Manager’а в піт. Досвідчений керівник ніколи не відповідає: “Все йде нормально, кодуємо”. Він відкриває дашборд (панель управління) і показує графіки, цифри та дошки задач, які математично доводять життєздатність проєкту та прогрес команди.

У сучасному IT ніхто не управляє задачами просто в Excel-таблицях. Інструменти, такі як Jira або Trello, стали стандартом індустрії. У цій лекції ми розберемо, як за допомогою метрик і графіків читати стан проєкту “як кардіограму”, чому важливо інтегрувати ваш менеджер задач з репозиторіями програмістів (GitHub) і як керувати неминучими змінами вимог від замовника.

1. Відстеження прогресу команди в Agile

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

Velocity (Швидкість команди)

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

Як рахується: Якщо в 1-му спринті команда закрила задач на 40 SP, у 2-му — на 45 SP, в 3-му — на 35 SP, то середня швидкість (Velocity) команди дорівнює 40 SP за спринт.
Застосування: Знаючи, що Product Backlog (всі вимоги до продукту) містить, наприклад, 600 SP, а швидкість команди становить 40 SP, ми можемо сказати клієнту: “Нам знадобиться 15 спринтів (600 / 40) для завершення проєкту” — і ця інформація буде математично підкріпленою, а не взятою зі стелі.

Діаграми згоряння та накопичення

Burndown Chart (Діаграма згоряння): Графік, що показує обсяг РОБОТИ, ЩО ЗАЛИШИЛАСЯ в спринті.
- Вісь X (горизонтальна) — дні спринту, Вісь Y (вертикальна) — залишок Story Points.
- Графік іде зверху вниз. Якщо лінія опускається нижче “ідеального тренду” — команда випереджає графік. Якщо лінія зависає нагорі (задачі не тестуються і не закриваються до останнього дня) — це сигнал про проблеми в процесі (Bottleneck на етапі QA).
Burnup Chart (Діаграма накопичення): Графік, що показує обсяг ВИКОНАНОЇ роботи та загальний обсяг робіт проєкту.
- Лінія росте знизу вгору. Цей графік набагато краще підходить для комунікації з клієнтом, оскільки на ньому чудово видно, коли клієнт додає нову роботу (Scope Creep) під час розробки: лінія загального обсягу (Total Scope) на графіку підстрибує вгору, відсуваючи фінал.

2. Управління змінами: Traditional vs Agile

Зміни вимог — це невідворотна частина ІТ: клієнт побачив новий продукт у конкурента, закони країни змінилися, бета-тестувальники не зрозуміли інтерфейс.

Традиційний формальний підхід (Change Request Process): Використовується при контрактах Fixed-Price або на державних проєктах. Будь-яка нова “кнопочка” проходить забюрократизований процес:

Замовник створює документ Change Request (CR) з описом нової ідеї.
Команда аналізує, як ця зміна вплине на (а) архітектуру, (б) бюджет, (в) розклад.
PM формує відповідь: “Зміна варта $500 і 3 дні”.
Скликається Рада з управління змінами (Change Control Board - CCB) за участі спонсорів для ухвалення чи відхилення запиту через підписання додаткової угоди до контракту. Недолік: Процес займає тижні. Якщо ринок швидко змінюється, це вбиває проєкт.

Agile адаптивність: В Agile інший майндсет: зміни — це конкурентна перевага клієнта.

Зміни НЕ БЛОКУЮТЬСЯ.
Процес: Product Owner просто заносить нову ідею у Backlog продукта (загальний список) і надає їй найвищий пріоритет. На наступному Planning мітингу (який відбудеться максимум через 2 тижні) команда бере цю нову фічу в роботу.
Єдине правило: Заборонено змінювати вимоги або додавати нові задачі всередині поточного активного спринту (щоб не ламати концентрацію розробників).

3. Огляд систем управління проєктами (PM Tools)

Не кожен інструмент підходить для кожної команди. Розглянемо лідерів ринку:

Jira Software (від Atlassian):
- Стандарт індустрії для середніх і великих IT-команд.
- Підтримує Scrum і Kanban дошки, глибоке управління дозволами, звіти (ті самі Burndowns), тайм-трекінг.
- Має власну мову запитів JQL (Jira Query Language) для створення потужних фільтрів.
- Мінус: Досить складна в налаштуваннях для невеликих стартапів, потребує адміністратора.
Trello:
- Найпростіший Kanban-інструмент (віртуальна дошка з картками). Куплений компанією Atlassian.
- Ідеальний для маленьких команд, фрілансерів, маркетологів. Не має складних ієрархій або спринтів “з коробки” (все робиться через плагіни).
Asana:
- Прекрасний баланс між розширеним функціоналом управління проєктами та простотою інтерфейсу. Добре підходить для багатопрофільних диджитал-агентств (де IT-розробка межує з маркетингом і копірайтингом).

4. Управління знаннями (Confluence)

Якщо Jira відповідає на запитання “Що і Коли ми маємо зробити?”, то інструмент Confluence (або аналоги на кшталт Notion) відповідає на запитання “Чому і Як?”.

IT-проєкт гине, коли знання залишаються в головах розробників: “Як розгорнути локальну базу даних знає тільки Вася. Вася у відпустці. Робота стоїть”. Для подолання цієї “автобусного фактора” (Bus Factor) використовують внутрішню Wiki проєкту.

Що зазвичай зберігають у Confluence:

Технічну документацію (описи API, архітектурні схеми);
Інструкції з онбордингу (Onboarding Guides) — що має зробити новий програміст у свій перший робочий день (і де взяти доступи);
Business Requirements (звичні нам SRS);
Записи ретроспектив і мітингів;
Правила написання коду (Code Standards) та процес Release-менеджменту.

5. Налаштування дошок (Kanban та Scrum Board)

Хороша віртуальна дошка — це інструмент, одного погляду на який достатньо, щоб зрозуміти стан речей. Дошка складається з колонок, які відповідають життєвому циклу розробки фічі (Workflow).

Типовий Workflow розробки ПЗ:

To Do (Backlog): Завдання, які плануються, але ще не узяті в роботу.
In Progress (В розробці): Задачі, над якими просто ЗАРАЗ пишеться код. (Тут діє найголовніше правило Канбану: WIP Limit. Наприклад, ліміт = 3. Якщо в цій колонці 3 задачі, жоден розробник не має права брати четверту, навіть якщо вільний. Він має допомогти колегам закінчити існуючі, щоб не створювати заторів).
Code Review / Pull Request: Інший Senior-програміст перевіряє написаний код.
Testing (В тестуванні / QA): Задачу перевіряє тестувальник.
Done / Deployed: Код опублікований на Production сервері, задача завершена і приносить гроші.

Різниця між Scrum-дошкою і Kanban-дошкою: Scrum-дошка повністю “очищається” в кінці двотижневого спринту. Kanban-дошка — це нескінченний конвеєр без спринтів (ідеально для команд підтримки / Support Services).

6. Інтеграція PM-інструментів із CI/CD (GitHub/GitLab)

Щоб програмістам не доводилося витрачати час на заповнення звітів і ручне перетягування карток у Jira, сучасні інструменти глибоко інтегруються.

Як це працює у професійній команді:

У Jira створюється завдання з ідентифікатором, наприклад, PROJ-102.
Програміст, відкриваючи код-редактор і починаючи роботу, створює нову гілку в GitHub з назвою цього тікета: git checkout -b feature/PROJ-102-login-button.
Система Jira, побачивши зв’язок (через плагін), автоматично перетягує картку PROJ-102 на дошці з колонки “To Do” в колонку “In Progress”.
Коли розробник закінчує кодувати, він робить коміт (Commit) у GitHub зі словами Fixed PROJ-102 і відправляє код.
CI/CD пайплайн (наприклад, GitLab CI) перехоплює код, автоматично проганяє Unit-тести.
Якщо тести зелені (успішні), картка в Jira автоматично пересувається в колонку “Ready for QA”, а тестувальнику надходить Slack-повідомлення.

Суть інтеграції: Від команди розробників більше не вимагають “оновлювати статуси в таблицях”. Вони просто пишуть і “комітять” код, а системи управління прогресом зчитують метрики автоматично. Це кардинально зменшує опір технарів до інструментів менеджменту.

Висновки

Для вимірювання успіху Agile-команд використовують Velocity (швидкість у Story Points) та діаграми згоряння/накопичення (Burndown/Burnup Charts). Вони забезпечують прозору математичну базу для переговорів щодо строків релізу.
Процес обробки змін суттєво різниться: у傳統них (важких) проєктах необхідно заповнювати бюрократичні форми Change Request та проводити переговори щодо ціни, тоді як в Agile зміни просто потрапляють у Backlog із новим пріоритетом.
Jira Software стала стандартом управління завданнями розробників через великі можливості кастомізації, підтримку Scrum та глибоку інтеграцію; хоча для менших команд часто обирають простіший Trello.
Документація проєкту (як-от правила кодування, API та база знань для нових співробітників) повинна зберігатися у єдиній системі типу Confluence, щоб уникнути втрати знань (Bus factor).
Віртуальні дошки завдань повинні мати не лише базову структуру “Робиться - Зроблено”, а відображати реальний Workflow: з колонками для перевірки коду колегами (Code Review) та роботою відділу якості (QA).
Автоматизація рутини (наприклад, коли створення Pull Request у GitHub самостійно переміщує картку в Jira) є критично важливою для задоволення команди розробників (скорочення мікроменеджменту).

Джерела

Інститут управління проєктами (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide).
Майк Кон (Mike Cohn). Agile Estimating and Planning (розділи про Velocity та Burndown).
Atlassian University: Офіційна документація по Jira Software та Confluence.
Кім Джин, Humble J., Debois P. The DevOps Handbook (про важливість інтеграції CI/CD з інструментами трекінгу).

Запитання для самоперевірки

Опишіть своїми словами, що таке Velocity (Швидкість команди). Як ви, будучи PM, використаєте цей показник, якщо клієнт попросить зробити ще 200 Story Points нових функцій?
Чому графік Burnup (накопичення) краще показувати клієнтові, ніж графік Burndown (згоряння), якщо на проєкті постійно відбувається Scope Creep (додавання нових вимог)?
Порівняйте ставлення до процедури внесення змін (Change Request) у контрактах типу Fixed-Price (Водоспад) та гнучкому фреймворку Scrum.
У чому полягає критична небезпека зберігання важливої архітектурної інформації лише у головах розробників, і який інструмент вирішує цю проблему?
З якими етапами життєвого циклу розробки обов’язково повинна перетинатися картка завдання (Issue) в Jira, перш ніж потрапити до колонки “Done”? Опишіть базовий Workflow.
Як саме інтеграція трекера завдань (напр., Jira) із системою контролю версій (GitHub/GitLab) зменшує необхідність у ручному мікроменеджменті команди? За допомогою якої дії (наприклад, назви коміту) ці системи спілкуються між собою?