Но философия не дает пошаговых инструкций. Именно поэтому бизнесу понадобились конкретные правила работы (фреймворки). В этой статье мы по косточкам разберем методологию Scrum — самый популярный в мире способ превратить абстрактный Agile в работающий и предсказуемый конвейер по выпуску продукта.
- Раздел 1. Введение в Scrum: что это и зачем нужно
- Раздел 2. Люди: кто есть кто в скрам-команде
- Раздел 3. Механика: как проходит спринт
- Раздел 4. Артефакты, оценки и термины
- Раздел 5. Практика внедрения: от учебника к реалиям
Раздел 1. Введение в Scrum: что это и зачем нужно
Что такое Scrum простыми словами?
Scrum (Скрам) — это самый популярный фреймворк (набор правил) гибкой разработки. Суть в следующем: вся работа жестко рубится на равные короткие отрезки времени (спринты). В начале каждого такого отрезка команда берет понятный кусок работы, делает его, а в конце — показывает заказчику готовый и работающий элемент продукта.
Простыми словами, вы не выполняете огромный проект сразу и полностью, а «едите слона по кусочкам», стараясь получить на каждом этапе относительно законченный продукт.
Как работает Scrum в общих чертах?
Жизненный цикл продукта в методе Scrum выглядит как зацикленный конвейер:
- Заказчик выписывает все свои пожелания в один длинный список (бэклог).
- Команда изучает этот список вместе с заказчиком и набирает себе задач, например, на две недели вперед (это будет их спринт).
- Две недели разработчики выполняют задачи, каждый день собираясь на 15 минут, чтобы синхронизироваться друг с другом.
- В последний день команда показывает заказчику то, что получилось.
- После этого команда проводит ретроспективу: обсуждает возникшие во время спринта проблемы и улучшает процессы.
- Затем стартует новый спринт, и все повторяется.
Зачем это нужно? В чем плюсы Скрама?
Главные преимущества Scrum заключаются в высокой гибкости: вы быстро получаете обратную связь и можете оперативно корректировать как планы, так и процессы. Если рынок изменился или какие-то функции оказались неудачными, управление проектами по Scrum позволяет поменять курс всего за один спринт, сэкономив миллионы на ненужной разработке.
Еще один профит для бизнеса — возможность быстрых, регулярных и предсказуемых релизов. Не нужно ждать целый год, чтобы выпустить продукт на рынок: можно выпустить базовую версию уже через месяц, а затем каждые две недели выкатывать обновления.
Для каких проектов подходит Скрам, а для каких не подходит?
Scrum используется там, где требования постоянно меняются, а конечный результат заранее неясен. Это почти вся современная цифровая индустрия: разработка ПО, создание сайтов и онлайн-сервисов, дизайн, маркетинговые проекты.
Скрам не подходит:
- Для конвейерного производства, когда однотипные задачи поступают непрерывным потоком (например: техподдержка, сбор заказов на складе, выпуск однотипных изделий). Здесь лучше использовать канбан.
- Для проектов, где последовательность шагов жестко задана и не меняется, например, в строительстве. Здесь лучше классический Waterfall («водопад»): полное планирование в начале и реализация строго по плану.
Чем отличается Scrum от Kanban?
Методы Канбан и Скрам имеют кардинальные отличия, хотя оба «лежат под зонтиком Agile». Скрам работает отрезками времени (спринтами) и хорошо подходит для проектов, где создается что-то уникальное, а требования могут меняться по ходу дела.
Канбан, напротив, управляет непрерывным потоком задач, зачастую однотипных. Работа строится на доске с колонками-этапами (от «Сделать» до «Готово»), где жесткие лимиты для каждого этапа помогают избежать хаоса и перегрузки. Канбан больше подходит для техподдержки или системных администраторов, где задачи сыплются постоянно.
💡 Не смешивайте Скрам и Канбан на одной доске — это приведет к хаосу. Это разные типы задач, подразумевающие разную скорость работы команд и разные критерии выполнения.
Раздел 2. Люди: кто есть кто в скрам-команде
Из кого состоит скрам-команда?
Скрам-команда — это небольшая, кросс-функциональная и самоуправляемая группа людей (обычно до 10 человек). В Scrum есть три ключевых роли:
- владелец продукта (Product Owner);
- скрам-мастер (Scrum Master);
- команда разработчиков.
Владелец продукта (Product Owner) — это просто заказчик?
Владелец продукта в Scrum — это представитель бизнеса и клиентов. Это человек, который точно знает, ЧТО делать. Он управляет списком задач, расставляет приоритеты и принимает решения о том, какую функцию пилить первой, а от какой отказаться.
💡 В заказной разработке иногда бывает так, что от клиента выступает несколько человек (например, совет директоров), и у каждого свои требования. В Скраме несколько Владельцев продукта — это катастрофа. В этом случае вам нужен «Proxy-Product-Owner» на вашей стороне (например, сильный менеджер), который будет собирать всю обратную связь в кучу, разрешать конфликты и выдавать команде единое видение.
Скрам-мастер: кто это и что он делает?
Скрам-мастер — это не начальник, а «служащий лидер» и фасилитатор (организатор обсуждений). Он отвечает за то, чтобы команда правильно понимала и применяла правила Скрама.
Что делает скрам-мастер в команде:
- Помогает устранять препятствия (буквально, если у программиста сломался стул или нет доступов — Скрам-мастер идет это решать).
- Следит за тем, чтобы митинги не затягивались и приносили пользу.
- Защищает разработчиков от бизнес-заказчиков, которые пытаются впихнуть новые задачи в середине спринта.
💡 Владелец продукта и скрам-мастер — это роли-антагонисты, поэтому их нельзя совмещать в одном лице. Первый всегда хочет «больше и быстрее», второй — защищает команду, процессы и стабильность.
Чем занимается Команда разработчиков (Developers)?
Это те люди, которые делают продукт руками. В команду Scrum входят не только программисты и тестировщики, но и другие специалисты: дизайнеры, UX-специалисты, технические писатели. Их главная задача — решить, КАК ИМЕННО они реализуют те идеи, которые принес Владелец продукта. Команда обычно организует свою работу сама: никто извне не указывает разработчику, как ему писать код.
А куда делся классический менеджер проекта?
В идеальном «коробочном» Скраме такой роли действительно нет — предполагается, что его функции растворяются между скрам-мастером, PO и разработчиками.
Но в реальной жизни зачастую все иначе: менеджер проекта в Scrum никуда не исчезает. Он берет на себя все то, что не делает никто другой: организует процессы, сшивает старые и новые подходы, воюет с бюрократией компании и заменяет собой Владельца продукта, если тот занят. Когда команда станет по-настоящему зрелой, его функции могут эволюционировать, и тогда он переквалифицируется в чистого скрам-мастера или аналитика.
Раздел 3. Механика: как проходит спринт
Что такое церемонии в Scrum?
Церемонии (или Scrum-мероприятия) — это ритмичные шаги, из которых состоит цикл разработки в Scrum: планирование спринта, ежедневные стендапы, обзор итогов и ретроспектива. Ниже — подробно о каждом из них.
Что такое спринт в Scrum и сколько он должен длиться?
Спринт в Scrum — это сердце фреймворка, тот самый фиксированный отрезок времени, за который команда должна выдать готовый кусок продукта. Продолжительность спринта в разных командах может варьироваться от 1 недели до 1 месяца.
💡 Практика показывает, что для большинства случаев оптимальный срок спринта — 2 недели. Недельные спринты создают слишком большую нагрузку, а месячные спринты затягивают получение обратной связи.
С чего все начинается?
Все начинается с планирования спринта. Команда встречается с Владельцем продукта, смотрит в список задач и отбирает для спринта столько идей, сколько успеет сделать. Обязательно фиксируется глобальная цель спринта, например, «сделать регистрацию и личный кабинет».
💡 При планировании спринта всегда оставляйте буфер: не забивайте расписание на 100%. Около 20% времени нужно закладывать на баги, долгие код-ревью и непредвиденные проблемы.
Что такое ежедневные встречи (Daily Scrum) и зачем они нужны?
Каждый день утром команда собирается вместе на 15 минут — это называется скрам-митинг (Daily). Его цель — синхронизировать работу команды. Каждый член команды отвечает на 3 вопроса: что он делал вчера, что он будет делать сегодня, какие есть проблемы.
💡 Лучше не просто рассказывать, а показывать все прямо на экране. Это и понятнее, и повышает вовлеченность участников.
Как демонстрируют результаты спринта?
В конце спринта команда проводит обзор итогов (Sprint Review) — демонстрацию готового инкремента заказчику и стейкхолдерам. Это не финальная приемка, а часть цикла «обратная связь — адаптация». Увиденное напрямую влияет на план следующих спринтов: Владелец продукта обновляет бэклог, отталкиваясь от того, что увидел и услышал на обзоре, а не от собственных догадок.
💡 Проводите демонстрации во время реальной встречи или по видеосвязи. Не отправляйте макеты и отчеты по электронной почте: клиент останется один на один со своими вопросами и придумает себе худшие ответы.
Зачем нужна ретроспектива в Scrum и как она проводится?
После демонстрации, когда заказчики ушли, команда остается одна. Начинается скрам-ретроспектива. Если на Обзоре с заказчиками обсуждают продукт, то на Ретро — обсуждают себя и процессы. Как прошел спринт? Что пошло не так? Что можно улучшить?
Главное правило ретроспективы — безопасность. Если участники боятся (наказаний, насмешек, осуждения), они не будут говорить о реальных проблемах. Цель ретроспективы — улучшить процессы, а не найти крайних.
💡 Результатом Ретро должны стать не декларации («нужно работать лучше»), а конкретные наблюдаемые улучшения (например, чек-лист), внедрение которых можно увидеть или проверить.
Раздел 4. Артефакты, оценки и термины
Что такое артефакты в Scrum?
Артефакты — это объекты, в которых фиксируется работа и её результат: бэклог продукта, бэклог спринта и инкремент. Они делают ход разработки прозрачным для всех участников и отвечают на вопросы:
- Что мы хотим сделать вообще? (бэклог продукта)
- Что делаем прямо сейчас? (бэклог спринта)
- Что уже готово? (инкремент)
Что такое бэклог в Scrum и как им управлять?
Бэклог в скрам (Product Backlog) — это тот самый список всех-всех «хотелок», требований и багов продукта. Вверху находятся самые приоритетные и детально проработанные задачи, готовые к спринту. Чем ниже, тем задачи туманнее — это планы на отдаленное будущее. Бэклог не статичен: он постоянно меняется и уточняется на основе обратной связи от пользователей и бизнеса.
💡 Регулярно причесывайте и чистите бэклог, удаляйте задачи, до которых годами не доходят руки. Если идея реально важна, она всплывет снова.
Для управления бэклогом необходимо расставлять приоритеты: что делать в первую очередь, что во вторую, а что можно пока не делать совсем. Для этого используются специальные техники (MoSCoW, ICE, RICE, Kano), о которых мы подробно рассказываем в нашем гайде по приоритизации бэклога.
💡 Если бэклог превратился в бесконечную стену задач, примените Story Mapping. Разложите пользовательские сценарии по горизонтали (поиск -> выбор -> корзина -> оплата), а по вертикали добавляйте детализацию. Так вы увидите скелет продукта и сможете легко планировать спринты, определяя минимум, необходимый для запуска.
А что такое бэклог спринта?
Если бэклог продукта — это бесконечный список желаний, то бэклог спринта (Sprint Backlog) — это жесткий план на ближайшие две недели. Это тот самый кусок важных задач, который разработчики отобрали на сессии планирования.
Главное правило Скрама: как только задачи попали в бэклог спринта, они словно «замораживаются». Никто, даже генеральный директор или Владелец продукта, не имеет права впихивать в этот список новые задачи, пока не закончился спринт — именно так команда сохраняет фокус и защищается от хаоса. Если что-то экстренно требует внимания, это обсуждается, но только ценой вытеснения равной по объему задачи из текущего спринта.
Что такое Инкремент в Scrum и что такое критерии готовности (DoD)?
Инкремент в скраме — это готовый продукт или его осязаемый рабочий кусок, созданный к концу спринта. С ним связано еще одно важное понятие — DoD (Definition of Done, критерии готовности). В Скраме не бывает задач уровня «ну, код написан, осталось только задеплоить». Если в DoD прописано, что задача должна быть протестирована, задокументирована и залита на сервер, значит, инкремент сдан только тогда, когда выполнены ВСЕ эти условия.
💡 Хорошая практика: разработчик и тестировщик сразу после планирования спринта составляют к задачам маленькие чек-листы приемки. Сначала программист проверяет сам себя по списку, и только после этого передает задачу дальше. Это в разы снижает количество недоработок.
В чем измеряется работа? Как оценивается время на задачи?
В Скраме работу обычно измеряют не в человеко-часах (поскольку разные сотрудники тратят разное время на одно и то же), а в стори поинтах (Story Points). Это условные «попугаи», которые отражают сложность задачи относительно других задач.
Например, команда договаривается: простая правка текста на кнопке — 1 поинт, а внедрение нового способа оплаты — 13. Чаще всего для оценки используют шкалу, близкую к числам Фибоначчи (1, 2, 3, 5, 8, 13...), что хорошо отражает растущую сложность.
Чтобы оценить задачу в поинтах, команда использует Scrum Poker (скрам покер). На планировании все участники вскрывают карточки одновременно — так исключается давление авторитета и каждый высказывает собственное мнение, не подстраиваясь под лидерów.
💡 Польза покера не только в самих оценках, но еще и в обсуждении расхождений. Если пять человек оценили задачу на «3», а один разработчик на «13», возможно, он знает какие-то неочевидные риски, о которых остальные не подумали.
Скрам-словарь для новичков
Вам также могут встречаться следующие термины:
- Velocity (скорость команды). Измеряется в стори поинтах — тех самых «попугаях», о которых мы говорили выше. Если команда стабильно делает 40 поинтов за спринт — это ее Velocity. Показатель помогает прогнозировать, сколько задач реально взять в следующий спринт.
- Scrum PBR (Product Backlog Refinement), или Груминг. Встреча для «причесывания» бэклога. Проводится в середине спринта, чтобы заранее обсудить задачи на будущее и не буксовать на планировании.
- Диаграмма сгорания (Burndown chart). График, который показывает, с какой скоростью команда закрывает задачи. Линия стремится к нулю по мере приближения к концу спринта. Если она идет не вниз, а вбок — пора бить тревогу.
Какую программу выбрать для скрам-доски?
Любую, которая вам удобна: Jira, Kaiten, Trello. Если хотите, чтобы скрам-доска жила там же, где и все остальные ваши задачи (личные дела, встречи, свои проекты), присмотритесь к SingularityApp. Это планировщик с совместным доступом: вы не заводите отдельный инструмент, а просто открываете команде доступ к проекту.
Главное — чтобы скрам-доска визуализировала основные этапы, например: «К выполнению», «В работе», «Код-ревью», «Тестирование», «Готово». Не усложняйте инструмент, пока процессы не налажены.
Раздел 5. Практика внедрения: от учебника к реалиям
Как правильно начать внедрение Скрама в компании?
Главное правило: никогда не начинайте внедрение основ Scrum директивно одним днем. Фреймворк «из коробки» почти нигде не работает с первого раза: его нужно изучать на практике и настраивать под себя.
Внедряйте Scrum поэтапно. Для начала дайте команде почитать теорию. Затем проведите «нулевую» ретроспективу — обсудите наболевшее, чтобы люди выговорились. Потом введите короткие итерации и стендапы. И только когда команда привыкнет жить в ритме, выстраивайте полноценные процессы.
💡 Важно: не запускайте спринты без ретроспектив. Иначе люди быстро решат, что из них просто «выдаивают» результаты, и саботаж неизбежен.
Какие ошибки чаще всего убивают Scrum?
Компании обычно наступают на одни и те же грабли. Вот две главные беды:
- Карго-культ — это когда команда имитирует ритуалы, но не понимает их смысла. Стендапы проводятся, доска с колонками висит, спринты называются спринтами... Но на деле никто не меняет процессы по итогам ретроспектив, а задачи спускаются сверху, как при классическом менеджменте. Форма есть, гибкости нет.
- ScrumBut («Скрам, но...») — это когда Scrum вроде бы принят, но с оговорками: «мы работаем по Скраму, но ретроспективы у нас раз в месяц», «мы работаем по Скраму, но заказчик может менять требования в середине спринта» и т. д. Со временем этих «но» становится так много, что от фреймворка остается только название.
Можно ли менять правила Скрама или нужно строго следовать Scrum Guide (руководству)?
Формально Scrum Guide говорит: если меняете правила — это уже не Скрам. На деле живые команды почти всегда адаптируют фреймворк под свою реальность. Где-то спринт длится месяц, потому что задачи большие. Где-то оценки ставят в часах, а не в стори поинтах, чтобы бизнесу было понятнее. Где-то ведут два бэклога (один для фич, другой — для багов и техдолга).
Правило простое: сначала попробуйте чистый Скрам, почувствуйте, что работает, а что нет. Затем точечно меняйте правила — и обязательно проверяйте на ретроспективе, стало ли лучше. Слепое следование догме и хаотичный «колхозинг» одинаково вредны.
Что делать большим корпорациям?
Когда над одним продуктом работает больше трех-четырех скрам-команд, они начинают путаться в задачах и мешать друг другу. Для решения этой боли придуманы фреймворки масштабирования — от простых до корпоративных.
Самый легкий — Scrum of Scrums: скрам-мастера команд просто проводят свой стендап, чтобы разруливать стыки. Если этого мало и нужен единый ритм для всех команд, подключают LeSS (Large Scale Scrum) — по сути, тот же Скрам, но с одним бэклогом и одним Владельцем продукта на всех. Наконец, SAFe — это уже тяжелая артиллерия для корпораций с десятками команд: жесткая структура, роли, уровни планирования и «релизные поезда», чтобы все ехало синхронно.
Где пройти обучение и получить сертификат скрам-мастера?
Если вы решили строить карьеру в этом направлении, обучение Scrum и получение сертификации действительно станут весомым преимуществом в резюме. Самые признанные сертификаты — PSM (Professional Scrum Master) от Scrum.org и CSM (Certified ScrumMaster) от Scrum Alliance. В России качественную подготовку к этим экзаменам предлагают профильные компании, например, ScrumTrek.
Однако нужно помнить: сертификат скрам-мастера ценен ровно настолько, насколько подкреплен реальным опытом (чаще именно он интересует работодателя). Умение проводить команду через кризис можно получить только в реальных проектах.
Какие книги по Scrum стоит почитать?
Теория без практики мертва, но хорошие книги помогают не наступать на чужие грабли. Если хотите глубже разобраться, начните с этих трех:
- Джефф Сазерленд — «Scrum. Революционный метод управления проектами»
Книга от создателя метода: история появления Scrum, его принципы и философия. Обязательный минимум для погружения в тему. - Хенрик Книберг — «Scrum и XP: заметки с передовой»
Короткая и очень наглядная книга. Минимум воды, максимум схем и живых примеров. Хорошо заходит сразу после Сазерленда — как мостик от теории к инженерным практикам.Где найти книгу: Ozon.
- Владимир Завертайлов — «Настольная книга project-менеджера»
Книга от практика, построившего одну из топовых веб-студий России. Scrum и Agile здесь не самоцель, а инструменты, вписанные в реальный контекст: экономика проекта, заказчики, рост в профессии. Много полезных инсайтов, которые не найти в переводных учебниках.
