Why (not) Kanban
С канбаном веселухи еще больше.
Если вы слышите слово «канбан» применительно к разработке или проектам, я на 90% уверен, что как раз канбан (как оригинальная базовая методология) вам не нужен.
История. Канбаном называют доску с надписями. Или карточками. Кан — надпись/вывеска, бан — доска. Бывает разделочная, а бывает вот такая. Поскольку наглядная доска с карточками — явление прогрессивное, канбан как доска (наглядный инструмент) появился и перекочевал внутрь многих практик, методов и методологий.
Канбан как методология управления производством (популяризованная Тойотой) тоже включает в себя, как ни странно, саму доску. Канбан.
Было не плохо, для начала, не путать одно с другим.
У Тойоты и далее «работать по канбану» означало/-ет использовать канбан как средство управления цепочками производства.
У вас в скраме и прочем карамельном латте канбан — это просто доска с карточками. Потому что до цепочек производства еще дорасти надо, чтобы методологией канбана их оптимизировать. А зачастую и не ей вовсе.
Здесь и далее речь пойдет об оригинальной уже методологии, лежащей за канбаном в его понимании оптимизации процессов, а не о самой разделочной доске. Методология его вам не нужна, почти всегда. Хотя штука сама по себе прикольная. Основная идея, как сказал, в цепочках производства.
Методология задумана чисто количественная: смотреть, сколько копится units of work на различных этапах, и успевает ли весь «конвейер» разгребаться. Поступление ресурсов на линию, и выход результата с линии должны быть сбалансированы количественно, иначе производство рискует работать не очень оптимально: где-то будет перегруз, где-то ожидание. Это если совсем на пальцах.
На уровне 1970 года, производственного цеха и рабочего в нём, самое простое и наглядное — взять большую доску и на ней отмечать вход и выход ресурсов. Цифры и баланс с локальных досок можно свести в доску-покрупнее, и видеть, что если мы вот сюда вливаем ресурс, выход получим вот тут, а затыки будут вот тут и вот тут.
Три железки = 1 деталька,
2 детальки — 1 элемент,
5 элементов — модуль,
10 модулей — готовый продукт.
Больше ничего сверхъественного методология канбана (и сам метод) вам не обещает.
- чтобы он работал, у вас должны работать и быть количественно оценены процессы (чтобы было, что балансировать)
- если у вас подходят процессы под канбан, то в сфере ERP на 2023+ уже есть гораздо более продвинутые методологии
Проблема обычно в первом пункте. Некоторым людям кажется, что вот у них-то в бизнесе прям конвейер, который они сейчас ка-а-аак оптимизируют, как выстроится процесс (сам)… Нет, так не работает. И конвейера у вас скорее всего нет (и не будет) — а есть набор типовых операций, по техкартам в лучшем случае. Нечего там балансировать, т.к. нету эластичности в цифрах входа и выхода.
Если вы почему-то решили, что у вас в айти будет канбан и цепочки производства, вы подумайте еще раз, потом вместе посмеёмся.
А если это вдруг действительно так, то замените людей скриптами, делов то. Не можете? Интересно, а почему? :D
Очень мало для каких айти-процессов реального мира действительно соблюдаются вот эти оригинальные критерии:
- Each process issues requests (kanban) to its suppliers when it consumes its supplies.
- Each process produces according to the quantity and sequence of incoming requests.
- No items are made or transported without a request.
- The request associated with an item is always attached to it.
- Processes must not send out defective items, to ensure that the finished products will be defect-free.
- Limiting the number of pending requests makes the process more sensitive and reveals inefficiencies.
Если допустить, что в разработке софта вообще часть задач — исследовательские (ссылка на популистскую статью, но не лишенную смысла) — операции и процессы уже совсем не подпадают под определение «типовых и предсказуемых». Нравится вам это, или не вполне.
Развитием идей канбан-доски принято считать дядю Голдратта, т.е теорию ограничений (theory of constraints). Ничего принципиально отличающегося на входе от задач канбана вы там не увидите — same story:
Но у Голдратта еще и описаны способы, как с этим всем лететь.
Сверху существует довольно много прикладных способов и моделей. Оптимизацию цепочек (процессов) вообще с научной точки зрения много кто изучал, и не важно, находятся у вас те цепочки в бизнесе, в производстве, или еще где. Гугл в помощь.
В англоязычной литературе канбан-про-разработку обычно принято упоминать в связи с Lean. Частью которого также является разделочная доска, вдобавок обратите внимание — она там уже и не про цепочки вовсе.
Для того, чтобы неофиту на прикладном уровне проникнуться оптимизацией цепочек, по теории ограничений — без шуток — порекомендую игрушку Factorio.
Вся видеоигра об этом: сначала накреативь себе сборочные процессы, а потом бегай и оптимизируй, перепиливай узкие места, выпиливай костыли, заноси рефакторинг.
Осторожно, если «зайдет» — минус месяц жизни. Зато вкус прочувствуете, по кругу бегать решать задачу «кто это здесь нагородил и что он думал», вокруг своих конвейеров. Просветляет.
В общем, это я к чему. Голдратт хорош, спору нет. Еще можно задачу о распределении пива посмотреть, и как ее в современном мире решают, в условиях локальной неопределенности и локальных экстремумов распределений.
Но если в вашем бизнесе (еще) нет количественно балансируемых цепочек и процессов — методология канбана (пока) не про вас.
Выбирайте инструмент под задачу.
Вместе с тем, еще раз оговорюсь: помимо канбана как такового, оригинального референсного, здесь упомянутого, есть жизнеспособные и вполне популярные подходы, которые включают в себя канбан-доску как базовый механизм, и даже успешно строят вокруг неё свои процессы. Например, скрамбан, lean, kanban-method-in-agile, довольно много их.