Конференція ScrumDayUkraine 2021 — зовсім скоро! Ловіть early bird price, поки не відлетіла
22 Грудня, 2020 | 577 | 0.0  0.0

Скрам + Канбан: основи

Як ви, мабуть, знаєте, на Scrum.org вже давно опублікований посібник зі скраму з канбаном, існує сертифікация PSK — Professional Scrum with Kanban. У блозі організації можна знайти цілу серію постів про скрам з елементами канбану від Стіва Портера (експерта Scrum.org і колишнього власника продукту в TeamPulse) і Юваля Ерета (досвідченого практика скраму з канбаном і одного з консультантів AgileSparks, відомої нашим учням за виступами Одеда Таміра). Приводимо декілька важливих витягів з Q&A Юваля і базового посібника з канбану для скрам-команд, а також перелік статей, які на цю тему рекомендує Scrum.org.

Цінності й базові принципи канбану

Канбан — це метод, в основі якого лежить система витягування (pull system) виробництва, тобто, обмеження на кількість незавершеної роботи (work-in-process). Тут усе влаштоване так, щоби застояні задачі було легко відстежити й перерозподілити всередині команди. Це дозволяє виявляти операційні проблеми і мотивувати працівників до покращень.

Ті, хто практикує канбан, дотримуються кількох основних принципів:

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

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

Дещо про дошки й картки Kanban і Scrum

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

Дошки бувають фізичними і віртуальними. Фізична дошка Kanban (на зображенні нижче) вішається на стіну, для створення віртуальних використовуються планувальники задач. Найпопулярніші — Trello і JIRA, але також є більш вузькопрофільні інструменти Kanban, що можуть краще підходити під задачі вашої конкретної команди: Hygger, MeisterTask, Asana, Favro, Paymo, Kanbachi, Blossom, Breeze, Taiga, ZenHub, ProofHub, LeanKit. Разбираемся в Scrum и Kanban

Що таке картки Kanban?

Картки — це фізичні чи віртуальні стікери, на яких прописуються задачі, найчастіше у формі історій користувачів з описом, вагою (у сторі пойнтах) і пріоритетом.

Принцип роботи з дошкою такий:

  • на дошку додають стовпчики, що візуалізують етап, на якому знаходиться задача (“Концепція”, “Дизайн”, “Розробка”, “Тестування”, “Реліз” чи інші);
  • у стовпчики вклеюють (чи вносять онлайн) картки Kanban. Коли задача переходить з одного етапу в інший, картку переносять у другий стовпчик.

Все просто. Завдяки дошці з картками Kanban з першого погляду зрозуміло, які успіхи команди в цьому спринті.

Застосування канбану в скрамі

1. Візуалізувати (роботу, розпорядок, ризики)

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

Окрім цього, для скрам-команди важливо стежити за просуванням елементів беклогу продукту: від створення ідеї через її уточнення, аналіз, дизайн, написання коду, тестування аж до релізу — іншими словами, відстежувати весь шлях “до готового”. В канбані це називається потоком цінності (value stream). Для цього існують спеціалізовані інструменти канбану — канбан-дошки, на яких прийнято візуалізувати не лише беклог спринту (окремі задачі), але й усе просування роботи на вході та виході зі спринту (елементи беклогу продукту). Між іншим, якраз із цим багато команд мають проблеми.

Скрам+Канбан: основы

2. Обмежувати незавершену роботу (Work in Process)

Наступний крок після візуалізації потоку — застосування канбан-системи. На практиці це — обмеження допустимої кількості незавершеної роботи.

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

Зазвичай на канбан-дошках уточнюють межі Work in Process на різних стадіях роботи (дизайну, програмування, тестування, запуску та ін.). Коли межі за одним із таких етапів досягнуто, члени команди допомагають одне одному відпрацювати існуючі елементи беклогу, а не хапаються за нові. Це може означати, що потрібно допомогти іншим в межах власних або навіть їхніх компетенцій (наприклад, програмісти допомагають тестувальникам, тестувальники допомагають бізнес-аналітикам і т.д.). Така канбан-система може розповсюджуватися за межі спринту й охоплювати такі дії в потоці цінності, як відкриття властивостей продукту, уточнення елементів Беклогу або підтримка продакшену.

Межі Work in Process мають бути досить низькими, щоб створювати певні незручності — вони мають, так би мовити, виштовхувати людей із зони комфорту. Цими незручностями можна керувати так, щоб команди покращували свої політики й процеси і тим самим зменшували дискомфорт через обмеження незавершеної роботи. 

