Система канбан

Каждой задаче соответствует своя карточка. В данном случае доска была разделена на четыре части:

  • ToDo содержит задачи, полученные от заказчика. Каждая задача отмечена цветом, который соответствует степени ее важности.
  • После того, как поступившие от заказчика задачи были проанализированы и был запланирован срок их реализации, они перемещаются в область Estimated.
  • Когда разработчик начинает работу над определенной задачей, он перемещает ее в область In Progress. На этом шагу разработчик отмечает задачу персональной меткой, которая дает понять, кто именно ответственен за реализацию конкретной задачи.
  • После того, как задача решена, она перемещается в область Done.

На этом шаге также реализуется принцип минимизации WIP. Для каждого этапа, из которых состоит процесс разработки, устанавливается максимально возможное количество задач, над которыми ведется работа. Следовательно, можно установить максимальное количество карточек, которое одновременно может находиться на доске в той или иной области. Снижение количества задач, над которыми ведется работа, позволяет уменьшить количество времени, необходимое для завершения каждой из них и повышает качество выполненной работы за счет того, что команда может сфокусироваться на ограниченном объеме задач. Это также позволяет снизить количество ошибок и минимизировать время, необходимое для их исправления.

Kanban относится к разряду так называемых Pull (от англ. “pull” — тянуть) систем. На практике это означает, что член команды разработчиков “перетаскивает” задачу из предыдущего этапа, давая понять разработчикам, ответственным за предыдущий этап, что они могут начать работу над следующей задачей. Такой подход также снижает WIP, в отличие от Push (от англ. “push” – толкать) систем, в которых на каждом этапе выполняется максимально возможный объем работы, который передается на следующий этап независимо от того, какой объем работы в данный момент выполняется.

3. Поиск слабых мест

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

4. Оптимизация процесса разработки

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

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

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

Одной из первых попыток практического внедрения концепции «точно и срок» появилась разработанная корпорацией Toyota Motor — микрологистическая система KANBAN (что в переводе с японского означает «карта».

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

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

Первоначальные попытки американских и европейских конкурентов автоматически перенести схему KANBAN в производство без учета этих и других факторов логистического окружения потерпели неудачу. Данная концепция, впервые примененная корпорацией Toyota Motor в 1972 г. на заводе «Такахама» (г. Нагоя, Япония), представляет собой систему организации непрерывного производственного потока, способного к быстрой перестройке и практически не требующего страховых запасов.

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

Средством передачи информации в системе является специальная карточка «kanban» в пластиковом конверте. Распространены два вида карточек: отбора и производственного заказа. В карточке отбора указывается количество деталей (компонентов, полуфабрикатов), которая должна быть взята на предшествующем участке обработки (сборки), в то время как в карточке производственного заказа — количество деталей, должна быть изготовлена (собранная) на предыдущий производственном участке. Эти карточки циркулируют как внутри предприятий фирмы Toyotа, так и между корпорацией и компаниями, сотрудничающими с ней, а также на предприятиях филиалов. Таким образом, карточки «kanbаn» несут информацию о расходах и производство продукции, что позволяет реализовать концепцию «точно в срок».

Практическое использование системы KANBAN, а затем и ее модифицированных версий, позволяет значительно улучшить качество выпускаемой продукции; сократить логистический цикл, существенно повысить тем самым оборачиваемость оборотного капитала фирм; снизить себестоимость производства, практически исключить страховые запасы и значительно уменьшить объем незавершенного производства. Анализ мирового опыта применения микрологистической системы KANBAN многими известными машиностроительными фирмами показывает, что она дает возможность уменьшить производственные запасы на 50%, товарные — на 8% при значительном ускорении оборачиваемости оборотных средств и повышении качества готовой продукции.

Методология 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 и начала её внедрения.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *