Что такое Kanban?

Kanban — это популярный подход к реализации agile-разработки ПО. Он предполагает обсуждение производительности в режиме реального времени и полную прозрачность рабочих процессов. Этапы работы визуально представлены на kanban-доске, что позволяет членам команды видеть состояние каждой задачи в любой момент времени. 

It is enormously prominent among today's agile software teams, but the kanban methodology of work dates back more than 50 years. In the late 1940s Toyota began optimizing its engineering processes based on the same model that supermarkets were using to stock their shelves. Supermarkets stock just enough product to meet consumer demand, a practice that optimizes the flow between the supermarket and the consumer. Because inventory levels match consumption patterns, the supermarket gains significant efficiency in inventory management by decreasing the amount of excess stock it must hold at any given time. Meanwhile, the supermarket can still ensure that the given product a consumer needs is always in stock.

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

>> Ознакомьтесь с этим обучающим материалом и создайте Kanban-проект с помощью Jira 

Kanban для команд разработчиков ПО

В наши дни agile-команды разработчиков ПО используют принцип JIT, чтобы добиться соответствия между объемом незавершенной работы (WIP) и производительностью команды. Это дает командам больше гибкости при планировании, позволяет быстрее получать результаты, облегчает концентрацию на работе и обеспечивает прозрачность всего цикла разработки.

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

Kanban-доски

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

Доски нужны, чтобы визуализировать работу команды, стандартизировать процесс, а также найти и устранить блокеры и зависимости. И не важно, в какой форме они представлены — в физической или в цифровой. На стандартной Kanban-доске процесс состоит из трех шагов: «Запланировано», «В работе» и «Сделано». Однако доску можно настроить в соответствии с процессом, принятым в той или иной команде, в зависимости от ее размеров, структуры и целей.

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

Kanban-карточки

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

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

Преимущества Kanban

На сегодняшний день Kanban — одна из самых популярных методологий разработки ПО, используемых agile-командами. Kanban предоставляет командам любых размеров ряд дополнительных преимуществ, касающихся планирования задач и обеспечения производительности.

Гибкость планирования

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

Подсказка. Опытные владельцы продуктов обязательно привлекают команду разработчиков к изменениям в бэклоге. Например, если в бэклоге описаны пользовательские истории 1–6, оценка пользовательской истории 6 может быть основана на завершении пользовательских историй 1–5. Во избежание неприятных сюрпризов все изменения лучше согласовывать с командой разработчиков. 

Меньшая продолжительность цикла

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

Если теми или иными навыками обладает несколько человек, продолжительность цикла сокращается, если же только один — в процессе появляется узкое место. Именно поэтому команды стремятся делиться знаниями и внедряют такие практики, как проверка кода и наставничество. Благодаря обмену знаниями члены команды могут выполнять разнообразные задачи, что еще больше оптимизирует продолжительность цикла. Это также означает, что в случае скопления работы вся команда сможет взяться за нее и восстановить нормальное течение процесса. К примеру, тестирование не всегда выполняют только инженеры по тестированию. Разработчики тоже могут поучаствовать.

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

Меньше узких мест

Многозадачность убивает эффективность. Чем больше незавершенных задач, тем чаще приходится переключаться между ними, а это сказывается на сроках их завершения. Поэтому ключевой принцип Kanban состоит в лимитировании объема незавершенной работы (WIP). Лимиты незавершенной работы позволяют быстро находить в работе команды узкие и проблемные места, вызванные нехваткой внимания, людей или навыков.

К примеру, типичная команда разработчиков ПО может использовать четыре состояния процесса разработки: «Запланировано», «В работе», «Проверка кода» и «Сделано». Для состояния проверки кода может быть установлен лимит WIP, равный 2. Число может показаться маленьким, но на все есть свои причины: разработчики предпочитают писать собственный код, а не проверять чужой. Низкий лимит стимулирует команду уделять особое внимание задачам в состоянии проверки, а также проверять чужую работу, прежде чем создавать свои задачи на проверку кода. В конечном итоге это снижает общую продолжительность цикла.

Наглядность

Одна из основных ценностей — предельное внимание к повышению эффективности команды с каждой рабочей итерацией. Графики — это визуальное средство, позволяющее командам не останавливаться на достигнутом. Если у всей команды есть доступ к данным, проще заметить (и устранить) узкие места в процессе. Kanban-команды часто используют два общих отчета: графики управления и совокупного потока.

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

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

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

Непрерывная интеграция

Вы уже знаете, что непрерывная интеграция (практика инкрементной автоматизированной сборки и тестирования кода в течение дня) — залог поддержания качества. Пришло время узнать, что такое непрерывная поставка (CD). CD предполагает частую поставку релизов продукта клиентам, вплоть до ежедневных или ежечасных релизов. Kanban и CD идеально дополняют друг другу, поскольку обе методологии основаны на своевременной (и последовательной) поставке ценного функционала.

Чем быстрее команда сможет выпустить инновацию на рынок, тем более конкурентоспособным будет ее продукт. Kanban-команды сконцентрированы именно на оптимизации процесса поставки продуктов клиентам.

Сравнение Scrum и Kanban

Некоторые концепции Kanban и Scrum похожи, однако в этих методологиях используются совершенно разные подходы. Их нужно четко разграничивать. 

  Scrum Kanban
График Регулярные спринты фиксированной продолжительности (например, 2 недели) Непрерывный процесс
Подходы к релизу В конце каждого спринта после одобрения владельцем продукта Поставка выполняется непрерывно или на усмотрение команды
Роли Владелец продукта, Scrum-мастер, команда разработчиков Ролей нет, в некоторых командах работают тренеры по agile
Ключевые показатели Скорость команды Продолжительность цикла
Отношение к изменениям В ходе спринта команды стремятся избегать изменений в прогнозах спринта: изменения приведут к неверным выводам относительно оценки задач Изменение может произойти в любой момент

Некоторые команды объединяют идеалы Scrum и Kanban в Scrumban. Из Scrum берут спринты фиксированной длительности и роли, а из Kanban — концентрацию на продолжительности цикла и лимитах незавершенной работы. Если ваша команда только начинает использовать Agile, мы настоятельно рекомендуем выбрать ту или иную методологию и некоторое время следовать только ей. Поэкспериментировать вы всегда успеете. 

Рассмотренный продукт
Логотип Jira Software
Отслеживание проектов и задач