Agile или Scrum: в чём разница и что выбирать

Это два разных уровня

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

Scrum описан отдельным руководством, у которого есть авторы — Кен Швабер и Джефф Сазерленд — и есть редакции. Последняя вышла в 2020 году. Там уже конкретика: три ответственности, пять событий, три артефакта с обязательствами к каждому.

Хронология тоже мешает считать их развилкой. Scrum появился раньше манифеста: его представили на конференции в 1995 году. Слово Agile в 2001-м потребовалось как раз для того, чтобы назвать общее у Scrum и нескольких соседних подходов.

Что даёт Agile сам по себе

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

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

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

Что Scrum добавляет сверху

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

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

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

Где проходит настоящая развилка

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

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

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

Как вопрос звучит на практике

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

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

В разговоре с заказчиком «мы работаем по Agile» звучит как обещание гибкости и часто читается как «сроки и объём не фиксируются». Здесь помогает конкретика: длина цикла, что показываем в конце, как меняется содержание и что при этом происходит с бюджетом.

Что с чем сравнивать

Проверка: вы выбираете правила, а не лозунг

Разговор про Agile становится предметным, когда в нём появляются проверяемые пункты. Пройдитесь по списку до того, как объявлять переход.

Как собрать процесс в Shtab

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

Частые вопросы