Kanban

Kanban-система на одному екрані

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

Дошка — це ще не Kanban

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

Саме слово пояснює чому. Kanban японською — вивіска чи картка. На лініях Toyota, де Тайіті Оно випробував систему в механічному цеху 1953 року й до 1962-го поширив на всю компанію, картка не була описом задачі. Вона була дозволом виробляти. Дільниця робила деталі лише тоді, коли від наступної дільниці поверталася картка, тож кількість карток в обігу і була лімітом запасів: немає картки — немає виробництва.

Дошки в софті перевернули це. На дошці картка — це сама задача, тож дозвіл доводиться записувати окремо — числом угорі кожної колонки. Це число називають лімітом WIP. WIP означає work in progress, тобто все розпочате, але не завершене. Дошка без цього числа зберегла картинку й загубила механізм.

А тепер про те, чому це одне правило так важить. Без нього дошка — це черга, яка може рости нескінченно: коли ви заблоковані, ви просто починаєте щось нове. З ним дошка чинить опір. Ви не можете почати нічого, доки щось не завершиться, тож команда змушена йти й розблоковувати те, що застрягло, а не обходити його.

Його визначають дві організації — і вони не згодні, наскільки детально

Хто шукає офіційне визначення, знаходить два, і чимала частина плутанини довкола Kanban походить від їх змішування. Kanban University, співзасновником якого є Девід Андерсон, публікує Kanban Method — підхід, який Андерсон вибудував у Microsoft з 2004 року й у Corbis з 2006-го та описав у книжці 2010 року. ProKanban.org публікує The Kanban Guide, уперше виданий у липні 2020 року й чинний у редакції травня 2025-го, — свідомо мінімальний текст Деніела Ваканті, Джона Коулмана та інших.

Жодне з них не хибне, і сторінка користується обома: чотирма метриками й service level expectation з Guide — бо це найгостріші інструменти прогнозу, — і принципами, ритмами та класами обслуговування з Method — бо команда, яка лише вимірює потік, не має нічого, що підкаже, чи цей потік кудись корисно спрямований. Там, де вони вживають одне слово по-різному, сторінка це позначає.

Шість принципів, шість практик

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

Шість практик — це те, як принципи виглядають у дії. Їх передбачається впроваджувати приблизно по черзі: кожна наступна стає можливою завдяки попередній.

1. Візуалізувати робочий процес

Намалюйте етапи, які робота проходить насправді, а не ті, що в документі про процес. Більшість команд виявляє два-три етапи, які вони ніколи не називали, і це зазвичай етапи очікування: «чекає на рев’ю», «чекає на клієнта», «чекає на деплой».

Ці приховані етапи очікування важливіші за робочі. У більшості команд задача проводить у чеканні значно більше часу, ніж у роботі, а покращити час, якого ви не бачите, неможливо. Намалюйте лінією й точку зобовʼязання. Усе, що до неї, Kanban University називає upstream: ідеї та варіанти, які ще можна відкинути, — і саме тому їх не можна рахувати обіцянками.

2. Обмежити роботу в процесі

Це та єдина практика, де компромісів немає. Поставте число вгорі кожної колонки й дотримуйтесь його.

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

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

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

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

4. Зробити правила явними

Запишіть, що потрібно, щоб задача увійшла в кожну колонку і щоб вийшла з неї. Що означає «готово до розробки»? Що має бути правдою, перш ніж щось перейде в «завершено»?

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

5. Побудувати цикли зворотного звʼязку

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

6. Покращувати спільно, розвиватися експериментально

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

Класи обслуговування — терміновість, записана як правило

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

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

• Expedite — кинути все

  Production лежить, гроші втрачаються. Ігнорує ліміт WIP і проходить поза чергою. Тримайте суворий максимум — зазвичай один одночасно, — інакше кожен запит стане expedite.

• Standard — за замовчуванням

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

• Fixed date — справжній дедлайн

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

• Intangible — без терміновості, з цінністю

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

Поруч із класами обслуговування стоїть друге правило — розподіл спроможності: ліміт WIP ділять між видами роботи, щоб позапланові запити не поглинули заплановану роботу, і навпаки. Найбільше це важить для команд, які поєднують roadmap із підтримкою, і сторінка про Scrumban розкладає його по доріжках.

Чотири метрики — і арифметика під ними

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

А тепер пастка термінології, бо команди регулярно звітують одним числом, маючи на увазі інше. Ця сторінка, як і Kanban Guide, називає часом циклу проміжок від початку до завершення. Lead time тут — проміжок замовника, від запиту до поставки; customer lead time у Kanban University натомість рахують від точки зобовʼязання. Проміжок між запитом і початком роботи — це те, скільки задача пролежала в черзі, доки хтось до неї торкнувся, і в багатьох командах саме він становить більшу половину того, що відчуває замовник. Коли хтось називає число, спитайте, де запустили годинник.

Закон Літтла — обґрунтування лімітів WIP

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

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

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

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

Накопичувальна діаграма потоку

Одна діаграма варта окремої згадки, бо показує все вищесказане одночасно. Накопичувальна діаграма потоку відкладає для кожного дня, скільки задач уже увійшло в кожен етап, — у вигляді кольорових смуг, накладених одна на одну. Її геометрія — це намальований закон Літтла: відстань між двома лініями по вертикалі — це WIP між ними, по горизонталі — приблизно час, який задача проводить між ними, а нахил нижньої лінії — пропускна здатність.

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

Чому повністю завантажена команда повільна

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

