Канбан в офисе. Однако начав вместе с Андерсоном анализировать работу XIT, он быстро выявил ключевые факторы, которые негативно влияли на скорость отдела

КАНБАН

Cистема Канбан (Kanban) - тянущая система организации производства и снабжения, позволяющая реализовать принцип точно вовремя (Just-In-Time).

Разработана и впервые в мире реализована фирмой "Тойота". В 1959 г. эта фирма начала эксперименты с системой Канбан и в 1962 г. начала процесс перевода всего производства на принципы Канбан. В основе Канбан - теоретические построения Ф. Тейлора (1856-1915); Г. Форда (1863-1947), а также некоторые положения философии дзэн-буддизма и конфуцианства.

В основе организации производства фирмы "Тойота" лежит годовой план производства и сбыта автомобилей, на базе которого составляются месячные и оперативные планы среднесуточного выпуска на каждом участке, основанные на прогнозировании покупательского спроса (период упреждения - 1 и 3 мес.). Суточные графики производства составляются только для главного сборочного конвейера. Для цехов и участков, обслуживающих главный конвейер, графики производства не составляются (им устанавливаются лишь ориентировочные месячные объемы производства).

Постоянное использование философии «точно-во-время» позволяет раскрыть не обнаруженные до сих пор дефекты. Запасы очень хорошо приспособлены для сокрытия дефектов. Только при уменьшении запасов можно разглядеть проблемы. Это очень похоже на то, как высокий уровень воды скрывает подводные рифы.

«Канбан» - на японском языке означает карточка.

Существует два вида системы «Канбан»:

- тарный «Канбан»;

- карточный «Канбан».

Тарный «Канбан» представляет из себя единицу тары, на которой находится бирка «Канбан». Бирка «Канбан» на контейнере закреплена жестко и имеет следующие содержание:

Наименование детали;

Номер детали;

Количество деталей;

Адрес получателя детали;

Адрес отправителя детали.

Система заказа деталей и узлов по тарному «Канбану» осуществляется следующим образом: по мере окончания деталей в первом тарном «Канбане» оператор убирает его с рабочего места на нижний ярус стеллажа (нижний ярус стеллажа является местом для складирования заказов оператора и получением заказов транспортировщиком) и работает из второго. Транспортировщик забирает порожнею тару и поскольку к таре прикреплен «Канбан» осуществляется обратная связь между оператором и кладовщиком через транспортировщика для заказа материалов.

Тарный «Канбан» имеет недостаток - требуется дополнительное количество тары на каждую единицу детали или КИ при создании склада.

Карточный «Канбан» представляет из себя карточку, разделённую на четыре раздела:

Цвет карточки;

Адрес отправителя детали;

Наименование детали, номер детали, количество деталей или узлов, необходимое для поставки по адресу получателя;

Адрес получателя детали.

Один из вариантов цветовой гаммы:

Синий - производственный «Канбан» (между производственной линией и зоной выдачи);

Красный - складской «Канбан» (между складом и зоной выдачи);

Зелёный - межцеховой «Канбан»(между цехами, производствами заводами и.т.д.).

Доставка деталей должна осуществляться на транспортировочных тележках. Внутри цеховой электротранспорт, должен быть исключён, так как это требует дополнительных затрат на обслуживание, ремонт, дополнительную численность работающих и влияет на безопасность окружающих. Транспортная тележка содержит четыре отделения: для крупных деталей; для средних деталей; для мелких деталей; для порожней тары.

Крупные детали, как на складе, так и на рабочем месте оператора должны перекладываться в ручную, они должны перекатываться с транспортировочной телеги на рабочее место, либо наоборот. Транспортировка деталей на рабочие места должна производиться таким образом, чтобы транспортировщик не заходил в рабочею зону оператора. Для этого необходимо на рабочих местах операторов указать все адреса деталей согласно планировке, с обратной стороны рабочего стола оператора.

Первый принцип системы «Канбан» - бирка «Канбан» должна находиться в таре с деталями или прикреплена к ним.

Второй принцип системы «Канбан» - два «Канбана» на рабочем месте, т.е. на одном рабочем месте допускается иметь две нормы деталей. Этот принцип распространяется только на мелкие и средние детали, транспортировка которых осуществляется в специальной таре - данный принцип устанавливает время на транспортировку деталей.

