Scrum: что это такое, зачем нужен бизнесу и как с его помощью создавать продукты

Представьте, что вы делаете квест-комнаты — закрытые пространства с интерактивными головоломками, из которых игроки должны выбраться за определенное время.

Квест-комната — сложный продукт, над ним работает много специалистов: сценаристы, бутафоры, инженеры, программисты, аудиорежиссеры, строители. При создании такого продукта очень сложно планировать производственный процесс:

Производством таких сложных продуктов можно управлять с помощью Scrum: он позволяет искать оригинальные решения, но при этом выдавать результат в разумные сроки.

Scrum — это один из способов разработки продукта. Работу разбивают на небольшие отрезки, делают ее последовательно короткими циклами и после каждого цикла получают видимое и понятное улучшение. Если в один момент что-то пошло не так, всегда есть возможность вернуться на шаг назад и исправить.

В Scrum входят зоны ответственности, события, артефакты и правила, которые их объединяют. О них подробнее расскажем в следующих разделах.

С помощью Scrum можно разрабатывать сложные продукты, например:

Для простых продуктов Scrum может не подойти, потому что он рассчитан на работу с неизвестным: в начале непонятно, что будет в конце. Команда постоянно тестирует гипотезы в процессе, анализирует работу и вносит изменения.

Scrum-команда — это небольшая группа людей. Внутри нее нет иерархии, лидеров или мини-команд — все участники работают над одной целью. В Scrum-команду входят:

При этом владелец продукта не руководит разработчиками напрямую: он ставит им цели, но не вмешивается в рабочий процесс. Разработчики сами решают, как достигать целей.

Оптимальное количество разработчиков в команде — от 3 до 9 человек. Обычно команду формируют специально под продукт и она ведет его от начала до конца. Если продукт масштабный, можно набрать несколько команд и распределить между ними задачи. Владелец продукта у этих команд будет общий: он будет вести единый бэклог и распределять задачи между всеми разработчиками.

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

Scrum-мастер. Человек, который отвечает за эффективность Scrum-команды и Scrum-процессы в компании. Ему не обязательно разбираться в продукте, он не вмешивается в рабочие процессы, пока они соответствуют Scrum.

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

Работа над продуктом по Scrum разбита на равные отрезки — спринты. В конце каждого спринта разработчики представляют новую версию продукта — инкремент.

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

В спринт входит пять событий:

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

Планирование. Спринт начинается со встречи Scrum-команды. На ней обсуждают цель предстоящей работы. Исходя из этой цели решают, какие задачи по продукту нужно сделать, оценивают, сколько времени займет каждая задача, определяют, как будут над ней работать. В конце встречи команда примерно понимает, что можно сделать за один спринт и как это реализовать.

Максимальное время планирования — 8 часов.

Ежедневный Scrum. Это короткие встречи до 15 минут, на которых участники команды обсуждают, что они сделали, чтобы достичь цели спринта. Формат таких встреч свободный: разработчики сами решают, в какой форме их проводить.

Часто такие встречи проводят в формате стендапа: разработчики по очереди рассказывают, какие задачи они выполнили и с какими сложностями столкнулись. Обычно каждый отвечает на такие вопросы:

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

Если продукт нужно доработать, владелец вносит изменения в бэклог продукта.

Максимальное время обзора спринта — 4 часа.

Ретроспектива спринта. После обзора спринта команда собирается на новую встречу. Инкремент уже оценили, теперь нужно обсудить работу: что было хорошо, а что — не очень, какие методы стоит использовать, а какие оказались неэффективными. В ретроспективе участвует только Scrum-команда, ведет ее обычно Scrum-мастер.

Во время ретроспективы участники команды рассказывают о сложностях в работе, предлагают, как улучшить процесс, дают обратную связь коллегам. Команда обсуждает замечания и предложения, а удачные идеи, которые появились во время обсуждения, берет в работу.

Максимальная продолжительность ретроспективы — 3 часа.

