Представьте, что вы делаете квест-комнаты — закрытые пространства с интерактивными головоломками, из которых игроки должны выбраться за определенное время.
Квест-комната — сложный продукт, над ним работает много специалистов: сценаристы, бутафоры, инженеры, программисты, аудиорежиссеры, строители. При создании такого продукта очень сложно планировать производственный процесс:
- сценаристы не знают заранее, какой сюжет у них получится;
- инженеры не могут точно сказать, какое оборудование им понадобится и как долго его придется делать;
- художники и бутафоры не могут заранее оценить, сколько времени они потратят на оформление квест-комнаты: это зависит от идей, которые появятся у их коллег в процессе работы;
- всем специалистам нужно пространство для творчества: чем больше у них будет свободы, тем интереснее получится проект;
- готовая квест-комната может не понравиться клиентам, и придется все переделывать.
Производством таких сложных продуктов можно управлять с помощью Scrum: он позволяет искать оригинальные решения, но при этом выдавать результат в разумные сроки.
Что такое Scrum и в чем его суть
Scrum — это один из способов разработки продукта. Работу разбивают на небольшие отрезки, делают ее последовательно короткими циклами и после каждого цикла получают видимое и понятное улучшение. Если в один момент что-то пошло не так, всегда есть возможность вернуться на шаг назад и исправить.
В Scrum входят зоны ответственности, события, артефакты и правила, которые их объединяют. О них подробнее расскажем в следующих разделах.
Scrum принадлежит к Agile — «гибкому» подходу организации процессов. Один из принципов Scrum — прозрачность. Участники команды должны иметь доступ ко всей информации по продукту. Например, если продукт — это квест-комната, инженер всегда в курсе, над чем работает декоратор, а декоратор знает, с какими проблемами сталкивается сценарист. Если у руководителя компании появляется информация, которая может повлиять на разработку продукта, он рассказывает о ней команде.
С помощью Scrum можно разрабатывать сложные продукты, например:
- ИТ-продукты: программное обеспечение, мобильные приложения, сайты;
- высокотехнологичное оборудование: машины, гаджеты, станки;
- услуги: программы ипотечного кредитования, программы страхования, сервисы доставки;
- коллективные произведения искусства: фильмы, спектакли, масштабные инсталляции.
Для простых продуктов Scrum может не подойти, потому что он рассчитан на работу с неизвестным: в начале непонятно, что будет в конце. Команда постоянно тестирует гипотезы в процессе, анализирует работу и вносит изменения.
Кто входит в состав Scrum-команды
Scrum-команда — это небольшая группа людей. Внутри нее нет иерархии, лидеров или мини-команд — все участники работают над одной целью. В Scrum-команду входят:
- Владелец продукта.
- Разработчики.
- Scrum-мастер.
Владелец продукта, Product Owner. Человек, который формирует список требований к конечной версии продукта. Владельцем продукта может быть собственник бизнеса, заказчик или его представитель. Вот основные функции Product Owner в команде:
- формировать бизнес-модель продукта, составлять его дорожную карту, управлять финансами, руководить жизненным циклом продукта;
- вести бэклог продукта: составлять список задач по разработке, определять их приоритет;
- объяснять разработчикам требования к результату и вместе с ними определять, что нужно сделать в первую очередь;
- оценивать результат работы разработчиков, давать обратную связь.
При этом владелец продукта не руководит разработчиками напрямую: он ставит им цели, но не вмешивается в рабочий процесс. Разработчики сами решают, как достигать целей.
Разработчики, Developers. Это специалисты, которые создают продукт. Разработчики — условное название. В Scrum-команде это могут быть любые специалисты, например маркетологи, дизайнеры, программисты, тестировщики. Все зависит от продукта, над которым работают.
Оптимальное количество разработчиков в команде — от 3 до 9 человек. Обычно команду формируют специально под продукт и она ведет его от начала до конца. Если продукт масштабный, можно набрать несколько команд и распределить между ними задачи. Владелец продукта у этих команд будет общий: он будет вести единый бэклог и распределять задачи между всеми разработчиками.
Чтобы работа шла слаженно, команда должна работать как единое целое. У нее нет формального лидера, работа строится на равноправии и взаимопомощи. Участники дополняют друг друга, самостоятельно распределяют задачи и решают их совместными усилиями. У каждого специалиста есть определенные навыки, которыми можно делиться с командой, обучать друг друга и делиться опытом.
«Представьте себе ситуацию. Футболист подбегает к воротам, у него отличная возможность забить гол, но он этого не делает, потому что он защитник, а не нападающий. В команде такое невозможно. Настоящие команды — это высокоэффективные люди, которые жертвуют своей личной эффективностью ради общего выигрыша. Даже вратарь пойдет забивать голы, если это будет нужно для победы.
В Scrum-командах то же самое: люди помогают коллегам по мере возможности и постепенно учатся смежным профессиям: например, фронтендер может помогать бэкендеру или тестировщику».
Илья Павличенко
Сооснователь компании Scrum.ru, Scrum-тренер, LeSS-тренер, соавтор книги «Creating Agile Organizations»
Scrum-мастер. Человек, который отвечает за эффективность Scrum-команды и Scrum-процессы в компании. Ему не обязательно разбираться в продукте, он не вмешивается в рабочие процессы, пока они соответствуют Scrum.
По сути, мастер выступает как менеджер процесса, учитель, коуч, фасилитатор. Он обучает участников команды нюансам работы по Scrum, направляет их и помогает решить вопросы с руководством компании, если возникли проблемы.
«Scrum-мастер в компании — как ужасная няня из фильма: пока он нужен, он никому не нравится. Он может довольно жестко требовать: если команда решит отменить некоторые обязательные события спринта, он этого не позволит. Но при этом мастер может советовать эффективные методы работы, например предлагать разработчикам программировать в паре.
На первых этапах внедрения Scrum такие советы и требования часто вызывают сопротивление. Потом команда осваивает принципы Scrum, и тогда потребность в Scrum-мастере становится меньше. Но никогда не исчезает совсем: ведь постоянно приходят новые люди, которых тоже нужно учить».
Илья Павличенко
Сооснователь компании Scrum.ru, Scrum-тренер, LeSS-тренер, соавтор книги «Creating Agile Organizations»
Во время работы Scrum-мастер всегда рядом с командой. Если все идет хорошо, он дает возможность разработчикам и владельцу продукта действовать самостоятельно, а сам активно наблюдает. Одновременно он может заниматься высокоуровневыми процессами: выстраивать общение между всеми Scrum-командами компании и работать с топ-менеджерами.
Что такое спринты и как по ним работать
Работа над продуктом по Scrum разбита на равные отрезки — спринты. В конце каждого спринта разработчики представляют новую версию продукта — инкремент.
Спринт длится не более 30 дней. Если сделать его длиннее, будет сложно управлять рисками: команда может увлечься творчеством и потерять фокус на результате.
В спринт входит пять событий:
- Планирование спринта.
- Ежедневный Scrum.
- Спринт.
- Обзор спринта.
- Ретроспектива спринта.
Давайте вернемся к нашему примеру с созданием квест-комнаты и с его помощью разберемся, как устроен спринт. Предположим, что продолжительность спринтов в этом проекте — две недели.
Планирование. Спринт начинается со встречи Scrum-команды. На ней обсуждают цель предстоящей работы. Исходя из этой цели решают, какие задачи по продукту нужно сделать, оценивают, сколько времени займет каждая задача, определяют, как будут над ней работать. В конце встречи команда примерно понимает, что можно сделать за один спринт и как это реализовать.
Максимальное время планирования — 8 часов.
На планировании Scrum-команда решила, что за две недели сделает первую головоломку квест-комнаты — «Поединок с драконом». Сценарист придумает идею, инженер займется технической реализацией, а декоратор с аудиорежиссером будут делать оформление.
Ежедневный Scrum. Это короткие встречи до 15 минут, на которых участники команды обсуждают, что они сделали, чтобы достичь цели спринта. Формат таких встреч свободный: разработчики сами решают, в какой форме их проводить.
Часто такие встречи проводят в формате стендапа: разработчики по очереди рассказывают, какие задачи они выполнили и с какими сложностями столкнулись. Обычно каждый отвечает на такие вопросы:
- Что сделали вчера?
- Что будем делать сегодня и нужна ли с этим помощь?
- Что может помешать выполнить задачу?
Обзор спринта. После завершения спринта команда получает результат — инкремент. Его показывают владельцу продукта, а тот дает обратную связь: нужно ли что-то доработать или можно запускать продукт.
Если продукт нужно доработать, владелец вносит изменения в бэклог продукта.
Максимальное время обзора спринта — 4 часа.
На обзор пригласили постоянных клиентов компании. Они пробуют решить головоломку, которую сделала команда, и не справляются с ней. Команда решает еще поработать над головоломкой, а если нужно — заменить ее. Это будет одной из задач следующего спринта.
Ретроспектива спринта. После обзора спринта команда собирается на новую встречу. Инкремент уже оценили, теперь нужно обсудить работу: что было хорошо, а что — не очень, какие методы стоит использовать, а какие оказались неэффективными. В ретроспективе участвует только Scrum-команда, ведет ее обычно Scrum-мастер.
Во время ретроспективы участники команды рассказывают о сложностях в работе, предлагают, как улучшить процесс, дают обратную связь коллегам. Команда обсуждает замечания и предложения, а удачные идеи, которые появились во время обсуждения, берет в работу.
Максимальная продолжительность ретроспективы — 3 часа.
На ретроспективе разработчики разбираются, почему головоломка получилась слишком сложной для пользователей. Чтобы избежать такого в будущем, придумывают новую процедуру тестирования: теперь каждую головоломку будут проверять на группах из 2—4 человек.
После того как спринт закончился, возможны два варианта.
- Продукт нужно дорабатывать: например, потому, что сделано не все запланированное. Тогда Scrum-команда немедленно начинает новый спринт.
- Продукт полностью готов: что-то в нем менять нет смысла. Тогда финальную версию делают доступной для клиентов, а Scrum-команду распускают.
Какие артефакты создает Scrum-команда
В Scrum артефактами называют все, что создает команда во время разработки. А создает она три вещи:
- Бэклог продукта — общий список задач по продукту.
- Бэклог спринта — цель спринта, список задач, план работы.
- Инкремент — последнюю версию продукта, которую можно презентовать заинтересованным лицам.
Расскажем подробнее о каждом артефакте.
Бэклог продукта. Это список запланированных работ, который ведет владелец продукта. Список постоянно обновляют, например меняют требования или добавляют улучшения. Самые важные задачи ставят в начало бэклога, менее приоритетные — в конец.
Каждая задача в бэклоге — это законченный кусочек продукта: глава книги, функция приложения, страница сайта. Такую задачу удобно принести клиенту, чтобы он дал по ней обратную связь. Если получилось не то, что нужно, он сразу скажет об этом команде и разработчики сделают по-другому.
Вернемся к примеру с квест-комнатой. Допустим, команда делает квест по Гарри Поттеру, локация — Турнир трех волшебников.
Бэклог продукта может меняться по ходу работы. Например, разработчики выяснили, что не получится сделать дракона огнедышащим, — тогда эту задачу убирают из бэклога продукта и решают, чем еще напугать игроков.
Когда определили требования к продукту и написали общий список задач для команды, можно начинать первый спринт.
Бэклог спринта. Это план работ на спринт: цели, задачи и способы, которыми эти задачи будут выполнять. Цель спринта определяет владелец продукта, а разработчики решают, как этой цели достигнуть.
Бэклог спринта удобно вести с помощью Scrum-доски. На такой доске обычно три колонки: «Что делаем», «В процессе» и «Готово». Разработчики постепенно перемещают задачи по Scrum-доске — к концу спринта, как правило, большинство задач перемещается в колонку «Готово».
В классическом формате Scrum-доска — это физическая доска, по которой двигают стикеры. Но можно вести ее в планировщике — такой функционал есть, например, у сервиса Week.
По ходу работы бэклог спринта может меняться. Если разработчики поняли, что задачу не стоит делать, ее убирают из бэклога. Если, наоборот, возникла новая важная задача, ее добавят. Главное, чтобы ничего не помешало достичь поставленной цели — результата, который команда хочет в итоге получить.
Инкремент. Это последняя версия продукта, результат, которого достигла команда на данный момент. Владельцу продукта должно быть понятно, в чем заключается инкремент: как изменился продукт, какие новые функции у него появились. Тогда он сможет протестировать изменения, показать новый вариант пользователям и собрать у них обратную связь.
Во время спринта команда может работать над каким-то одним разделом продукта: например, делать вкладку с рецептами в мобильном приложении или, как в нашем примере, создавать локацию для квест-комнаты. Но инкрементом будет продукт, каким он получился после спринта: мобильное приложение с новой вкладкой, квест-комната с дополнительной локацией, книжка с новой главой.
Новые инкременты можно создавать, пока это приносит выгоду компании. Например, если новый функционал приложения поможет увеличить количество его пользователей, стоит поработать над этим функционалом. А если улучшения уже не приводят к росту прибыли, смысла в дальнейшей разработке нет. Тогда Scrum-команду распускают, а инкремент последнего спринта становится итоговым результатом.
Как навести порядок в деньгах бизнеса и личных сбережениях
- Как свести доходы с расходами: 4 совета из книги консультанта по финграмотности «Девушка с деньгами»
- Как инвестировать время и деньги, чтобы обрести финансовую свободу: 5 принципов из книги «Капитал»
- 9 способов получать пассивный доход
- 10 фильмов про деньги
- 3 проверенных десятилетиями совета по управлению финансами из книги «Самый богатый человек в Вавилоне»
Чек-лист: как внедрить Scrum в компании
Составили краткий чек-лист, как бизнесу начать работать по Scrum.
1. Найти Scrum-мастера. Он будет руководить внедрением Scrum. Такого специалиста можно взять в штат или пригласить на проект. Есть и другой вариант: руководитель или любой другой специалист, который хорошо знаком с внутренними процессами компании, может самостоятельно изучить теорию и выполнять функции Scrum-мастера.
2. Найти владельца продукта. Это хранитель информации по продукту и человек, который транслирует команде интересы клиентов, руководителей и других заинтересованных лиц.
3. Сделать бэклог продукта. Владелец продукта составляет его вместе с заказчиком и разработчиками.
4. Собрать Scrum-команды — одну или несколько. Нужно включить в них всех специалистов, которые требуются для разработки продукта.
5. Спланировать и провести первый спринт. Решите, сколько времени будет длиться спринт: чем он короче, тем больше владелец продукта вовлечен в дела команды и тем меньше свободы у разработчиков. Наблюдайте, как команда организует работу: проводит планирование, встречается на ежедневных Scrum, демонстрирует результаты работы на обзорной встрече, анализирует спринт на ретроспективе.
6. Постепенно внедрять в компании новую корпоративную культуру. Вместе с новой структурой приходят и новые ценности. Участники команд постепенно учатся быть открытыми, уважать профессионализм коллег, фокусироваться на целях команды и брать на себя сложные задачи, а руководитель компании — доверять специалистам, давать им конструктивную обратную связь и гордиться их успехами.
Как вы думаете, ваша компания смогла бы работать по Scrum? Почему?