London, United Kingdom
info@telesens.co.uk
+44 20 3432 8178

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

Kanban

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

Говорячи про Kanban як підхід управління проектами, найчастіше мається на увазі дошка Kanban. Вона втілює в собі етапи роботи зі стовпцями, які містять окремі завдання для кожного етапу: To do, In progress, Done, Hold та інші. Тобто Kanban — це метод оптимізації та керування робочими процесами, який дозволяє візуалізувати процеси на дошці Kanban і безперервно обробляти робочі елементи. Обмеження незавершеної роботи на кожному етапі робочого процесу дозволяють команді оптимально використовувати свої можливості.

Іншими словами, Kanban допомагає оптимізувати існуючий процес за допомогою набору принципів. 

Принципи управління змінами:

  • Почніть з того, що ви робите зараз:
    • зрозумійте поточний процес та практики;
    • дотримуйтесь поточних ролей, обов’язків та інструкцій.
  • Погодьтеся на поступові, еволюційні зміни.
  • Заохочуйте акти лідерства на всіх рівнях.

Принципи надання послуг:

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

Також Kanban має певний перелік практик, за допомогою якого реалізуються ці принципи:

  1. Візуалізуйте робочий процес.
  2. Обмежуйте кількість незавершеної роботи.
  3. Керуйте потоком.
  4. Робіть правила роботи зрозумілими.
  5. Впроваджуйте цикли зворотного зв’язку.
  6. Вдосконалюйтеся разом, еволюціонуйте на основі експериментів.

Завдяки Канбан-методу у PM-а формується розуміння того, яку роботу команда виконує, за якими правилами, з яким обсягом завдань може впоратися за одиницю часу та який результат надає замовникам.

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

Структура Kanban дуже гнучка і може допомогти команді з часом стати більш динамічною та спритною.

Scrum

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

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

Scrum швидко та багаторазово перевіряє фактично працююче програмне забезпечення й акцентує увагу на командній роботі та ітеративному прогресі розробки. Його мета — постачати нове програмне забезпечення кожні 2-4 тижні.

Робота поділена на менші завдання, які потрібно виконати за заздалегідь визначений період — спринт. Вкрай не рекомендується додавати нові робочі елементи під час спринту, що змушує нову роботу очікувати на новий спринт і зменшує здатність команди реагувати на зміни.

У рамках методології Scrum існує поняття «артефактів» — це матеріальне уявлення роботи чи цінності. Артефакти: 

1) надають ключову інформацію, яку команда Scrum та замовник повинні знати для розуміння розроблюваного продукту; 

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

Scrum використовують, щоб виконувати свою роботу швидше та ефективніше.

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

Майстер Scrum відповідає за реалізацію трьох традиційних етапів Scrum:

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

Етап 2. Щоденні стендапи Scrum. Зазвичай по 15 хвилин, щоб перевірити прогрес і переконатися, що обсяг призначеної роботи є відповідним.

Етап 3. Ретроспектива спринту. Коли цикл Scrum закінчується, майстер Scrum проводить ретроспективну зустріч спринту, щоб оцінити виконану роботу, повернути будь-яку незавершену роботу назад у відставання та підготуватися до наступного спринту.

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

Scrum VS Kanban

Тож на відміну від Kanban, який зазвичай використовується як інструмент для візуалізації роботи, Scrum — це повноцінний фреймворк, і ви можете «керувати командами» в рамках методології Scrum. Фреймворк допомагає команді зосередитися на постійному удосконаленні та повторенні.

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

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

Scrum обмежений часом, Kanban гнучкий. Scrum виконується на спринтах, які зазвичай є двотижневими робочими циклами. Наприкінці спринту у PM-а є зібрання готової роботи — незалежно від того, яка це робота. Канбан-дошки не обов’язково повинні мати дату початку чи кінця.

Колонки канбан-дошки можна організувати по-різному. Коли ви запускаєте Scrum, важливо відстежувати роботу, коли вона проходить через етапи. Але в дошці Kanban, не заснованій на Scrum, стовпці дошки можуть представляти різноманітну роботу, а не лише робочий статус. Стовпці можуть представляти роботу, яка буде виконана щомісяця, ретроспективу, яка відображає роботу, яка була виконана раніше, або будь-що інше, що вам потрібно — на відміну від Scrum, який має більш визначені «правила».

Немає точного правила, коли команда повинна використовувати Kanban або Scrum.

Однак вам вірогідніше підійде Kanban, якщо:

  • Вашій команді потрібна візуальна система управління проектами.
  • Вам потрібно з одного погляду зрозуміти, де знаходиться проект.
  • Ви не в команді engineering, product чи software development.
  • Ви запускаєте поточні процеси та проекти.
  • Більшість ваших робіт не виконується за короткий проміжок часу.

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

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

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

Також поширена практика поєднання обох, коли команда запускає Scrum на дошці Kanban.

Kanban і Scrum були створені, щоб допомогти командам підвищити ефективність і продуктивність.

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

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

Архивы