Scrumban.

Що таке Scrumban насправді

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

Чого в ньому немає: щоденних стендапів, зустрічей із грумінгу спринту, церемоній зі story points, ретроспектив заради ритуалу. Усе це працює для десяти інженерів у налагодженій організації; але не працює для одного засновника, який намагається щось випустити в суботу.

Чому Weft обирає Scrumban

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

Як це реалізовано у Weft

• Чотири колонки за замовчуванням: Backlog, Todo, Doing, Done. Незавершену роботу обмежує те, що чекає на тебе, а не число на кожній колонці. Kanban Guide розглядає явне правило обмеження незавершеної роботи як частину визначення робочого процесу, щоб нові елементи бралися в роботу лише тоді, коли звільняється місткість.
• Один активний спринт водночас. Спринти необов’язкові — обходься без них, якщо тобі пасує чистий канбан. Scrum Guide визначає спринти як події фіксованої тривалості — місяць або менше, причому новий спринт починається одразу після завершення попереднього.
• Задачі мають пріоритет, оцінку, дедлайн і необов’язкову прив’язку до спринту. Жодних епіків, жодних workflow, жодних власних полів.
• Час циклу починається, коли задача переходить у колонку з semantic="doing", і закінчується в "done". Цифри беруться з чесної роботи, а не з арифметики story points.

Коли Scrumban — не той метод

• У тебе кілька паралельних Scrum-команд. Scrum Guide зазначає, що Scrum-команда зазвичай налічує 10 або менше людей, а більші продукти варто організовувати в кілька Scrum-команд зі спільною Product Goal та одним Product Backlog. Звітність на рівні програми, спільна velocity, міжкомандні залежності — тут повноцінний Scrum у Jira себе виправдовує. Nexus Guide написано саме для такої ситуації: кілька Scrum-команд працюють з одного Product Backlog і мають додаткові практики, щоб виявляти та розв’язувати міжкомандні залежності.
• У тебе чиста підтримка чи безперервна експлуатація. Ритм спринтів не потрібен — чистий канбан або тікет-система підійдуть краще.
• Тобі потрібні діаграми Ганта й таймлайни. Scrumban зосереджений на спринтах, а не на графі залежностей.