Что такое Scrum? Скрам-команда
Что такое методология Scrum? Как её использовать в разработке в команде? Всегда ли хороша гибкость? Об этом мы и поговорим в статье, в которой постараемся раскрыть всё, что вам нужно знать про Скрам.
Так что же такое Scrum
Scrum – гибкая методология разработки, которую ещё называют гибким управленческим фреймворком, то есть структурой, в которой основной акцент переносится на качество процессов.
Суть Scrum заключается в том, что создание продукта разделяется на несколько частей. А на выполнение этих частей команде выделяется определённый отрезок времени или спринт (как правило, это 2 недели). Когда спринт завершается, производится демонстрация завершённого куска работы. На рисунке выше вы можете видеть лишь общий принцип процессов. Но лучше будет, если мы рассмотрим всё подробнее.
Как работает Scrum
Скрам устроен следующим образом:
Выглядит как китайская грамота? Не беда, сейчас мы разберём каждый элемент структуры. Кстати, часть картинок взята из книги Б. Вольфсана «Гибкие методологии», которая рекомендуется к прочтению, если вы интересуетесь данной темой.
Структура Scrum
Итак, Scrum состоит из следующих элементов:
Роли в Скрам: — владелец продукта (не кто иной, как product owner/manager). Он ставит задачу команде, определяя приоритеты по задачам и взаимодействуя с заказчиком; — Скрам-мастер – человек, отвечающий за процессы внутри команды, координирующий работу, отслеживающий внутреннюю атмосферу. Он планирует спринт, организовывает митинги, участвует при демонстрации итогов в конце каждого спринта. Кстати, скрам-митингом называют ежедневную планёрку, в ходе которой разбирается и анализируется ход работы. Обсуждается, что планируется сделать и что сделали, какие есть проблемы. Как правило, на собрание уходит около 15 минут, но все участники команды должны высказать своё мнение. За таймингом в процессе выступления каждого следит скрам-мастер; — команда — включает в себя 7, плюс-минус несколько человек, которые непосредственно участвуют в реализации требований владельца продукта.
Разбираем структуру Scrum дальше, на очереди артефакты: — беклог продукта. Это список требований, где расставлены приоритеты и отмечены трудозатраты; — беклог спринта. Это часть беклога спринта, т. е. ряд задач, которые можно уместить в один спринт; — инкремент продукта. Это часть продукта, готовая для демонстрации. Например, функциональность в digital-проектах. Или рабочая форма регистрации на сайте, готовая к практическому использованию.
Процессы в Скрам: — планирование спринта. Команда и скрам-мастер планируют фронт работ на будущий спринт, составляя беклог спринта, то есть, формируя список задач; — обзор спринта. Это показ инкремента продукта после каждого отрезка времени. Здесь команда демонстрирует рабочую функциональность владельцу продукта или заказчику, а те вносят изменения или выдвигают какие-нибудь требования в случае необходимости; — ретроспектива. Это обзор прошедшего спринта для того, чтобы улучшить процессы в будущем. Команда, владелец продукта и скрам-мастер обсуждают прошедший спринт, приходят к определённым выводам, думают, что можно улучшить; — Скрам-митинг. Определение этому мы уже дали в блоке «Роли в Скрам»; — спринт. Как уже говорили, обычно это 2-недельный отрезок времени, на протяжении которого команда успевает подготовить функционал, готовый для демонстрации.
Пример Scrum
Давайте представим, что нам нужно создать онлайн-сервис для клининговой фирмы по обслуживанию загородных домов. Назовём его «Уберимойдвор».
Работа с помощью этого сервиса будет строиться следующим образом: 1) регистрируется новый пользователь; 2) пользователь подаёт заявку; 3) клиенту перезванивает оператор, уточняя детали уборки (время, место и т. п.).
Соответственно, т. к. это онлайн-сервис, нам потребуется сайт. Создадим его с помощью гибкой методологии Scrum. Для начала, возьмём такую важную задачу, как история регистрации пользователя, и разложим её на более мелкие части, сформировав беклог продукта:
Теперь вместе с членами команды расставим приоритеты и поделим мелкие задачи по спринтам. Важно не забыть главное правило — после каждого спринта мы должны иметь в активе готовую функциональность для показа.
На деле историй типа «Регистрация пользователя» может быть довольно много. При определении приоритетов мы строим этот процесс сверху вниз и слева направо, располагая в верхней левой части наиболее важные задачи и активности.
Чтобы отображать беклог задач, можно использовать обычные стикеры на доске или даже стене. На практике это может выглядеть так:
Стена — это, конечно, хорошо, но лишь на первоначальном этапе, когда все члены команды увлечены, чувствуют личный вклад в общее дело. Разумеется, для удобства последующей работы используют не стену, а специальный софт типа Jira, Trello, Redmine и другие системы управления проектами. Там легко назначаются ответственные за задачи и их исполнители, меняются статусы задач и т. д.
Но вернёмся к нашей уборке. Выбрав спринты с задачами, мы приступаем к работе. Какой-то объём работ выполняется каждый день, а Скрам-мастер организовывает 15-минутные митинги, обновляя на них статус задач и выясняя трудности, возникшие в работе.
Здесь важно, чтобы Scrum-мастер смотрел за отношениями внутри команды и «климатом» в коллективе. Его задача — поддерживать команду в статусе мотивированной и способной к самоорганизации. Для этого вопросы недопонимания решаются в обязательном порядке. По сути, Скрам-мастер — это тренер в команде, действия которого улучшают общий результат.
Итак, после 2-недельного спринта Scrum-мастер и члены команды выполняют демонстрацию готового функционала. В нашем примере это форма регистрации, которую мы показываем владельцу продукта. Если он принимает работу, переходим к следующему спринту.
Ретроспектива: анализ спринта
Спустя пару дней после завершения спринта команда, скрам-мастер и владелец продукта собираются для проведения ретроспективы. Это может занять несколько часов, что зависит от размеров команды и продолжительности спринта. Здесь анализируются все возникшие сложности.
Каждый участник высказывает своё мнение, сообща все решают, как и что можно улучшить. В результате с каждой новой итерацией качество процесса повышается.
Как расставлять приоритеты?
То, что мы применяем Scrum, это хорошо, но как нам расставить приоритеты в огромнейшем списке историй пользователя? Ведь не секрет, что проект может включать в себя множество таких историй.
А вот для этого и нужен такой человек, как владелец продукта. Он лучше понимает потребности аудитории, осуществляет мониторинг рынка и определяет что в каком порядке должно выполняться. Главная задача — решение потребностей клиента, начиная с самых важных.
Также нужно учитывать и возможности команды. Сколько задач команда может выполнить за один спринт? Какие это задачи? Как запланировать общий ход их выполнения? Ответ на все эти вопросы даст оценка внутри беклога.
Оценка внутри беклога
Итак, мы сформировали беклог, но каким образом можно дать оценку истории пользователя с точки зрения сложности? В этом случае подходит метод эталона. Это относительная оценка, позволяющая понять потенциал команды, а также приблизительно оценить ресурсы.
Допустим, в сервисе есть user story типа «Регистрация пользователя». Возьмём её за образец и дадим ей ценность в 1 бал или один story point. Каждый участник команды напишет собственную оценку к остальным историям пользователя в списке, учитывая задачу, взятую за образец.
Выше мы видим, что «Фотогалерея с довольными клиентами» оценивается 0,5 story point, т. е. она меньше образца в 2 раза. Все эти оценки члены команды проставляют анонимно, например, на стикерах, написав и перевернув.
После оценивания результаты открываются. Scrum-мастер организовывает обсуждение между участниками, поставившими крайние оценки. На нашем рисунке это 8 и 2. Они договариваются, после чего запускается 2-й раунд голосования.
Таким образом, участники команды должны прийти к общему решению, поэтому оценки выравниваются. В результате получается разбивку по всем user stories с учётом эталонной оценки.
Потом задачи набираются в спринты (с учётом приоритетов), и начинается работа. По результатам завершённых спринтов становится ясно, сколько story point-ов может выполнить команда. А по итогам ретроспективы находятся точки роста.
Можно ли использовать Scrum не только в разработке?
Дело в том, что задачи должны быть типовыми. Разработка в IT — это всё же инженерная практика, а её можно привести к некоторым стандартам. И в разработке это сделать намного проще, чем, скажем, в маркетинге, управлении и каких-нибудь креативных сферах.
Но отдельные практики из Scrum вполне себе применимы в прочих областях. Вы можете работать с командой и анализировать результат, прогнозировать задачи и управлять ими.
Когда используют Scrum?
Чаще всего в стартапах и небольших проектах. Можно и в крупных проектах, например, Mail.ru. Но тут должно соблюдаться условие наличия некоторой свободы действий. Стоит помнить, что Scrum — это ведь про гибкость. Да и команды не должны быть слишком большими, иначе возникнут сложности при организации коммуникации.
Нюансы Scrum
Если вы всё-таки решились внедрить Scrum в свой проект, учтите ряд нюансов: — не каждый заказчик готов к определённым стандартам Scrum; — все участники в команде должны иметь высокий уровень ответственности, создание команды с хорошей мотивацией — сложная задача; — немаловажную роль играет Scrum-мастер — специалист, отвечающий за процессы, связи внутри группы, мотивацию. Иногда трудно найти подходящего человека.
Делаем выводы
Вне зависимости от вышеперечисленных нюансов, Scrum остаётся наиболее популярным среди всех гибких методологий, включая Аджайл. Отдельные его компоненты применимы и в других сферах бизнеса, а принципы без проблем станут основой для создания вашей собственной стратегии развития.
