Scrum і Kanban – це два популярні гнучкі фреймворки, які використовуються в розробці програмного забезпечення та управлінні проектами. Їх об'єднує прагнення до гнучкості та постійного вдосконалення, але вони мають певні ключові відмінності в принципах, практиках та підходах до управління робочим процесом.
Розглянемо різницю між ними
1) Філософія та походження
Scrum. Походить від терміну з регбі, наголошуючи на командній роботі, співпраці та постійному прогресі. Scrum розбиває роботу на ітерації фіксованої довжини, які називаються спринтами, довжина яких від 2 до 4 тижнів.
Kanban. З японської мови перекладається як "візуальна дошка, білборд". Грунтуючись на принципах економічного виробництва, Kanban зосереджується на безперервному робочому потоці та доставці продукту на ринок. Він підкреслює візуалізацію робочого процесу, обмеження незавершеної роботи (work in progress, WIP) та мінімізацію втрат.
2) Ролі та обов'язки
Scrum. Визначає чітко окреслені ролі: Scrum Master, Product Owner та Developer's Team (технічні спеціалісти). Кожна роль має чітко визначені обов'язки.
Kanban. Зазвичай має менш чітко визначені ролі. Головну роль, яку можна виділити - це Kanban-фасилітатор, його обов'язки можуть бути більш гнучкими та часто визначаються командою.
3) Планування
Scrum. Працює з ітераціями фіксованої довжини (спринтами) з чітко визначеним набором завдань, які потрібно виконати протягом кожного спринту. Планування відбувається на початку кожного спринту.
Kanban. Зазвичай не має фіксованих ітерацій. Робота виконується безперервно, планування може відбуватися в будь-який час.
4) Пріоритезація
Scrum. Пріоритезація роботи відбувається за допомогою списку завдань з загального беклогу (відноситься до всього проекту), команда зобов'язується виконати певний обсяг роботи, який визначений спринт беклогом (відноситься до певного спринта).
Kanban. Пріоритезація роботи грунтується на можливостях команди та потребах системи. Пріоритет робочих елементів можна змінювати в будь-який час.
5) Ітерації
Scrum. Робота організована через ітерації фіксованої довжини (спринти), які зазвичай тривають від 2 до 4 тижнів. Зміни до обсягу роботи в ході спринту, як правило, не рекомендуються, але можливі в деяких випадках за згодою усіх зацікавлених сторін.
Kanban. Грунтується на безперервному потоці роботи, де нові завдання можуть додаватися в будь-який час, а пріоритети та обсяг роботи можуть гнучко змінюватися в міру необхідності.
6) Обмеження незакінченої роботи (WIP, work in progress)
Scrum. Не встановлює чітких обмежень WIP, але рекомендує командам не перевантажувати себе роботою під час планування спринту. Це допомагає зберегти фокус та уникнути мультизадачності.
Kanban. Застосовує обмеження WIP для кожного етапу робочого процесу. Це допомагає оптимізувати потік роботи, виявляти вузькі місця та запобігати перевантаженню команди.
7) Каденція
Scrum. Працює за чітким графіком з регулярними подіями/мітингами, такими як планування спринту, перегляд спринту та ретроспектива спринту. Ці події відбуваються з фіксованою періодичністю, зазвичай раз на 1-4 тижні, та забезпечують чіткий ритм роботи для команди.
Kanban. Не має фіксованої каденції та постійно безперервно. Робочі завдання переміщуються через весь робочий процес (розробка, тестування і т.д) у міру готовності, без заздалегідь визначених подій/мітингів. Це забезпечує більшу гнучкість та адаптивність до мінливих потреб.
8) Зміни протягом циклу
Scrum. Зазвичай не рекомендується змінювати обсяг роботи в ході спринту після його початку. Це робиться для того, щоб зберегти фокус команди, уникнути мультизадачності та гарантувати своєчасне виконання поставлених завдань. Зміни можуть бути можливі за винятковими обставинами, та за згодою усіх зацікавлених сторін.
Kanban. Дозволяє змінювати пріоритети та обсяг роботи в будь-який час протягом робочого процесу. Це забезпечує гнучкість та можливість реагувати на непередбачувані зміни або нові вимоги.
9) Детально про ролі
Scrum. Scrum Master, або фасилітатор Scrum, який направляє весь процес Scrum, усуває перешкоди та допомагає команді досягти своїх цілей. Власник продукту - він представляє інтереси зацікавлених сторін, визначає пріоритети для невиконаних завдань та співпрацює з командою для забезпечення відповідності продукту потребам користувачів. Команда розробки - це самоорганізована, багатофункціональна команда, яка несе відповідальність за розробку, тестування та постачання продукту.
Kanban. Лідер, менеджер, фасилітаток Kanban процесу, який направляє впровадження Kanban, забезпечує дотримання правил, моніторить показники та допомагає команді оптимізувати робочий процес. Команда - це зазвичай міжфункціональна команда, де кожен член несе відповідальність за виконання певної частини роботи. Команда може колективно приймати рішення та розподіляти завдання.
10) Оцінка
Scrum. Зазвичай використовує чітко визначений мітинг для оцінювання. Оцінка відбувається у story points або годинах, що допомагає планувати та моніторити прогрес.
Kanban. Як правило, не має чітко визначених практик оцінки. Робочі завдання можуть додаватися до Kanban-дошки на основі пріоритету, без використання явного оцінювання.
11) Метрики для вимірювання
Scrum. Використовує діаграми згоряння (burn-down чарти) та швидкість (velocity) для візуалізації прогресу, продуктивності та відстеження скільки роботи залишилося виконати.
Kanban: Наголошує на візуалізації робочого процесу на Kanban-дошці. Використовує такі показники: Сycle time - це час, що потрібен для виконання конкретної задачі (наприклад розробки, або тільки тестування); Lead Time - це час виробництва або час виконання, це повний час який включає всі процесі від початку від початку до завершення (розробка, тестування, перерва яка виникла в процесі); та обмеження роботи WIP.
12) Розмір команд
Scrum. Добре підходить для невеликих, багатофункціональних команд (зазвичай 5-9 учасників).
Kanban. Може застосовуватися як до малих, так і до великих команд. Розмір команди може бути більш гнучким, залежно від потреб проекту.
13) Церемонії
Scrum. Має набір чітко визначених церемоній, таких як планування спринту, щоденні stand-up зустрічі, ретроспектива спринту, тощо. Ці церемонії допомагають команді залишатися організованою, синхронізованою та постійно вдосконалюватися.
Kanban. Зазвичай має менше формалізованих церемоній. Команди Kanban мають гнучкість у виборі та адаптації церемоній, які найкраще відповідають їхнім потребам.
14) Можливість застосування
Scrum. Добре підходить для проектів з чітко визначеним списком завдань (backlog), чітко окреслененими цілями та потребою в ітераціях фіксованої довжини.
Kanban. Добре підходить для проектів, що потребують безперервної доставки, постійної підтримки та обслуговування, а також для ситуацій, де вимоги часто змінюються.
15) Обробка змін
Scrum. Зміни до списку завдань (беклогу) під час спринту зазвичай не рекомендуються, щоб зберегти фокус команди та гарантувати своєчасне виконання поставлених завдань. Зміни можуть бути розглянуті в наступному спринті.
Kanban. Легко адаптується до змін. Пріоритети та обсяг роботи можуть гнучко змінюватися в будь-який час протягом робочого процесу, що дозволяє команді швидко реагувати на непередбачувані обставини або нові вимоги.
16) Управління ризиками
Scrum. Виявляє та оцінює ризики під час планування та перегляду спринту. Команда зосереджується на вирішенні потенційних проблем протягом фіксованого періоду спринту.
Kanban. Розглядає ризики в міру їх виникнення, забезпечуючи більш постійний та адаптивний підхід до управління ризиками. Це може включати регулярний аналіз ризиків та коригування плану дій у міру необхідності.
17) Навчання та вдосконалення
Scrum. Наголошує на ретроспективі спринту, де команда після завершення кожного спринту обговорює, що пройшло добре, а що можна покращити. Це сприяє постійному вдосконаленню процесів та практики.
Kanban. Включає постійне вдосконалення як невід'ємну частину методології. Команди заохочуються постійно виявляти та усувати вузькі місця, неефективність та можливості для покращення. Це може відбуватися протягом усього робочого процесу, а не лише в чітко визначені періоди.
18) Залучення клієнтів
Scrum. Залучає власника продукту до визначення пріоритетів та для перегляду актуальності беклогу, щоб гарантувати, продукт який розробляється відповідає потребам клієнтів.
Kanban. Забезпечує безперервну видимість для зацікавлених сторін через дошку Kanban. Це дозволяє отримувати зворотний зв'язок у реальному часі та адаптувати продукт до мінливих вимог клієнтів.
19) Планування випуску
Scrum. Передбачає планування випуску наприкінці кожного спринту, коли команда може представити потенційно готовий до випуску продукт. Це може призвести до жорстких дедлайнів та меншої гнучкості у випуску оновлень.
Kanban. Підтримує безперервну доставку, де нові функції або вдосконалення можуть випускатися, щойно вони будуть завершені та протестовані. Це забезпечує більш швидке та гнучке реагування на мінливі потреби та ринкові умови.
20) Документація
Scrum. Виступає за спрощену документацію, з акцентом на робоче програмне забезпечення, а не на вичерпну документацію. Це може призвести до дефіциту детальної інформації, необхідної для підтримки та подальшого розвитку продукту.
Kanban. Заохочує своєчасну документацію, яка фокусується на забезпеченні цінності та мінімізації непотрібної інформації. Це може включати документацію процесів, рішень та важливих моментів, що сприяє кращому розумінню та співпраці.
Що вибрати, Kanban чи Scrum?
Kanban зазвичай обирають для проектів з тривалою та непередбачуваною роботою, де вимоги можуть часто змінюватися. Цей підхід добре підходить для ситуацій, коли чітке планування наперед може бути складним через невизначеність. Kanban є більш гнучким та може легше адаптуватися до змін.
Scrum більше підходить для проектів з чітко визначеними вимогами та фіксованим обсягом роботи. Структура Scrum з чіткими ітераціями та визначеними ролями може бути корисною для команд, яким потрібна чітка структура та передбачуваність. Scrum забезпечує більшу передбачуваність завдяки спринтам фіксованої довжини та чітко визначеним цілям.
Отже,
Scrum і Kanban – це два потужні фреймворки agile, які можуть допомогти командам ефективно керувати проектами. Найкращий вибір фреймворку залежить від конкретних потреб, уподобань та обмежень команди чи організації.
Важливо також зазначити, що команди можуть використовувати практики обох фреймворків, адаптуючи підхід до свого унікального контексту. Цей підхід відомий як "змішаний" або "гібридний" підхід з назвою Scrum-ban.
Додатково:
Огляд книги - Scrum: навчись робити вдвічі більше за менший час.
Scrum, як найпопулярніша методологія Agile
Скачати 12 принципів Agile (english)
Скачати книгу - Блискучий Agile. Практичний посібник з використання Agile, Scrum, Kanban (english).
Ще немає коментарів