Скрам простыми словами: что такое scrum, роли, спринты и как начать

Что такое скрам простыми словами

Скрам (scrum) — это рамка для управления проектом, в которой работа идёт короткими фиксированными отрезками, спринтами, по одной-четыре недели. В начале отрезка команда сама решает, сколько задач успеет сделать, а в конце показывает готовый результат: работающую функцию, а не отчёт о процессе. Если что-то пошло не так или требования изменились, это выясняется через две недели, а не через полгода.

Суть скрам сводится к трём идеям, которые в методологии называют эмпиризмом:

• Прозрачность. Все видят одни и те же задачи, их приоритет и статус — в бэклоге и на скрам-доске.
• Инспекция. Команда регулярно смотрит и на результат (обзор спринта), и на собственный процесс (ретроспектива).
• Адаптация. Заметили отклонение — меняем бэклог, план или способ работы в следующем спринте.

Scrum — самый распространённый фреймворк среди гибких подходов: в отчётах State of Agile его называет примерно половина опрошенных команд. При этом scrum намеренно не описывает, как именно делать работу. В Scrum Guide — официальном документе фреймворка, в редакции 2020 года это 13 страниц, — задана только структура: три роли, три артефакта и пять событий. Всё остальное команда подбирает под себя.

Откуда взялся scrum: регби, японские инженеры и Джефф Сазерленд

Название пришло из регби: scrum — это схватка, в которой команда собирается вокруг мяча и продвигается вперёд единым целым. Метафору предложили Хиротака Такэути и Икудзиро Нонака в статье «The New New Product Development Game» (Harvard Business Review, 1986 год). Они изучали Honda, Canon и Fuji-Xerox и заметили: успешные компании разрабатывают продукты не эстафетой «отдел передал отделу», а командой, которая ведёт мяч вместе.

Дальше были три ключевые даты:

1. 1993 год — Джефф Сазерленд (Jeff Sutherland) собрал первую scrum-команду в компании Easel Corporation: спринты, ежедневные встречи и разбор процесса появились именно там.
2. 1995 год — Кен Швабер (Ken Schwaber) вместе с Сазерлендом представил формализованный Scrum на конференции OOPSLA. С этого момента scrum стал воспроизводимой методологией, а не практикой одной компании.
3. 2001 год — Сазерленд, Швабер и ещё 15 авторов подписали Agile Manifesto: четыре ценности и двенадцать принципов гибкой разработки. Scrum стал одним из фреймворков этого семейства.

Канонический источник сегодня — Scrum Guide, который Швабер и Сазерленд ведут с 2010 года (актуальная редакция — 2020-я). А массовую популярность методу принесла книга Сазерленда «Scrum. Революционный метод управления проектами» (в оригинале — Scrum: The Art of Doing Twice the Work in Half the Time, 2014 год): из-за неё scrum до сих пор ищут как «революционный метод управления проектами».

Из чего состоит scrum: 3 роли, 3 артефакта, 5 событий

Структура скрама маленькая — её реально выучить за вечер. Сложность в другом: элементы нельзя выбрасывать по отдельности, иначе фреймворк перестаёт работать. Разберём каждый.

Три роли скрам-команды

• Владелец продукта (Product Owner). Отвечает за то, что делать: ведёт бэклог продукта, расставляет приоритеты, формулирует цель продукта и отвечает за ценность результата для бизнеса и пользователей. Это один человек с полномочиями решать, а не комитет.
• Скрам-мастер (Scrum Master). Отвечает за то, как идёт процесс: помогает команде соблюдать правила scrum, убирает препятствия, ведёт события и защищает команду от хаотичных «срочных» задач. Скрам-мастер — не начальник и не секретарь: власти над людьми у него нет, есть только авторитет процесса.
• Разработчики (Developers). Команда, которая делает работу и сама решает, как выполнить задачи спринта. В редакции Scrum Guide 2020 года роль «команда разработки» переименована в «разработчиков», и это не только программисты: дизайнеры, аналитики, тестировщики и маркетологи входят в ту же команду. Раньше Scrum Guide рекомендовал три-девять человек; жёсткого числа сейчас нет, но принцип тот же — команда достаточно мала, чтобы синхронизироваться за 15 минут, и достаточно полна, чтобы довести задачу до «готово».

Отдельной роли «менеджер проекта» в скраме нет: его функции распределены между владельцем продукта (объём и приоритеты), командой (оценки и исполнение) и скрам-мастером (процесс).

Три артефакта scrum