Третий принцип системы «Канбан» - отсутствие бракованных деталей на производственной линии (конвейере), так как если бракованные детали будут попадать на конвейер, будет отсутствовать стабильная работа транспортировщика и работа конвейера.

Четвертый принцип системы «Канбан» - формирование новой схемы складского хозяйства:

Склад должен быть один, максимально приближённый к конвейеру;

Склад формируется по принципу магазина самообслуживания - транспортировщик движется по складу и сам собирает в тележку необходимые детали и сборочных единиц;

Детали и КИ в нужном количестве должны быть подготовленные для транспортировщика работниками склада, одним из самых важных факторов является отсутствие пересчёта, либо скорый пересчёт (мерная, ячеистая тара). Передача ТМЦ от транспортировщика оператору, также должна осуществляться без пересчёта - на первый план выходит доверие людей друг другу.

Для рационального использования рабочего времени кладовщика, транспортировщика и т.д., необходимо применить - упростить систему документооборота (применить штрих-кодирование).

Wikimedia Foundation . 2010 .

Синонимы :

Книги

• Канбан и "точно вовремя" на Toyota. Менеджмент начинается на рабочем месте , . О писках совершенствования, восходящих к самурайской традиции, согласно которой воин никогда не перестает повышать свое мастерство и оттачивать свой меч. О системе канбан и "точно вовремя",…

Я собираюсь написать несколько статей про новую методологию гибкой разработки Канбан (Kanban Development) в целях подготовки к Scandinavian Agile Conference 2009 , где я буду делать один из докладов (кстати, заодно приглашаю всех на конференцию).
Сегодня публикую первую из статей.
Основная задача первой статьи - это как можно проще описать основы Канбан: что это такое, в чем отличие от других гибких методологий и зачем это нужно.
Также я хотел бы собрать как можно больше вопросов и сомнений в комментариях, чтобы ответить на них в следующих статьях, так что пишите всё, что вам непонятно, или что ещё вы хотели бы узнать про Канбан.
Я не то, чтобы большой специалист по этой новой методологии, но мы внутри команды пришли к Канбану самостоятельно и последовательно прошли все этапы мутации от SCRUM до Канбан, так что практический опыт есть.

Для начала напишу про происхождение термина Канбан .

Этот термин пришёл к нам из Японии благодаря широко известной в узких кругах производственной системе Тойота . Хотелось бы, чтобы как можно больше людей прочитало про эту систему и основные принципы, заложенные в неё - бережливое производство, постоянное развитие, ориентацию на клиента и т.п. Все эти принципы описаны в книге Тайити Оно Производственная система Тойоты , которая переведена на русский.

Термин Канбан имеет дословный перевод: “Кан” значит видимый, визуальный, и “бан” значит карточка или доска.
На заводах Тойота карточки Канбан используются повсеместно для того, чтобы не загромождать склады и рабочие места заранее созданными запчастями. Например, представьте, что вы ставите двери на Тойоты Короллы. У вас около рабочего места находится пачка из 10 дверей. Вы их ставите одну за другой на новые машины и, когда в пачке остается 5 дверей, то вы знаете, что пора заказать новые двери. Вы берете карточку Канбан, пишете на ней заказ на 10 дверей и относите ее тому, кто делает двери. Вы знаете, что он их сделает как раз к тому моменту, как у вас закончатся оставшиеся 5 дверей. И именно так и происходит - когда вы ставите последнюю дверь, прибывает пачка из 10 новых дверей. И так постоянно - вы заказываете новые двери только тогда, когда они вам нужны.
А теперь представьте, что такая система действует на всём заводе. Нигде нет складов, где запчасти лежат неделями и месяцами. Все работают только по запросу и производят именно столько запчастей, сколько запрошено. Если вдруг заказов стало больше или меньше - система сама легко подстраивается под изменения.

