Scrum: все что нужно знать

Что такое Scrum методология? Как ее применять в разработке и не только? Почему гибкость не всегда хороша?

Учеба продолжается, три раза в неделю я знакомлюсь с новыми знаниями из области разработки и понимания digital продуктов изнутри. Для маркетолога, это новый мир. Ты слышишь про какой-то там Agile, понимаешь, что связано это с разработкой и вполне можешь поддержать беседу в общих красках. Но как только дело доходит до деталей, “поплыл”.

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

Что такое Scrum

Scrum – гибкая методология разработки или гибкий управленческий фреймворк (т.е. структура) с акцентом на качество процессов.

Суть методологии сводится к тому, что создание продукта делится на определенные части. На выполнение таких частей отводится кусок времени или спринт (обычно 2 недели). В конце каждого такого спринта необходимо проводить демонстрацию завершенного куска. Рисунок выше, это просто общий принцип процессов. Давайте разберем более подробно.

Как работает Scrum

Как Scrum устроен на самом деле смотрите ниже.

Пока это выглядит как китайская грамота, поэтому предлагаю посмотреть на отдельные части и разобрать каждый элемент структуры. Очень рекомендую книгу Бориса Вольфсана “Гибкие методологии” именно она легла в основу данного материала (часть картинок оттуда).

Структура Scrum

Давайте посмотрим из каких элементов состоит Scrum.

Роли

Владелец продукта (product owner/manager). Ставит задачу, определяет приоритеты по задачам, взаимодействует с заказчиком.
Скрам-мастер – человек, который отвечает за процессы внутри команды, координирует работу, следит за внутренней атмосферой. Планирует спринт, организует скрам митинг, участвует в демонстрации результатов в конце каждого спринта.

Скрам митинг – ежедневная планерка, летучка, где разбирается ход работы спринта. Что сделали, есть ли проблемы, что планируется сделать. Не более 15 минут на собрание. Все участники команды должны высказаться. Скрам-мастер следит за таймингом и выступлением каждого.

Команда – 7±2 человек, которые реализуют требования владельца продукта.

Артефакты

Беклог продукта. Список требований с расставленными приоритетами и трудозатратами.
Беклог спринта. Часть беклога спринта, то есть несколько задач, которые реально уместить в один спринт.
Инкремент продукта. Готовая часть продукта для демонстрации. В digital проектах, это может быть функциональность. К примеру, рабочая форма регистрации на сайте, которую можно показать.

Процессы

Планирование спринта. Команда со скрам-мастером планирует план работ на будущий спринт, то есть составляет беклог спринта (список) задач.
Обзор спринта. Демонстрация инкремента продукта после каждого спринта. Команда показывает рабочую функциональность владельцу продукта (и заказчику по запросу), а тот, в свою очередь, вносит изменения в требования, если они необходимы.
Ретроспектива. Обзор прошедшего спринта с целью улучшения процессов. Команда, скрам-мастер и владелец продукта обсуждают прошедший спринт, делают выводы, думают над тем, что можно было бы улучшить.
Скрам митинг. (см.определение выше в блоке “Роли”)
Спринт. Как правило двухнедельный этап времени, в течении которого команда успевает разработать готовый для демонстрации функционал.

–

Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал. Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

–

Пример Scrum

Представьте себе, что вам необходимо создать сайт/сервис по уборке на своих дачных участках. У вас есть загородный дом, где на участке творится полный швах, а тратить свои выходные на уборку, не представляется возможности, ведь хочется и отдохнуть немного. Поэтому, вуаля, сервис Уберимойдвор!

Мы считаем, что сервис будет базироваться на сайте. Пользователь регистрируется, оставляет заявку и ему перезванивает оператор, который уточняет детали и договаривается об удобном для клиента времени. Для разработки сайта мы хотим применить Scrum.

Выбираем, для примера, важную задачу или историю пользователя (user story) в рамках создания сайта: “Регистрация клиента/пользователя”. И раскладываем ее на более мелкие части. Формируем беклог продукта.

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

На практике, историй пользователя (типа “Регистрация пользователя”) гораздо больше. Сервис/продукт может включать множество таких историй, поэтому приоритезация строится сверху вниз, слева направо. В верхней левой части располагаются самые важные user story (Активность) и самые важные задачи.

Для отображения беклога задач используются обычные стикеры, доска (иногда даже стена). Вот как это может выглядеть.