Реальні команди в деталях відрізняються від підручника, але форма загальна, і Дональд Райнертсен побудував на ній значну частину книжки «The Principles of Product Development Flow» (2009): останні десять відсотків завантаженості коштують більше очікування, ніж перші вісімдесят. Це і є арифметика під третьою практикою. Запас — не марнування, а те, що тримає чергу короткою.

Прогноз з історії замість оцінок

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

Позначте кожну завершену задачу точкою: коли завершили — по горизонталі, скільки тривала — по вертикалі. Це діаграма розсіювання часу циклу, і три горизонтальні лінії перетворюють її на прогноз. 50-й процентиль — час, у який вкладається половина задач. 85-й — час, у який вкладається більшість, і звичайна основа для обіцянки. 95-й — час, у який вкладаються майже всі.

Далі команда публікує service level expectation, скорочено SLE: тривалість і ймовірність, наприклад «85 відсотків задач завершуються протягом 11 днів від початку». Це не ціль і не контракт. Це опис того, що система робила досі, і він змінюється, коли змінюється система.

А тепер корисна частина. Вік задачі — скільки задача, яка ще в роботі, уже в ній перебуває, — можна щоранку порівнювати з SLE. Задача, вік якої наближається до 85-го процентиля, у зоні ризику, поки ще є час діяти: навалитися на неї всім, розбити чи розблокувати. Час циклу каже, що задача запізнилася, коли вона вже завершилась; вік каже, що вона запізниться, поки її ще можна врятувати. Тому Kanban Guide і зробив його однією з чотирьох обовʼязкових метрик.

Сім ритмів — і де тут події Scrum

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

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

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

Поруч зі Scrum

Ці два підходи не суперники, і команди регулярно використовують обидва. Але один структурний вибір у них справді різний, і розуміння цього робить рішення простим.

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

Пʼять задокументованих випадків — і правило, яке кожен перевірив

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

Де він вироджується

Щойно команда запроваджує справжній ліміт WIP, її перша реакція — дискомфорт. Люди опиняються заблокованими, без «своєї» задачі, яку можна почати, і це відчувається як стояння без діла. Цей дискомфорт і є роботою методу: він перетворив невидиму чергу на видиму розмову про вузьке місце. До ліміту та сама людина почала б пʼяту задачу, а затор лишився б рівно там, де був, — з більшою кількістю незавершеної роботи позаду.

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

• Дошка без лімітів WIP — найпоширеніший випадок, і це не Kanban.
• Ліміт, який підвищують щоразу при досягненні, — це прибирає єдиний механізм тиску.
• Колонка «Заблоковано» як стоянка, де заблоковані задачі перестають рахуватися у WIP.
• Впроваджено лише два швидкі ритми — тож ніхто ніколи не питає, чи це та робота.
• Усе позначене як expedite — черга втрачає сенс, а прогноз стає хибним.
• Час циклу як ціль для окремих людей — задачі дроблять, щоб виглядати швидкими, і закривають, не завершивши.
• Годинник запускають на «В роботі» — і це ховає чергу перед нею, ту частину очікування, яку замовник відчуває найбільше.
• Звітують середнім замість процентилів — і приблизно половина обіцянок порушується.
• «Ми працюємо за Kanban» у значенні «ми не плануємо»: ні поповнення, ні SLE, ні перегляду того, що потрапляє на дошку.
• Колонки інструмента за замовчуванням прийняті як процес — і ніхто не намалював етапи, які робота проходить насправді.

Коли це застосовувати

Пов’язані сторінки

• МенеджментScrumScrum — це фреймворк, у якому команда до десяти людей видає придатний інкремент у фіксованих циклах до місяця — спринтах — і коригує курс на пʼяти подіях. Він визначає три зони відповідальності, три артефакти й ці пʼять подій — і свідомо нічого не каже про інженерію. Сторінка починається з усього фреймворку на одному екрані — кожна подія з таймбоксом, хто присутній і що вона дає; далі — теорія, на якій він тримається, кожна подія по черзі разом із чотирма зустрічами, які додають реальні команди, зони відповідальності й чому межа — десятеро, Definition of Done і що стається, коли вона зупиняється зарано, пʼять задокументованих епізодів і де все це вироджується.
• МенеджментScrumbanScrumban — це спосіб організувати роботу команди, який зберігає зустрічі Scrum, а зобовʼязання спринту замінює лімітами WIP із Kanban і плануванням на вимогу. Назву 2008 року придумав Корі Ладас для шляху від Scrum до безперервної поставки; сьогодні більшість команд називає так сталий гібрид. Сторінка починається з кожного елемента Scrum і того, що з ним стає; далі — навіщо гібрид існує, два значення слова, три числа, які його визначають, як запланована робота й переривання ділять одну дошку, планування далі ніж на два тижні, порівняння з обома батьками й один виміряний перехід, і де все це вироджується.
• МенеджментAgileAgile — це чотири цінності й дванадцять принципів розробки софту, записані 2001 року, які ставлять навчання на робочому продукті вище за дотримання плану. Це не методологія: Scrum, Kanban і Extreme Programming — методології, збудовані поверх нього, — і власних зустрічей, ролей чи артефактів у нього немає. Сторінка починається з Маніфесту повністю, пронумерованого, щоб на рядок можна було послатися; далі — шар, який він займає, на що міняє кожна цінність, ставка на вартість змін, петлі зворотного звʼязку як справжній механізм, кожен принцип як перевірка, яку можна провести у своїй команді, шість програм, долю яких він вирішив, і де все це вироджується в театр.