• Бэклог продукта (Product Backlog). Живой упорядоченный список всего, что может понадобиться в продукте: функции, исправления, технический долг. Ведёт его владелец продукта, а привязан бэклог к цели продукта — долгосрочному результату, к которому идёт команда.
• Бэклог спринта (Sprint Backlog). Задачи, взятые в текущий спринт, плюс цель спринта — короткая формулировка, зачем этот отрезок нужен. Бэклог спринта принадлежит команде и уточняется по ходу работы.
• Инкремент (Increment). Готовый, работающий результат спринта, который соответствует Definition of Done — заранее согласованному набору критериев «что значит готово»: код написан, протестирован, задокументирован, выложен. Задача, не прошедшая Definition of Done, в инкремент не попадает.

Пять событий scrum

• Спринт. Контейнер для остальных событий: отрезок в одну-четыре недели, чаще всего две. Длина фиксирована и не меняется от спринта к спринту — именно это создаёт предсказуемость. Спринт нельзя отменить из-за того, что «не успеваем»: его можно только завершить и сделать выводы.
• Планирование спринта (Sprint Planning). Команда отвечает на три вопроса: зачем этот спринт (цель), что берём из бэклога и как именно это сделаем. Таймбокс — до восьми часов для месячного спринта и пропорционально меньше для коротких.
• Ежедневный скрам (Daily Scrum). Пятнадцать минут каждый день в одно и то же время, только для разработчиков. Классический формат — три вопроса: что сделал вчера, что сделаю сегодня, что мешает. В Scrum Guide 2020 три вопроса не обязательны: важно лишь, чтобы команда синхронизировалась и скорректировала план дня.
• Обзор спринта (Sprint Review). До четырёх часов: команда показывает инкремент заказчику и стейкхолдерам, собирает обратную связь, а владелец продукта обновляет бэклог. Это не защита отчёта, а рабочая сессия — решения по приоритетам принимаются прямо на ней.
• Ретроспектива (Sprint Retrospective). До трёх часов: команда разбирает сам процесс — что мешало, что помогло — и выбирает одно-два конкретных улучшения на следующий спринт. Без ретроспективы scrum превращается в бег по кругу: спринты идут, а лучше не становится.

Как проходит спринт: цикл scrum по шагам

Если собрать всё вместе, работа scrum-команды выглядит как повторяющийся цикл. Один проход — один спринт:

1. Приведение бэклога в порядок. До планирования владелец продукта вместе с командой уточняет верхние задачи бэклога: формулировки, критерии приёмки, зависимости. Практика называется refinement (или груминг); в прежних редакциях Scrum Guide на неё отводили не больше 10% времени команды.
2. Планирование спринта. Команда формулирует цель спринта и набирает задачи из верха бэклога — столько, сколько реально успеет. Объём обычно оценивают в story points (условная сложность) или в часах; важно, что оценку даёт тот, кто делает работу. Story points, кстати, — распространённая практика, а не требование Scrum Guide.
3. Работа над задачами. Задачи двигаются по скрам-доске слева направо. Новое «срочное» в спринт не берётся: оно уходит в бэклог продукта и ждёт следующего планирования.
4. Ежедневные скрамы. Пятнадцать минут в день: команда сверяет прогресс с целью спринта и перераспределяет задачи. Препятствия фиксируются — их разбор входит в работу скрам-мастера.
5. Обзор спринта. Демонстрация инкремента стейкхолдерам, сбор обратной связи, обновление бэклога продукта.
6. Ретроспектива. Разбор процесса и одно-два улучшения, которые команда действительно применит в следующем спринте.
7. Новый спринт. Начинается сразу за предыдущим, без паузы. По итогам нескольких спринтов команда узнаёт свою velocity — средний объём работы, который она успевает: это главный инструмент предсказуемости сроков.

Скрам-доска: как выглядит работа спринта

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

• Бэклог спринта — задачи, взятые в работу в этом спринте;
• В работе — то, что команда делает прямо сейчас;
• На проверке — задачи, готовые по коду, но ждущие тестирования или ревью;
• Готово — задачи, прошедшие Definition of Done: именно они образуют инкремент.

От канбан-доски скрам-доска отличается тремя деталями:

• сверху висит цель спринта, а не просто список задач;
• доска обнуляется в начале каждого спринта, а незакрытые задачи возвращаются в бэклог продукта;
• рядом часто ведут burndown-график — сколько работы осталось до конца спринта. По нему сразу видно, успевает ли команда.

Инструмент значения не имеет: подойдёт стена со стикерами, Jira, Kaiten, Trello, Битрикс24 или любой таск-трекер со спринтами. Важно одно — карточка переезжает в момент смены статуса, а не в конце дня «по памяти».

Скрам и канбан: в чём разница

Запросы «scrum kanban» и «скрам и канбан» — среди самых частотных в теме: методы из одного семейства agile, их постоянно сравнивают и часто путают. Разница не в инструментах, а в логике работы:

