Kanban
Использование методологии Kanban при разработке ПО
Начните бесплатно с шаблоном Kanban для Jira
Повысьте эффективность до максимума, отслеживая и продвигая вперед наиболее важную работу.
Что такое Kanban?
Kanban — это популярный подход к реализации принципов agile и DevOps при разработке ПО. Методика предполагает обсуждение производительности в режиме реального времени и полную прозрачность рабочих процессов. Рабочие задачи визуально представлены на доске Kanban, что позволяет участникам команды видеть состояние каждой задачи в любой момент времени.
Статьи о Kanban
Задачи на досках Kanban в Jira — от постановки до выполнения
Доска Kanban в Jira помогает командам непрерывно улучшать время цикла и повышать эффективность работы.
Получить бесплатноОптимизация разработки программного обеспечения с помощью процесса Kanban
Наглядные рабочие процессы Kanban, лежащие в основе методологий Agile и DevOps, повышают эффективность работы за счет последовательного продвижения по заданиям. Процесс Kanban аналогичен отработанному подходу к управлению запасами в супермаркетах — задания передаются на следующий этап процесса разработки именно тогда, когда это необходимо.
На досках Kanban задания представлены в виде карточек, что помогает визуально отслеживать прогресс и быстро выявлять узкие места. Команды ограничивают объемы незавершенной работы, чтобы оптимизировать распределение ресурсов и поддерживать стабильность рабочего процесса. Чтобы постоянное улучшение оставалось в центре внимания, в Kanban используют такие показатели, как графики управления и совокупного потока, благодаря которым команды могут итеративно совершенствовать рабочие процессы.
При разработке программного обеспечения процесс Kanban способствует динамичному управлению заданиями, ускоряет циклы поставки и повышает удовлетворенность клиентов за счет целенаправленной и бесперебойной работы. По сути, он воплощает в себе эффективность — гармоничное сочетание прозрачности, адаптируемости и постоянного совершенствования, раскрывающее весь потенциал гибких методологий разработки.
Структурирование процесса Kanban
Для эффективного внедрения методологии Kanban в команде разработчиков программного обеспечения важно наладить структурированный процесс. Это позволит выполнять задания в равномерном темпе и оптимизировать управление рабочим процессом. Вот как можно структурировать процесс Kanban.
Визуализируйте рабочий процесс. Для начала представьте рабочий процесс команды на доске Kanban. На доске, физической или виртуальной, нужно отразить каждый этап процесса разработки — от создания заданий до их завершения.
Стандартизируйте этапы. Определите и стандартизируйте стадии рабочего процесса в соответствии с методами и требованиями вашей команды. Обычно используют этапы «К исполнению», «В работе» и «Готово», но при необходимости их можно подобрать специально под особенности вашего рабочего процесса.
Определите блокеры и зависимости. Важно, чтобы по вашей доске Kanban можно было мгновенно выявить блокеры и зависимости. Такая прозрачность позволяет без промедления решать проблемы и предотвращать перебои в рабочем процессе.
Ограничьте объемы незавершенной работы. Предусмотрите ограничения для каждого этапа рабочего процесса, чтобы избегать перегрузок и поддерживать стабильный рабочий процесс. Это поможет оптимизировать распределение ресурсов и реже работать над несколькими задачами одновременно, что способствует повышению производительности.
Поощряйте сотрудничество. Развивайте культуру сотрудничества в своей команде, чтобы участники сообща устраняли узкие места и продвигались по этапам рабочего процесса в равномерном темпе. Такой совместный подход способствует эффективному и быстрому выполнению заданий.
Используйте карточки Kanban. Представьте каждое задание на доске в виде карточки Kanban с важными сведениями, такими как описание задания, исполнитель и предполагаемое время выполнения. Они помогают визуально отслеживать выполнение заданий и способствуют прозрачности в команде.
С такой структурой процесса Kanban вы сможете оптимизировать процессы разработки программного обеспечения, укрепить сотрудничество в команде и добиться максимальной эффективности в управлении заданиями.
Истоки Kanban
Методология Kanban очень популярна среди современных Agile- и DevOps-команд разработчиков программного обеспечения, однако она существует уже более 50 лет. В конце сороковых годов XX века компания Toyota начала использовать модель заполнения полок в супермаркетах, чтобы оптимизировать свой технологический процесс.
Супермаркеты выставляют ограниченное, но достаточное для удовлетворения потребительского спроса количество товарных запасов. Таким образом оптимизируется поток товаров между супермаркетом и потребителем. Поскольку уровень запасов соответствует потребительскому спросу, управление складом становится значительно более эффективным, ведь избыточных запасов, которые тоже нужно хранить, становится меньше. При этом в супермаркете по-прежнему есть все необходимые потребителю товары.
Компания Toyota применила эту систему в своих цехах, чтобы добиться соответствия между огромными складскими запасами и реально используемыми в производстве материалами. Для отслеживания уровня запасов в цехе (и коммуникации с поставщиками) в реальном времени рабочие передавали между командами специальную карточку под названием kanban.
Когда в корзине заканчивались используемые на участке производства материалы, на склад передавали карточку Kanban с указанием, какой материал необходим, в каком количестве и т. д. На складе уже стояла новая корзина с этим материалом: ее отправляли в цех, а складские работники отправляли поставщику свой kanban. Несмотря на то что с 1940-х годов процесс усовершенствовали, его суть осталась та же — все основано на концепции Just-in-time (JIT).
Kanban для команд разработчиков ПО
В наши дни agile-команды разработчиков ПО используют принципы JIT, чтобы добиться соответствия между объемом незавершенной работы и производительностью команды. Это дает командам больше гибкости при планировании, позволяет быстрее получать результаты, заостряет внимание на непрерывном совершенствовании и обеспечивает прозрачность всего цикла разработки.
Ключевые принципы методологии Kanban не устаревают, их можно применить практически в любой отрасли, однако особым успехом пользуется среди agile-команд разработчиков ПО. Для внедрения Kanban в цехах требуется изменить физические процессы и приобрести дополнительные материалы, а командам разработчиков ПО нужны только доска и карточки заданий, да и те могут быть виртуальными.
Kanban-доски
Работа всех kanban-команд строится вокруг доски Kanban — инструмента визуализации и оптимизации рабочего процесса в командах. Хотя некоторые команды предпочитают реальные доски, виртуальные доски давно стали обязательно поддерживаемой возможностью любого инструмента agile-разработки ПО: с ними можно отследить процессы, организовать совместную работу и доступ из разных мест.
Независимо от того какую доску Kanban, цифровую или физическую, использует команда, она позволяет сделать работу нагляднее, стандартизировать рабочий процесс, а также мгновенно выявлять и устранять все блокеры и зависимости. На стандартной доске Kanban процесс состоит из трех шагов: «Запланировано», «В работе» и «Сделано». Однако в зависимости от размера, структуры и целей команда может составить собственный план рабочего процесса по своим методам.
Поскольку методология Kanban основана на полной прозрачности работы и общении в реальном времени, доска Kanban служит единым достоверным источником информации о работе команды.
Kanban-карточки
В переводе с японского Kanban дословно означает «вывеска». Команды Kanban представляют каждую рабочую задачу в виде отдельной карточки на доске. Зачем отображать работу в виде карточки на доске Kanban? Благодаря такому наглядному представлению участникам команды проще и удобнее отслеживать прогресс по рабочему процессу.
Карточки Kanban содержат важную информацию о заданиях проекта и наглядно демонстрируют, кто отвечает за какие задания, дает краткое описание задания и предполагаемый срок их выполнения. На виртуальных досках Kanban в карточки также часто добавляют снимки экрана и другие важные для исполнителя технические детали.
Возможность видеть статус каждого рабочего задания и всю связанную с ним информацию, повышает концентрацию участников команды, обеспечивает прозрачность и помогает быстрее выявлять блокеры и зависимости.
Преимущества методики Kanban
На сегодняшний день Kanban — одна из самых популярных методологий разработки ПО, используемых agile-командами. Kanban предоставляет командам любых размеров ряд дополнительных преимуществ, касающихся планирования заданий и обеспечения производительности.
Гибкость планирования
Kanban-команда сосредоточена только на текущей работе. Как только команда завершает работу над заданием, она выбирает следующее задание из бэклога. Владелец продукта может менять приоритет заданий в бэклоге, не мешая работе команды, поскольку изменения происходят за пределами текущих рабочих задач.
Если владелец продукта следит, чтобы наверху бэклога находились самые важные рабочие задачи, команда разработчиков точно будет работать с максимальной ценностью для бизнеса.
Опытные владельцы продуктов обязательно привлекают команду разработчиков к изменениям в бэклоге. Например, если в бэклоге описаны пользовательские истории 1–6, оценка пользовательской истории 6 может требовать завершения работы над пользовательскими историями 1–5. Во избежание неприятных сюрпризов все изменения лучше согласовывать с командой разработчиков.
Сокращение времени цикла
Время цикла — ключевой показатель для Kanban-команд. Под временем цикла понимается время прохождения рабочей задачей жизненного цикла, от начала работы над ней до ее поставки. Оптимизация времени цикла позволяет команде с уверенностью предсказывать срок поставки по дальнейшим задачам.
Если теми или иными навыками обладает несколько человек, время цикла сокращается, если же только один — в процессе появляется узкое место. Именно поэтому команды стремятся делиться знаниями и внедряют такие практики, как проверка кода и наставничество. Благодаря обмену знаниями участники команды могут выполнять разнообразные задачи, что еще больше оптимизирует время цикла.
Кроме того, при таком подходе вся команда может совместно устранять любые узкие места, что способствует быстрому решению проблем и равномерному продвижению по рабочему процессу. Например, ответственность за тестирование лежит не только на инженерах по контролю качества, но и на разработчиках, то есть эффективность поддерживается совместными усилиями. В системе Kanban вся команда следит за тем, чтобы работа продвигалась в равномерном темпе на протяжении всего процесса.
Меньше узких мест
Многозадачность губит эффективность. Чем выше рабочая нагрузка, тем чаще приходится менять контекст, что затрудняет выполнение заданий. Вот почему важнейший принцип процесса Kanban — ограничение незавершенной работы. Именно за счет него удается быстро выявлять в работе команды узкие места, вызванные нехваткой внимания, людей или навыков.
К примеру, типичная команда разработчиков ПО может использовать четыре состояния процесса разработки: «Запланировано», «В работе», «Проверка кода» и «Сделано». Для состояния проверки кода можно установить ограничение в две задачи. На первый взгляд, ограничение довольно жесткое, но тому есть своя причина.
Разработчики часто предпочитают писать собственный код, а не проверять чужой. Жесткое ограничение стимулирует команду уделять особое внимание задачам в состоянии проверки, а также проверять чужую работу, прежде чем создавать свои задачи на проверку кода, что в конечном итоге сокращает общее время цикла.
Наглядность
Одна из основных ценностей — предельное внимание к повышению эффективности команды с каждой рабочей итерацией. Графики служат наглядным инструментом, благодаря которому команда всегда будет развиваться.
Когда у всей команды есть доступ к данным, заметить (и устранить) узкие места в процессе становится проще. Kanban-команды часто используют два общих отчета: графики управления и совокупного потока. На графике управления отображается время цикла выполнения каждой задачи и скользящее среднее для всей команды.
Цель команды — сократить время прохождения задачи по этапам рабочего процесса. Если среднее время цикла на графике управления снижается, команда на правильном пути.
На графике совокупного потока отображается количество задач в каждом состоянии. Выявить блокеры не составит труда: когда количество задач на одном из этапов растет, что-то идет не так. Промежуточные состояния, такие как «В работе» или «На проверке», указывают на то, что задача еще не поставлена клиенту. Блокеры на этих этапах могут повысить вероятность серьезных конфликтов при интеграции в процессе слияния кода.
Непрерывная поставка
Непрерывная поставка (CD) описывает процесс частой поставки релизов продукта клиентам. Непрерывная интеграция (CI) — это практика инкрементной автоматизированной сборки и тестирования кода в течение дня. Вместе они образуют конвейер CI/CD, без которого командам DevOps сложно будет ускорить поставку ПО, сохранив при этом его высокое качество.
Kanban и CD идеально дополняют друг друга, поскольку обе методологии основаны на своевременной (и последовательной) поставке ценного функционала. Чем быстрее команда выпустит инновационное решение на рынок, тем более конкурентоспособным будет ее продукт. Kanban-команды сконцентрированы именно на оптимизации процесса поставки продуктов клиентам.
Сравнение Scrum и Kanban
Некоторые концепции Kanban и Scrum похожи, однако в этих методиках используются совершенно разные подходы. Их необходимо четко разграничивать.
| | Scrum | Kanban |
|---|---|---|
| Подходы к релизу | Scrum Регулярные спринты фиксированной продолжительности (например, 2 недели) | Kanban Непрерывный процесс |
| Роли | Scrum Владелец продукта, Scrum-мастер, команда разработчиков | Kanban Поставка выполняется непрерывно или на усмотрение команды |
| Ключевые показатели | Scrum Скорость команды | Kanban Продолжительность цикла |
| Отношение к изменениям | Scrum В ходе спринта командам следует стремиться избегать изменений в прогнозах спринта: изменения приведут к неверным выводам относительно оценки задач | Kanban Изменение может произойти в любой момент |
Некоторые команды объединяют идеалы Scrum и Kanban в метод под названием Scrumban. Из Scrum берут роли и спринты фиксированной длительности, а из Kanban — пристальное внимание к времени цикла и ограничениям на объем незавершенной работы.
Но командам, которые только начинают использовать Agile, лучше выбрать одну методологию и некоторое время следовать только ей. Если ваша команда готова начать применять методику Kanban, воспользуйтесь нашим бесплатным шаблоном доски Kanban уже сегодня!
Related resources
Начните бесплатно с шаблоном Kanban для Jira
Повысьте эффективность до максимума, отслеживая и продвигая вперед наиболее важную работу.
Готовы начать знакомство?
Пошаговые инструкции по ведению проекта Kanban, распределению приоритетов между рабочими задачами, визуализации рабочего процесса и сокращению объема незавершенной работы до минимума с помощью Jira.
Читать учебное руководствоДизайн по методике agile: процесс и рекомендации по совместному дизайну
Совместный дизайн предполагает итеративную разработку дизайна продукта, в ходе которой опрашиваются мнения клиентов и разработчиков на первых порах работы над проектом. Узнайте больше.
Читать статью