Scrum: что это такое и как работает agile методология
Scrum — это фреймворк для гибкой разработки программного обеспечения, где работа делится на короткие итерации-спринты длиной 1-4 недели. По данным State of Agile 2023, 87% компаний, применяющих Agile-практики, используют именно Scrum. Команда работает с фиксированным набором задач, каждую итерацию выдаёт работающий продукт и корректирует курс на основе обратной связи.
Последнее обновление: март 2026
Что такое Scrum: суть методологии
Scrum — это не процесс и не технология. Это фреймворк: набор правил, ролей и событий, внутри которых команда сама решает, как именно делать работу. Главная идея — не планировать всё на полгода вперёд, а двигаться итерациями и постоянно сверяться с реальностью.
Появился Scrum в 1990-х у Джеффа Сазерленда и Кена Швабера как ответ на провалы waterfall-разработки. Классический каскадный подход требовал месяцев планирования, а продукт заказчик видел только в конце — когда менять что-то было уже дорого. Scrum перевернул схему: заказчик участвует на каждом этапе, а команда адаптируется к изменениям, а не сопротивляется им.
Сегодня Scrum применяется не только в IT. Маркетинговые команды, HR, финансовые департаменты — всюду, где есть сложные проекты с меняющимися требованиями, Scrum даёт результат быстрее и предсказуемее.
Agile и Scrum: в чём разница?
Частый вопрос: Agile методология и Scrum — это одно и то же? Нет. Agile — это философия, набор ценностей из Манифеста 2001 года. Scrum — один из конкретных способов реализовать эту философию на практике. Кроме Scrum существуют Kanban, SAFe, XP и другие фреймворки. Scrum просто самый популярный.
Если аналогия помогает: Agile — это конституция, а Scrum — один из законов, написанных в её духе.
Три роли в Scrum: кто за что отвечает
В Scrum всего три официальные роли. Никаких «аналитиков», «архитекторов» и «тестировщиков» в Scrum Guide нет — это внутренние специализации внутри команды, не роли.
Product Owner: что это за роль
Product Owner (Владелец продукта) — единственный человек, который отвечает за то, что команда делает в правильном порядке. Его задача — поддерживать бэклог продукта: упорядоченный список всего, что нужно сделать, с объяснением ценности каждого пункта.
Product Owner — не менеджер проекта и не аналитик. Он принимает финальное решение о приоритетах. Если продакт говорит «сначала делаем авторизацию», команда делает авторизацию — даже если разработчик считает, что важнее сначала отладить базу данных. Это его зона ответственности.
Scrum Master: фасилитатор и страж процесса
Scrum Master не управляет командой и не раздаёт задачи. Его задача — убирать препятствия, которые мешают команде работать продуктивно, и следить за тем, что Scrum применяется правильно.
Хороший Scrum Master тихо и методично разрешает конфликты, договаривается со смежными отделами о зависимостях, помогает команде провести ретроспективу честно, а не формально. Без него команды часто скатываются в «Scrum на словах, хаос на деле».
Команда разработки: самоорганизация как принцип
Команда в Scrum — кроссфункциональная (5-9 человек) и самоорганизующаяся. Никто не говорит ей, как делать работу. Она сама решает, как декомпозировать задачи, кто что делает и как проверять качество. Это убирает лишнее согласование и ускоряет работу.
В DEVRUM такой подход позволяет выпускать рабочие фичи каждые 2 недели — без полугодовых согласований с заказчиком «на берегу».
Как работает Scrum методология: спринты и события
Scrum строится вокруг спринта — фиксированного по времени периода работы. Обычно это 2 недели. Внутри каждого спринта четыре события:
Sprint Planning: планирование спринта
В начале спринта команда берёт задачи из бэклога продукта и формирует бэклог спринта — конкретный план на 2 недели. Команда сама оценивает объём работы (в story points или часах) и берёт ровно столько, сколько реально выполнить. Никто не спускает план сверху.
Daily Scrum: ежедневный стендап
15 минут каждое утро. Три вопроса: что сделал вчера, что сделаю сегодня, что мешает. Не отчёт менеджеру — синхронизация команды. Если обсуждение затягивается, тему выносят за рамки стендапа и решают отдельно.
Sprint Review: демонстрация результатов
В конце спринта команда показывает заказчику работающий продукт. Не презентацию, не слайды — рабочую функциональность. Заказчик смотрит, даёт обратную связь, корректирует приоритеты бэклога. Это ключевой момент Scrum: заказчик влияет на продукт непрерывно, а не только в момент подписания ТЗ.
Ретроспектива: улучшение процесса
После ревью команда собирается и честно разбирает: что шло хорошо, что нет, что изменить в следующем спринте. Конкретные действия — не абстрактные пожелания. Хорошая ретроспектива каждые 2 недели делает команду лучше за год больше, чем любой тренинг.
Бэклог продукта: основной инструмент управления
Бэклог продукта — живой документ. Это не фиксированное ТЗ и не техзадание. В нём хранятся все задачи, идеи и улучшения, отсортированные по приоритету. Product Owner обновляет его после каждого ревью, убирая выполненное и добавляя новое.
Бэклог продукта никогда не заканчивается — пока продукт живёт, в нём есть задачи. Это нормально. Задача не в том, чтобы выполнить всё, а в том, чтобы всегда делать самое ценное.
Scrum vs Kanban: когда что выбирать?
Оба — Agile-фреймворки, но для разных ситуаций.
| Критерий | Scrum | Kanban |
|---|---|---|
| Тип работы | Продуктовая разработка | Поддержка, операционные задачи |
| Итерации | Фиксированные спринты | Непрерывный поток |
| Роли | PO, SM, команда | Нет обязательных ролей |
| Планирование | На спринт | По мере готовности |
| Метрика | Velocity (скорость команды) | Cycle time (время выполнения) |
Если у вас продукт с регулярными релизами и активный заказчик — Scrum. Если поддержка сервиса с непредсказуемыми тикетами — Kanban. В DEVRUM мы используем Scrum для продуктовых проектов и Kanban для сопровождения готовых систем.
Scrum в DEVRUM: как мы работаем с заказчиками
Когда клиент приходит с идеей нового приложения или системы, мы не пишем ТЗ на 40 страниц. Мы проводим discovery-сессию, формируем первоначальный бэклог и запускаем первый спринт в течение 1-2 недель после старта.
Каждые 2 недели заказчик видит работающий продукт и влияет на приоритеты. За 3-4 месяца вместо полугода согласований появляется реальный MVP. Такой подход особенно хорошо работает для разработки мобильных приложений и внедрения ERP-систем, где требования постоянно уточняются по ходу работы.
Мы работаем командами 3-7 человек. Стоимость разработки по Scrum — от 2 500 руб./час за специалиста. Первый спринт (2 недели) обычно обходится в 80 000-150 000 руб. в зависимости от сложности задач.
Часто задаваемые вопросы о Scrum
Product Owner это кто? Владелец продукта — человек, который принимает решения о приоритетах задач. Обычно это представитель бизнеса или заказчика, который знает, что именно нужно рынку и пользователям.
Сколько длится спринт в Scrum? Стандарт — 2 недели, допускается от 1 до 4. Большинство команд выбирают 2 недели как баланс между скоростью обратной связи и достаточным временем для значимых задач.
Нужен ли Scrum Master в маленькой команде? В команде до 4 человек роль Scrum Master часто совмещает один из разработчиков или техлид. Главное — чтобы кто-то отвечал за соблюдение процесса и убирал препятствия.
Чем Scrum отличается от Agile? Agile — это ценности и принципы (Манифест 2001). Scrum — конкретный фреймворк для реализации этих принципов. Scrum — один из способов «жить по Agile».
Можно ли применять Scrum в не-IT проектах? Да. Маркетинг, HR, финансы, строительство — Scrum работает везде, где есть сложные проекты с меняющимися требованиями и важна быстрая обратная связь.
Хотите запустить разработку по Scrum? Расскажите о вашем проекте — составим бэклог и запустим первый спринт уже через неделю.