Понятно, что управлять такой “махиной” в реальном времени просто невозможно, поэтому для удобства работы, вся эта стена переезжает в специальный софт/программу (Jira, Trello, Redmine и прочие трекеры управления проектами). Там вы можете назначать ответственных за задачи и исполнителей, изменять статусы задач и прочее.

Стена работает тоже хорошо, так как на этапе создания вся команда увлечена и чувствует свой вклад в общее дело. Но после ее нужно перенести в подходящий инструмент.

Вернемся к уборке двора. Вот мы выбрали спринты с задачами и преступили к работе. Команда каждый день выполняет объем работ, а скрам-мастер организует 15 минутные планерки (скрам митинги), где обновляет статус задач спринта и выясняет трудности в работе, если они возникли.

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

После 2-х недельного спринта скрам-мастер и команда проводит демонстрацию функционала. В нашем примере, мы успели сделать форму регистрации и показываем ее владельцу продукта. Он смотрит и вносит корректировки, если требуется. После принятия работы переходим к следующему спринту.

Ретроспектива: анализ спринта

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

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

Как расставлять приоритеты

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

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

В тоже время необходимо учесть возможности команды. Сколько задач она способна решить за спринт? Какого рода эти задачи? Как планировать общий ход выполнения? Поможет оценка внутри беклога.

Оценка историй пользователей внутри беклога

Мы сформировали беклог, но как оценить истории пользователя с точки зрения сложности? Для этого используется метод эталона. Это относительная оценка, которая позволяет понять потенциал команды и приблизительно оценить ресурсы.

Мы берем одну user story из беклога за образец и присваиваем ей ценность единицу (story point). Дальше оцениваем другие истории пользователя с точки зрения выбранной.

Например, в нашем сервисе есть история пользователя “Регистрация пользователя”. Мы берем ее за образец и даем ценность в один бал или один story point (так его называют в гибких методологиях). Каждый участник команды пишет свою оценку к остальным историям пользователя в списке с учетом задачи, которую взяли за образец и отдает ее скрам-мастеру.

В примере выше “Фото галерея с довольными клиентами” стоит 0,5 story point, то есть по сложности она в 2 раза меньше нашей эталонной истории “Регистрация пользователя”. Все оценки участники команды ставят анонимно, можно на стикерах писать и переворачивать.

Когда все проставили оценки, результаты открываются. Скрам-мастер организует обсуждение между участниками, которые поставили самые крайние оценки. На рисунке выше, это 2 и 8. Они договариваются между собой и запускается второй раунд голосования.

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

Далее с учетом приоритетов задачи набираются в спринты и начинается работа. По итогам завершенных спринтов становится понятно, сколько story point-ов приблизительно может выполнить команда. А в процессе разбора (ретроспективы) после могут найтись точки роста.

Таким образом, мы получаем внутренний измеритель или валюту, которую получает команда за спринт. По ней можно мерить эффективность команды и прогнозировать будущие итерации.

Можно ли применять Scrum не только в разработке

И да и нет. До того, как я начал понимать, что означают эти 5 букв (Scrum), часть принципов уже использовал в работе. Планирование, с помощью различных инструментов и выстраивание своего так называемого “спринта задач” уже было.

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

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

Отдельные практики из методологии вполне себе применимы в других областях. Работа с командой и анализ проделанной работы, да. Прогнозирование задач на этапе времени, да. Управление задачами, в удобных программах, тоже да.

Когда применять Scrum

В основном в небольших проектах и старт-апах. Можно и в больших, типа Mail.ru, но там должна быть определенная свобода действий и отдельные функциональные команды со своим владельцем продукта. Не забывайте, что Scrum про гибкость и изменения. Команды не должны быть больше 7±2 человек, иначе невозможно будет эффективно организовать коммуникации.

Нюансы

Если вы решили внедрить Scrum у себя в проектах, то учитываете следующие нюансы:

Нет ориентации на клиента. Не все заказчики будут готовы к определенным стандартам Scrum.
Не учитывается система реагирования на риски. Команда может заложить какое-то доп.время на выполнение задач, но при сильных отклонениях от плана, система встанет.
Команда и человеческие качества. Так как упор сделан на самоорганизующуюся команду, то все участники должны обладать высоким уровнем ответственности и соответствующей мотивацией. Создание такой команды, очень сложная задача.
Скрам-мастер. Человек отвечающий за процессы и мотивацию команды, должен чувствовать всех участников и связи внутри группы. Это редкий специалист, которого также тяжело найти на рынке.

Завершим

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

Все что нужно знать про Scrum