Scrumban

Scrumban на одному екрані

У Scrumban немає ні посібника, ні організації-власника, тож найчіткіше його визначає те, що він робить із кожною частиною Scrum. Ось кожен елемент Scrum Guide і що з ним стає — лишається, змінюється чи зникає, — разом із правилом, яке команда записує замість нього. Читайте це як звичну форму, а не стандарт: команди різняться, і розділи нижче кажуть, де саме.

Однією картинкою: Kanban-дошка з лімітами, поріг під чергою готових задач, який скликає планування, коли черга порожніє, і ритм Scrum, що триває знизу за фіксованим графіком.

Навіщо він існує: спринт, який ламають переривання

Ось ситуація, яку розвʼязує Scrumban. Команда нормально працює за Scrum. Далі інциденти в production починають забирати третину її спроможності, і вона три спринти поспіль не досягає Sprint GoalSprint Goalнавіщо цей спринтОдне речення, узгоджене на плануванні спринту, про те, що зміниться наприкінці й навіщо це варто робити. Саме воно дає команді посеред спринту прибрати чи замінити окремі задачі без провалу: спринт, який оцінюють лише за списком тікетів, має квоту, а не ціль.Докладніше в статті →Усі терміни. Ніхто нічого не зробив неправильно — просто ціль ніколи не була реалістичною за таких переривань.

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

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

Два значення одного слова

Слово змістилося, і цей зсув пояснює більшість суперечок довкола нього. Корі Ладас, колишній менеджер розробки в Microsoft, придумав його в есеї 2008 року й розгорнув у книжку 2009 року «Scrumban: Essays on Kanban Systems for Lean Software Development». Його Scrumban був шляхом, а не місцем: почати зі Scrum, міняти по одній практиці в бік безперервного потоку, дати процесу стабілізуватися, виміряти й повторити.

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

Більшість команд, які вживають це слово сьогодні, мають на увазі інше: сталий гібрид, до якого доходять, зупинившись на пів дороги з наміром там і лишитися. Відтоді ще два тексти провели межу в інших місцях. «The Scrumban [R]Evolution» Аджая Редді (2015) розглядає Scrumban як Kanban Method, застосований до команди, що стартує зі Scrum. «Kanban Guide for Scrum Teams» від Scrum.org, написаний разом із Деніелом Ваканті в лютому 2018 року й переглянутий 2021-го, іде в протилежний бік: додає до Scrum ліміти WIP, метрики потоку й service level expectationSLEService Level Expectation — скільки має тривати задача — з імовірністюПрогноз, який Kanban-команда публікує з власної історії: тривалість і ймовірність, наприклад «85 відсотків задач завершуються протягом 11 днів від початку». Він описує, що система робила досі, а не обіцяє, що вона робитиме, тож змінюється щоразу, коли змінюється система.Докладніше в статті →Усі терміни, зберігаючи SprintSprintцикл роботи фіксованої довжиниФіксований період, зазвичай від тижня до чотирьох, наприкінці якого є щось достатньо завершене, щоб показати. Фіксована саме довжина, а обсяг рухається: спринт, який подовжили під роботу, втратив єдине, заради чого існував.Докладніше в статті →Усі терміни і Sprint Goal недоторканими. Це Scrum із Kanban — і свідомо не Scrumban.

Три числа, які треба обрати

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

1. Ліміт WIP

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

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

2. Точка замовлення

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

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

3. Збережений ритм

Вирішіть, які зустрічі Scrum лишаються, і внесіть їх у календар як повторювані події. Ретроспектива обовʼязкова. Щоденну зустріч і огляд раз на два тижні зазвичай варто зберегти. Планування стає на вимогу — його скликає точка замовлення.

Запланована робота й переривання на одній дошці

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

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

Планування далі ніж на два тижні

Щойно зникає ціль спринту, одразу постає питання: як планувати щось далі, ніж на два тижні? Книжка Ладаса відповідає на це bucket planning, або системою трьох кошиків. Робота лежить в одному з трьох кошиків і рухається вперед по одному кошику в міру того, як стає зрозумілішою.

• Кошик на рік

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

• Кошик на пів року

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

• Кошик на три місяці

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

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

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

Поруч з обома батьками — і один виміряний перехід

Siemens Health Services, 2012

Найкраще задокументований перехід такого роду не називав себе Scrumban, але за визначенням цієї сторінки саме ним і був. Siemens Health Services працювала за Scrum з 2005 року. До 2012-го її програма Soarian Financials — близько пʼятнадцяти Scrum-команд у Малверні (Пенсільванія), Брукліні й Колкаті — зʼясувала, що story pointsstory pointsвідносний розмір, не годиниОдиниця для оцінки відносного розміру задач беклогу — 8 приблизно вдвічі більше за 5, — навмисно не привʼязана до годин. Корисні для планування однієї команди й більше ні для чого: перетворені на ціль чи порівнювані між командами, вони роздуваються замість вимірювати.Докладніше в статті →Усі терміни і velocity не дають придатного прогнозу в масштабі релізу.

У травні 2012 року команди відмовилися від планування спринту, спринтів з таймбоксом, story points і velocity та перейшли на безперервне витягування з лімітами WIP, вимірюючи час циклу й пропускну здатність на накопичувальних діаграмах потоку й діаграмах розсіювання. Вони зберегли свої інженерні практики, щомісячні ретроспективи, а також огляди команд і програми. Беннет Валле із Siemens опублікував результати 2014 року:

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

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

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

• Прибрати зобовʼязання спринту, не додавши ліміт WIP, — це не Scrumban, а необмежена черга.
• Зберегти назву спринту й церемонії, тихо ігноруючи ціль, — це приховує зміну від стейкхолдерів.
• Немає точки замовлення, тож планування відбувається, коли хтось згадає, і черга пересихає.
• Ретроспектива зникає, бо жодна межа спринту не заганяє її в календар.
• VelocityVelocityскільки вміщується у спринтСкільки команда реально завершує за спринт, усереднено за кілька. Це допоміжна величина для планування однієї конкретної команди й нічого більше: порівнювати velocity двох команд чи ставити її за ціль означає надійно отримати роздуті оцінки, а не більше роботи.Докладніше в статті →Усі терміни досі звітують нагору поряд із часом циклу — і команду оцінюють за числом, якого її процес уже не видає.
• Доріжка expediteexpediteклас роботи для аварійКлас обслуговування в Kanban для справжніх аварій: задача expedite проходить поза чергою й ігнорує ліміт WIP. Це працює лише із суворим обмеженням, зазвичай одна задача одночасно, — без нього аварією стає кожен запит, який важливий комусь із керівництва.Докладніше в статті →Усі терміни без ліміту — і вся дошка знову перетворюється на чергу переривань.
• Немає доріжки покращень — і технічний борг чекає на спринт, якого більше не існує.
• Спринти оголошують у календарі, а задачі на дошці підміняють щодня, — Scrum за назвою і жодного процесу на ділі.
• Впроваджений, щоб утекти від дисципліни Scrum, а не щоб відповідати характеру роботи.

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

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

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