Основная задача карт Канбан в этой системе - это уменьшать количество «выполняющейся в данный момент работы» (work in progress).
Например, на всю производственную линию может быть выделено ровно 10 карточек для дверей. Это значит, что в каждый момент времени на линии не будет больше 10 готовых дверей. Когда заказывать новые двери и сколько - это задача для того, кто их устанавливает. Только он знает свои потребности, и только он может помещать заказы производителю дверей, но он всегда ограничен числом 10.
Этот метод Бережливого производства (Lean manufacturing) был придуман в Тойоте и сейчас многие производственные компании по всему миру его внедряют или уже внедрили.

Но это всё относится к производству, а не к разработке программного обеспечения.
А что же такое Канбан разработка применительно к ПО, и чем она отличается от других гибких методологий, буть то SCRUM или XP?

Во-первых, нужно сразу понять, что Канбан - это не конкретный процесс, а система ценностей. Как, впрочем, и SCRUM с XP. Это значит, что никто вам не скажет что и как делать по шагам.
Во-вторых, весь Канбан можно описать одной простой фразой - «Уменьшение выполняющейся в данный момент работы (work in progress)» .
В-третьих, Канбан - это даже еще более «гибкая» методология, чем SCRUM и XP. Это значит, что она не подойдет всем командам и для всех проектов. И это также значит, что команда должна быть еще более готовой к гибкой работе, чем даже команды, использующие SCRUM и XP.

Разница между Канбан и SCRUM:
- В Канбан нет таймбоксов ни на что (ни на задачи, ни на спринты)
- В Канбан задачи больше и их меньше
- В Канбан оценки сроков на задачу опциональные или вообще их нет
- В Канбан «скорость работы команды» отсутствует и считается только среднее время на полную реализацию задачи

А теперь посмотрите на этот список и задумайтесь - что остается от гибкой методологии, если мы удаляем спринты, увеличиваем размеры задач и перестаем мерять скорость работы команды? Ничего?
Как вообще можно говорить о контроле за разработкой, если мы убираем основные инструменты контроля - сроки, скорость работы и спринты? Для меня этот вопрос является чуть ли не самым важным.
менеджеры всегда думают о контроле и пытаются его получить, хотя на самом деле никогда его не имеют. Контроль разработки со стороны менеджера - это фикция. Если команда не хочет работать, то как ее не контролируй, она провалит проект.
Если команда получает фан от работы и работает с полной отдачей, то никакой контроль и не нужен, а только мешает, увеличивает издержки.
Например, общеизвестная проблема SCRUM - это большие издержки от обсуждений, встреч и большие потери времени на стыках спринтов (когда как минимум день уходит на закрытие одного спринта, а потом день на открытие нового. И если спринт - 2 недели, то 2 дня из 2 недель - это 20%, чертовски много). В итоге чуть ли не 30-40% времени при применении SCRUM тратится на поддержание самого процесса - на ежедневные митинги, на 5% workshop, на спринт ретроспектив и т.п. 30%!

Канбан разработка отличается от SCRUM в первую очередь ориентацией на задачи. Если в SCRUM основная ориентация команды - это успешное выполнение спринтов (надо признать, что это так), то в Канбан на первом месте задачи.
Спринтов никаких нет, команда работает над задачей с самого начала и до завершения. Деплоймент задачи делается тогда, когда она готова. Презентация выполненной работы - тоже. Команда не должна оценивать время на выполнение задачи, ибо это имеет мало смысла и почти всегда ошибочно вначале.
Если менеджер верит команде, то зачем иметь оценку времени? Задача менеджера - это создать приоритизированный пул задач, а задача команды - выполнить как можно больше задач из этого пула. Всё. Никакого контроля не нужно. Всё, что нужно от менеджера - это добавлять задачи в этот пул или менять им приоритет. Именно так он управляет проектом.

Команда для работы использует Канбан-доску. Например, она может выглядеть так (взял ):

Столбцы слева направо:

Цели проекта :
Необязательный, но полезный столбец. Сюда можно поместить высокоуровневые цели проекта, чтобы команда их видела и все про них знали. Например, «Увеличить скорость работы на 20%» или «Добавить поддержку Windows 7».

Очередь задач :
Тут хранятся задачи, которые готовы к тому, чтобы начать их выполнять. Всегда для выполнения берется верхняя, самая приоритетная задача и ее карточка перемещается в следующий столбец.