После того как спринт закончился, возможны два варианта.

В Scrum артефактами называют все, что создает команда во время разработки. А создает она три вещи:

Расскажем подробнее о каждом артефакте.

Бэклог продукта. Это список запланированных работ, который ведет владелец продукта. Список постоянно обновляют, например меняют требования или добавляют улучшения. Самые важные задачи ставят в начало бэклога, менее приоритетные — в конец.

Каждая задача в бэклоге — это законченный кусочек продукта: глава книги, функция приложения, страница сайта. Такую задачу удобно принести клиенту, чтобы он дал по ней обратную связь. Если получилось не то, что нужно, он сразу скажет об этом команде и разработчики сделают по-другому.

Вернемся к примеру с квест-комнатой. Допустим, команда делает квест по Гарри Поттеру, локация — Турнир трех волшебников.

Бэклог продукта может меняться по ходу работы. Например, разработчики выяснили, что не получится сделать дракона огнедышащим, — тогда эту задачу убирают из бэклога продукта и решают, чем еще напугать игроков.

Когда определили требования к продукту и написали общий список задач для команды, можно начинать первый спринт.

Бэклог спринта. Это план работ на спринт: цели, задачи и способы, которыми эти задачи будут выполнять. Цель спринта определяет владелец продукта, а разработчики решают, как этой цели достигнуть.

Бэклог спринта удобно вести с помощью Scrum-доски. На такой доске обычно три колонки: «Что делаем», «В процессе» и «Готово». Разработчики постепенно перемещают задачи по Scrum-доске — к концу спринта, как правило, большинство задач перемещается в колонку «Готово».

В классическом формате Scrum-доска — это физическая доска, по которой двигают стикеры. Но можно вести ее в планировщике — такой функционал есть, например, у сервиса Week.

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

Инкремент. Это последняя версия продукта, результат, которого достигла команда на данный момент. Владельцу продукта должно быть понятно, в чем заключается инкремент: как изменился продукт, какие новые функции у него появились. Тогда он сможет протестировать изменения, показать новый вариант пользователям и собрать у них обратную связь.

Во время спринта команда может работать над каким-то одним разделом продукта: например, делать вкладку с рецептами в мобильном приложении или, как в нашем примере, создавать локацию для квест-комнаты. Но инкрементом будет продукт, каким он получился после спринта: мобильное приложение с новой вкладкой, квест-комната с дополнительной локацией, книжка с новой главой.

Новые инкременты можно создавать, пока это приносит выгоду компании. Например, если новый функционал приложения поможет увеличить количество его пользователей, стоит поработать над этим функционалом. А если улучшения уже не приводят к росту прибыли, смысла в дальнейшей разработке нет. Тогда Scrum-команду распускают, а инкремент последнего спринта становится итоговым результатом.

Составили краткий чек-лист, как бизнесу начать работать по Scrum.

1. Найти Scrum-мастера. Он будет руководить внедрением Scrum. Такого специалиста можно взять в штат или пригласить на проект. Есть и другой вариант: руководитель или любой другой специалист, который хорошо знаком с внутренними процессами компании, может самостоятельно изучить теорию и выполнять функции Scrum-мастера.

2. Найти владельца продукта. Это хранитель информации по продукту и человек, который транслирует команде интересы клиентов, руководителей и других заинтересованных лиц.

3. Сделать бэклог продукта. Владелец продукта составляет его вместе с заказчиком и разработчиками.

4. Собрать Scrum-команды — одну или несколько. Нужно включить в них всех специалистов, которые требуются для разработки продукта.

5. Спланировать и провести первый спринт. Решите, сколько времени будет длиться спринт: чем он короче, тем больше владелец продукта вовлечен в дела команды и тем меньше свободы у разработчиков. Наблюдайте, как команда организует работу: проводит планирование, встречается на ежедневных Scrum, демонстрирует результаты работы на обзорной встрече, анализирует спринт на ретроспективе.

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