nmk

Лекція №3 (4 години). Гнучкі методології розробки програмного забезпечення: Agile, Scrum, Kanban

План лекції

  1. Криза “Водоспаду” та народження Agile. Маніфест гнучкої розробки.
  2. 4 цінності та 12 принципів Agile. Як це працює на практиці.
  3. Scrum: найпопулярніший Agile-фреймворк. Три стовпи Scrum.
  4. Ролі у Scrum: Product Owner, Scrum Master, Developers.
  5. Артефакти та Події (Церемонії) Scrum: Спринти, Дейлі, Планування, Ретроспективи.
  6. Kanban: управління потоком створення цінності. WIP-ліміти.
  7. Відмінності Scrum і Kanban. Як вибрати правильну методологію для проєкту.

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

Вступ

До початку 2000-х років IT-індустрія потерпала від “кризи доставки”. Компанії витрачали роки на написання сотень сторінок вимог, а коли продукт (через 3 роки каскадної розробки) виходив на ринок, з’ясовувалося, що користувачам він вже не потрібен, або технологія безнадійно застаріла. Відповіддю на ці виклики став Agile — не просто методологія, а зміна мислення (mindset), яка поставила здатність до адаптації вище за сліпе слідування плану.

У цій лекції ми розберемо, як цінності Agile реалізуються через два найвідоміші фреймворки: Scrum (розділяй і володарюй за допомогою Спринтів) та Kanban (безперервний конвеєр доставки фіч). Сьогодні понад 80% комерційних IT-проєктів використовують саме ці підходи.

1. Народження Agile та Маніфест гнучкої розробки

У лютому 2001 року 17 експертів з різних методологій розробки (XP, Crystal, Scrum) зібралися на лижному курорті в штаті Юта. Вони усвідомили, що всі їхні успішні проєкти мали спільні риси: розробники постійно спілкувалися із замовником, код писався і тестувався маленькими порціями, а бюрократія була зведена до мінімуму.

Результатом їхньої зустрічі став всесвітньо відомий документ — Agile Manifesto (Маніфест гнучкої розробки програмного забезпечення).

Маніфест стверджує 4 головні цінності:

  1. Люди та їхня взаємодія важливіші за процеси та інструменти.
    • Приклад: Замість того, щоб тиждень налаштовувати складні статуси переходу в Jira (інструмент), краще просто посадити розробника і QA-інженера поруч, щоб вони домовились про критерії приймання фічі.
  2. Працююче програмне забезпечення важливіше за вичерпну документацію.
    • Приклад: Замовнику не потрібна 300-сторінкова паперова специфікація (SRS). Йому потрібен хоча б “сирий”, але працюючий прототип сайту, щоб він міг “поклікати” і дати фідбек.
  3. Співпраця із замовником важливіша за жорсткі контрактні обмеження.
    • Приклад: Якщо ринок змінився, ми не кажемо клієнту “цього не було в контракті, ми це не робитимемо”. Ми сідаємо і разом переписуємо пріоритети на наступний тиждень.
  4. Готовність до змін важливіша за дотримання початкового плану.
    • Приклад: План — це не священна корова. Якщо поява нової технології (наприклад, інтеграція ChatGPT) дає проєкту конкурентну перевагу, ми змінюємо план розробки посеред року.

Важливо: Маніфест не каже, що документація чи план не потрібні взагалі (це поширена помилка новачків). Він каже, що пункти зліва є більш пріоритетними.

2. 12 принципів Agile-мислення

Цінності Маніфесту розкриваються через 12 принципів. Найважливіші для IT-спеціаліста:

  1. Задоволення клієнта через ранню та безперервну доставку: Найвищий пріоритет. Розробляйте і віддавайте продукт шматками кожні 2-4 тижні.
  2. Вітайте зміни вимог: Навіть наприкінці розробки. Зміни дають клієнту конкурентну перевагу.
  3. Працюйте разом: Бізнесмени (замовники) і розробники мають працювати щодня разом (Daily meetings).
  4. Довіряйте професіоналам: Дайте команді ресурси, середовище і довіру. Не займайтеся мікроменеджментом.
  5. Особисте спілкування: Найкращий спосіб передачі інформації — це розмова віч-на-віч (або відеокол), а не довгі email-переписки.
  6. Працюючий софт — головний мірило прогресу: Фраза “Я на 90% закінчив бекенд” нічого не варта. Працююча кнопка “Купити” на сайті варта всього.
  7. Сталий темп: Розробники, спонсори і користувачі повинні мати змогу підтримувати постійний нормальний темп нескінченно. Agile проти постійних “кранчів” (перепрацювань ночами перед релізом).
  8. Простота: Мистецтво мінімізації зайвої роботи — це життєва необхідність. (YAGNI - You Aren’t Gonna Need It: не пишіть код для функцій, які “можливо” знадобляться через рік).
  9. Самоорганізовані команди: Найкращі архітектурні вимоги та дизайн народжуються саме в самоорганізованих командах (а не спускаються зверху менеджером).

