Scrum (Скрам) и Kanban (Канбан) – це методи керування проєктами. Вони є представниками популярної методології Agile-сімейства. Ці методи гнучкі та ітеративні, вони можуть використовуватися для роботи в будь-якій галузі, однак найкраще вони підходять для IT-сфери. Обидва методи близькі, тому їх інструменти можна використовувати в комбінації. Дуже часто застосовують гібридний підхід. При цьому використовують найкраще з Scrum і Kanban.
У чому різниця між Scrum і Kanban
Вони об'єднують основоположні принципи Agile-маніфесту:
- Люди та взаємодія важливіші ніж процеси та інструменти. Команда, яка працює спільно і налаштована на одну спільну мету, має більший потенціал та досягає великих успіхів. Команда – це єдине ціле, тому за позитивний результат або невдачу команда відповідає спільно. Головний принцип – вільне спілкування між фахівцями і колективні обговорення.
- Працюючий продукт набагато важливіше, ніж вичерпна документація. У Scrum і Kanban робиться акцент на зменшенні документообігу та збільшенні комунікацій всередині команди, а також безперервне обговорення поточного проєкту. Дуже важлива візуалізація процесу розробки. Для цього використовуються спеціальні дошки з картками, кожна з яких відповідає певній задачі.
- Співпраця з замовником важливіше узгодження умов контракту. Запорука успіху – щоденне спілкування з замовником і зворотний зв'язок. Вона допомагає зрозуміти, що клієнту важливо і який продукт йому необхідний.
- Готовність до змін важливіше проходження попереднім планом. Даний принцип необхідний для того, щоб вміти швидко реагувати на зворотний зв'язок і покращувати продукт, що розробляється.
Незважаючи на те, що дані методології близькі і мають багато спільного, у них досить багато відмінностей, які ми розглянемо в даній статті.
1. Команди
Команда фахівців у Scrum універсальна. Вона складається з такої кількості широких фахівців, яка потрібна для вирішення кожного завдання проєкту. У більшості випадків достатньо 5-7 чоловік. При більшій кількості людей результат менш очевидний через незліченну кількість розмов. При цьому у фахівців Scrum-команди немає формальної компетенції, наприклад: тестувальник може допомагати дизайнеру, а аналітик – розробнику або навпаки.
У Kanban же основне завдання полягає в тому, щоб збалансувати різних вузькопрофільних фахівців всередині команди. Над завданням може працювати кілька вузькопрофільних команд. Наприклад, спочатку працює аналітичний відділ, після – дизайнерський відділ, і тільки потім до роботи приступають розробники. При цьому не забороняються і універсальні команди.
2. Ролі
В Scrum-команді потрібно більше ресурсів, ніж в Kanban-команді. Для управління всім процесом розробки потрібні додаткові ролі: Scrum master (скрам-майстер) і Product owner (власник товару).
Scrum master – це організатор. Він не керує і не роздає вказівки. Скрам-майстер організовує наради, усуває побутові та інші проблеми, мотивує команду, відстежує статус завдань, стежить за дотриманням скрам-підходу. Крім виконуваних завдань організатора, скрам-майстер працює над проєктом, як і інші співробітники команди.
Product owner взаємодіє з клієнтом, пов'язує замовника і команду, відстежує розвиток проєкту, але при цьому не є формальним керівником команди. Він виставляє завданням пріоритети. Саме йому команда надає результат роботи.
У Kanban-команді такі ресурси не потрібні, тому що процес лінійний і більш простий в організаційному плані. У команді немає ролей Scrum master і Product owner. Команда єдина.
3. Планування
В обох методах проєкт ділиться на десятки, а може і сотні більш дрібних завдань. Всі майбутні завдання проєкту, складаються в загальний список завдань – беклог. Кожне завдання має свій пріоритет і актуальність.
Відмінність в тому, що пріоритети в Scrum розставляє власник продукту, а в Kanban – команда.
4. Тимчасові рамки
У Scrum час роботи над проєктом розбивається командою на рівні відрізки – спринти, тривалістю від одного до чотирьох тижнів, але чим коротше відрізок, тим легше вносити зміни. У Scrum терміни дотримуються командою в обов'язковому порядку.
Кожен спринт складається з чотирьох послідовних етапів:
- Планування. Команда перевіряє завдання в загальному списку завдань за проєктом та формує їх за пріоритетом. На спринт беруть стільки завдань, на думку команди, скільки встигнуть зробити.
- Виконання. Учасники команди працюють одночасно, наприклад: програміст створює код, в цей час тестувальник пише до нього тести, а технічний письменник – документацію.
- Реліз. До моменту кожного релізу, продукт повинен бути працездатним, корисним для користувача і більш досконалим, ніж до спринту.
- Ретроспектива. Члени команди разом обговорюють спринт і проблеми, які виникли в процесі. Спільно думають, як підвищити якість роботи і зробити в наступному спринті більше.
Scrum менш гнучкий, так як в цьому методі категорично заборонено додавати завдання в поточний спринт. Навіть сама термінова і важлива задача піде в роботу з наступного спринту.
В кінці відрізка недороблені завдання йдуть назад в беклог. А на етапі планування наступного спринту визначається необхідність і час їх завершення.
Також в Scrum потрібно виділяти час на щоденні мітинги, на яких плануються спринти і вирішуються організаційні питання.
У Kanban же не потрібні обов'язкові зустрічі-звіти. Вони можуть проводитися раз на місяць або тиждень.
У Kanban методології проєкт поділяється не на універсальні спринти, а на етапи виконання конкретних завдань, наприклад: «Планується», «Розробляється», «Тестується», «Завершено» і т.ін. Дані етапи можуть бути різної довжини. Нові завдання можна додавати в будь-який час. Якщо потрібно терміново щось зробити, то команда не буде чекати наступного етапу для виконання термінового завдання. Задача може перебувати в роботі стільки, скільки буде потрібно для неї часу, до тих пір поки команда не завершить її або не скасує.
Отже, в Kanban складніше контролювати час розробки продукту і прогнозувати терміни завершення модуля, ніж в Scrum.
5. Дошки
Для візуалізації даних методологій застосовують фізичні або електронні дошки, наприклад: Trello, Jira та ін. Вони дозволяють зробити робочий процес максимально відкритим і зрозумілим для всіх фахівців команди. А також розпланувати завдання і поставити деякі обмеження.
Дошка розділяється на стовпці, яким присвоюється різний стан завдання, наприклад: «To do», «In progress», «Review», «Test», «Done» та ін. Кількість і назви стовпців, звичайно ж, залежать від конкретного проєкту, але в цілому, чим їх менше, тим краще. У картках описують завдання, а також вказують пріоритет. По мірі виконання завдань, вони переміщаються по дошці в інший стовпець, що дозволяє побачити як виконуються завдання і де виникають проблеми.
Відмінність методів в тому, що при Kanban дошка знаходиться постійно в заповненому стані. А в Scrum дошка очищається кожен раз при новій ітерації.
6. Показники
В Scrum вимірюється загальна вага всіх завдань, які виконуються за спринт. Розділивши загальну вагу завдань проєкту на продуктивність за спринт, отримують приблизний термін закінчення проєкту. Підвищення продуктивності – це головний показник команди в Scrum.
У Kanban вимірюється середній час проходження одного завдання по дошці. Цей час – показник ефективності команди. Члени команди не зосереджуються на виконанні конкретних завдань, вони стежать за тим, щоб середній час виконання був мінімальним.
Як ми бачимо, Kanban і Scrum мають свою специфіку. Той чи інший проєкт вимагає певного підходу до розробки. В одних випадках потрібно використовувати Scrum, в інших – Kanban. Scrum ідеально підходить для керування одним масштабним проєктом тривалістю від трьох місяців, який має вичерпну специфікацію і вимоги перед початком розробки. В цьому випадку команда легко підготує детальний план розробки та весь процес розділить на спринти. А Kanban відмінно підходить для маленьких проєктів, для яких не потрібно так багато часу на планування. Також він ідеально підходить для довгострокових проєктів, в яких відсутня чітка специфікація і завдання формуються в процесі розробки.
