2021-04-21 22:16:53
Кратко о канбан-методе, сумбурный набор тезисов.
1) Канбан-метод и канбан, который в Тойоте - это два разных канбана.
2) Канбан-метод, в отличие от скрама, не является набором конкретных жестких правил и инструментов. Это скорее набор принципов и рекомендуемых практик
3) Один из главных принципов - надо начать с того, что есть, и эволюционно развивать, а не перестраивать всё сразу целиком. И одна из важнейших практик с этим связанная - для начала надо
визуализировать то, что есть сейчас.
Очень много примеров, когда удачное отображение происходящих процессов на канбан-доске сразу сходу выявляет большую проблему и приносит немедленный профит. Ключевой пункт здесь - надо отрисовывать доску как оно есть на самом деле.
Например, если перед выкаткой кода надо получить апрув Иван Иваныча, даже если это просто кивок головой, то Иван Иваныч должен существовать в виде отдельной колонки на канбан-доске. И возможно перед ним будет видна большая очередь задач.
4) обычная программистская задача, если посмотреть на нее от момента взятия в работу до попадания на прод, больше ждет, чем по ней реально идут работы. Иногда в 10-20 раз. Это ожидание код ревью, деплоя, уточнений у коллег, прерывания на выполнение более важных задач и тд.
5) поэтому вторая обязательная практика - это ограничение количества задач, одновременно взятых в работу (wip-лимит). У десяти программистов всего десять голов, они не могут делать 100 задач одновременно. Стоит поставить разумный лимит на количество одновременно выполняемых работ, это существено уменьшит
lead time, существенно увеличит предсказуемость поставки и даже улучшит самочувствие разработчиков и лидов. Программисты не будут переключаться с задачи на задачу, лид будет полностью понимать, что происходит в его отделе.
6) Когда количество задач ограничено, придется построить процесс, который позволяет понять, какую задачу брать следующей, когда освободилось место. Заказчики (product-менеджеры) должны между собой договориться, какая задача сейчас важнее.
7) Так как обычно задача больше ждет чего-то, чем программируется, важнее отслеживать, кто кого блокирует, чем кто быстрее программирует. Поэтому стоит делать ежедневный митинг на 5-10 минут для выявления блокеров.
8) Визуализация может быть на нескольких уровнях. На одной доске продуктовые задачи, приносящие ценность, на других досках отдельные задачи в каждой из тех команд.
И там, и там должны быть свои WIP-лимиты.
9) WIP- лимиты вообще не зависят от размера задач. Это количество одновременно разрабатываемых задач, только и всего. Не путать со скрамом и списком задач на спринт.
10) идеально использовать "вытягивание". Т.е. только когда освободилось место (задач в работе меньше, чем WIP-лимит), брать новую задачу у продактов. Но в реальности продакты не могут работать "по вызову" и собираются время от времени, чтобы сформировать небольшой список актуальных задач, из которых разработчики будут брать задачи, когда освободятся руки. Размер этого буфера зависит лишь от частоты, с которой продакты собираются и изменчивости рынка
785 viewsAnton Okolelov, edited 19:16
C
