Закрыть

Kanban

Использование методологии Kanban при разработке ПО

Что такое Kanban?

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

Kanban articles

[CONTINUED]

Kanban 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.

When Toyota applied this same system to its factory floors, the goal was to better align their massive inventory levels with the actual consumption of materials. To communicate capacity levels in real-time on the factory floor (and to suppliers), workers would pass a card, or "kanban", between teams. When a bin of materials being used on the production line was emptied, a kanban was passed to the warehouse describing what material was needed, the exact amount of this material, and so on. The warehouse would have a new bin of this material waiting, which they would then send to the factory floor, and in turn send their own kanban to the supplier. The supplier would also have a bin of this particular material waiting, which it would ship to the warehouse. While the signaling technology of this process has evolved since the 1940s, this same "just in time" (or JIT) manufacturing process is still at the heart of it.

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

Agile software development teams today are able to leverage these same JIT principles by matching the amount of work in progress (WIP) to the team's capacity. This gives teams more flexible planning options, faster output, clearer focus, and transparency throughout the development cycle.

Kanban Board | Atlassian agile coach

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

Kanban-доски

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

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

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

Agile Kanban Board | Atlassian agile coach

Kanban-карточки

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

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

The benefits of Kanban

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

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

A kanban team is only focused on the work that's actively in progress. Once the team completes a work item, they pluck the next work item off the top of the backlog. The product owner is free to reprioritize work in the backlog without disrupting the team, because any changes outside the current work items don't impact the team. As long as the product owner keeps the most important work items on top of the backlog, the development team is assured they are delivering maximum value back to the business. So there's no need for the fixed-length iterations you find in scrum.

PRO TIP:

Savvy product owners always engage the development team when considering changes to the backlog. For example, if user stories 1-6 are in the backlog, user story 6's estimate may be based on the completion of user stories 1-5. It's always a good practice to confirm changes with the engineering team to ensure there are no surprises. 

Shortened time cycles

Cycle time is a key metric for kanban teams. Cycle time is the amount of time it takes for a unit of work to travel through the team’s workflow–from the moment work starts to the moment it ships. By optimizing cycle time, the team can confidently forecast the delivery of future work.

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

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

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

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

For example, a typical software team might have four workflow states: To Do, In Progress, Code Review, and Done. They could choose to set a WIP limit of 2 for the code review state. That might seem like a low limit, but there's good reason for it: developers often prefer to write new code, rather than spend time reviewing someone else's work. A low limit encourages the team to pay special attention to issues in the review state, and to review others work before raising their own code reviews. This ultimately reduces the overall cycle time.

Наглядность

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

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

Pro Tip:

The team's goal is to reduce the amount of time an issue takes to move through the entire process. Seeing the average cycle time drop in the control chart is an indicator of success. 

Agile control chart | Atlassian agile coach

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

Cumulative Flow Diagram

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

We know that continuous integration–the practice of automatically building and testing code incrementally throughout the day–is essential for maintaining quality. Now it's time to meet continuous delivery (CD). CD is the practice of releasing work to customers frequently–even daily or hourly. Kanban and CD beautifully complement each other because both techniques focus on the just-in-time (and one-at-a-time) delivery of value.

The faster a team can deliver innovation to market, the more competitive their product will be in the marketplace. And kanban teams focus on exactly that: optimizing the flow of work out to customers

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

Kanban and scrum share some of the same concepts but have very different approaches. They should not be confused with one another. 

 

SCRUM

KANBAN
График

Регулярные спринты фиксированной продолжительности (например, 2 недели)

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

 

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

Дэн Радиган
Дэн Радиган

Методология Agile оказала на меня огромное влияние как в профессиональном, так и в личном плане. Я понял, что и в работе, и в жизни лучший подход — гибкий. Я интересуюсь технологиями, фотосъемкой и мотоциклами. До встречи в Twitter! @danradigan

Up Next
Доски