Проработка дизайна :
этот и остальные столбцы до «Закончено» могут меняться, т.к. именно команда решает, какие шаги проходит задача до состояния «Закончено».
Например, в этом столбце могут находиться задачи, для которых дизайн кода или интерфейса еще не ясен и обсуждается. Когда обсуждения закончены, задача передвигается в следующий столбец.

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

Тестирование :
В этом столбце задача находится, пока она тестируется. Если найдены ошибки - возвращается в Разработку. Если нет - передвигается дальше.

Деплоймент :
У всех проектов свой деплоймент. У кого-то это значит выложить новую версию продукта на сервер, а у кого-то - просто закомитить код в репозиторий.

Закончено :
Сюда стикер попадает только тогда, когда все работы по задаче закончены полностью.

В любой работе случаются срочные задачи. Запланированные или нет, но такие, которые надо сделать прямо сейчас. Для таких можно выделить специальное место (на картинке отмечено, как «Expedite»). В Expedite можно поместить одну срочную задачу и команда должна начать ее выполнять немедленно и завершить как можно быстрее. Но может быть только одна такая задача! Если появляется еще одна - она должна быть добавлена в «Очередь задач».

А теперь самое важное. Видите цифры под каждым столбцом? Это число задач, которые могут быть одновременно в этих столбцах. Цифры подбираются экспериментально, но считается, что они должны зависеть от числа разработчиков в команде.
Например, если вы имеете 8 программистов в команде, то в строку «Разработка» вы можете поместить цифру 4. Это значит, что одновременно программисты будут делать не более 4-х задач, а значит у них будет много причин для общения и обмена опытом. Если вы поставите туда цифру 2, то 8 программистов, занимающихся двумя задачами, могут заскучать или терять слишком много времени на обсуждениях. Если поставить 8, то каждый будет заниматься своей задачей и некоторые задачи будут задерживаться на доске надолго, а ведь главная задача Канбан - это уменьшение времени прохождения задачи от начала до стадии готовности.
Никто не даст точный ответ, какие должны быть эти лимиты, но попробуйте для начала разделить число разработчиков на 2 и посмотреть, как это работает в вашей команде. Потом эти числа можно подогнать под вашу команду.
Под «разработчиками» я понимаю не только программистов, но и других специалистов. Например, для столбца «Тестирование» разработчики - это тестеры, т.к. тестирование - это их обязаность.

Задачи на такой доске - это не просто задачи, а то, что называется Минимальной Маркетинговой Фичей, то есть фича, которую можно «продать» клиентам.
Хорошая проверка для ММФ - это вопрос себе «А стал бы я писать про эту фичу в блоге компании?». Если нет - это не ММФ.

Что нового и полезного дает такая доска с лимитами?

Во-первых, уменьшение числа параллельно выполняемых задач сильно уменьшает время выполнения каждой отдельной задачи. Нет нужды переключать контекст между задачами, отслеживать разные сущности, планировать их и т.д. - делается только то, что нужно. Нет нужды устраивать спринт планнинги и 5% воркшопы, т.к. планирование уже сделано в столбце «очередь задач», а детальная проработка задачи начинается ТОЛЬКО тогда, когда задача начинает выполняться.

Во-вторых, сразу видны затыки. Например, если тестеры не справляются с тестированием, то они очень скоро заполнят весь свой столбец и программисты, закончившие новую задачу, уже не смогут переместить ее в столбец тестирования, т.к. он заполнен. Что делать? Тут время вспомнить, что «мы - команда» и решить эту проблему. Например, программисты могут помочь тестерам завершить одну из задач тестирования и только тогда передвинуть новую задачу на освободившееся место. Это позволит выполнить обе задачи быстрее.

В-третьих, можно вычислить время на выполнение усредненной задачи. Мы можем помечать на карточке дату, когда она попала в очередь задач, потом дату, когда ее взяли в работу и дату, когда ее завершили. По этим трем точкам для хотя бы 10 задач можно уже посчитать среднее время ожидания в очередь задач и среднее время выполнения задачи. А из этих цифр менеджер или product owner может уже рассчитывать всё, что ему угодно.

