Сравнение Scrum и Kanban. Какая методика Agile подойдет вам?

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

Max Rehkopf Автор: Max Rehkopf
Просмотр тем

Краткое описание. Kanban — это методика управления проектами, в которой управление рабочими процессами осуществляется на основе наглядного представления заданий, а методика Scrum помогает командам структурировать работу и управлять ею с учетом набора ценностей, принципов и практик.

Agile — это набор идеалов и принципов, которые служат нам ориентиром. DevOps — это способ автоматизации и интеграции процессов команд разработчиков и операционных команд. При внедрении Agile и DevOps следуйте методике Kanban или Scrum. Каждая из них предлагает свой вариант управления работой.

Указать на различия между методологиями scrum и kanban несложно, но это даст лишь поверхностное представление. Хотя методологии различаются, их принципы в целом одинаковы. Обе помогают улучшить качество продуктов (и сервисов) и избавляют от множества проблем.

Итак, на чем мы остановились?

Agile — это структурированный итеративный подход к управлению проектами и разработке продуктов. В нем учитывается непостоянный характер разработки продуктов. Самоорганизующиеся команды, выбравшие этот подход, получают возможность реагировать на изменения, не отклоняясь от намеченного пути. В наши дни agile не дает особого преимущества перед конкурентами. Сегодня просто невозможно разрабатывать продукт в течение нескольких месяцев или даже лет в условиях полной секретности. А значит, сейчас как никогда важно работать правильно.

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

Задача Scrum-команд — создать инкремент (промежуточный продукт работы), который теоретически можно поставить, за ряд промежутков времени, которые называются спринтами. Они стремятся создавать циклы обучения для быстрого сбора и учета отзывов клиентов. Scrum-команды используют особые роли, создают специальные артефакты и проводят регулярные собрания, чтобы работа шла в нужном русле. Лучше всего методика Scrum описана в руководстве по Scrum.

Какую бы методику управления проектами вы ни выбрали, у нас есть шаблоны Jira, которые помогут быстро приступить к работе. Ознакомьтесь с нашим шаблоном Scrum или шаблоном доски Kanban. Оба шаблона можно использовать бесплатно.

 

Scrum

Kanban

Источник

Scrum

Разработка программного обеспечения

Kanban

Бережливое производство

Основная идея

Scrum

Учиться на собственном опыте, самоорганизовываться и расставлять приоритеты, анализировать свои победы и поражения, чтобы постоянно совершенствоваться.

Kanban

Повышать качество выполняемой работы с помощью наглядных материалов

График

Scrum

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

Kanban

Непрерывный процесс

Методы

Scrum

Планирование спринтов, спринт, ежедневное Scrum-совещание, обзор спринта, ретроспектива спринта

Kanban

Визуализация процесса работы, ограничение объемов незавершенной работы, управление процессом, включение циклов обратной связи

Роли

Scrum

Владелец продукта, Scrum-мастер, команда разработчиков

Kanban

Нет обязательных ролей

Коллеги по команде используют доску Scrum | Atlassian — тренер по agile

Scrum — структурированный agile-подход

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

График Scrum

В Scrum высокий темп работы достигается за счет ее деления на спринты продолжительностью от одной до четырех недель с точными датами начала и окончания. Из-за узких временных рамок сложные задания приходится делить на более мелкие истории, и команда быстрее учится. Сможет ли команда за это время поставить пригодный для использования код? В этом главный вопрос.

Ключевыми точками в спринте являются собрания по планированию спринта и по обзору итогов спринта, а также ретроспективы. Кроме того, в ходе спринта проходят ежедневные scrum-совещания (стендапы). Эти scrum-собрания не отнимают много сил и проводятся на регулярной основе.

Роли в Scrum

В scrum четко обозначены три роли.

  • Владелец продукта представляет интересы клиента, управляет бэклогом продукта и помогает определить приоритеты для команды разработчиков.
  • Scrum-мастер следит, чтобы команда соблюдала принципы scrum.
  • Команда разработчиков выбирает, какую работу нужно сделать, поставляет инкременты и несет коллективную ответственность.

Кто руководит командой scrum? По факту никто. Команды scrum проповедуют принцип самоорганизации; в них все участники равны, хоть и исполняют разные обязанности. Команду объединяет общая цель: поставить ценный продукт клиентам.

Общие показатели

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

Отношение к изменениям

Команды стремятся понять, сколько они могут сделать за время, отведенное на спринт. Они берут на себя обязательство выполнить поставленную задачу за спринт. Однако отзывы клиентов могут подтолкнуть Scrum-команды к тому, чтобы перестроиться и изменить спринт ради создания максимальной ценности для клиентов. В рамках ретроспективы спринта Scrum-команды должны обсуждать, как свести число изменений к минимуму в будущем, так как они ставят под угрозу возможность создания готового к поставке инкремента. Если команда часто меняет объем работ посреди спринта, возможно, при выборе задач не было до конца понятно, что нужно сделать. Либо в планы команды вмешивается незапланированная или текущая работа.

