Кратко о канбан-методе, сумбурный набор тезисов.

1) Канбан-метод и канбан, который в Тойоте - это два разных канбана.

2) Канбан-метод, в отличие от скрама, не является набором конкретных жестких правил и инструментов. Это скорее набор принципов и рекомендуемых практик

3) Один из главных принципов - надо начать с того, что есть, и эволюционно развивать, а не перестраивать всё сразу целиком. И одна из важнейших практик с этим связанная - для начала надо визуализировать то, что есть сейчас.

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

Например, если перед выкаткой кода надо получить апрув Иван Иваныча, даже если это просто кивок головой, то Иван Иваныч должен существовать в виде отдельной колонки на канбан-доске. И возможно перед ним будет видна большая очередь задач.

4) обычная программистская задача, если посмотреть на нее от момента взятия в работу до попадания на прод, больше ждет, чем по ней реально идут работы. Иногда в 10-20 раз. Это ожидание код ревью, деплоя, уточнений у коллег, прерывания на выполнение более важных задач и тд.

5) поэтому вторая обязательная практика - это ограничение количества задач, одновременно взятых в работу (wip-лимит). У десяти программистов всего десять голов, они не могут делать 100 задач одновременно. Стоит поставить разумный лимит на количество одновременно выполняемых работ, это существено уменьшит lead time, существенно увеличит предсказуемость поставки и даже улучшит самочувствие разработчиков и лидов. Программисты не будут переключаться с задачи на задачу, лид будет полностью понимать, что происходит в его отделе.

6) Когда количество задач ограничено, придется построить процесс, который позволяет понять, какую задачу брать следующей, когда освободилось место. Заказчики (product-менеджеры) должны между собой договориться, какая задача сейчас важнее.

7) Так как обычно задача больше ждет чего-то, чем программируется, важнее отслеживать, кто кого блокирует, чем кто быстрее программирует. Поэтому стоит делать ежедневный митинг на 5-10 минут для выявления блокеров.

8) Визуализация может быть на нескольких уровнях. На одной доске продуктовые задачи, приносящие ценность, на других досках отдельные задачи в каждой из тех команд.
И там, и там должны быть свои WIP-лимиты.

9) WIP- лимиты вообще не зависят от размера задач. Это количество одновременно разрабатываемых задач, только и всего. Не путать со скрамом и списком задач на спринт.

10) идеально использовать "вытягивание". Т.е. только когда освободилось место (задач в работе меньше, чем WIP-лимит), брать новую задачу у продактов. Но в реальности продакты не могут работать "по вызову" и собираются время от времени, чтобы сформировать небольшой список актуальных задач, из которых разработчики будут брать задачи, когда освободятся руки. Размер этого буфера зависит лишь от частоты, с которой продакты собираются и изменчивости рынка