Agile и Scrum: в чем разница и как использовать

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

Чтобы этого избежать, нужно понимать разницу между Agile и Scrum.

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

Они не конкурируют друг с другом. Scrum можно использовать как один из способов реализации принципов Agile. Но не каждой команде нужен именно Scrum.

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

Что такое Agile

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

Его основы сформулированы в Agile-манифесте 2001 года. Документ описывает четыре ключевых ценностных приоритета:

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

При этом Agile не отрицает пользу документации, договоров или планирования. Речь идет о выборе приоритетов, когда между ними возникает противоречие.

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

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

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

Принципы Agile на практике

Помимо четырех ценностей, манифест содержит 12 принципов Agile.

Для управления продуктом особенно важны следующие:

• Ранняя и регулярная поставка ценности. Пользователи получают полезный результат, не дожидаясь завершения всей разработки.
• Готовность к изменению требований. Новые обстоятельства учитываются даже на поздних этапах работы.
• Постоянное взаимодействие бизнеса и команды. Решения не должны приниматься изолированно от потребностей заказчика.
• Устойчивый темп. Работа организуется так, чтобы команда могла поддерживать качество и производительность длительное время.
• Техническое совершенство. Внимание к качеству продукта помогает сохранять возможность дальнейших изменений.
• Регулярное улучшение работы. Команда анализирует собственную эффективность и меняет способы взаимодействия.

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

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

Подробнее об особенностях подхода рассказано в статье Agile: метод управления проектами.

Что такое Scrum

Scrum (скрам) - легкий фреймворк для решения сложных задач и создания ценности.

Его правила описаны в Руководстве по Scrum 2020 года, подготовленном Кеном Швабером и Джеффом Сазерлендом.

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

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

При этом команда самостоятельно выбирает конкретные способы выполнения задач.

Три основы Scrum: прозрачность, инспекция и адаптация

Работа Scrum строится на эмпирическом подходе: решения принимаются на основании опыта и наблюдаемых результатов.

У него три опоры.

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

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

Адаптация. Полученные знания используются для изменения планов, продукта или способов работы.

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

Инспекция помогает обнаружить проблему. Адаптация - изменить приоритеты и переработать неудобный этап вместо продолжения работы по первоначальному плану.

Без последующих изменений проверка результатов превращается в формальность.

Как устроена Scrum-команда

Согласно руководству 2020 года, в Scrum существуют три зоны ответственности.

Владелец продукта

Владелец продукта отвечает за максимизацию ценности, создаваемой командой.

Он:

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

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

Scrum-мастер

Scrum-мастер отвечает за правильное понимание и применение Scrum и помогает повышать эффективность команды.

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

Scrum-мастер не является начальником разработчиков и не должен распределять между ними задания.

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

Разработчики

Разработчики - участники Scrum-команды, непосредственно создающие пригодный к использованию результат.

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

Разработчики отвечают за план спринта, качество результата и ежедневную адаптацию работы для достижения цели спринта.

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

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

События Scrum: как организована работа

В Scrum определены пять событий. Центральное из них - спринт, внутри которого проходят остальные четыре.

Спринт

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

Новый спринт начинается сразу после завершения предыдущего.

Планирование спринта

Команда совместно определяет:

• Почему предстоящий спринт ценен.
• Что можно выполнить за выбранный период.
• Как будет организована работа.

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

Ежедневный Scrum

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

Это не отчет руководителю. Разработчики сами выбирают формат обсуждения.

Обзор спринта

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

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

Ретроспектива спринта

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

Ретроспектива завершает спринт.

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

Можно ли менять задачи в ходе спринта?

Да. Это один из наиболее неправильно понимаемых моментов Scrum.

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

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

Если сама цель спринта потеряла актуальность, владелец продукта может отменить спринт.

Артефакты Scrum: что помогает управлять результатом

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

Артефакт	Что представляет собой	Связанное обязательство
Список задач продукта	Упорядоченный, постоянно обновляемый перечень того, что нужно для улучшения продукта	Цель продукта
Список задач спринта	Цель спринта, выбранные элементы и план их выполнения	Цель спринта
Инкремент	Пригодный к использованию результат, дополняющий уже созданный продукт	Определение готовности

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

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