Із цим їм допоможе грамотне застосування acceptance test-driven development (дослівно — розробка через прийомне тестування, ATDD), зменшення розміру та кількості елементів беклогу в спринті, а також взаємне навчання. З часом, коли команда розвине ще більші здібності, можна буде встановлювати їй нові незручні межі незавершеної роботи і добиватися ще більшої результативності. Обмеження Work in Process — ефективний спосіб посилити співпрацю в команді.

Скрам+Канбан: основы

3. Керувати потоком

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

Можна використовувати кумулятивні діаграми потоку — вони стануть непоганим додатком до бьорнап-чартів. Скрам-команда може також шукати можливості зменшити час надходження роботи в продакшн. Скрам регламентує розробку в межах спринту. Запланована робота має бути готова до кінця спринту, але при роботі відразу ж і над потоком команда шукає шляхи випускати роботу відразу по готовності. У Посібнику зі скраму не сказано, що треба обов’язково очікувати на завершення спринту. Схожа точка зору викладена у статті про огляд спринту на Scrum.org.

psk3

4. Працювати над прозорістю процесу

Чим прозоріший процес, тим більша впевненість. Канбан допомагає скрам-командам додати прозорості не лише до роботи, але й до процесу. Коли учасники й учасниці команд чітко розуміють процес, їм простіше самоорганізовуватися (приклади використання канбану зі скрамом ви знайдете в книзі Девіда Марке Turn the Ship Around!).

Прозорість процесу також допомагає командам його покращити. Їм простіше задавати такі питання, як “Чому ми працюємо саме так?” або “Як зміна політики відобразиться на нашій швидкості і результатах?”.

Визначення “готового” в скрамі — чудовий зразок прозорої політики. Сам фреймворк також прозорий: Посібник зі скраму можна розглядати як прозоро викладену політику, яку втілює скрам-команда. В канбані команди додають ще й інші політики: межу WIP для кожної лінії потоку і кожної людини, класи сервісної політики, правила візуалізації й обробки труднощів, пріоритизація задач.

5. Використовувати петлі зворотного зв’язку

Для зворотного зв’язку скрам-команди використовують планування спринту, щоденний скрам, огляд спринту й ретроспективу спринту.

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

Скрам+Канбан: основы

6. Підвищувати якість через співпрацю й експеримент з науковими методами й моделями

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

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

У цьому процесі можуть допомогти інструменти канбан на зразок A3 / Toyota Kata. Вивчіть також моделі типу Reinertsen’s principles of product development flow — вони (часом із неочікуваного боку) розкривають взаємодію об’єму, варіативності і частоти роботи, команд, WIP і часу циклу.

Скрам+Канбан: основы

Резюме про канбан-практики

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

У Посібник зі скраму з канбаном також не включено такі практики канбану, як Classes of Service, Cost of Delay і Flow Efficiency (хоч вони і згадані в курсі Scrum.org): на думку авторів посібника, вони не входять до мінімально необхідного скрам-командам набору практик. Частина з них може виявитися більш корисною в контексті скраму, частина — менш корисною, але застосовувати їх чи ні – рішення кожної окремої команди, після того як вона розбереться з основами, викладеними в посібнику.

Додаткові питання

Чи можна вважати скрам + канбан застосуванням канбан-методу?

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

Існує твердження, що обмеження work in process — не еволюційна, а різка, революційна зміна. Юваль вважає, що цей перехід дійсно не є простим, та ми все ж можемо вважати його еволюційним, порівняно зі зміною структур, ролей і потоків процесу. Професійній скрам команді в кожному разі буде легше обмежувати WIP, ніж багатьом іншим командам.

Чи можна вважати це скрамбаном?

Усе залежить від того, як ви бачите скрамбан. Деякі практики визначають його як “спосіб допомогти командам перейти від скраму до канбану”. В такому разі, скрам + канбан — не скрамбан.

Інше визначення (якого дотримується в тому числі Юваль) таке: скрамбан — це спосіб застосовувати принципи ліну й канбану в процесі скраму, кардинально не змінюючи цей процес. Таке визначення близьке до скраму + канбану, який ми описуємо.

Скрамбан можна розглядати і як просте поєднання скраму й канбану незалежно від того, з чого ви почали. І це саме те, що описується в Посібнику з канбану для скрам-команд.

Коли слід додавати канбан до скраму?

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

Коли канбан не потрібно застосовувати разом зі скрамом?

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

Скрам и Канбан

Джерела, рекомендовані Scrum.org

Тренінг

Матеріали для курсу

Матеріали блогів

Статті

Відео й подкасти

Книги

Інші ресурси

Перекладено й адаптовано командою BrainRain за матеріалами: