Kanban

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

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

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

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

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

Шість практик

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. Покращувати спільно

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

Сім ритмів

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

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

Пройдімо їх від найшвидшого до найповільнішого.

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

Метрики і чому вони працюють

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

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

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

Під усім цим лежить трохи математики, і її можна викласти одним рядком.

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

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

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

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

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

Класи обслуговування

Ось питання, до якого доходить кожна команда протягом місяця після впровадження Kanban: що робити, коли з’являється справді термінове, а колонка вже на ліміті?

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

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

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

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

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

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

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

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

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

Kanban поруч зі Scrum

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

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

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

Як це виявляється в реальній поставці

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

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

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

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

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

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

• МенеджментScrumScrum — це найпоширеніший спосіб організувати роботу команди розробки. Scrum ділить роботу на короткі фіксовані цикли — спринти, дає трьом ролям чіткі зони відповідальності й обкладає роботу невеликим набором регулярних зустрічей, щоб проблеми спливали за дні, а не за місяці. На цій сторінці ми пройдемо кожну з цих зустрічей — включно з кількома, які реальні команди проводять, хоча в офіційному посібнику їх немає.
• МенеджментScrumbanScrumban — це ритм Scrum із механікою витягування Kanban. Ви зберігаєте ритм планування й ретроспективу, прибираєте зобов’язання спринту й поповнюєте дошку, коли вона порожніє, а не за календарем. Більшість команд, які кажуть «у нас Scrum, але гнучкий», описують саме це — і правильна назва перетворює тиху ерозію Scrum на свідому конструкцію.
• МенеджментAgileAgile — це спосіб створювати софт, який припускає, що ви в чомусь помиляєтесь, і планує дізнатися про це рано. Agile не є процесом, який «встановлюють», і не є набором зустрічей — це невелика група переконань, записаних 2001 року, на яких побудовано з десяток різних методологій. На цій сторінці ми розберемо ці переконання, усі дванадцять принципів за ними і те, що насправді змінюється в команді, яка сприймає їх серйозно.