Весь Канбан можно описать всего тремя основными правилами:
1. Визуализируйте производство
- Разделите работу на задачи, каждую задачу напишите на карточке и поместите на стену или доску.
- Используйте названные столбцы, чтобы показать положение задачи в производстве.
2. Ограничивайте WIP (work in progress или работу, выполняемую одновременно) на каждом этапе производства.
3. Измеряйте время цикла (среднее время на выполнение одной задачи) и оптимизируйте постоянно процесс , чтобы уменьшить это время.

Всего 3 правила!
Например, в SCRUM - 9 базовых правил. В XP - 13, а в классическом RUP - аж более 120. Почувствуйте разницу.

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

Чтобы использовать их в работе, придумали правила.

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

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

Кому подходит Канбан

Канбан не имеет ограничений. С его помощью молодожёны планируют семейный бюджет , небольшие подразделения в Microsoft разрабатывают новые программы, а Toyota управляет всеми производствами.

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

Как использовать, чтобы быть аджайл

В Канбане всего шесть правил, они вводятся постепенно. Новые не добавляются, пока предыдущие изменения не стали привычными для большинства сотрудников.

На первых порах Канбан предлагает щадить старую структуру и иерархию, поэтому изменения будут эволюционными. Всё, что нужно, - твёрдое желание начать и поощрение инициативы в компании.

Правило 1. Визуализируйте поток задач

Канбан опирается на визуализацию. Все задачи записываются на видном месте, чтобы в любой момент знать, как обстоят дела.

Визуализация бывает разной: доска со стикерами, стол с карточками, таблица в Excel или программы типа Trello и Jira. Правильной или неправильной визуализации нет - хорошо то, что подходит именно вам:

Новичкам мы рекомендуем использовать доску или стену со стикерами. Физическая доска удобнее программ, потому что всегда перед глазами. Не нужно включать компьютер, открывать браузер и заходить на сайт, чтобы узнать, как идёт работа. Команда сразу видит актуальную картину.

Ещё физическая доска эмоционально тёплая. Только представьте, что вы сделали задачу, подошли к доске и перенесли карточку в другую колонку. Вы - молодец, и все это знают. В Trello и Jira такого не будет, карточка просто появится в другой колонке.

Запишите все задачи. Чтобы создать визуализацию, нужно записать все задачи, которые вы делаете сейчас и собираетесь сделать в ближайшие дни. После этого станет понятно, сколько у вас реальной работы, а сколько в планах.

Определите статусы задач. Статусы задач - это колонки на доске. Колонки можно использовать разные, конкретных правил нет. Для начала мы предлагаем три: «Сделать», «В работе» и «Готово». Потом их можно разбить на более мелкие, если нужно, или придумать новые статусы.

Важно: все задачи должны быть на доске. Нельзя работать над тем, чего нет в визуализации.

Правило 2. Ограничивайте количество одновременной работы

После создания визуализации вы будете удивлены, как много работы параллельно выполняет Команда. Это одна из причин, почему проекты растягиваются: силы тратятся не на задачи, а на переключение между ними.

Канбан предлагает ограничить количество одновременной работы. Так вы повысите свою эффективность и ускорите продвижение карточек от статуса «Сделать» до статуса «Готово». Рекомендуем зафиксировать количество текущих задач и взять это число за начальное ограничение. Дальше лимит нужно постепенно уменьшать:

Зафиксируйте лимит. Договоритесь с коллегами, сколько задач из каждой колонки сможете делать одновременно. Запишите эти ограничения цифрами над колонками или ограничьте место на доске, чтобы новые карточки не могли на неё поместиться.

Приоритизируйте задачи. После ограничения количества одновременной работы в колонке «Сделать» окажется много карточек. Чтобы их упорядочить, нужна приоритизация. Можно пометить карточки цветом, расположить в определённом порядке или составить рейтинг с баллами. Главное, чтобы все однозначно понимали, какие задачи нужно сделать сейчас, а какие можно отложить на пару дней.

Важно: заканчивайте начатые дела, а не беритесь за несколько новых параллельно.

Правило 3. Контролируйте поток задач

Визуализация помогает следить за скоростью продвижения карточек и равномерной загрузкой сотрудников. Если что-то не так, на доске это сразу видно:

Когда появляется пробка, действует принцип: один за всех, и все за одного. Сотрудники, которые остались без дела, не отсиживаются в уголке, а помогают разбирать завал. Например, дизайнеры подключаются к тестированию или составлению документов, когда нет своей работы.

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