• Ритм. Скрам задаёт календарь: спринт начался — спринт закончился, между этими точками команда живёт взятым обязательством. Канбан календаря не имеет: поток непрерывен, а «итерация» длится ровно столько, сколько задача идёт по доске.
• Новые задачи. В скраме всё, что прилетело после планирования, ждёт следующего спринта. В канбане задача заходит в поток сразу, как только в колонке освободилось место под WIP-лимит.
• Кто в команде. Скрам вводит две роли, которых раньше могло не быть: владельца продукта и скрам-мастера. Канбан ролей не добавляет — достаточно тех, кто уже делает работу.
• Что ограничивают. Скрам ограничивает объём, взятый в спринт. Канбан ограничивает число задач, одновременно находящихся в работе.
• Чем измеряют успех. В скраме — velocity и достижение цели спринта. В канбане — lead time (сколько задача шла от появления до готовности) и cycle time (сколько времени была в работе).
• Сколько встреч. Скрам предписывает пять событий. Канбан встреч не требует: команды обычно ограничиваются регулярным разбором доски и потока.

Что выбрать? Если вы делаете продукт с регулярными релизами, а требования меняются по ходу, — берите scrum. Если работа приходит непрерывно и её нельзя отложить до следующего спринта (поддержка, инциденты, маркетинг, администрирование), — канбан подходит лучше; он подробно разобран в статье «Канбан для начинающих».

Многие команды в итоге приходят к гибриду — scrumban: спринты и ретроспективы сохраняют, но добавляют WIP-лимиты и следят за временем выполнения задач. Это нормальная эволюция, а не нарушение методологии.

Scrum, agile и waterfall: как они соотносятся

Здесь возникает больше всего путаницы, поэтому зафиксируем уровни:

• Agile — не методология, а философия и семейство подходов. Основа — Agile Manifesto 2001 года: четыре ценности (люди и взаимодействие важнее процессов и инструментов; работающий продукт важнее исчерпывающей документации; сотрудничество с заказчиком важнее согласования условий контракта; готовность к изменениям важнее следования первоначальному плану) и двенадцать принципов.
• Scrum — конкретный фреймворк внутри agile: роли, артефакты, события. Рядом с ним стоят kanban, XP (extreme programming), lean и crystal.
• Waterfall — каскадная модель: проект идёт последовательными фазами (требования → проектирование → разработка → тестирование → внедрение), каждая фаза закрывается документом, а вернуться назад дорого.

Сравнение scrum и waterfall удобно свести к четырём пунктам:

• Изменения. Waterfall сопротивляется изменениям: правка требований после старта разработки стоит дорого. Scrum построен на том, что изменения придут, и принимает их каждый спринт.
• Результат. В waterfall заказчик видит продукт в конце проекта. В scrum — работающий инкремент каждые одну-две недели.
• Планирование. Waterfall планирует весь объём заранее; scrum детально планирует только ближайший спринт, а дальше работает приоритетами бэклога.
• Риски. В waterfall главный риск обнаруживается на тестировании или внедрении. В scrum риски вскрываются рано: уже первый спринт показывает, реалистичны ли оценки и требования.

При этом waterfall не «устаревший и плохой»: он уместен там, где объём работ жёстко зафиксирован, а цена ошибки огромна, — строительство, медицина, авиация, госзаказы с фиксированной сметой. На практике часто встречается гибрид: требования и архитектуру фиксируют по-водопадному, а разработку и тестирование ведут спринтами.

Как бы вы ни планировали, сам план проекта остаётся рабочим инструментом — про его состав у нас есть отдельная статья «Планирование проекта».

Кому подходит scrum, а кому нет

Скрам — не универсальный ответ на запрос «методологии управления проектами». Он хорошо работает, когда совпадает несколько условий:

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

И работает плохо, если:

• задачи приходят непрерывным потоком и их нельзя отложить до следующего спринта (поддержка, инциденты, операционка) — здесь лучше канбан;
• объём, сроки и бюджет зафиксированы контрактом, а изменения невозможны — здесь честнее waterfall или гибрид;
• у команды нет полномочий: решения всё равно принимаются сверху и на месяцы вперёд;
• «внедрить agile» пытаются сразу во всей компании, а не на одном пилотном проекте.

Как внедрить scrum: план на первые два спринта

Внедрение scrum не требует разрешения сверху и покупки нового софта. Достаточно последовательно пройти семь шагов:

