Получите все материалы с наших тренингов — бесплатно
Scrum Фреймворк 🔄 — Методология Управления Проектами
Scrum Фреймворк 🔄 — Методология Управления Проектами
Scrum Фреймворк 🔄 — Методология Управления Проектами
⚡ Ответим в течение 30 минут — contact@leadstartup.ru
+7 495 150 42 63 — с 8:00 до 21:00 МСК
Катерина Сухих

Scrum фреймворк 🔄 — что такое «Скрам», руководство по методологии управления проектами

111 отзывов, в среднем 5 из 5
Скрам (Scrum) — это фреймворк, который помогает решать изменяющиеся в процессе работы задачи, чтобы продуктивно и творчески поставлять клиентам продукты с максимально возможной ценностью.

Scrum

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

Получите нашу единую MIRO–доску с 100+ инструментами и доступ к Google–диску
Материалы тренингов LeadStartup

Правила Scrum

Разработка делится на циклы (итерации или спринты), итогом каждого цикла — рабочая версия продукта. У каждой задаче есть приоритет. Работа идет по сценариям. Люди превыше всего. Помощник в работе — доска, на которой отражается статус задач.

Компоненты Scrum

Бэклог, Sprint или итерация, Stand up, Sprint Review, ретроспектива в Scrum.

Что такое Scrum?

Scrum — модный способ управления разработкой в айти. На первое место здесь выходит команда профессионалов: если внедрять Скрам будут неумелые ребята,  все станет только хуже. В идеале люди в такой команде  кайфуют от своей работы, они лояльны и болеют за продукт.

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

scrum

Что такое методология Scrum

Scrum — это способ организации работы = процессный фреймворк. Суть Scrum заключается в том, что команда делит работу на части и создает продукт вместе с заказчиком.  Он лично включается в процессы, постоянно дает обратную связь.

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

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

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

scrum Скриншот из книги Николая Товеровского «Управление проектами, людьми и собой».

Как может выглядеть путь из точки А в точку Б

История Scrum

Термин Scrum в теме разработки IT–продуктов впервые прозвучал в 1986 году.  Японские разработчики опубликовали в Harvard Business Review статью, где провели аналогию между командной работой и игрой в регби.

В регби «scrum» — это схватка. Элемент игры, когда игроки двух команд после нарушения правил сцепляются вместе и ждут вброс мяча.

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

Позднее Джефф Сазерленд и Кен Швабер придумали, как должны работать процессы Scrum и опробовали метод для разработки продукта в компании Easel Corporation. Scrum помог им выпустить продукт почти без багов, сделать это за полгода и уложиться в бюджет.

Сазерленд и Швабер вдохновились успехом и сформулировали методологию Scrum для широкой публики. Они писали статьи в журналы для разработчиков и выступали на IT–конференциях. В основе  первых версий Скрам лежал подход заводов Toyota: искать и устранять потери. Тогда была озвучена идея спринтов — коротких итераций, на которые делится работа.

scrum Первое описание Скрам–процесса. Источник scrumtrek.ru

В конце 90-х Сазерленд и Швабер описали шаблоны процессов Скрам, чтобы другие компании могли повторять их и создавать успешные продукты. Так появился фреймворк Scrum — набор правил и принципов: перенимаете их и Скрам работает. В это же время они описали роль Scrum–мастера, человека который устраняет проблемы и помогает команде на всем пути создания продукта.

В 2001-м году Кен Швабер и инженер–программист Майкл Бидл выпустили книгу «Agile Software Development with Scrum». В ней описаны процессы Scrum, роли в команде,  встречи и события. Эти правила прижились, их сейчас использую скрам–команды в IT и других сферах, когда надо выпустить продукт.

 scram Обложка книги Швабера «Agile Project Management with Scrum».

В ней говорится, что фреймворк Scrum работает, если в команде выделены три роли, созданы три артефакты и происходят пять процессов

Структура методологии Scrum

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

Об этом узнали создатели метода Scrum и написали книгу «Agile Project Management with Scrum». В ней они описали кейсы разных компаний, которые переходили на Скрам.  Разбор кейсов показал, что  мероприятия Scrum  связаны между собой, одно без другого не работает. Роли, артефакты и процессы во–многом помогают добиться того результата, которого команды ждут от Scrum. Отсюда родилось правило 3-5-3.

Три роли в Scrum: Владелец продукта (Product owner), Скрам–мастер (Scrum Master), Скрам–команда ( Scrum Team).

