Kanban

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Непрерывная поставка (CD) предполагает частую поставку релизов продукта клиентам. Непрерывная интеграция (CI) — это практика инкрементной автоматизированной сборки и тестирования кода в течение дня. Вместе они образуют конвейер CI/CD, без которого сложно обойтись командам разработчиков (особенно командам DevOps), если они хотят быстрее выпускать качественное ПО.

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

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

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