Scrum — это лёгкий фреймворк для работы над сложными продуктами, где заранее невозможно всё спланировать. Команда делит работу на короткие отрезки — спринты длиной не больше месяца, в конце каждого показывает готовый результат и по обратной связи решает, что делать дальше. Правила Scrum описаны в официальном Scrum Guide; актуальная редакция вышла в ноябре 2020 года. Ниже — всё, что в нём есть: роли, события, артефакты и принципы, на которых они держатся.
Откуда взялся Scrum
Фреймворк сформулировали Кен Швабер и Джефф Сазерленд в первой половине 1990-х и представили на конференции OOPSLA в 1995 году. Первая версия Scrum Guide появилась в 2010-м, с тех пор её несколько раз обновляли. Редакция 2020 года стала короче и меньше привязана к разработке ПО: Scrum применяют и в маркетинге, и в продуктовых командах, и в исследованиях.
На чём основан Scrum
Scrum опирается на эмпиризм — решения принимаются на основе того, что команда наблюдает, а не того, что предсказала в начале. Отсюда три столпа:
- Прозрачность. Работа и её результаты видны всем, кто в ней участвует или от неё зависит.
- Инспекция. Артефакты и прогресс к целям регулярно проверяются, чтобы вовремя заметить отклонения.
- Адаптация. Если что-то идёт не так, процесс или продукт меняют как можно быстрее.
Scrum Guide также называет пять ценностей: приверженность, фокус, открытость, уважение и смелость.
Роли: кто входит в Scrum-команду
В редакции 2020 года нет отдельной «команды разработки» — есть одна Scrum-команда без иерархии и подкоманд. Она кросс-функциональна (умеет всё, что нужно для результата) и самоуправляема (сама решает, кто, что и как делает). Обычно в ней 10 человек или меньше. Если команда разрастается, её делят на несколько Scrum-команд с общим продуктом, общей целью и одним владельцем продукта.
Внутри команды три зоны ответственности:
| Роль | За что отвечает |
|---|---|
| Владелец продукта (Product Owner) | Максимизирует ценность продукта: формулирует цель продукта, ведёт и упорядочивает бэклог продукта, объясняет его элементы. Это один человек, а не комитет. |
| Разработчики (Developers) | Создают готовый инкремент в каждом спринте: планируют спринт, следят за качеством по критериям готовности, ежедневно корректируют план. |
| Скрам-мастер (Scrum Master) | Отвечает за то, чтобы Scrum работал: обучает команду и организацию, помогает убирать препятствия, следит, чтобы события проходили с пользой и укладывались во время. |
«Разработчик» здесь — не обязательно программист. Это любой участник, который создаёт результат: дизайнер, аналитик, тестировщик, копирайтер.
События: из чего состоит спринт
Scrum Guide описывает пять событий. Каждое — возможность проверить результат и скорректировать курс. Длительность ограничена сверху (таймбокс); для коротких спринтов события обычно короче.
Спринт
Контейнер для всех остальных событий. Длится фиксированное время — месяц или меньше, чаще всего одну-две недели. Новый спринт начинается сразу после окончания предыдущего. Во время спринта не вносят изменения, угрожающие цели спринта, и не снижают требования к качеству. Отменить спринт может только владелец продукта — если его цель потеряла смысл.
Планирование спринта
Команда отвечает на три вопроса: почему этот спринт ценен (цель спринта), что можно сделать (какие элементы бэклога взять), как это будет сделано (план работы). Для месячного спринта — не больше 8 часов.
Ежедневный Scrum
15-минутная встреча разработчиков каждый рабочий день в одно и то же время и место. Цель — проверить движение к цели спринта и поправить план на ближайшие сутки. Привычных «трёх вопросов» (что сделал вчера, что сделаю сегодня, что мешает) в редакции 2020 года больше нет: формат команда выбирает сама.
Обзор спринта
Команда показывает результат заинтересованным сторонам, обсуждает, что изменилось вокруг продукта, и вместе решает, что делать дальше. Это рабочая сессия, а не презентация. Для месячного спринта — до 4 часов.
Ретроспектива спринта
Завершает спринт. Команда разбирает, как прошла работа: люди, взаимодействие, процессы, инструменты, критерии готовности. Выбирает самые полезные улучшения и может сразу внести их в следующий спринт. Для месячного спринта — до 3 часов.
Артефакты и обязательства
Артефакты делают работу прозрачной. В редакции 2020 года у каждого артефакта появилось обязательство — ориентир, по которому измеряют прогресс.
| Артефакт | Что это | Обязательство |
|---|---|---|
| Бэклог продукта | Упорядоченный, постоянно меняющийся список того, что нужно для улучшения продукта. Единственный источник работы для команды. | Цель продукта — долгосрочная цель, к которой команда движется. Одновременно у команды одна цель продукта. |
| Бэклог спринта | Цель спринта, выбранные элементы бэклога продукта и план их выполнения. Принадлежит разработчикам и обновляется в течение спринта. | Цель спринта — единственная задача спринта, которая придаёт команде фокус и оставляет гибкость в выборе работы. |
| Инкремент | Готовый, проверенный шаг к цели продукта. За спринт их может быть несколько; показать результат можно и до обзора спринта. | Критерии готовности (Definition of Done) — описание качества, которому должен соответствовать инкремент. Что им не соответствует, инкрементом не считается. |
Оценки в story points, диаграммы сгорания, пользовательские истории и доска с задачами в Scrum Guide не входят. Это популярные практики, которые команды добавляют по желанию.
Как выглядит спринт на практике
Возьмём команду, которая делает интернет-магазин, и двухнедельный спринт:
- Понедельник, планирование. Владелец продукта предлагает цель: «покупатель может оплатить заказ картой». Разработчики берут из бэклога задачи по подключению платёжного сервиса, странице оплаты и письму с подтверждением и раскладывают их на шаги.
- Каждый день — ежедневный Scrum. Выясняется, что тестовый доступ к платёжному сервису задерживается. Скрам-мастер помогает решить вопрос, команда временно переключается на вёрстку страницы оплаты.
- Последняя пятница, обзор. Команда показывает работающую оплату на тестовом стенде. Отдел продаж просит добавить оплату через СБП — владелец продукта вносит её в бэклог.
- Сразу после обзора — ретроспектива. Команда договаривается заранее запрашивать доступы к внешним сервисам и вносит это в план следующего спринта.
Scrum и Kanban: в чём разница
| Scrum | Kanban | |
|---|---|---|
| Ритм | Фиксированные спринты | Непрерывный поток задач |
| Роли | Владелец продукта, скрам-мастер, разработчики | Обязательных ролей нет |
| Изменения в работе | Состав работы может уточняться, цель спринта сохраняется | Новую задачу можно взять, как только освободилось место |
| Главный ограничитель | Длительность спринта | Лимит незавершённой работы на этапе |
| Подходит | Продуктовой разработке с понятной целью | Поддержке, потоку заявок, операционной работе |
Подходы можно сочетать: многие Scrum-команды ведут доску в стиле Kanban и ограничивают число задач в работе.
Когда Scrum подходит, а когда нет
Scrum хорошо работает, когда:
- требования будут меняться по ходу работы, и важна быстрая обратная связь от пользователей;
- продукт можно поставлять частями — каждую одну-две недели показывать работающий результат;
- есть человек, готовый взять роль владельца продукта и принимать решения о приоритетах.
Scrum избыточен, если задача хорошо известна и повторяется (типовой сайт по шаблону), если работа состоит из потока мелких несвязанных заявок или если в команде один-два человека — там хватает простой доски задач.
Частые ошибки
- Владелец продукта без полномочий. Если каждое решение согласуют с руководством, бэклог перестаёт быть единственным источником работы.
- Ежедневный Scrum как отчёт начальнику. Встреча нужна разработчикам для корректировки плана, а не для контроля.
- Спринты без готового инкремента. «Почти готово» не считается — результат должен соответствовать критериям готовности.
- Ретроспектива без изменений. Если по итогам ничего не меняется, команда быстро перестаёт видеть в ней смысл.
- Scrum «на бумаге». Переименовать менеджера проекта в скрам-мастера, а планы — в спринты недостаточно: без прозрачности, инспекции и адаптации фреймворк не работает.
Коротко
Scrum — это одна команда из владельца продукта, скрам-мастера и разработчиков, которая работает спринтами до месяца. В каждом спринте пять событий: сам спринт, планирование, ежедневный Scrum, обзор и ретроспектива. Работа видна через три артефакта — бэклог продукта, бэклог спринта и инкремент, — каждый со своим обязательством: цель продукта, цель спринта и критерии готовности. Всё остальное — практики, которые команда выбирает сама.