Три артефакта: Бэклог продукта, Бэклог спринта, Инкремент продукта.

Пять процессов: Планирование спринта, Спринт, Скрам–митинг, Ретроспектива, Демо спринта.

Роли во фреймворке Scrum

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

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

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

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

Скрам–команда создает продукт. В нее входят специалисты, которые нужны для разработки определенного продукта. Например, в команду по разработке мобильного приложения могут входить: UX–дизайнер, iOS–разработчик, Android–разработчик, менеджер. В команду разработки программного обеспечения войдут: UI/UX дизайнер, разработчики, тестировщики, бизнес–аналитик, маркетолог.

scrum Источник: www.atlassian.com Обязанности Скрам–мастера

Кто такой Скрам–мастер

В книге «Agile Software Development with Scrum» роль Scrum Master описана такими словами: «Scrum–мастер несет ответственность за успех Scrum. Scrum–мастер отвечает за обеспечение того, чтобы ценности, практики и правила Scrum были приняты и соблюдались».

Чтобы Скрам–мастер мог выполнять этот функционал, на его роль ставили лидера команды: тим–лида или руководителя проекта. Считалось, что Скрам можно внедрить только давлением сверху. В некоторых компания вводили правило: если участник команды опоздал на ежедневный Скрам–митинг, он платил 1 доллар Скрам–мастеру.

Сегодня роль Скрам–мастера воспринимают иначе. Это скорее поддерживающий лидер, который помогает, направляет и подсказывает. Команды, которые переходят на технологию Scrum, часто нанимают Скрам–мастера со стороны, а не назначают на его роль лидера команды.

Что делает Скрам–мастер:

  • Следит за работой команды, чтобы Скрам–команда разбивала работу на части, записывала все задачи и их статусы на доске, внедряла решения ретроспективы, оценивала результаты спринтов.
  • Помогает организовать и спланировать Scrum мероприятия, объясняет, почему приходить на них важно.
  • Убирает блокаторы: сломалась кофе–машина и команда не может работать, Скрам–мастер делает все возможное, чтобы машина заработала или находит другой способ сварить кофе.

scrum Скрам гайд — это пдф документ, который поддерживают и редактируют создатели фреймворка Scrum

Что такое Скрам гайд

Scrum Guide  — это руководство по теории и правилам фреймворка Скрам. Его написали создатели методологии — Кен Швабер и Джефф Сазерленд.

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

Скрам гайд помогает разобраться:

что такое Scrum,

как и где его применять,

что такое бэклог,

зачем нужен стендап,

какие бывают роли в команде,

чем занимается Скрам–мастер.

Скрам гайд служит учебником для Скрам–мастеров. Здорово, если его прочитает вся команда и руководство компании перед внедрением фреймворка.

Правила фреймворка Scrum

  • Разработка делится на циклы, их еще называют итерациями или чаще спринтами. Проще говоря, делим работу на небольшие кусочки и друг за другом их делаем.
  • Итогом каждого такого цикла должна быть рабочая версия продукта. Или каждый сделанный кусочек = улучшенный продукт.
  • В конце спринта проходит ретроспектива со всеми членами команды. На ней обсуждают прошедшую работу, что там пошло не так, как это можно улучшить в следующий раз. Все в позитивном ключе и не для галочки, а чтобы реально изменить что–то в следующем цикле.
  • Каждой задаче присваивается приоритет, он зависит от того, как выполнение повлияет на прогресс продукта. Этому уделяют большое внимание. Нельзя просто так взять и надавать разработчикам задач «сверху».
  • Работа идет по сценариям. Не «запилить кнопку регистрации», а «пользователь может войти в личный кабинет через соцсеть ВКонтакте, Инстаграм и Гугл почту».
  • Люди превыше всего. В скраме важна дружеская атмосфера в команде. Конфликты будут долго разбирать и решать все вместе.
  • Реальная или виртуальная доска, на которой отражается статус задач, типа «Можно брать в работу», «В работе», «На проверке», «Готово».

Компоненты фреймворка Scrum

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

Без этих моментов фреймворк Scrum не Scrum. Есть основные, без которых никак не обойтись.  Есть опциональный — какие–то команды их применяют, какие–то от них отказываются.

Начнем с основных и самых важных ритуалов и церемоний.

Бэклог в Scrum

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

Пример:

«Пользователь может записывать голосовые сообщения и отправлять их своим друзьям из списка».

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

