Agile: Scrum або Kanban — що обрати для свого проєкту?

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

Щоб ви не плуталися в різноманітті термінів, давайте розбиратися, в чому різниця, які особливості кожного методу і який з них краще обрати для свого проєкту.

Agile

Agile — узагальнююче поняття для ряду методик і підходів до управління проєктами, суть яких зводиться до прискорення процесів створення продукту. Це досягається завдяки серії коротких циклів (ітерацій), які зазвичай тривають по 2—3 тижні. Кожна ітерація складається з етапів, необхідних для приросту функціональності: планування, аналізу вимог, проєктування, програмування, тестування і документування. Після кожної ітерації команда виконує переоцінку пріоритетів розробки та приймає рішення про подальшу стратегію. Це забезпечує гнучкість процесу.

В основі Agile лежить маніфест гнучкої розробки програмного забезпечення. Серед основних його принципів такі:

• Люди та взаємодія важливіші процесів та інструментів. В основі гнучкого процесу лежить комунікація, тому ваша робота не обійдеться без регулярних мітингів, а також інструментів для управління проєктами, таких як JIRA або Redmine.
• Продукт, що працює, важливіший вичерпної документації. Наприклад, є проєкт і три місяці на його розробку. Можна почати зі збору вимог, аналізу даних, створення архітектури, дизайну системи тощо та витратити на все дуже багато часу і ресурсів. А проте гарантій, що результат буде в строк і задовольнить запити клієнта і споживача, немає. Це «водоспадна модель». Можна піти шляхом мінімізації цих кроків заради отримання працездатної моделі, додати в процес взаємодії команди замовника та кінцевого споживача, а у підсумку отримати більш гнучку та ефективну систему.
• Співпраця з клієнтом важливіша за узгодження умов договору. Із замовником слід вибудовувати партнерські взаємини Win-Win. За контрактом розробник отримує оплату за витрачений час.
• Готовність до змін важливіша дотримання початкового плану. Звичайно, в Agile є план, оцінки та прогнози. Але наявність нових даних або зворотного зв’язку від користувачів може повністю змінити стратегію.

Головна мета цих принципів — задоволений клієнт з реалізованим проєктом на фініші. А для цього необхідна якісна комунікація інвесторів, розробників та користувачів, наявність команди мотивованих професіоналів, регулярний аналіз виконаної роботи та пошук кращих рішень.

Існує ряд agile-підходів, найбільш популярними серед яких вважаються Scrum і Kanban. У чому різниця між ними і як обрати відповідний для свого проєкту?

Scrum

Термін «Scrum» перекочував у проєктний менеджмент із регбі та буквально означає «сутичка». При виникненні суперечливої ситуації команди шикуються одна проти одної, а головне завдання гравців — дійти з м’ячем до центру, розштовхавши інших. У роботі цей принцип виглядає так само, тільки замість сили у гравців аргументи. Команда діє спільно заради досягнення єдиної мети, засвоює уроки з попереднього досвіду, аналізує успіхи та невдачі, щоб удосконалюватися. Робочий процес передбачає короткі цикли релізу і переоцінку пріоритетів, що сприяє перманентному навчанню і вдосконаленню команди.

Як відбувається розробка?

Scrum-розробка складається з мінімальної кількості компонентів: 3 ролі, 3 артефакти та 5 подій із жорстко фіксованими ітераціями (спринтами) і логікою процесу. Це організм, що здатен самоорганізовуватися, де важливий внесок кожного учасника команди, оскільки всі несуть відповідальність за кінцевий продукт. Але давайте по черзі.

Ролі

Ролі, які утворюють Scrum-команду:

• Власник продукту. Він розуміє його цінність для бізнесу, є сполучною ланкою між розробниками та споживачами/стейкхолдерами, але не відповідає за технічну сторону процесу. Він зацікавлений у раціональному використанні ресурсів команди для створення цінного продукту.
• Команда розробки відповідає за реалізацію технічних завдань: аналіз, дизайн, програмування, тестування тощо. Вона формується в залежності від потреб проєкту та зазвичай складається з дизайнера, тестувальника, маркетолога, контент-менеджера, Back-end і Front-end розробників.
• Scrum-майстер виступає посередником між командою та власником продукту і допомагає їм безперешкодно виконувати роботу. Він вибудовує процеси та стежить за їхньою реалізацією, а будь-яка комунікація людей поза командою зі Scrum-командою проходить через Scrum-майстра.

Артефакти

Артефакт — це те, що створює команда. У Scrum їх всього три: беклог продукту, беклог спринту та інкремент. Ці елементи присутні в кожній команді.