Подробнее о методологиях scrum см. в статье Что такое scrum?.

Коллеги по команде используют доску Kanban | Atlassian — тренер по agile

Kanban — непрерывное совершенствование, гибкие процессы

Суть Kanban — в визуализации работы, ограничении объема незавершенной работы (WIP) и быстром перемещении задач от стадии «Выполняется» на стадию «Завершено».

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

Модель Kanban

В основе kanban лежит непрерывная структура рабочего процесса, дающая командам свободу действий и возможность меняться вместе с изменениями приоритетов. Рабочие задачи представлены карточками на доске kanban и перемещаются из одной стадии рабочего процесса (столбца) в другую. Обычно рабочий процесс подразделяется на стадии «Предстоит сделать», «В процессе», «На проверке», «Заблокировано» и «Завершено». Но это не самый интересный способ разбить процесс.

Возможность создавать собственные столбцы в зависимости от того, как работает ваша команда, — лучшая особенность Kanban. Моя команда поставляет контент, поэтому задачи проходят столбцы (упрощенно) «Бэклог», «Приоритеты расставлены», «Схема набросана», «Написание», «Оформление», «Техническая экспертиза» и «Поставлено». С помощью нашей доски мы узнали, что поставляем примерно одну порцию контента в неделю, и поняли, где у нас проблемные места. (Да, это именно «Техническая экспертиза»!)

Подходы к релизу

В kanban обновления выпускаются по мере готовности; регулярный график или заранее определенные сроки отсутствуют как таковые.

Теоретически в рамках kanban не требуется устанавливать точный срок для завершения задания. Если задание выполняется раньше (или позже), результат выпускается по мере необходимости: для выпуска не нужно ждать контрольной точки, например собрания по обзору итогов спринта.

Роли в Kanban

Доска Kanban принадлежит всей команде. Некоторые команды привлекают к участию тренера по agile, но Kanban, в отличие от Scrum, не предусматривает роль «kanban-мастера», который отвечал бы за устранение шероховатостей в процессе работы. Команда несет коллективную ответственность за совместное выполнение заданий на доске и поставку результатов.

Ключевые показатели

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

Еще одним аналитическим инструментом является сводная диаграмма процесса. Глядя на нее, команды понимают, сколько рабочих задач находится на каждой стадии. С ее помощью можно выявить проблемные места, которые нужно устранить для повышения производительности.

Другое средство борьбы с проблемными местами — лимиты незавершенной работы (WIP). Это ограничение максимального количества карточек, которые могут находиться в любом столбце одновременно. Когда лимит WIP достигнут, специальный инструмент, например Jira, устанавливает ограничение для столбца, и команда направляет свои усилия на соответствующие задачи, чтобы добиться прогресса в их решении.

Отношение к изменениям

В Kanban рабочий процесс можно менять в любой момент. В зависимости от приоритетов новые рабочие задачи можно добавлять в бэклог, а существующие карточки — блокировать или удалять. В случае изменения производительности команды можно соответствующим образом скорректировать лимит WIP и изменить рабочие задачи. Суть Kanban — в гибкости.

Подробнее о методике Kanban см. в статье Что такое Kanban?.

Agile-проект Atlassian | Atlassian — тренер по agile

Сравнение инструментов Scrum и Kanban

Сторонники Agile не склонны рассуждать об инструментах. Нередки случаи, когда выбор инструмента определяет выбор методологии, а выбор методологии определяет принципы, которых придерживается команда. Мы же считаем, что процесс принятия решения должен идти в обратном направлении.

Только после того, как вы освоили принципы Scrum и пришли к выводу, что эта методика полностью отвечает вашим потребностям, следует выбирать оптимальный инструмент Scrum. То же можно сказать и про Kanban. Не претендуя на объективность, мы все же считаем: Jira — лучший инструмент для разработки ПО, используемый agile-командами, — удовлетворит любые потребности.

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

Kanban или Scrum — не можете выбрать?

Применять Scrum и Kanban — значит следовать всем правилам Agile. Эти методики прошли проверку временем и, откровенно говоря, им сложно что-либо противопоставить. Переиначив известный девиз IBM, можно сказать, что еще никого не уволили за выбор Scrum.

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

Проекты команды, как видно из названия, позволяют командам самим выбирать возможности Agile, которые им нужны. Это могут быть элементы Scrum, Kanban или их сочетание. Необязательно брать за основу одну методологию в первый же день работы. В проектах команды можно поэтапно добавлять все более и более мощные возможности по мере понимания того, что подходит команде (а что нет).

При выборе проекта команды Scrum или Kanban нет никаких рисков, ведь шаблоны обоих типов можно дорабатывать с учетом потребностей команды.

Что бы вы ни выбрали, не спешите менять методологию. Пусть какие-нибудь рабочие задачи из бэклога пройдут весь путь до стадии «Завершено», и только потом спросите команду, что удалось, а что нет. Знакомьтесь со Scrum и Kanban, задавайте эти вопросы, и в конечном счете вы познаете радость следования Agile.

Связанные ресурсы

продолжение темы
Kanplan