Agile: Scrum или Kanban — что выбрать для своего проекта?

Agile, Scrum, Kanban относятся к числу наиболее используемых терминов современности. Семейство так называемых гибких методологий управления проектами становится все более востребованным и популярным, ведь по ним можно работать не только в сфере IT. Но в чем суть? 

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

Agile

Agile — обобщающее понятие для ряда разных методик и подходов к управлению проектами, суть которых сводится к ускорению процессов создания продукта. Это достигается благодаря серии коротких циклов (итераций), которые обычно длятся по 2—3 недели. Каждая итерация состоит из этапов, необходимых для прироста функциональности: планирования, анализа требований, проектирования, программирования, тестирования и документирования. После каждой итерации команда выполняет переоценку приоритетов разработки и принимает решение о дальнейшей стратегии, что обеспечивает гибкость процесса. 

В основе Agile лежит манифест гибкой разработки программного обеспечения. Среди основных его принципов следующие: 

• Люди и взаимодействие важнее процессов и инструментов. В основе гибкого процесса лежит коммуникация, поэтому ваша работа не обойдется без регулярных митингов, а также инструментов для управления проектами, таких как JIRA или Redmine.

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

• Сотрудничество с клиентом важнее согласования условий контракта. С заказчиком следует выстраивать партнерские взаимоотношения Win-Win: время = материалы. По контракту разработчику оплачивается его потраченное время.

• Готовность к изменениям важнее следования первоначальному плану. Конечно, в Agile есть план, оценки и прогнозы. Но наличие новых данных или обратной связи от пользователей могут полностью изменить стратегию.

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

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

Scrum

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

Как происходит разработка?

Scrum-разработка состоит из минимального количества компонентов: 3 роли, 3 артефакта и 5 событий с жестко фиксированными итерациями (спринтами) и логикой процесса. Это самоорганизующийся организм, где важен вклад каждого участника команды, поскольку все несут ответственность за конечный продукт. Но давайте по порядку. 

Роли

Роли, которые образуют Scrum-команду:

• Владелец продукта. Он понимает его ценность для бизнеса, является связующим звеном между разработчиками и потребителями/стейкхолдерами, но не отвечает за техническую сторону процесса. Он заинтересован в рациональном использовании ресурсов команды для создания ценного продукта.
• Команда разработки отвечает за реализацию технических задач: анализ, дизайн, программирование, тестирование и т. д. Она формируется в зависимости от потребностей проекта и обычно состоит из дизайнера, тестировщика, маркетолога, контент-менеджера, Back-end и Front-end разработчиков.
• Scrum-мастер выступает посредником между командой и владельцем продукта и помогает им беспрепятственно выполнять работу. Он выстраивает процессы и следит за их реализацией, а любая коммуникация людей вне команды с Scrum-командой проходит через Scrum-мастера.

Артефакты

Артефакт — это то, что создает команда. В Scrum их всего три: бэклог продукта, бэклог спринта и инкремент. Эти элементы присутствуют в каждой команде.

• Бэклог продукта — главные требования по продукту, которые определяет владелец либо менеджер продукта. Это регулярно обновляемый список функций, условий и улучшений, на основании которого формируются задачи для бэклога спринта. Владелец/менеджер продукта меняет в нем приоритеты и поддерживает актуальность, согласно новой информации или изменениям на рынке.
• Бэклог спринта — список задач, которые команда разработчиков определила для реализации в текущем цикле спринта. Перед каждым спринтом проводится его планирование, на котором команда выбирает задачи из бэклога продукта для выполнения в рамках новой итерации. Этот бэклог может меняться по ходу спринта, но достижению главной цели спринта ничего не должно мешать.
• Инкремент — цель спринта, готовый к использованию продукт по его итогам. Критерии готовности продукта команда определяет самостоятельно.

Мероприятия

Всю методологию Scrum можно разделить на 5 процессов:

1. Перед началом спринта проводится встреча Sprint Planning Meeting, где ставятся цели и разрабатывается план их достижения — бэклог спринта. Он должен быть четким, а главное — осуществимым.
2. Ежедневный Scrum. Это 15-минутный стендап, на котором члены команды синхронизируют свои действия: что было сделано, с какими трудностями столкнулись и какие действия планируются дальше.
3. Спринт. Чем он короче, тем более гибкий процесс разработки. Спринт может длиться от недели до четырех, но чаще всего команды работают по двухнедельным итерациям.
4. Sprint Review. Это встреча команды и заказчика для демонстрации инкремента, который был сделан за спринт для определения дальнейших доработок.
5. Ретроспектива. Встреча, на которой оценивается прошедший спринт с точки зрения организации процессов, работа над улучшениями.

Kanban

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

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

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

В Kanban не принято делать оценку «скорости работы команды», считается среднее время на выполнение задачи: 

Cycle Time = время выполнения задачи – время начала работы над задачей

Важно соблюдать WIP (Work in Progress) — принцип ограничения количества задач, которые одновременно находятся в работе. Это помогает избежать мультизадачности и ее негативного воздействия на эффективность. Чем меньше WIP, тем быстрее задачи проходят цепочку и закрываются, тем выше скорость работы. Поэтому у каждой задачи должен быть понятный индикатор завершенности.

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

Какую методологию выбрать?

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

Scrum удобен для линейного метода управления и сработанных команд (7—9 человек). Он более показателен для заказчика, так как позволяет отслеживать успеваемость. Работа делится на спринты, и только опытная команда может определить оптимальное количество задач в этих спринтах. Обязательный элемент — регулярные встречи для синхронизации процессов всех членов команды. Временная рамка для выполнения поставленных задач весьма относительна, главное — это результат. Обратная связь осуществляется по завершении каждого спринта, а на основании полученной информации происходит разработка улучшений.

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