Scrum vs Kanban: переваги та відмінності методологій

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

Принципи методологій, загалом, однакові — вони розроблені для покращення якості продукту та позбавлення як керівника, так і команди, маси непотрібної роботи. Але QATestLab допоможе розібратися, у чому різниця між Scrum і Kanban та яка методологія краще підходить для команди тестувальників.

Scrum — структурований agile-підхід

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

Scrum має декілька складових:

1. Графік

Scrum характеризується високим темпом роботи, що досягається за рахунок ділення робочого часу на спрінти. Вони можуть бути тривалістю від 1 до 4 тижнів, мають точні дати початку та завершення. Через вузькі часові рамки, складні задачі доводиться ділити на дрібні шматки, тому команда краще вчиться та ефективніше розробляє нові рішення. 

Ключовими точками у спрінті є мітинги для його планування та огляд результатів, а також ретроспективи. Окрім того, по ходу спрінта проходять щоденні мітинги (стендапи), для швидкого обговорення поточних процесів та задач. Такі мітинги не потребують багато часу, але допомагають керівнику команди тримати руку на пульсі усіх процесів і вчасно зреагувати, якщо щось іде не так.

2. Ролі

В Scrum чітко визначені три ролі:
▪️ власник продукта відповідає за потреби клієнта, керує беклогом продукта та допомагає визначити пріорітети для команди розробників;
▪️ Scrum-майстер слідкує, аби команда дотримувалася усіх принципів методології;
▪️ команда (розробники, тестувальники, дизайнери тощо) — обирає, яку роботу потрібно зробити у якому спрінті, створює інкременти та несе колективну відповідальність за результати.

Команди Scrum діють за принципом самоорганізації — всі учасники рівні, хоч і виконують різні обовʼязки. Команду обʼєднує спільна мета — постачання клієнтам якісних продуктів.

3. Загальні показники

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

На етапі планування спринту такими показниками можуть бути цілі спрінту, швидкість та продуктивність команди, тип роботи. Можна застосовувати показники і на щоденних стендапах, аби щодня оцінювати свої успіхи, звірятися з планами та зрозуміти, як розподіляється навантаження в рамках спрінта.

4. Ставлення до змін

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

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

Kanban — безперервне вдосконалення, гнучкість у процесах

Суть методології Kanban — у візуалізації роботи, обмеження обʼєму незавершених задач та швидкому переміщенні задач від етапу «Виконується» до етапу «Завершено».

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

Розглянемо 5 основних рис цієї методології:

1. Модель

В основі Kanban лежить безперервна структура робочого процесу, що дає командам простір для дій та рішень і можливості змінювати процеси відповідно до змін пріоритетів. Робочі задачі формуються у вигляді окремих карток на дошці та вільно переміщуються залежно від етапу робочого процесу. Зазвичай процес ділять на етапи «Потрібно зробити», «Виконується», «На перевірці», «Відхилено», «Завершено». Але тут все залежить від потреб та фантазії команди, оскільки варіантів може бути безліч.

2. Підхід до релізу

У Kanban оновлення виходять по готовності, а регулярний графік чи заздалегідь визначені терміни, як правило, відсутні.

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

3. Ролі

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

4. Ключові показники

Час виконання задачі і час цикла — важливі показники для команд Kanban. Вони показують, скільки часу у середньому йде на виконання роботи від початку до кінця. Скорочення циклу говорить про успіх і продуктивну роботу команди.

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

Окрім цього, існують ліміти незавершеної роботи. Це налаштування на дошках, які дозволяють обмежити кількість карток, що одночасно перебувають на одному етапі і якщо їхня кількість перевищується — варто звернути увагу на побудову процесу. Деякі інструменти, наприклад, Jira, одразу сповіщає про перевищення лімітів і подібні «просідання» не лишаються непоміченими.

5. Ставлення до змін

Kanban абсолютно гнучкий і робочий процес може змінюватися в будь-який момент. В залежності від пріоритетів, задачі можна додавати у беклог, а існуючі картки блокувати чи видаляти. Якщо продуктивність команди різко змінюється (наприклад, внаслідок зміни складу) — ліміти незавершеної роботи легко корегуються, а задачі адаптуються.

То як обрати?

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

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

Отож не бійтеся експериментувати, міксувати та змінювати рішення з плином часу чи виникненням додаткових потреб!