Скрам и Канбан: чем отличаются гибкие методологии управления

Скрам и Канбан — близкие по философии гибкие методы управления (Agile). Но подходы имеют принципиальные отличия. Скрам направлен на совершенствование продукта, а Канбан — на улучшение рабочих процессов. 

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

Вы узнаете:

• почему Скрам и Канбан — это все философия гибкой методологии (Agile);

• в чем разница между подходами Скрам и Канбан;

• как организовать работу по методологии Канбан;

• как внедрить в компанию Скрам-подход;

• когда актуальнее Скрам, а когда — Канбан;

• как использовать гибридную методологию СкрамБан.

Общие корни: Скрам и Канбан — это все эджайл?

В 2001 году мир увидел манифест гибкой методологии (Agile) — краткую, но емкую памятку о главных ценностях и принципах гибкой разработки ПО. Со временем манифест стал основой целой философии Эджайл, а также семейства гибких методологий управления проектами, к которым причисляют Скрам и Канбан. Оба метода направлены на внимание к продукту, его ценность для клиента и адаптивность к изменению требований. 

Несколько лет специалисты в области менеджмента активно сравнивали подходы, находили общие стороны и противопоставляли конкретные инструменты работы. Но приходили к одному выводу — это все Аджайл: Скрам Канбан и ряд других методологий, например, экстремальное программирование (eXtreme Programming) и бережливый подход (Lean). 

Бизнес-гибкость — это повышение конкурентоспособности компании с помощью быстрой адаптации к изменениям рынка и внедрения инноваций.

Сейчас мнения специалистов расходятся. Одни до сих пор считают, что Канбан — Аджайл-подход. Другие думают, что Канбан вышел за пределы гибкой методологии (Agile), несмотря на то что методология во многом соответствует принципам гибкого управления проектами. 

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

Скрам и Канбан: разница между подходами

Рассмотрим отличия более подробно.

Разница целей

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

Поэтому перед руководством стоят разные цели. И выбирать программную платформу (фреймворк) нужно с опорой на них.

Разница принятия решений

1. Канбан нужен руководителю. Это инструмент менеджмента. Начальник оценивает ситуацию и внедряет Канбан, чтобы улучшить рабочие процессы, получить более прозрачный контроль над ними. Потому и решение о внедрении Канбан обычно идет сверху вниз, то есть от руководителя к сотрудникам. 

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

Разница встреч

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

1. Задачи Скрам-встреч — сплотить команду, скоординировать работу всех участников и поделиться опытом. Если возникают конкретные трудности, блокирующие проблемы (блокеры), то их чаще обсуждают лично. А во время Скрам-встреч делают упор на активное вовлечение сотрудников в командную работу. 

2. Задача Канбан-встреч, наоборот, — обсудить проблему и принять решение. Например, сотрудники могут собрать встречу у Канбан-доски, чтобы выявить причины затрудненного движения карточек. Менеджер будет опираться на статистику и примет решение о перераспределении ресурсов или другом изменении бизнес-процессов. 

Разница внедрения

Скрам — достаточно трудный в освоении программной платформы (фреймворка), для работы по которому понадобится:

• обучить сотрудников;

• распределить роли внутри команды;

• привлечь и замотивировать заинтересованных лиц на совместную работу;

• продумать время и порядок проведения встреч;

• перестроить рабочие процессы в компании. 

На внедрение даже пилотного проекта по Скрам может уйти ни один месяц. Продолжительность перехода на новую модель зависит от готовности команды к изменениям.

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

Потом можно добавлять остальные элементы Канбан, в том числе каденции и лимиты незавершенной работы (WIP-лимиты), но делать это постепенно. Причем в процессе внедрения компания уже будет работать по Канбан. 

Можно привести такое сравнение: 

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

• Внедрение Канбан — это как ящик с инструментами. Из него можно по выбору взять один или два и приступить к сборке мебели на свой вкус. Например, внедрил в работу Канбан-доску, уже рабочий метод. 

Сервис Аспро.Cloud — система для эффективного управления по гибким методологиям. Вне зависимости от того, какой подход вы выберите для своей команды, сотрудники могут работать в системе: 

• формировать список задач (бэклог) проекта;

• перемещать задачи на доске;

• запускать спринты;

• учитывать лимиты незавершенной работы (WIP-лимиты);

• проводить ретроспективы и многое другое. 