Контролируйте загрузку. Работа должна быть ритмичной. Если вы почувствовали спад, сходите к доске. Возможно, у коллег завал, и нужна ваша помощь.

Сами просите о помощи. Если пробка образовалась на вашем участке, молчать не нужно. От вашей работы зависит общий успех, поэтому коллеги обязательно помогут. Посмотрите на доске, кто меньше всех загружен, и попросите его о помощи.

Важно: доска покажет, как идёт работа. Помогите Команде закончить её как можно быстрее.

Правило 4. Сделайте договорённости и ожидания явными

Правила, по которым работает Команда, должны быть известны каждому и при этом регулярно меняться . Мы рекомендуем повесить самые важные правила у доски или внутри колонок. Вот как это выглядит:

Запишите правила работы с доской. Договоритесь с коллегами и запишите, при каких условиях можно брать новую задачу, как переносить её в другую колонку и когда считать готовой. Сделайте правила продвижения карточек очевидными.

Повесьте правила на видное место. Чтобы подключаться к коллегам было проще, повесьте правила у доски или внутри колонок.

Важно: договорённости помогают Команде работать слаженно. Сделайте их явными.

Правило 5. Анализируйте работу

Регулярные планёрки и анализ - обязательное требование Канбана. Они нужны, чтобы быть уверенным: Команда движется в правильном направлении и не выбивается из сроков и бюджетов.

Ограничений по формату нет. Это могут быть встречи, созвоны или просто анкеты. Аджайл отдаёт предпочтение живому общению, поэтому мы рекомендуем собираться у доски. Планёрки - каждый день и каждую неделю, анализ - раз в месяц. Что представляют собой эти встречи:

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

На еженедельных планёрках вся Команда встречается с руководством. Вместе они обсуждают скорость работы и снижение рисков.

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

Важно: будьте инициативны, общайтесь с коллегами и предлагайте идеи.

Правило 6. Эволюционируйте благодаря совместным экспериментам

Канбан-команда всегда находится в поиске идеальной системы, где карточки двигаются по доске максимально быстро.

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

Предлагайте улучшения. Если Команда не сможет доказать, что это плохо скажется на результате работы, проводится эксперимент.

Пробуйте одно изменение за раз. Чтобы точно знать, какой эффект дало нововведение, не проводите несколько экспериментов сразу. Лучше пробовать одну идею за другой, и оставлять в работе самые удачные.

Важно: эксперименты помогают Команде развиваться, не бойтесь пробовать новое.

Как не забыть о правильном образе мышления

Мы разобрали все шесть правил Канбана. Они не дают конкретных указаний, а только направляют Команду. Мы рекомендуем проверять себя:

Каждый сотрудник инициативен и заботится об общем успехе;

Он помогает, если у коллег завал;

Сотрудники регулярно проводят эксперименты, чтобы улучшить процесс работы;

Команды обсуждают финансы компании и свой вклад в её показатели;

В компании происходят эволюционные изменения.

О том, что такое канбан и почему это не просто доски со стикерами, рассказывает Дэвид Андерсон, автор книги , которая вышла на русском языке в издательстве «МИФ».

Андерсон был первым, кто использовал канбан в разработке ПО (2005 год), он внедрял гибкие методы управления в таких компаниях, как Motorola и Microsoft, а также основал Lean Kanban University и David J Anderson School of Management.

Что такое канбан-метод?

Весной 2005 года мне посчастливилось провести отпуск в , в Токио. Дело было в начале апреля, когда цветут вишни. Чтобы насладиться этим зрелищем, я во второй раз в жизни приехал в Восточные сады в Императорском дворце в Токио. Именно здесь меня осенило: канбан - это не только производство .

В субботу, 9 апреля 2005 года, я вошел в парк с северного входа, перейдя мост через ров неподалеку от станции метро «Такэбаси». Многие токийцы решили этим солнечным воскресным утром выбраться в парк и насладиться его спокойствием и цветением японской вишни - сакуры.

Обычай устраивать пикник под вишневыми деревьями, когда опадают их цветы, называется «ханами» (цветочный праздник). Это древняя японская традиция - возможность подумать о красоте, хрупкости и кратковременности жизни.

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