• Беклог продукту — головні вимоги до продукту, які визначає власник або менеджер продукту. Це регулярно оновлюваний список функцій, умов і поліпшень, на підставі якого формуються завдання для беклога спринту. Власник/менеджер продукту змінює в ньому пріоритети та підтримує актуальність, відповідно до нової інформації або змін на ринку.
• Беклог спринту — список завдань, які команда розробників визначила для реалізації в поточному циклі спринту. Перед кожним спринтом проводиться його планування, на якому команда обирає завдання з беклогу продукту для виконання в рамках нової ітерації. Цей беклог може змінюватися під час спринту, але досягненню головної мети спринту нічого не повинно заважати.
• Інкремент — мета спринту, готовий до використання продукт за його підсумками. Критерії готовності продукту команда визначає самостійно.

Заходи

Всю методологію Scrum можна розділити на 5 процесів:

• Перед початком спринту проводиться зустріч Sprint Planning Meeting, де обираются цілі та розробляється план їхнього досягнення — беклог спринту. Він повинен бути чітким, а головне — здійсненним.
• Щоденний Scrum. Це 15-хвилинний стендап, на якому члени команди синхронізують свої дії: що було зроблено, на які труднощі натрапили і які дії плануються далі.
• Спринт. Чим він коротший, тим більш гнучкий процес розробки. Спринт може тривати від тижня до чотирьох, але найчастіше команди працюють по двотижневих ітераціях.
• Sprint Review. Це зустріч команди та замовника для демонстрації інкременту, який був зроблений за спринт для визначення подальших доробок.
• Ретроспектива. Зустріч, на якій оцінюється минулий спринт з точки зору організації процесів, робота над поліпшеннями.

Kanban

Kanban — досить нова і друга за популярністю методологія, яка добре підходить для управління особистими завданнями, розробки ПО, організації виробництва, роботи з командами підтримки та для стартапів.

Основний інструмент методу — візуалізація. Етапи роботи відображаються на Kanban-дошці, що дозволяє учасникам процесу бачити стан завдань у будь-який момент. На стандартній дошці процес представлений у вигляді трьох кроків: «Заплановано», «У роботі» і «Зроблено». Але можна кастомізувати дошку відповідно до цілей тієї чи іншої команди, її процесів, розмірів і структури. Головне — щоб усі учасники розуміли завдання і хто над чим працює.

Кожна робоча задача на дошці оформлюється у вигляді окремої картки. Це наочне уявлення спрощує членам команди відстеження життєвого циклу робочих завдань. На картках вказується важлива інформація про конкретне завдання, яку може бачити вся команда: ім’я відповідального за її виконання, короткий опис виконаної роботи, оцінка необхідного часу тощо.

У Kanban не заведено робити оцінку «швидкості роботи команди», рахується середній час на виконання завдання:

Cycle Time = час виконання завдання — час початку роботи над завданням

Важливо дотримуватися WIP (Work in Progress) — принципу обмеження кількості завдань, які одночасно перебувають у роботі. Це допомагає уникнути мультизадачності та її негативного впливу на ефективність. Чим менший WIP, тим швидше завдання проходять по ланцюгу і закриваються, тим вища швидкість роботи. Тому у кожного завдання повинен бути зрозумілий індикатор завершеності.

Kanban-методологія пропонує високу гнучкість планування, оскільки команди концентруються виключно на поточній роботі. Навіть якщо власник продукту змінить пріоритет завдань у беклозі, зміни не торкнуться поточних завдань, а отже, не завадять роботі команди. Головне — стежити, щоб зверху беклогу знаходилися найбільш пріоритетні завдання. Завдяки такій схемі відпадає необхідність у спринтах із фіксованою тривалістю, які використовуються в Scrum-методиці.

Яку методологію обрати?

Навряд чи існує такий підхід до ведення проєктів, який міг би стати універсальним. У кожної методології є свої сильні та слабкі сторони, а щоб вам було простіше зробити вибір на користь Scrum або Kanban, давайте резюмувати особливості кожного.

Scrum зручний для лінійного методу управління і спрацьованих команд (7—9 осіб). Він більш показовий для замовника, бо дозволяє відстежувати успішність. Робота ділиться на спринти, і тільки досвідчена команда може визначити оптимальну кількість завдань у цих спринтах. Обов’язковий елемент — регулярні зустрічі для синхронізації процесів усіх членів команди. Часова рамка для виконання поставлених завдань дуже відносна, головне — це результат. Зворотний зв’язок здійснюється після завершення кожного спринту, а на підставі отриманої інформації відбувається розробка поліпшень.

Kanban хороший у компаніях із корпоративною культурою і чіткою ієрархією, де робота відбувається в групах до 5 осіб. Організувати робочий процес набагато простіше, але складніше відстежувати його результативність. Робота будується поетапно, в рамках обмеженої кількості завдань для кожного співробітника. Процес максимально гнучкий, а стратегія повністю візуалізується на загальній дошці. Логіка її побудови дуже зрозуміла: все починається з рішення найважливіших завдань, а подальші дії коригуються в залежності від оновлення даних. Розробка відбувається в безперервному режимі, а збори команди — щодня.