Відмінність Scrum від Kanban: різниця методологій

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

Kanban vs Scrum

Скрам – agile фреймворк управління проектами, при якому одна або кілька кроссфункціональних команд поетапно імплементують продукт з урахуванням ролей. Завдання загальноприйнято розраховувати в Story Points, що надає можливість утворювати чіткий майбутній спринт (як правило 2-3-х тижневі відрізки).

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

Раніше ми писали, як залишатися сфокусованим на позитивний результат.

Майбутній спринт буде складатися з наступних чотирьох послідовних непересічних етапів:

  1. Planning. Команда перевіряє завдання в backlog та вибирає найбільш пріоритетні з сторі поінтс. Скоуп обмежується кількістю, який може бути реалізований за поставлений проміжок часу.
  2. Execution. Всі працюють паралельно та можуть бути незалежними. Наприклад поки девелопер пише код, тестувальник може створювати вже до нього тести.
  3. Release. Кожна релізна версія продукту повинна бути працездатною та виконувати весь функціонал, який був поставлений.
  4. Retrospective. В кінці кожного спринту проводяться спільні обговорення які виникли в негативних та позитивних ситуаціях. Після вже йде обдумування та брейншторм для поліпшення загальної роботи.

Істотна відмінність підходу “Scrum” від “Kanban” – додавання нових завдань в поточний sprint під забороною, тому він буде менш гнучкий для реалізації. Навіть якщо з’явилося термінове завдання (наприклад зі статусом “Blocker”) – воно буде реалізовано як мінімум у наступному.

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

Можливо вам буде цікава також наступна інформація – як формувати стратегічне мислення?

По закінченню кожної ітерації ми бачимо аналітику по витраченому часу і Story points. Velocity – це аналітичний параметр продуктивності групи людей які працюють на проекті, що дозволяє Scrum менеджеру передбачити, де команда буде через наступні 2 тижні.

У scrum-команді крім власне фахівців є дві додаткові ролі:

  1. Product Owner – визначає хід і курс проекту, іноді представляє замовника.
  2. Scrum-master – людина, яка організовує виконання роботи

Kanban дозволяє організувати роботу над завданнями в непередбачуваною послідовності, так як одні етапи не зав’язані на інші. Головна метрика на відміну від Скрам – середній час виконання завдання. Підхід цієї методології – безперервна розробка. Але часом присутній ліміт для кількості завдань з певним статусом (to do, in progress, done etc.).

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

У будь-який момент ділянки часу ми можемо об’єднати готові тікети в майстер гілку. Реліз – коли необхідний, планування – коли закінчилися завдання, retrospectives – приблизно раз на місяць.

Особливості підходу Канбан

  1. Несхожість Kanban від Scrum – нові завдання з’являються в беклоге на будь-якій фазі.
  2. Існує поняття тут і зараз, команда не чекає наступного спринту;
  3. Найголовніше – етап виконання завдання: «Планується», «Розробляється», «Завершено» і т. д.
  4. Немає конкретного терміну на виконання завдання, тому що він не має чітко виражених спринтів.

Коли краще застосовувати Scrum і коли Kanban?

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

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

Підсумок: У чому глобальні розбіжності Scrum і Канбан

  1. Довжина ітерацій. Scrum – 2 тижні, Kanban завдання можна формувати повсякденно.
  2. Канбан складніше для контролювання часу та прогнозування завершення будь-якого модуля.
  3. При виборі Скрам методології, в команді повинен бути Продукт Власник і Скрам Майстер.
  4. У Scrum витрачається час на обговорення спринту, Канбан немає обов’язкових мітингів.

Якщо у вас є бажання досконало вивчити цю тему, ви можете знайти бізнес-заходи на нашій афіші.