Вы находитесь на странице: 1из 4

ТЕМА 9.

ГИБКИЕ МЕТОДОЛОГИИ УПРАВЛЕНИЯ


ПРОЕКТАМИ

9.6. Методология Канбан

Здравствуйте, слушатели курса «Гибкие методологии разработки управления проектами». В


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

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

Позднее, на базе концепции «Тойоты» и методов бережливого производства, появляется Канбан


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

В Канбан всего три простых базовых принципа, на которых строится все остальное:

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

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

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

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

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

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

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

• Глобальные цели
Столбец стоит в самом начале, благодаря ему команда видит, каким должен стать
продукт за этот год, полгода или несколько месяцев. Например, повышение
производительности на 30%.

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

• Колонки с этапами работы над задачей


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

• Выполненные задачи
Перед ним полезно ставить колонку «Тест» или «Проверка». Причем не только для
разработчиков ПО, но и в других сферах, чтобы перед завершением убедиться в качестве
выполнения.

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

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

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

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

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

Канбан часто сравнивают со Scrum и причисляют к Agile-методикам. Методику можно назвать


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

Отличия Kanban от Scrum:


• Отсутствие спринтов
• Отсутствие ролей
• Пользовательские истории не обязательны
• Рабочий процесс практически не управляется и мало регламентируется
• Лучше внедрять в хорошо мотивированную команду
• Набор принципов

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

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

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


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

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

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

Kanban сейчас применяется многими IT-стартапами, а также частично реализуется в ряде крупных
компаний, таких как Microsoft. Множество новых маркетинговых и IT-компаний используют
элементы методологии — Kanban-доску.

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

Какими же инструментами необходимо воспользоваться для внедрения Канбан методологии?

Здесь есть два варианта:

1. Облачные решения
С точки зрения разработки программного обеспечения моя рекомендация к
использованию — это облачный сервис Trello. Для отдела продаж мы используем Amo
CRM, но что в случае с разработкой ПО, что в случае с продажами я могу вам только
посоветовать. Фактически существует множество разнообразных сервисов, которыми
можно воспользоваться — это всего лишь вопрос ваших предпочтений.

2. Доска со стикерами.

На этом мы заканчиваем разбор методологии Канбан.