Система Kanban (яп. «камбан» — «рекламный щит», «табличка», вывеска») — это система организации производства и снабжения, обеспечивающая реализацию принципа «точно в срок» (just-in-time, JIT).
В ИT-сфере это метод управления разработкой, позволяющий равномерно распределить нагрузку между членами команды и обеспечить прозрачность процессов.
В организации рабочих процессов используется Канбан-доска, на которой размещены столбики с указанием статуса:
- «Сделать/Входящие»;
- «В работе»;
- «Выполнено»;
- «На тестировании» и так далее.
В колонках размещают стикеры с заданиями. Благодаря визуализации задачу любой сложности можно «разложить на этапы» и равномерно распределить нагрузку между сотрудниками.
История канбана началась в Японии на производстве Toyota. В 1952 году 10 рабочих месяц собирали один грузовик. Сегодня промышленное предприятие выпускает в месяц 200 000 автомобилей, а каждый рабочий «собирает» по 5. Во многом этих показателей удалось добиться за счет оптимизации производственных процессов и использования методологии с наглядной визуализацией.
С 1959 года на предприятии начали тестировать новую систему организации работы. Мастера участков перечисляли задачи на бумаге и вывешивали на общей доске рядом со списками от других специалистов. В 1962 г. Toyota запустила процесс перевода всего производства на новую методику.
Виртуальные карточки и канбан-доски сегодня внедрены во многих таск-трекерах и сервисах-планировщиках. В России команды разработчиков часто ищут альтернативы зарубежным Jira, Confluence, Jira Service Management. Например, можно перейти на отечественное ПО Kaiten, «Пространства», «Планиро» (Planiro), Eva (EvaTeam) или взять трекер от GitVerse.
Как работает Kanban
Канбан-система позволяет разделить задачу на части и визуализировать каждый рабочий процесс: в каком статусе и у какого исполнителя он находится.
Основные элементы методологии:
- Канбан-доска. Пространство, на котором визуализируется рабочий процесс. Доски могут быть виртуальными (цифровыми) или физическими (ватман, магнитные или маркерные). Доску делят на колонки с указанием стадии работы.
- Колонки — этапы рабочего процесса. Как правило, в канбан-доске не больше пяти визуализированных этапов: «Входящие», «В работе», «На проверке», «Готово». Могут добавлять дополнительные: «На тестировании», «На приемке у заказчика».
- Канбан-карточки (стикеры), на которых размещают подзадачи. Когда статус изменяется (например, переход из «Входящие» во «В работе»), стикер перемещают. Метод называется drag-and-drop — «перетаскивание».
- WIP (Work In Progress) лимиты. Чтобы работа была комфортной, статусы задач должны распределяться равномерно. Лучше не допускать ситуации, когда во «Входящие» и на «Проверке» по одной подзадаче, а «В работе» более 20.
Канбан можно использовать и в быту. Самый простой вариант — отслеживать, какие книги прочитаны. В этом случае board может выглядеть так:
| Нужно прочитать | Читаю | Прочитано |
| Томас Х. Кормен, Чарльз И. Лейзерсон. «Алгоритмы. Построение и анализ» | Роберт К. Мартин. «Чистый код. Создание, анализ и рефакторинг» | Роберт К. Мартин. «Идеальный программист. Как стать профессионалом разработки ПО» |
| Абельсон Харольд, Сассман Джеральд Джей. «Структура и интерпретация компьютерных программ», | Джон Влиссидес, Эрих Гамма, Ричард Хелм. «Приемы объектно-ориентированного проектирования. Паттерны проектирования» | |
| Мартин Фаулер. «Рефакторинг. Улучшение существующего кода» |
Пользователь ставит цель «Нужно прочитать» и заносит в подзадачи определенные книги. Когда он начинает изучать пособие, подзадача переходит в статус «Читаю», а когда закрывает последнюю страницу — в «Прочитано».
В командной работе над ИT-проектами задач и исполнителей больше. Но общие принципы отслеживания статуса и визуализации остаются прежними.
Например, нам нужно создать лендинг для AI-ассистента разработчика GigaCode на проекте GitVerse. Для этого необходимо:
- разработать прототип посадочной страницы (отдел маркетинга);
- найти примеры кода и работы GigaCode (маркетологи, менеджер по продукту, разработчики);
- создать дизайн лендинга (дизайнер, маркетолог);
- заверстать сайт и подключить логику (frontend-разработчики);
- протестировать корректность отображения, наличие ошибок (тестировщики, маркетологи, менеджер по продукту);
- разместить страницу на сайте;
- создать объявления для запуска рекламной кампании (контекстной, таргетированной);
- запустить РК.
Пример условный: в рамках каждой задачи могут быть разные подзадачи. Но цель в том, чтобы показать работу с канбаном на конкретном проекте. Board может выглядеть таким образом:
| Поставлено | В работе | На проверке | Завершено |
| Протестировать корректность отображения, наличие ошибок | Заверстать сайт и подключить логику | Создать дизайн лендинга | Разработать прототип посадочной страницы |
| Разместить страницу на сайте | Найти примеры кода и работы GigaCode | ||
| Запустить РК | Создать объявления для запуска рекламной кампании (контекстной, таргетированной) |
В нашем кейсе маркетологи подготовили макет и материалы для страницы. Дизайнер создал страницу, и задание на верстку находится в работе. Канбан-система позволяет увидеть не только статус, но и возможные «блокировки».
Например, frontend-разработчик может быть «заблокирован», если дизайнер не сдал макет: нет прототипа страницы — значит, и верстать нечего.
Что такое Kanban-доски
Канбан-доска (desk) — это общее пространство, на котором размещаются задания и их статусы.
Доска может быть:
- виртуальной (цифровой) — таск-трекеры и планировщики онлайн;
- физической — маркерной, магнитной, бумажной.
Канбан-доска содержит колонки с указанием статуса. Количество колонок и надписи могут изменяться в зависимости от конкретной команды.
Как правило, есть три столбца:
- поставленные задания (to do);
- задания в процессе / в работе (doing);
- выполненные / завершенные (done).
Доску легко адаптировать под конкретный проект, поэтому могут появиться колонки:
- testing, QA (тестирование) — на тестировании;
- review (согласование) — на согласовании;
- stopped — приостановка;
- backlog (бэклог) — общий список и так далее.
За передвижение тасков по доске отвечает каждый член команды. При внедрении метода важно объяснить сотрудникам, что вклад в прозрачность и эффективность процессов вносит каждый.
Анализировать работу команды помогают метрики. Среди них:
- контрольный график (Control chart, CC) — скорость выполнения задач на определенный период, максимальные и минимальные отклонения от средних значений;
- спектральная диаграмма (Spectral chart, Lead Time Distribution Chart, LTDC) — средняя скорость работы над карточкой;
- время разрешения блокировок (Block resolution time) — сколько времени исполнитель не мог приступить к таске из-за того, что она была заблокирована;
- пропускная способность (Throughput) — сколько задач команда может закрыть за день/неделю/месяц/квартал/полугодие или иной период;
- время цикла (Cycle time) — сколько времени уходит на задачу с момента ее постановки до завершения.
Эти и другие метрики позволяют отслеживать эффективность команды и планировать сроки реализации будущих проектов.
Что такое каденции
Допустим, команда работает над созданием посадочной страницы для AI-ассистента разработчика GigaCode. Необходимо подключить сотрудников, объяснить цели/сроки/условия, проверить статус заданий, уточнить наличие блокировок и так далее.
Для этого используются каденции — регулярные встречи для обсуждения работы. Мероприятия могут проводиться:
- онлайн — с помощью сервисов видеоконференций вроде SberJazz (Jazz by Sber) или иных;
- офлайн — в офисе компании.
Термин «каденция» происходит от итальянского «cadenza» и означает «темп», «ритм».
Метод подразумевает семь ключевых каденций. Не все они могут использоваться на конкретном проекте: канбан удобен именно тем, что предоставляет набор инструментов, а команды выбирают подходящие для себя.
| Каденция | Частота и длительность | Горизонт планирования | Для чего необходима |
| Ежедневная встреча (Daily Meeting, Standup Meeting) | Каждый день, до 10 минут | 1–2 дня | Обсудить работу на короткую перспективу, уточнить статус блокировок и нагрузку, перераспределить задания между членами команды |
| Встреча по пополнению очереди (Replenishment Meeting) | 1 раз в неделю, до 30 минут | Неделя или более | Обсудить бэклог, нагрузку на сотрудника, обязательства и сроки (тайм) |
| Встреча по планированию поставки (Delivery Planning Meeting) | 1 раз в месяц, от 30 минут до 1 часа | От недели | Разобрать таски и сроки их выполнения с планированием даты релиза |
| Обзор предоставления услуг (Service Delivery Review) | 1 раз в месяц, от 1 часа | От 1 месяца | Обсудить результаты текущей работы, оценить шансы уложиться в намеченные сроки |
| Анализ рисков (Risk Review) | 1 раз в месяц или квартал, от 1 часа | Месяц, квартал и более | Проанализировать риски, связанные с реализацией: затягивание сроков, блокировка, увеличение потока заданий, нагрузки на сотрудников, уход ключевых специалистов |
| Обзор операций (Operation Review) | 1 раз в месяц или квартал, от 2 часов | Месяц и более | Оценить метрики и эффективность работы команды, продумать механизмы оптимизации процессов |
| Обзор стратегии (Strategy Review) | 1 раз в квартал или полугодие, от 3 часов | Более месяца | Продумать общую стратегию позиционирования и работы на рынке, скорректировать ее, спланировать дополнительные мероприятия для достижения целей |
Разница между Kanban и Scrum
Канбан, Agile, Scrum — методы организации процессов на ИT-проектах, производстве и других.
Kanban и Scrum похожи разделением работы на этапы, но есть и различия. Скрам подразумевает общий бэклог, которые распределяют по спринтам с конкретным результатом. Канбан обеспечивает равномерное распределение тасков.
В таблице ниже приведены основные отличия гибких методов управления ИT-проектами.
| Критерий сравнения | Kanban | Scrum |
| Источник происхождения | Концепция бережливого производства, менеджмент | Разработка программного обеспечения |
| Название колонок на доске | Произвольное, команды могут самостоятельно определять наименования и структуру | Жестко фиксированы: «бэклог», «бэклог спринта», «в процессе», «выполнено» |
| Режим работы | Непрерывный процесс, который можно остановить, изменить или вообще начать заново | Строгие спринты, которые нельзя прерывать |
| Распределение ролей | Все участники (в том числе на стороне заказчика) видят доску и процессы | Доступ к канбан-доске есть только у владельца продукта, скрам-мастера и команды |
| Ключевая метрика | Продолжительность цикла | Скорость спринта |
Преимущества и недостатки методологии
Каждый метод гибкого управления имеет плюсы и минусы.
Основные плюсы канбана:
- универсальность — методику можно использовать как в ИT-проектах, так и в быту;
- визуализация — задания наглядно отображаются на доске и доступны всем участникам команды;
- метрики эффективности — методика позволяет отслеживать скорость работы над задачами и отдельными тасками, время разрешения блокировок и другие;
- гибкость — можно изменять приоритетность карточек и последовательность работы над ними;
- вовлеченность сотрудников — каждый член команды видит вклад в достижение цели.
Но есть и минусы:
- ограничения по количеству сотрудников — когда в команде больше 10 человек, управлять статусами задач и рабочими процессами сложнее;
- зависимость от сотрудников и самодисциплины: система не работает, если члены команды забывают или не хотят передвигать стикеры;
- сложность масштабирования. Канбан хорош для небольших ИT-проектов. В случае с крупными системами сложнее разместить на board условные 76 заданий в работу (проверить, проконтролировать, отследить блокировку);
- краткосрочность планов: в backlog попадают только актуальные задания.
Метод можно комбинировать с другими — например, создать технику Scrumban: взять из скрама спринты, а из канбана — лимиты незавершенной работы.
Как внедрить канбан-систему
Канбан-методология предоставляет набор инструментов для организации работы в ИT или других сферах: boards, стикеры, метрики эффективности, последовательность действий и другие. Но резкое изменение принципов работы может стать причиной организационных сложностей и сопротивления сотрудников.
Поэтому для внедрения канбан-методики на текущем проекте рекомендуют:
- Оценить текущие задачи и процессы, перенести их на доску, но сохранить принятые ранее стандарты работы.
- Проанализировать потенциальную нагрузку на сотрудников, возможности канбан-системы в краткосрочной и долгосрочной перспективе.
- Установить классы сервиса (т.е. приоритеты — с фиксированной датой, срочные, стандартные) и разработать канбан-систему с учетом установленных практик.
- Договориться, что сотрудники будут постепенно переходить на новую систему — например, завершать задания так, как привыкли, а дополнительно перетаскивать карточку на канбан-доске.
- Внедрить канбан-систему и канбан-доску.
Смена методологии может занять от полугода в зависимости от текущих практик и бизнес-процессов. С внедрением канбана работа не заканчивается. Команды могут отслеживать метрики эффективности и корректировать рабочие процессы: увеличивать или уменьшать лимиты (WIP), добавлять или отменять каденции, перераспределять нагрузку на сотрудников.
Заключение
Методы управления ИT-проектами призваны упростить работу команды, минимизировать риск блокировок и связанных с ними простоев, подчеркнуть причастность каждого сотрудника к общему результату.
Когда речь идет о командной разработке, стоит обратить внимание на хостинг Git-репозиториев GitVerse с собственным трекером. Пользователям доступны совместные ревью, соавторство, импорт и зеркалирование из других git-сервисов, а также многое другое. Виртуальную машину и объектное хранилище можно получить бесплатно. Также на платформе GitVerse доступен AI-ассистент GigaCode. Искусственный интеллект знает 15 языков программирования (Java, JS, TS, Python, C/C++ и прочие) и совместим с популярными IDE: VS Code, WebStorm, Jupyter Notebook, Android Studio, CLion.
Используйте методологии и инструменты командной работы, чтобы сделать рабочие процессы простыми и эффективными.