Разница в графике работы

1. Работа по Скрам итеративная. То есть проект разбивается на циклы — небольшие промежутки времени. Результатом каждого спринта становится продукт, который совершенствуется с каждой итерацией. 

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

Разница досок

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

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

Канбан-доска в Аспро.Cloud

Отличие Скрам-доски от Канбан-доски в том, что на нее попадают только те задачи, которые актуальны для текущего спринта. Остальные лежат в списке задач (бэклоге). Иногда виртуальная доска имеет один дополнительный столбец — список задач. Но из нее задачи перемещают в другие колонки только при планировании нового спринта.

Скрам-доска в Аспро.Cloud

Соответственно, в ходе спринта на Скрам-доске все задачи переходят в колонку «Готово». Распределение карточек в колонках неравномерное. А на Канбан-доске происходит непрерывное перемещение и добавление задач. И их количество в каждой колонке приблизительно одинаковое. А если где-то их скапливается много карточек, такой процесс называют бутылочным горлышком — слабым местом в работе. 

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

Канбан

Как появилась методология

Слово «Канбан» пришло из Японии, оно означает доску со знаками — лаконичную вывеску, которую рисовали художники в 16 веке. Доска осталась, но ее значение в 20 веке существенно изменилось: знаки превратились в карточки. Таичи Оно, инженер компании Toyota, в процессе борьбы с излишними складскими запасами и перепроизводством, внедрил на производстве такую систему: 

• за каждым товаром закреплена карточке;

• когда на производстве товар подходит к концу, карточка отправляется на склад;

• когда на складе накопилось определенное количество карточек, их отправляют поставщикам. 

Такой подход обеспечил соблюдение принципа «точно в срок» — то есть товары поступали на производство именно в тот момент, когда они были необходимы, а не пылились на складах. Фактически это стало первой Канбан-доской с перемещающимися карточками от одной колонки к другой. Только карточки крепились обычно не на доску, а на ящики с деталями и сырьем. 

Методика закрепления карточек по принципу Канбан была только одной частью новой философии Toyota — бережливого производства. Весь менеджмент компании строился на принципе постоянного улучшения процессов и оптимизации расходов. 

Однако большую известность Канбан получил в 2000-х годах, когда в ИТ-сфере все начали работать по гибкой методологии (Agile). В 2003 году свет увидела книга «Бережливая разработка программного обеспечения: набор инструментов Agile» Мэри и Тома Поппендик, в которой авторы перенесли принципы производственной работы компании Toyota на сферу ИТ. Однако открытие методологии Канбан в сфере разработки ПО принадлежит Дэвиду Андерсону. В 2004 году он опубликовал книгу, в которой были перечислены основные инструменты и принципы Канбан. 

Изначально использование досок было тесно связано с методологией Скрам. Разработчики, которые работали по Скрам, записывали на карточках задачи, которые составляли список задач спринта. Но со временем Канбан стал отдельным методом, включающим в себя набор принципов и инструментов.

Основные принципы

1. Визуализация рабочих процессов. Распределение задач по колонкам помогает отслеживать стадии продвижения проекта и обеспечивает прозрачность бизнес-процессов.

2. Лимиты незавершенной работы (WIP-лимиты) для сокращения незавершенных задач. Чтобы не растягивать рабочий процесс и сосредотачиваться на выполнении конкретных задач, у каждого сотрудника есть ограниченное количество карточек в работе.

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

4. Постоянное улучшение рабочих процессов. Для оптимизации работы руководитель должен проводить встречи у доски — Канбан-встречи. На них он получает обратную связь от команды и находит решение проблем.

Как работать по Канбан

Основной инструмент работы — это Канбан-доска. Рассмотрим, как с ней работать, на примере системы Аспро.Cloud. В сервисе есть программная платформа (фреймворк) для командной работы по Канбан, который позволяет: 

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

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

Ставить лимиты незавершенных задач (WIP-лимиты). Это помогает концентрировать внимание сотрудников на задачах в работе.

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

Основное отличие гибкой методологии (Agile) от Канбан в том, что в методологии Эджайл люди и взаимодействие ценнее процессов и инструментов. В то время как в Канбан важен инструмент — канбан-доска и налаженные рабочие процессы.

Скрам

Скрам — это гибкий подход в управлении проектами. Цель использования Скрам — постепенное совершенствование продукта путем итерационной разработки. 