1. Соберите бэклог. Выпишите все задачи и хотелки одним списком — от «сделать авторизацию» до «переписать отчёты». Один список, один источник правды.
2. Приоритизируйте с заказчиком. Владелец продукта расставляет порядок: сверху то, что даёт больше ценности раньше. Спорные приоритеты — это нормально: спор решается ценностью для пользователя, а не громкостью голоса.
3. Назначьте роли. Владелец продукта — один человек с полномочиями говорить «нет». Скрам-мастер — тот, кто следит за процессом: на старте роль часто совмещают, но лучше не с владельцем продукта. Команда — со всеми нужными компетенциями.
4. Зафиксируйте длину спринта и календарь событий. Для старта оптимум — две недели. Сразу поставьте в календарь все пять событий: планирование, дейли ежедневно по 15 минут, обзор и ретроспективу в последний день.
5. Проведите первое планирование. Сформулируйте цель спринта одной фразой и наберите задач столько, сколько команда считает реальным. В первом спринте почти всегда переоценивают себя — это нормально: velocity появится к третьему-четвёртому спринту.
6. Доведите спринт до конца и покажите результат. На обзоре — только работающее, не «почти готово». На ретроспективе — выберите одно-два улучшения и запишите их задачами следующего спринта.
7. Измеряйте и корректируйте. Следите за тремя вещами: сколько задач доходит до «Готово», какая у команды velocity и что происходит с моралью. Через три-четыре спринта станет видно, работает ли рамка в ваших условиях.

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

Сколько длится спринт и можно ли его изменить?

От одной до четырёх недель, чаще всего две. Длину выбирает команда и держит постоянной: именно постоянство позволяет сравнивать спринты между собой и считать velocity. Менять длину «под конкретный спринт» не стоит — иначе пропадает предсказуемость.

Нужен ли скрам-мастер, если уже есть менеджер проекта?

Это разные роли. Менеджер проекта отвечает за сроки, бюджет и отчётность перед заказчиком, скрам-мастер — за то, чтобы команда понимала и применяла scrum, и за устранение препятствий. В небольших командах один человек иногда совмещает функции, но совмещать скрам-мастера с владельцем продукта не рекомендуют: пропадает баланс между «хотим больше» и «делаем качественно».

Что такое story points и зачем они нужны?

Story points — условная оценка сложности задачи, а не времени: команда сравнивает задачи между собой («эта вдвое сложнее той»). Нужны они, чтобы планировать объём спринта, не привязываясь к часам, и считать velocity. Это практика сообщества, а не требование Scrum Guide: оценивать можно и в часах, и в количестве задач.

Скрам — это только для IT?

Нет. Метод пришёл из разработки продуктов, но применяется в маркетинге, образовании, HR, производстве и даже в личных проектах. Ограничение одно: работа должна допускать итерации и выдачу результата частями. Там, где результат неделим (построить мост), scrum в чистом виде не работает.

Можно ли работать по scrum без спринтов?

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

Типичные ошибки при внедрении scrum

• Спринт без цели. Набрали несвязанных задач, «чтобы команда была занята». Формально scrum соблюдён, а результата, который можно показать и оценить, нет.
• Дейли как отчёт начальству. Если на ежедневной встрече команда отчитывается перед руководителем, а не синхронизируется между собой, люди начинают говорить то, что хотят слышать.
• Недоступный владелец продукта. Бэклог не приоритизирован, решения по задачам ждут днями — спринт буксует, а команда сама придумывает требования.
• Скрам-мастер-надзиратель. Следит, чтобы все заполняли таск-трекер, вместо того чтобы убирать препятствия. Роль превращается в контроль, и команда начинает сопротивляться.
• Переполненный спринт. Взяли «с запасом», чтобы не выглядеть ленивыми, — сорвали обязательства, потеряли доверие заказчика и мораль команды.
• Ретроспектива без действий. Обсудили, покивали, ничего не изменили. Через три спринта команда перестаёт верить в смысл встречи.
• ScrumBut. «Мы работаем по скраму, но ретроспективы не проводим / бэклог не ведём / демо не показываем». Выброшенные элементы — не мелочи: без них фреймворк распадается.
• Story points как KPI. Оценки начали сравнивать между командами и требовать «роста скорости». Команды быстро понимают, что выгоднее завышать оценки, и метрика перестаёт что-либо означать.

Коротко

• Скрам (scrum) — рамка гибкого управления проектами: работа короткими спринтами по одной-четыре недели с готовым результатом в конце каждого.
• Структура: три роли (владелец продукта, скрам-мастер, разработчики), три артефакта (бэклог продукта, бэклог спринта, инкремент) и пять событий (спринт, планирование, дейли, обзор, ретроспектива).
• Основа метода — эмпиризм: прозрачность, инспекция, адаптация. Скрам не гарантирует, что план сбудется, но делает отклонения заметными каждые две недели.
• Scrum и kanban — оба agile-подхода: скрам даёт ритм и роли, канбан — непрерывный поток и WIP-лимиты. Команды часто совмещают их в scrumban.
• Scrum и waterfall — разные модели: итерации и готовность к изменениям против фиксированных фаз и плана. Waterfall оправдан при жёстком объёме работ и высокой цене ошибки.
• Внедрять стоит с одного проекта: бэклог, роли, двухнедельный спринт, демо и ретроспектива с конкретными улучшениями.

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