Scrumban
Scrumban — це ритм Scrum із механікою витягування Kanban. Ви зберігаєте ритм планування й ретроспективу, прибираєте зобов’язання спринту й поповнюєте дошку, коли вона порожніє, а не за календарем. Більшість команд, які кажуть «у нас Scrum, але гнучкий», описують саме це — і правильна назва перетворює тиху ерозію Scrum на свідому конструкцію.
- Зберігає зі Scrum
- Ритм, ретроспектива
- Бере з Kanban
- Ліміти WIP, витягування
- Прибирає
- Зобов’язання спринту
Чому це взагалі існує
Scrumban не є фреймворком із посібником, сертифікацією чи органом, що ним володіє. Це назва для конкретного компромісу, до якого приходить чимало команд, і сама наявність назви важить більше, ніж здається.
Ось ситуація, яку воно розв’язує. Команда нормально працює за Scrum. Далі інциденти в production починають забирати половину її спроможності, і вона три спринти поспіль не досягає Sprint Goal. Ніхто нічого не зробив неправильно — просто ціль ніколи не була реалістичною за таких переривань.
Далі зазвичай настає тихе виродження. Команда продовжує проводити планування спринту, продовжує називати два тижні спринтом, і всі мовчки перестають сприймати ціль серйозно. Церемонії лишаються, а сенс із них витікає.
Як зібраний гібрид
Дошка — від Kanban: колонки з явними лімітами WIP, робота витягується зліва направо. Ритм навколо неї — від Scrum: регулярна ретроспектива, щоденна зустріч, періодичний огляд.
Єдина структурна зміна — коли відбувається планування. У Scrum воно запускається за датою. У Scrumban — за числом: коли черга готових задач опускається нижче порогу, ви проводите коротку сесію й поповнюєте її.
Що лишається, що змінюється, що зникає
Саме тут команди найчастіше помиляються, бо «ми прибрали спринт» зазвичай перетворюється на «ми прибрали все». Розберімо кожну церемонію конкретно.
| Церемонія | У Scrumban | Чому |
|---|---|---|
| Планування спринту | Змінюється — запускається за порогом | Спорожніла черга є кращим тригером, ніж дата |
| Щоденна зустріч | Лишається — прохід по дошці | Фокус зміщується з людей на заблоковані задачі |
| Backlog Refinement | Лишається — стає важливішим | Без нього чергу готових нічим поповнювати |
| Огляд / демо | Лишається — за фіксованим ритмом | Стейкхолдерам однаково потрібен передбачуваний момент |
| Ретроспектива | Лишається — без обговорень | Ніщо інше не змушує команду рефлексувати |
| Ціль спринту | Зникає | Зобов’язанням натомість стає ліміт WIP |
| Velocity | Зникає | Замінюється виміряним часом циклу й пропускною здатністю |
Три числа, які треба обрати
Налаштування Scrumban здебільшого зводиться до вибору трьох чисел. Оберіть їх правильно — і решта складеться сама; лишите розмитими — отримаєте дошку без правил.
1. Ліміт WIP
Встановлюйте його на колонку, а не на людину. Ліміт на людину дозволяє кожному щось почати — і дошка все одно повна незавершеного.
Робочий старт — півтори задачі на розробника в колонці «в роботі». Для команди з чотирьох це шість. Далі знижуйте протягом кількох тижнів, доки люди не почнуть іноді в нього впиратися.
2. Тригер поповнення
Це число замінює початок спринту. Коли в черзі готових лишається менше за N задач, скликається планування.
3. Збережений ритм
Вирішіть, які зустрічі Scrum лишаються, і внесіть їх у календар як повторювані події. Ретроспектива обов’язкова. Щоденну й періодичний огляд зазвичай варто зберегти. Планування стає на вимогу.
Bucket planning — довший горизонт
Щойно зникає ціль спринту, одразу постає питання: як планувати щось далі, ніж на два тижні?
У Scrumban є відповідь, запозичена з ощадливого виробництва: bucket planning, або система трьох кошиків. Робота лежить в одному з трьох кошиків і рухається вперед по одному кошику в міру того, як стає зрозумілішою.
Кошик на рік
Стратегічний напрямок. Розмиті наміри, без деталей і оцінок. Переглядається кілька разів на рік.
Кошик на пів року
Те, що бізнес уже вирішив, що хоче. Достатньо оформлене для обговорення, але ще не розкладене.
Кошик на три місяці
Готове до уточнення й витягування на дошку. Саме звідси бере зустріч поповнення.
Сенс кошиків у тому, що деталі додаються лише коли задача рухається вперед. Ніщо в річному кошику не оцінюється, бо оцінювати те, що ви, можливо, ніколи не збудуєте, — найчистіша форма змарнованого планування.
Де він розташований між двома
| Аспект | Scrum | Scrumban | Kanban |
|---|---|---|---|
| Тригер планування | Початок спринту | Черга нижче порогу | Безперервно |
| Зобов’язання | Sprint Goal | Ліміт WIP | Ліміт WIP |
| Визначені ролі | Три | Опційно | Немає |
| Ретроспектива | Щоспринту | За фіксованим ритмом | Опційно |
| Прогнозування | Velocity | Час циклу | Час циклу |
| Зміни на льоту | Небажані | Дозволені при витягуванні | Завжди дозволені |
Як це виявляється в реальній поставці
До Scrumban значно частіше приходять, ніж його обирають. Це нормально — але прихід має бути рішенням, оголошеним стейкхолдерам, а не дрейфом, який ніхто не називає.
Оголосити важливо ось чому: стейкхолдери, яким обіцяли ціль спринту, мають знати, що зобов’язання змінило форму. Натомість вони отримують прогноз за виміряним часом циклу, і це часто чесніше, — але лише якщо хтось повідомив їм про заміну.
Де він вироджується
- Прибрати зобов’язання спринту, не додавши ліміт WIP, — це не Scrumban, а необмежена черга.
- Зберегти назву спринту й церемонії, тихо ігноруючи ціль, — це приховує зміну від стейкхолдерів.
- Немає порогу поповнення, тож планування відбувається, коли хтось згадає, і черга пересихає.
- Ретроспектива зникає, бо жодна межа спринту не заганяє її в календар.
- Впроваджений, щоб утекти від дисципліни Scrum, а не щоб відповідати характеру роботи.
Коли це застосовувати
Застосовуйте, коли
- Команда поєднує заплановану роботу з постійним потоком переривань — платформа, супровід, внутрішні інструменти.
- Scrum-команда систематично не досягає Sprint Goal з причин поза її контролем.
- Вам потрібен потік як у Kanban, але з повною відмовою від Scrum ви втратите ретроспективу.
- Задачі досить дрібні й однорідні, тож ціль дає менше користі, ніж пропускна здатність.
Уникайте, коли
- Команді потрібна спільна ціль для координації — краще лишіть Scrum.
- Його впроваджують, щоб утекти від дисципліни, а не щоб відповідати характеру роботи.
- Організація планує спринтами, тож команда без спринтів стає для неї невидимою.
- Ви ще не працювали як слід ні за Scrum, ні за Kanban — освойте один, перш ніж змішувати.
Було корисно?
Поділіться з тим, хто працює над тією ж задачею.