3. Scrum: найпопулярніший Agile-фреймворк

Agile — це набір філософських принципів. Як їх імплементувати в реальному житті? Найчастіше для цього використовують Scrum. Scrum — це легкий фреймворк, який допомагає людям, командам та організаціям створювати цінність за допомогою адаптивних рішень складних проблем.

Три стовпи емпіричного процесу Scrum:

  1. Прозорість (Transparency): Всі учасники бачать реальний стан справ (код у загальному репозиторії, задачі на відкритій дошці Jira). Ніхто не ховає баги.
  2. Інспекція (Inspection): Команда регулярно перевіряє прогрес наближення до цілі Спринта.
  3. Адаптація (Adaptation): Якщо ми бачимо, що процес не працює або ми відстали від графіка, ми негайно адаптуємо план. Не завтра, не через місяць, а сьогодні.

“Серце” Скраму — це Спринт.

Спринт (Sprint) — це фіксований за часом відрізок (Timebox), зазвичай від 1 до 4 тижнів (найчастіше 2 тижні), протягом якого створюється Потенційно готовий до релізу (Done) продукт. Спринти йдуть один за одним без перерв. Важливо: під час Спринта мета і вимоги до задач, взятих в роботу, не повинні змінюватись.

4. Ролі у Scrum (Accountabilities)

У класичному Scrum немає ролі “Project Manager” або “Team Lead”. Ієрархія відсутня. Є лише одна Scrum Team (до 10 людей), яка складається з 3 ролей:

  1. Product Owner (Власник продукту):
    • Повністю відповідає за цінність продукту. Представляє інтереси клієнта та ринку.
    • Єдина людина, яка формує Product Backlog і каже, що ми будемо робити спочатку, а що потім (пріоритезує задачі).
    • “Диктатор Backlog-у”. Ніхто не може змусити команду робити задачу, яка не стоїть першою в списку PO.
  2. Scrum Master (Скрам-майстер / SM):
    • Відповідає за те, щоб команда розуміла і дотримувалась теорії Scrum.
    • Це “Слуга-лідер”. Він не роздає завдання. Він усуває перешкоди (Impediments).
    • Приклад: Якщо розробникам повільно відповідає відділ безпеки щодо доступів до серверу, SM йде “вибивати” ці доступи, щоб команда не простоювала. Також SM фасилітує усі мітинги.
  3. Developers (Розробники):
    • Це не тільки програмісти, а всі фахівці: кодери, QA-інженери, UX-дизайнери, аналітики. Всі вони називаються “Developers”.
    • Вони повністю самоорганізовані. Ніхто (навіть PO) не вказує їм, ЯК перетворити елемент з Беклогу у працюючий код і ХТО конкретно писатиме яку функцію. Команда сама розбирає задачі.

5. Артефакти та Події (Церемонії) Scrum

Щоб підтримувати прозорість та інспекцію, Scrum вимагає використання конкретних подій та артефактів.

5 подій (Церемоній) Scrum:

  1. Спринт (Sprint): Контейнер для всіх інших подій (2 тижні).
  2. Планування спринту (Sprint Planning): Робоча сесія (до 8 годин) на початку спринта. Команда збирається з Product Owner. PO озвучує: “Ціль цього спринта — зробити кошик покупок”. Команда бере задачі з верху Product Backlog, оцінює їх і формує Sprint Backlog.
  3. Щоденний скрам (Daily Scrum / Stand-up): 15-хвилинна зустріч кожного ранку лише для Developers. Кожен коротко синхронізується: Що робив учора? Що робитиму сьогодні? Які є проблеми/блокери? Мета: щоденна інспекція прогресу.
  4. Огляд спринту (Sprint Review / Демонстрація): Проводиться в кінці спринта (близько 4 годин). Команда показує реальний, працюючий продукт (а не презентацію в PowerPoint) клієнтам та стейкхолдерам. Вони отримують зворотний зв’язок.
  5. Ретроспектива спринту (Sprint Retrospective): Одразу після Review. Команда обговорює не продукт, а свій процес. Що було добре? Що пішло погано під час Спринту? Які покращення (наприклад, “давайте краще писати автотести”) ми внесемо у наступний Спринт?

3 Артефакти Scrum (що ми створюємо):

  1. Product Backlog: “Живий” список всього, що взагалі колись потрібно зробити в продукті. Впорядкований PO за пріоритетом. Ніколи не буває “завершеним”, доки живе продукт.
  2. Sprint Backlog: Список задач, які Developers вибрали для реалізації у поточному спринті.
  3. Інкремент (Increment): Це готова, перевірена та працююча частина продукту, створена під час спринта. Додається до всіх попередніх інкрементів. Має суворо відповідати Definition of Done (DoD) — критеріям готовності (наприклад: “код написаний, unit-тести пройдені, документація оновлена”).

6. Kanban: управління потоком