Как появилась методология

В разработке ПО термин прижился, потому что Скрам — это всегда про сплоченность и командную игру. Основатели Скрам-подхода — ученые из Японии Хиротаку Такэути и Икудзиро Нонака. Они наблюдали за компаниями Fuji-Xerox, Honda и Canon и заметили, что при командной работе разнопрофильных специалистов получаются самые высокие результаты. На основе этих наблюдений они вместе с Кеном Швабером разработали методологию Скрам. И несмотря на то, что первые идеи были опубликованы еще в конце 1980-х, официальная дата рождения Скрам — 1995 год. 

Спустя еще 15 лет появилась инструкция по использованию методологии — Скрам руководство (Scrum Guide). Со временем информация по применению подхода уточнялась, в новые редакции добавлялись детали.

Основные принципы

1. Кросс-функциональность. Участники команды — специалисты в разных областях. Они могут совместно работать над проектом без привлечения сторонних экспертов.

2. Непрерывное улучшение. В ходе ретроспектив, встреч после завершения каждого спринта, команда обсуждает достижения и провалы. Обзор кейса помогает понять, что и как можно сделать лучше.

3. Прозрачность. Чтобы каждый участник команды понимал, какие задачи стоят перед группой, регулярно проводятся Скрам-встречи. На них, кроме обсуждения списка задач, происходит обмен информацией: результаты завершенных задач, промежуточные успехи. 

4. Итеративная разработка. Вся работа делится на спринты — промежутки времени от недели до пары месяцев. Перед началом спринта команда ставит цели, пересматривает список задач. 

5. Командная работа и общение. Сплоченность сотрудников — условие эффективной работы.

6. Тесное взаимодействие с заказчиком. Клиент регулярно оценивает промежуточный результат, вносит правки. 

Как работать по Скрам 

Если сравнить Скрам — Канбан, внедрение Скрам-подхода требует более тщательной подготовки. Недостаточно использовать только инструменты для командной работы, важно обучить сотрудников и перестроить процессы внутри компании или отдела. Для этого отлично подходит сервис Аспро.Cloud, в котором есть инструменты для работы по программной платформа (фреймворку) Скрам.

Рассмотрим важные элементы внедрения Скрам.

Формирование Скрам-команды и распределение ролей. Каждый сотрудник должен знать свои обязанности. Лучше всего, если команда будет кросс-функциональной. То есть над одним проектом работают эксперты из разных областей, которые совместными усилиями могут закрыть все задачи и не передавать часть дел другим отделам. 

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

Создание спринта. При планировании нужно выбрать задачи из списка задач, обозначить продолжительность периода и частоту встреч. В Аспро.Cloud можно отмечать успешно завершенные задачи и ошибки, чтобы следить за статистикой спринта. 

Проведение стендапов. Ежедневные встречи, а также совещания перед началом и после завершения спринта можно проводить как лично, так и онлайн. В Аспро.Cloud для ежедневных стендапов можно использовать групповой чат, а для встреч по итогам спринта — конструктор ретроспектив. 

Что выбрать — Скрам или Канбан 

Выбор методологии зависит от готовности вашей компании к изменениям, опыта применения Эджайл и сферы деятельности. Рассмотрим факторы, которые могут повлиять на выбор метода.

Скрам отлично подходит для разработки ПО, создания сайтов и творческих проектов. А Канбан хорошо работает практически во всех сферах — в производстве, торговле, цифровой сфере (digital). 

СкрамБан: объединяем Канбан и Скрам

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

• команда проводит долгосрочное планирование на год, полгода и 3 месяца;

• задачи «вытягиваются» из списка задач в потоковом режиме, а не порционно, как в Скрам;

• среди метрик важнее время выполнения задачи и количество закрытых задач, а не трудозатраты;

• участники соблюдают лимиты незавершенной работы (WIP-лимиты), например, разработчик ПО не приступает к работе над новой фичей, пока не закончит то, что уже было начато;

• команда проводит ежедневные стендапы, а также ретроспективы спринтов.

СкрамБан часто используют команды, которые привыкли работать по Скрам, но хотят постепенно перейти на потоковое выполнение задач, как в Канбан. 

В блоге Аспро.Cloud  мы делимся полезными статьями и видеоматериалами о гибких методологиях проектами, чтобы ваша команда смогла выбрать самый эффективный подход к работе.