Составлением бэклога занимается product owner (продуктоунер, а переводится как владелец продукта). Часто эту функцию берет на себя Teamlead. Это не заказчик, но человек из команды, которые выполняет его роль. То есть он отвечает за видение продукта заказчиком или тем, как это хотят видеть Топы, СЕО компании.  Product owner принимает решения об изменениях в бэклоге или в продукте. Связывает между собой команду и  «верхушку» или заказчика, стейкхолдеров.

scrum

Sprint в Scrum

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

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

В идеале спринт длится от одной до четырех недель. В Apple, например, sprint занимает 3 недели. А в Nokia — 6 месяцев (хотя, стоит задуматься, где сейчас Нокиа, а где Эпл).

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

scrum Пример планирования Спринта. Скриншот из книги

Stand up в Scrum

Задачи есть, время на их выполнение согласовано. Что дальше? А дальше команда каждый день проводит 15-минутные встречи. На них каждый должен ответить на три вопроса:

  • Что делал вчера?
  • Что буду делать сегодня?
  • Какие есть проблемы в работе над проектом? Что делаю, чтобы устранить их?

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

Проходят стендапы утром, либо днем, если есть разница во времени между офисами. Но всегда в одно и то же время.

Цель всех этих стендапов не бесить участников. А  сделать так, чтобы все в команде знали, как двигается работа над задачами, кто тормозит и почему, как ему помочь.

Sprint Review в Scrum

Проходит, как вы догадались, в конце спринта.  Тут все показывают, что  сделали за цикл и получают обратную связь. Во многих (особенно в продуктовы) компаниях этот этап опускают или заменяют на что–то другое. Например, улучшили что–то в продукте, выкатили на определенную аудиторию, собрали обратную связь, обработали, поправили, выкатили на всю аудиторию продукта.

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

В этом митинге участвует команда, стейкхолдеры, заказчики, product owner и скрам–мастер.  Последний — тот человек, что контролирует весь процесс работы над проектом. Он организует спринты, стендапы и митинги. Следит за порядком на доске, чтобы никто не завис на какой–то задаче, и все вовремя отмечали ход работы. Выявляет проблемы и узкие места. Типа, сломался у дизайнер ноутбуку, Скрам–мастер позаботился и быстро достал новый. Или команда пожаловалась, что кофе–машина плохо работает, поэтому на утренних стендапах все вялые. Скрам–мастер постарался и все починил сам или нашел ремонтника.

Ретроспектива в Scrum

Она же ретро. Проводится в последний день спринта. Длится от 60 минут до двух часов (например, для двухнедельного спринта). Участвуют: команда проекта, Scrum–мастер, product owner или тимлид.

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

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

Как должна проходить ретроспектива в идеальном мире:

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

Кейс внедрения методики Scrum в геймдеве

Герой истории — NX Studio. Это студия разработки социальных и мобильных игр. Начинали с команды меньше 10 человек. Уже применяли на этом этапе элементы Scrum, но не по учебнику. Были спринты, выстроенная команда.

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

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

Продюсер компании NX Studio Дмитрий Цуканов заметил: «Теперь при встрече с новой задачей мы сами сначала ищем уже существующие готовые решения. Даже если они нам не нравятся, мы сначала пробуем что–то внедрить, а потом делаем выводы. Как оказалось, большинство лучших мировых практик имеют свое обоснование. Конечно, мы уже потом добавляем свое дизайнерское видение, такой подход кажется более правильным».

Плюсы методики Scrum

  • Довольные и мотивированные сотрудники. Неформальное общение, возможность высказываться и предлагать. Кайф же?
  • Отсутствие ненужной бюрократии и документации. Как Apple сильно заморачиваются над продуктами, и выпустить новый гаджет им куда важнее, чем крутую инструкцию по его использованию. Ее можно делать и после презентации.
  • Заказчик получит продукт, который купят. Потому что постоянно есть обратная связь и та самая гибкость в работе.
  • Скрам можно использовать даже в небольших стартапах.

Минусы методики Scrum

  • Сложно собрать команду профессионалов. Да еще так, чтобы им было комфортно работать и общаться друг с другом.
  • Людей нужно обучить работе со скрам. А это время и деньги.
  • Сложно избежать ошибок в планировании. Особенно на старте. Времени на задачи закладывают то слишком много, то слишком мало.
  • Жесткое следование церемониям. Проект разбивается на части, которые делают в несколько спринтов. Со всеми митингами, ревью и ретроспективами.
Получите единый доступ ко всем нашим 21 курсам, 8 тренингам, 4 профессиям и 126 воркшопам — с сертификацией