Як і Scrum, Kanban — це ще один Agile-фреймворк, але з іншою філософією. У перекладі з японської Kanban — це “вивіска” або “сигнальна картка”. Метод був придуманий на заводі Toyota Девідом Андерсоном для оптимізації безперервного потоку конвеєра та усунення “вузьких місць” (Bottlenecks).

Основна відмінність: У Kanban немає Спринтів (фіксованих ітерацій) і немає жорстко визначених ролей (можливі PM, можуть бути SM). Робота тече безперервним потоком.

Головні практики Kanban:

  1. Візуалізація потоку (Kanban Board): Усі задачі (картки) знаходяться на дошці з колонками, що відображають етапи процесу. Базовий набір колонок: To Do ➡️ In Progress ➡️ In Review ➡️ Testing ➡️ Done. Усі бачать, де “застрягла” робота.
  2. Обмеження незавершеної роботи (WIP Limits): Це “золоте правило” Kanban. Над колонкою встановлюється ліміт. Наприклад, над колонкою Testing стоїть ліміт “3”. Це означає, що тестувальники не можуть тримати більше 3-х задач у роботі одночасно.
    • Що це дає? Якщо програмісти розробили 4-ту фічу, а колонка Testing переповнена, програмісти ЗУПИНЯЮТЬ кодування нових задач і йдуть допомагати тестувальникам закривати ті 3 задачі, що застрягли. “Stop starting, start finishing” (Досить починати, почніть закінчувати).
  3. Управління потоком (Flow): Ключова метрика — оптимізація часу між появою запиту на дошці та його переходом у Done.

Метрики Kanban:

7. Відмінності Scrum і Kanban. Що вибрати?

Характеристика Scrum Kanban
Ритм Фіксовані спринти (наприклад, 2 тижні). Релізи часто в кінці спринта. Безперервний потік (Continuous flow). Реліз може відбутися будь-коли.
Планування Строге обмірковування задач на весь Спринт. Зміна цілі спринта заборонена. Just-in-Time. Як тільки звільнилося місце (WIP-ліміт дозволяє), береться нова задача.
Ролі Обов’язкові (PO, SM, Developers). Не регламентуються (використовуйте ті, що є).
Ключові метрики Velocity (швидкість команди у Story Points за Спринт). Cycle Time / Lead Time.
Для яких проєктів ідеально? Розробка нових продуктів (Startups, MVP), де продукт складний, але його можна поділити на 2-тижневі релізи. Технічна підтримка (Support), DevOps, інфраструктурні задачі. Там, де задачі “прилітають” хаотично.

Приклад: Ви створюєте новий мобільний банк. Ніхто не знає точного списку фіч. Вам потрібен Scrum. Ви забезпечуєте підтримку існуючого серверного парку. Щодня падають нові баги і запити від користувачів. Ви не можете спланувати Спринт на 2 тижні, бо завтра впаде сервер, і це стане ТОП-1 пріоритетом. Вам потрібен Kanban.

Примітка: В сучасному IT найчастіше використовують гібрид — Scrumban, поєднуючи спринти зі Scrum з дошками та WIP-лімітами з Kanban.

Висновки

  1. Agile народився як відповідь на бюрократичність і нездатність “Водоспаду” реагувати на швидкі зміни в IT.
  2. Головна цінність Agile — працюючий софт та задоволення від цього клієнта, а не сліпе слідування плану.
  3. Scrum структурує розробку через Спринти (Timeboxes), чіткі ролі (PO, SM) та 5 обов’язкових мітингів. Мета Scrum — створити перевірений Інкремент за 2 тижні.
  4. Kanban фокусується на оптимізації потоку створення цінності через потужний інструмент — WIP-ліміти, які фізично забороняють команді брати забагато задач і змушують доводити почате до кінця.
  5. Вибір методології залежить від природи задач: для стартапів та продуктової розробки краще підходить Scrum, для служб підтримки, DevOps та операційної діяльності з високим ступенем непередбачуваності — Kanban.

Джерела

  1. Beck, K., et al. (2001). Manifesto for Agile Software Development. agilemanifesto.org
  2. Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. scrumguides.org
  3. Anderson, D. J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business.
  4. Rubin, K. S. (2012). Essential Scrum: A Practical Guide to the Most Popular Agile Process.

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

  1. Як ви розумієте першу цінність Agile-маніфесту: “Люди та їхня взаємодія важливіші за процеси та інструменти”? Наведіть приклад з життя студента.
  2. Хто у Scrum має право змінювати пріоритет задач у Product Backlog і чому ця роль не делегується розробникам?
  3. У чому головна відмінність Daily Scrum від класичної “наради-звіту для начальника”?
  4. Що станеться в команді Kanban, якщо колонка “Code Review” заповнена повністю згідно з її WIP-лімітом (наприклад, ліміт = 4, і там лежить 4 задачі)? Що мають робити розробники?
  5. Чому Kanban вважається кращим вибором для відділу кібербезпеки або техпідтримки програми (L2 Support), ніж Scrum з його 2-тижневими спринтами?
  6. Що таке Definition of Done (DoD) і чому інкремент не може вважатися завершеним, якщо DoD виконано лише частково?