Это условный пример. Конкретные требования зависят от продукта и стандартов организации.

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

При этом за один спринт можно создать несколько инкрементов. Они могут быть предоставлены пользователям до окончания спринта - ждать обзора для выпуска необязательно.

Agile и Scrum: в чем главная разница

Критерий	Agile	Scrum
Что представляет собой	Ценности и принципы гибкой разработки	Легкий фреймворк для создания ценности при решении сложных задач
Что определяет	Приоритеты и общий подход к работе	Зоны ответственности, события, артефакты и правила
Состав команды	Не устанавливает обязательных ролей	Владелец продукта, Scrum-мастер и разработчики
Организация работы	Не предписывает единую схему	Работа организована последовательными спринтами
Длительность циклов	Не устанавливает обязательных ограничений	Спринт продолжается не более месяца
Управление изменениями	Поощряет готовность учитывать новую информацию	Позволяет пересматривать работу, сохраняя цель спринта
Оценка результата	Ориентация на полезный работающий продукт	Проверка инкремента, прогресса к целям и способов работы

Главное различие не в том, что Agile более гибкий, а Scrum более строгий.

Agile формулирует ценности и принципы. Scrum предлагает конкретную организационную структуру, которая помогает применять эмпирический подход на практике.

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

Когда подходит Scrum, а когда лучше использовать другой подход

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

Например:

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

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

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

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

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

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

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

Пример применения Scrum

Рассмотрим условную ситуацию.

Компания развивает сервис онлайн-записи на занятия. Пользователи могут выбрать время, но для переноса записи вынуждены обращаться к администратору.

Владелец продукта определяет цель: дать пользователям возможность самостоятельно переносить занятия.

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

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

Разработчики определяют необходимые действия: изменение интерфейса, обработка свободных интервалов, сохранение новых данных, проверка ограничений и тестирование.

В течение спринта они регулярно проверяют продвижение к цели и уточняют план.

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

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

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

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

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

Ошибки при использовании Agile и Scrum

Scrum превращают в систему контроля сотрудников

Руководитель проводит ежедневные совещания, раздает поручения и требует отчеты.

Внешне процесс напоминает Scrum, но команда лишена возможности самостоятельно планировать работу.

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

Считают выполненные задачи главным результатом

Команда завершила все пункты плана, но новая функция оказалась неудобной для пользователей.

Формально задачи закрыты. Однако это не доказывает, что продукт стал полезнее.

Поэтому важно оценивать не только объем выполненной работы, но и качество инкремента, продвижение к цели продукта и полученную обратную связь.

Подменяют цель спринта перечнем задач

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

Цель спринта помогает сохранять направление и одновременно оставляет возможность корректировать конкретные действия.

Используют только отдельные элементы Scrum

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

Отдельные практики могут приносить пользу. Однако, согласно Scrum Guide, использование части элементов не означает применения Scrum как целостного фреймворка.

Если компании нужна только доска задач и короткие регулярные встречи, не обязательно называть это Scrum.

Как начать применять Scrum в компании

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

1. Определить продукт и его цель.

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

2. Обеспечить необходимые зоны ответственности.

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

3. Сформировать список задач продукта.

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

4. Согласовать определение готовности.

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

5. Выбрать продолжительность спринта.

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

6. Организовать события Scrum.

Планирование, ежедневный Scrum, обзор и ретроспектива должны выполнять свои задачи, а не становиться дополнительной отчетностью.

7. Проверять ценность и улучшать работу.

После каждого спринта нужно анализировать созданный инкремент, продвижение к цели продукта и эффективность взаимодействия команды.

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

Какие инструменты нужны для работы

Для организации работы команде полезно иметь общее пространство, где видны задачи, их состояние и необходимые материалы.

Например, инструмент "Задачи" в Platrum позволяет вести работу на канбан-досках, назначать исполнителей, фиксировать сроки и обсуждать задачи.

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

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

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

Что в итоге выбрать

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

Затем необходимо оценить характер работы.

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

Если задачи поступают непрерывно и требуют частого изменения приоритетов, разумнее рассмотреть управление потоком работ.

А если компании достаточно прозрачного учета поручений, не нужно вводить весь Scrum только ради использования знакомого названия.

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

Также читайте: Как внедрить культуру continuous improvement (кайзен) в команде