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

Что такое Agile

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

Само слово Agile переводится с английского как «гибкий, быстрый, подвижный», и именно эти качества ставятся во главу угла. Проект выполняется короткими циклами, и приоритет отдаётся скорости, адаптации и сотрудничеству, а не следованию установленному плану и управлению сверху вниз.

Такой подход лучше всего работает в проектах, где нет полной ясности во всех деталях; в отраслях, которые имеют дело с постоянными изменениями; в командах, где создаются новые продукты.

Основа подхода Agile – Agile-манифест, сформулированный в 2001 группой разработчиков, в котором обозначены четыре базовые ценности:

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

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

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

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

Поэтому принципы Agile поощряют непрерывную поставку функционирующего программного обеспечения и тесную связь между командами, чтобы постоянно получать отклик пользователей и вносить все нужные изменения. Таким образом, гибкая разработка программного обеспечения – это не метод, а, скорее, набор методов и фреймворков, которые следуют этим принципам. Можно сказать, что Agile – это основа для стиля мышления и принятия решений.

Что такое Scrum

Scrum – это один из методов для воплощения Agile; самый популярный фреймворк этого подхода. Термин заимствован из регби, где scrum (в русской терминологии – «схватка») представляет собой построение игроков и предполагает командную работу.

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

Работа поэтапная, и каждый этап зависит от предыдущего. Цель каждого спринта – выполнить запланированную задачу. Бывает и так, что не всё удаётся реализовать; тогда то, что не сделано, переносится на следующий спринт. В конце каждого спринта команда предоставляет заказчику результаты работы, чтобы клиент получил какую-то готовую ценность и мог предоставить фидбэк.

Длительность спринта определяется в начале проекта и не меняется до его завершения. Чем короче этап, тем проще вносить изменения в случае необходимости, потому что во время самого спринта корректировки нежелательны. Однако срок в 1-2 недели подходит не для всех команд: оптимальная продолжительность спринта зависит от общего расписания проекта, количества задач, количества человек в команде и т. д.

Что касается количества людей, то scrum-команды обычно небольшие – 3-9 человек. БОльшее число не позволит продуктивно работать и сотрудничать друг с другом в рамках scrum. Как сформулировал некогда это правило Джефф Безос: в команде должно быть столько сотрудников, чтобы их можно было накормить двумя пиццами.

Три роли в scrum-команде:

  • владелец продукта – по сути, голос заказчика; человек, ответственный за направление проекта, который ставит цели и задачи и определяет приоритеты. Он же ведёт бэклог продукта – список того, что должно быть сделано для завершения и улучшения продукта.
  • scrum-мастер – человек, который координирует работу команды, отвечает за её эффективность и за выполнение всех этапов scrum.
  • команда разработки — самоорганизующаяся и кросс-функциональная. Это означает, что её участники сами решают, кто, что, когда и как делает, а также обладают всеми навыками, необходимыми для выполнения задачи каждого спринта.

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

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

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

Agile vs Scrum

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

Отличительные особенности Scrum:

  • наличие спринтов определённой длины;
  • наличие бэклога продукта и бэклога спринта;
  • наличие ролей – владельца продукта, scrum-мастера и команды;
  • наличие регламентированных встреч: планирования спринта, ежедневных собраний, обзора и ретроспективы спринта.

Что такое Kanban

Метод Kanban изобрели не разработчики ПО – он берёт своё начало в производственных процессах компании Toyota. Само слово по-японски означает «вывеска, таблица, доска». Суть Kanban – в визуализации задач с помощью доски, реальной или виртуальной.

Доска разделена на столбцы, которые представляют собой разные этапы проекта. Карточки или стикеры с задачами перемещаются по столбцам, пока вся работа не будет выполнена. Самый простой пример – этапы/столбцы Сделать → Делается → Готово. Задача добавляется в «Сделать», затем, когда её берут в разработку, переходит в «Делается» и в итоге оказывается в «Готово».

На практике количество этапов/столбцов может быть больше, например: Бэклог → Разработка спецификации → Готово к разработке → Разработка → Проверка кода → Тестирование → Развёрнуто (→ Никто на самом деле не использует → Удалено).

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

Таким образом, в Kanban нет строгих процедур или ролей, как в Scrum; меньше внимания уделяется фиксированным срокам, и проект представляет собой единый непрерывный поток.

Поскольку цель Kanban – визуализация, его можно делать вообще без доски. Например, можно вести простой список задач в документе Google и отмечать этапы (состояние задачи) разными цветами фона. Можно рисовать диаграммы Ганта, составлять таблицы. В конце концов, в офисе можно даже завести несколько корзин (каждая будет представлять этап), и закидывать мяч (олицетворяющий задачу) в нужную корзину. Годится всё, что позволяет визуализировать рабочий процесс и обеспечивать прозрачность работы для всех участников.

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

Ещё одна важная роль Kanban – регулировать объём задач. Проще говоря – помогать команде избегать многозадачности. Это означает установку ограничений на количество задач в один момент времени. Например, команда ограничивает число карточек в столбцах активной работы до трёх или пяти. Когда в столбце оказываются 3-5 карточек, в него уже нельзя помещать новых задач, пока предыдущие карточки не перейдут в следующий столбец.

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

Scrum vs Kanban

Поскольку и Scrum, и Kanban – методы Agile, у них много общего: оба предполагают быструю адаптацию к изменениям, оба призваны оптимизировать скорость и прозрачность работы, оба ориентированы на заказчика и продукт.

Но немало и различий. В Scrum есть опредёленные роли, а в Kanban сохраняются текущие роли и обязанности. Scrum предполагает новый способ работы, а Kanban можно применять сразу, в текущем процессе. В Scrum этапы разработки разбиты на спринты в 2-4 недели, во время которых идёт работа над фиксированными задачами, а в Kanban новые задачи можно ставить хоть каждый день. Scrum – это чёткий график событий (встречи, обзоры, ретроспективы), в Kanban запланированных событий нет.

Kanban проще внедрить, поскольку не требует значительных изменений – как в процессах, так и в культуре работы. Scrum, с другой стороны, предлагает значительно больше структур для управления процессом. Поэтому не стоит ставить вопрос: «Что лучше – «Scrum или Kanban?» Лучше спросить: «Что лучше использовать в конкретном проекте и с конкретной командой?» Тем более что Scrum и Kanban вовсе не исключают друг друга. В некоторых компаниях используется гибридная концепция – Scrumban, которая берёт нужное от обоих методов. Поэтому ничто не мешает выбрать лучшие элементы – внедрить ежедневные встречи, использовать канбан-доску и т. д.

В заключение

Кто-то считает, что Kanban – это хороший путь в Agile, и что после внедрения Kanban будет легче внедрить Scrum. Другие утверждают, что использование Scrum логически ведёт к использованию Kanban.

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

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