Методология Kanban

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

История

Канбан впервые появилась в Японии. Там это слово переводится как «рекламный щит» или «рекламная вывеска» («кан» — видимый, визуальный, «бан» — карточка). Сам термин на японском читается «камбан», но на Западе почему-то стал записываться и произноситься с согласной «н».

Эту методику изобрела в 1959-м году и начала использовать в 1962-м компания Toyota для производства автомобилей. Создатели были заинтересованы снизить затраты на производстве, сократить время на сборку машин и быстро выявлять простои и дефекты. У них это во многом получилось

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

Принципы Kanban

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

Временные рамки

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

Бережливое производство и уменьшение количества задач

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

Продукт таким образом собирается как бы по конвейеру. Однако элементы этого конвейера работают, когда необходимо, избавляя себя от лишнего и ненужного труда: задача выполняется не заранее, а когда появляется. Это очень легко проиллюстрировать на примере «Тойоты»: можно произвести 15 левых и пять правых дверей для машины, в итоге десять дверей останутся лишними и будут пылиться на складе. Такого не произойдёт, если делать двери по запросу сборщика автомобиля.

Визуализация

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

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

• Глобальные цели. Столбец стоит в самом начале, благодаря нему команда видит, каким должен стать продукт за этот год, полгода или несколько месяцев. Например, повышение производительности на 30%.
• Задачи в очереди. Здесь располагаются те задачи, которые можно начать выполнять.  Чем выше в столбце задача, тем выше её приоритет, начинать нужно с самой верхней.
• Колонки с этапами работы над задачей. Задача перемещается по ним, пока не дойдёт до завершающего столбца. Их количество зависит от типа работы, иногда можно обойтись и одной–двумя. Стикер переходит как вперёд, если очередной этап выполнен успешно, так и назад, если были обнаружены дефекты на предыдущей стадии.
• Последний столбец содержит стикеры с выполненными задачами. Перед ним полезно ставить колонку «Тест» или «Проверка». Причём не только для разработчиков ПО, но и в других сферах, чтобы перед завершением убедиться в качестве выполнения.
• На Канбан-доске будет нелишним выделить область для срочных задач. Им будет сразу же выделяться приоритет у всей команды. При этом не может быть более одной неотложной задачи одновременно — тогда остальные тоже стоят в очереди.
• Максимальное количество задач. Это цифра, которая ставится под каждой колонкой кроме «Целей» и «Выполнено». Исходя из численности команды, определяется, над сколькими задачами они могут трудиться одновременно. Нельзя перенести стикер в следующий столбец, если под ним стоит цифра «3», а их там уже три. Так, если члены команды обнаруживают, что рабочий процесс встал, они приходят на помощь своим товарищам, чтобы те быстрее отправили задачу на следующий этап.
• Цвета карточек. Цвет каждого стикера тоже может нести дополнтельную информацию. Например, степень важности или срочности или необходимость пропустить несколько этапов, попав лишь в один–два определённых.

Другой инструмент визуализации — карточки Канбан. Их впервые начали использовать на заводах Toyota.

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

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

Преимущества и недостатки Kanban в сравнении со Scrum

Канбан часто сравнивают со Scrum и причисляют к Agile-методологиям. Методику можно назвать гибкой, если говорить о разработке ПО, но сама по себе Канбан лишь частично соблюдает принципы гибких методологий. Если сравнивать со «Скрамом»: в Kanban отсутствуют спринты, роли, пользовательские истории необязательны. При этом методологию часто считают более «гибкой», так как рабочий процесс практически не управляется, мало регламентируется, и результат на 90% зависит от команды и сообщения внутри неё, а не от менеджера.

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

Следует понимать, что Канбан — скорее не методология, а набор принципов. Одни считают, что легче начинать с более жёсткого Scrum, постепенно переходя к Kanban, другие же делают наоборот или сразу вводят эту методику.

Применение

В отличие от того же Scrum Kanban можно ввести на любых типах производства и в коллективах с любой численностью. Пример тому концерны «Тойота», с которых методология и берёт своё начало. Ограничение составляет не сфера или количество сотрудников, а готовность как руководства, так и персонала перейти на новый методы работы над проектами. Для этого может потребоваться не один год, в течение которого производительность наверняка снизится.

Kanban сейчас применяется многими IT-стартапами, а также частично реализуется в ряде крупных компаний, таких как Microsoft. Методика приживается в России в ряде «околоавтомобильных» производств: «Ярославский шинный завод», на предприятии «Аком» для производства комплектующих аккумуляторов. Множество новых маркетинговых и IT компаний используют элементы методологии — Kanban-доску.

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

Книги о Канбан

Лучше понять суть методологии и научиться внедрять её в работу коллектива или свой бизнес поможет литература по Канбан.

1. «Производственная система Тойоты», Тайити Оно. История о том, как методологию начали применять в Toyota. Эти практики дали старт распространению Канбан в том виде, в котором она сейчас.
2. «10 канбан досок и их контекст», Маттиас Скарин. Статья с подборкой примеров Kanban-досок в разных сферах: разработка ПО, продажи, маркетинг.  Этот же автор написал полезную книгу «Scrum и Kanban: выжимаем максимум» о переходе от одной Agile-методологии к другой.
3. «Канбан. Альтернативный путь в Agile», Дэвид Андерсон. Автор впервые применил Kanban в разработке ПО и рассказывает о том, как эффективно внедрять методологию в IT-сфере.

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