Проведя утро на солнышке, мы направились на выход, где стояла очередь к киоску. Когда она немного продвинулась вперед, я понял, что это люди возвращают пластиковые карточки, которые были входными билетами. Я залез в карман и вынул наши карточки. В киоске находилась японка в униформе. Между нами была стеклянная перегородка с полукруглым вырезом у стойки, как в кассе кинотеатра или парка развлечений. Я передал наши карточки. Дама взяла их руками в белых перчатках и положила в стопку к другим. Никаких денег не требовалось. Никакого объяснения, зачем я два часа с момента входа в парк носил с собой белые пластиковые карточки, дано не было.

Что же это за входные билеты? Зачем их выдавать, если они бесплатные? Сначала я предположил, что это связано с безопасностью. Подсчитав все возвращенные карточки, администрация могла убедиться, что внутри не осталось никого постороннего после закрытия парка на ночь. Однако затем я понял, что если речь идет о безопасности, то это какая-то очень сомнительная схема. Как они могут знать, что мне дали не одну карточку, а две? Моя трехмесячная дочь - это посетитель или багаж? Система казалась слишком вариативной. Чересчур много возможностей для ошибки! Если бы это действительно была схема безопасности, то она была обречена на провал и ежедневно давала бы ошибки первого рода.

(Кстати, отмечу, что подобная система не может выдавать ошибки второго рода, поскольку это потребовало бы печати дополнительных входных билетов. Это общее полезное свойство систем канбан.)

Тем временем охрана ежевечерне рыскала бы по парку в поисках заблудившихся туристов. Нет, дело в чем-то другом.

Я понял, что в садах Императорского дворца реализуется канбан-система! Это озарение позволило мне понять, что канбан-системы полезны не только в производстве.

Похоже, канбан-жетоны разного вида помогают во всех типах управленческих ситуаций.

Что такое канбан‐система?

Некоторое количество канбан-жетонов (в нашем случае - карточек), равное (оговоренной) емкости системы, запускается в обращение. Одна карточка соответствует одному элементу работы. Каждая карточка - это сигнальный механизм. Новый элемент работы может начаться, только если для него доступна карточка. Эта доступная карточка прикрепляется к элементу работы на время его прохода через всю систему. Когда карточек больше не остается, новую работу начинать нельзя. Любая новая работа должна оставаться в очереди, пока карточка не освободится. Когда какое-то количество работы окончено, карточка освобождается и снова запускается в обращение. Теперь можно начинать работу над новым элементом в очереди.

Этот механизм известен как вытягивающая система, поскольку новая работа втягивается системой, когда она обладает достаточной емкостью для этого, а не вталкивается в нее по требованию. Вытягивающая система не может оказаться перегруженной, если емкость, определяемая количеством находящихся в обращении карточек, определена верно.

В садах Императорского дворца система - сами сады, посетители - это неоконченная работа, а емкость определяется количеством находящихся в обращении карточек. Вновь прибывающие посетители получают доступ, только если в наличии есть билеты для них.

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

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

Применение канбана в разработке ПО

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

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

Простое ограничение незавершенных задач посредством канбана приводит к повышению качества работы и ее производительности. Сочетание оптимизации потока работ и повышения качества помогает сократить время выполнения работ и повышает предсказуемость и вероятность выполнения задачи в срок.

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

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

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

10 тезисов о Канбане

Канбан-системы могут быть использованы в любой ситуации через ограничение наличия элементов работы внутри системы.

1. Сады Императорского дворца в Токио используют канбан-систему, чтобы контролировать число посетителей в парке.
2. Количество сигнальных карточек «канбан», находящихся в обращении, ограничивает объем незавершенных задач.
3. Новая работа втягивается в процесс после возвращения в оборот сигнальной карточки, когда предыдущее задание выполнено.
4. В IT-сфере мы, как правило, используем виртуальную канбан-систему, поскольку для ограничения количества незавершенных задач не передаются какие-либо физически существующие карточки.

Доски со стикерами, часто встречающиеся в гибкой разработке ПО, не являются канбан-системами.

Канбан использует инструменты разных областей знаний для анализа проблем и поиска решений.

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

Современное определение Канбан-метода можно найти в сети на сайте Общества ограничения незавершенных задач (Limited WIP Society).

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

Канбан (kanban, система канбан) — этометод управления бережливыми производственными линиями (японское слово, обозначающее «сигнал» или «карточка»), использующий информационные карточки для передачи заказа на изготовление с последующего процесса на предыдущий.

Инструмент вытягивающей системы, который дает указание на производство или изъятие (передачу) изделий с одного процесса на другой. Применяется в Производственной Системе Toyota для организации вытягивания путем информирования предыдущей производственной стадии о том, что надо начинать работу. Система канбан позволяет оптимизировать цепочку планирования производственных мощностей, начиная от прогноза спроса, планирования производственных заданий и балансировки/распределения этих заданий по производственным мощностям с оптимизацией их загрузки.

Является составной частью этой системы производства «точно-во-время» (Just-in-Time-Production, JIT) , которая предполагает синхронную поставку необходимого в производстве материала: поступление непосредственно в производство на рабочее место к необходимому времени, в необходимом количестве, с предписанным качеством и в соответствующей потреблению упаковке. В качестве средства передачи информации используются бирки, карточки, тара, электронное сообщение карточки (по-японски «канбан»), которые перемещаются между потребителями и производителями по принципу супермаркета (см.схему 1).

Схема 1. Управление производством с помощью канбан по принципу супермаркета

Цель метода - это реализация производства «точно-во-время» (JIT) на всех производственных линиях, чтобы обеспечивать снижение размеров материальных запасов на складах и несмотря на это гарантировать высокую степень выполнения заказов в установленные сроки.

Предпосылкой упрощения коммуникации является однозначное обозначение информации на определенном носителе, в чем нуждаются и в каком количестве потребители. Если материал израсходован (или, например, запас достиг минимального уровня), только тогда, поставщик просит доставить новый материал. Этот запрос выдается через карточку канбан, которая обязательно транспортируется с каждой поставкой материала и возвращается в начало для новой поставки. Если карточку получает производитель, он начинает изготавливать необходимые детали. Когда запрошенное количество деталей произведено, кaнбан-карточка прикрепляется к держателю транспортирующего оборудования и отправляется по определенным правилам на исходное место (см.схему 2). Кстати, если вас интересует именно российский опыт внедрения и использования системы канбан, его можно найти в Альманахе «Управление производством» .

Схема 2. Транспортировка карточки канбан вместе с выполненным заказом.

Пример карточки представлен на схеме 3.

Схема 3. Пример карточки с применяемыми обозначениями.

Правила эффективного применения системы канбан

Президентом корпорацию Toyota Motor Corporation Тайити Oно предложены следующие правила эффективного применения карточек канбан:

• Каждый последующий рабочий процесс изымает указанное карточкой канбан количество деталей от предшествующего рабочего процесса.
• Расположенный впереди рабочий процесс производит детали в количестве и последовательности в соответствии с указанной карточкой.
• Ни одна деталь не должна быть произведена без карточки. Этим самым обеспечивается сокращение перепроизводства и избыточные перемещения товаров. Находящееся в обороте количество карточек канбан представляет собой объем максимальных запасов.
• Товар всегда пристраивается к карточке. Карточка является своеобразным заказом на изготовление товара.
• Дефектные детали не передаются дальше в последующий рабочий процесс. Результатом является изготовление полностью бездефектных изделий.
• Уменьшение количества карточек повышает их чувствительность. Они вскрывают существующие проблемы и делают возможным контроль запасов.

При применении карточек канбан должна быть гарантирована обзорность и безопасность системы. Карточки не должны теряться, и не должны смешиваться. Так как часто на рабочем месте применяются несколько различных карточек, имеет смысл внедрения доски канбан, на которой собираются карточки. Карточки, прибывающие к производителю, вставляются в управляющую доску. Когда вновь прибывшие карточки канбан дошли до поля «запуск», все собранные карточки соответствующего номера детали принимаются совместно используются для производства (см.схему 4).

Схема 4. Пример карточки с применяемыми обозначениями.

Больше аналитических и практических материалов на эту тему можно найти в разделе Канбан библиотеки портала.