Agile, scrum, kanban: у чому різниця і навіщо використовувати?

Agile (agile software development, від англ. agile – моторний) – це сімейство «гнучких» підходів до розробки програмного забезпечення. Такі підходи також іноді називають фреймворками чи agile-методологіями.

Agile виник у IT-середовищі, але потім поширився і на інші сфери – від промислової інженерії до штучного інтелекту.

Сенс Agile сформульований в Agile-маніфесті розробки ПЗ: «Люди та взаємодія важливіші за процеси та інструменти. Працюючий продукт важливіший за вичерпну документацію. Співпраця із замовником важливіша за узгодження умов контракту. Готовність до змін важливіша за дотримання початкового плану».

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

До окремих agile-підходів відносяться scrum та kanban.

Scrum – це “підхід структури”. Над кожним проектом працює універсальна команда фахівців, до якої приєднується ще двоє людей: власник продукту та scrum-майстер. Перший з’єднує команду із замовником та стежить за розвитком проекту; це не формальний керівник команди, а скоріше куратор. Другий допомагає першому організувати бізнес-процес: проводить загальні збори, вирішує побутові проблеми, мотивує команду та стежить за дотриманням scrum-підходу.

Scrum-підхід ділить робочий процес на рівні спринти – зазвичай це періоди від тижня до місяця, залежно від проекту та команди. Перед спринтом формулюються завдання на спринт, наприкінці – обговорюються результати, а команда починає новий спринт. Спринти дуже зручно порівнювати між собою, що дозволяє керувати ефективністю роботи.

Kanban – це “підхід балансу”. Його завдання – збалансувати різних фахівців усередині команди та уникнути ситуації, коли дизайнери працюють цілодобово, а розробники скаржаться на відсутність нових завдань.

Вся команда єдина – у kanban немає ролей власника продукту та scrum-майстра. Бізнес-процес ділиться не на універсальні спринти, а на стадії виконання конкретних завдань: «Планується», «Розробляється», «Тестується», «Завершено» та інших.

Головний показник ефективності в kanban – це середній час проходження завдання на дошці. Завдання пройшло швидко – команда працювала продуктивно та злагоджено. Завдання затяглося – треба думати, на якому етапі і чому виникли затримки і чию роботу треба оптимізувати.

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

У чому різниця між Scrum та Kanban?

Основу Scrum становлять короткі ітерації чи спринти, зазвичай, 2-3-х тижневі. Перед початком спринту команда сама формує список фіч на ітерацію, далі запускається спринт.

Після закінчення спринту виконані фічі заливаються на продакшн, а невиконані переносяться в інший спринт. Як правило, фічі, які робляться під час спринту, не змінюються: що було на старті спринту – має бути зроблено до закінчення спринту.

На Kanban ми подивимося там, де він і з’явився. Уявіть конвеєр, на якому роблять деталі для машин Toyota. Є верстат, він робить дзеркала для машин. Він вміє робити ліві дзеркала, праві дзеркала, задні та дзеркала для сонцезахисного козирка. Принцип простий: натисни на кнопку, поміняй режим — отримай нову продукцію.

Ось ви замовляєте нову Toyota Camry на “максималці”, і для вас уже роблять дзеркала в козирку (ви вибрали “максималку” саме через дзеркала в козирку). Важливий момент, тут ми можемо змінювати пріоритети у будь-який момент. Ми дуже швидко можемо перемикати верстат в інший режим.

Основна різниця між Scrum та Канбан — у довжині ітерацій. У Scrum ітерації – 2 тижні, у Kanban завдання програмісту можна «підсовувати» хоч щодня.

Kanban дає більше гнучкості, якщо під гнучкістю розуміти частоту зміни пріоритетів. Вчора ви залили на прод нову фічу, а сьогодні отримали дані з передової і дізналися, що ця штука не працює так, як було задумано — люди не натискають кнопку «купити». Ви “даєте по шапці” UX, він дає вам нові вимоги. Ви піднімаєте нагору черги це завдання, програміст бере це завдання «згори», виконує його і, до вечора fix вже на продажі, конверсія в платежі зросла на 12%. Це перемога.

У Scrum завдання прийнято оцінювати в Story points або годинах. Без оцінки не вдасться сформувати спринт: нам треба знати, чи встигнемо ми зробити завдання за 2 тижні. Через 2 тижні ми отримуємо цінну статистику — скільки годин чи Story points команда змогла зробити за спринт. Velocity – це продуктивність команди за один спринт. Цей параметр дозволяє Scrum менеджеру передбачити, де команда буде через 2 тижні.

У Kanban не прийнято робити оцінку часу. Це опціонально, команда вирішує самостійно. Тут не має поняття “швидкість роботи команди”, рахується лише середній час, витрачений на виконання задачі. Цей час рахується за допомогою спеціального відліку — Cycle Time.

Cycle Time для задачі = час виконання завдання мінус час початку роботи над завданням. Наприклад, у вас є колонки: to do, reopened, developing, testing, stage testing, deployed. Cycle time для завдання дорівнюватиме deployed-developing, тобто скільки часу пройшло від моменту, коли завдання почали виконувати, до моменту, поки воно потрапило в deployed.

Отже, у Scrum наша мета – закінчити спринт, у Kanban – завдання.

Scrum – це автобус, який зупиняється лише на певних зупинках, де люди виходять гуртами. А Kanban це маршрутка: захотів пасажир вийти, попросив водія і вийшов там, де йому потрібно.