Фреймворк scrum что это

Обновлено: 06.07.2024

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

Откуда возник Scrum

В 1986 году в статье для Harvard Business Review японские учёные Икуджиро Нонака и Хиротака Такеучи рассказали, что проекты с небольшими командами из разнопрофильных специалистов систематически приносят лучшие результаты. Они назвали это «подходом регби». В 1991 году в книге «Нечестивые проблемы, праведные решения» подход впервые называют регбийным термином «scrum».

В чём идея Scrum

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

Согласно Scrum, над проектом должна работать небольшая команда от 3 до 9 человек (если у тебя команда больше, придётся её разбить на несколько небольших). Команда работает непрерывно, короткими итерациями (спринтами) продолжительностью 1–4 недели. В конце каждого спринта команда должна создать что-то ценное для заказчика. То есть работа не просто разбивается на итерации. Каждая итерация должна иметь смысл и приносить пользу.

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

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

Итак, над проектом работает так называемая scrum-команда. Она состоит из разработчиков (а также маркетологов, дизайнеров и любых других специалистов, которые нужны в проекте) и людей, которые берут на себя особые роли: владельца продукта (Product Owner) и scrum-мастера.

Владелец продукта отвечает за общий список задач (бэклог продукта) и согласованность работы команды, взаимодействует с заказчиком и определяет требования. И хотя команда может высказывать своё мнение по тем или иным вопросам, именно владелец продукта принимает все решения, определяет приоритетность задач, даёт советы и т. д. Владелец продукта всегда один, чтобы не возникал хаос из-за противоречащих друг другу указаний.

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

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

Артефакты

Ещё в Scrum есть три сущности, называемые артефактами:

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

События

В основе Scrum лежат спринты, но с ними связано ещё несколько важных событий, без которых Scrum не Scrum.

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

Затем, когда понятен общий пул задач, команда собирается со scrum-мастером и планирует спринт — ставит цели и решает, какие задачи из бэклога помогут их достичь.

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

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

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

Плюсы Scrum

Управление проектом по Scrum со всеми этими ежедневными стендапами со стороны выглядит, как тотальный контроль, но у методики есть и свои плюсы:

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

Минусы Scrum

Правда минусов тоже немало. Кроме проблем с тщательным следованием всем ритуалам (создание бэклога, митинги и т. д.), есть ещё:

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

Кому подходит Scrum

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

Создайте рассылку в конструкторе за 15 минут. Отправляйте до 1500 писем в месяц бесплатно.

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

Scrum как часть agile

Scrum (скрам) относят к agile-подходам. Такие подходы часто называют фреймворками. Их суть состоит в использовании набора инструментов для ускоренной разработки. Проще говоря, фреймворк — это каркас, состоящий из множества типовых шаблонов (библиотек), которые можно дорабатывать. При создании продукта по принципам scrum разработчик не тратит время на создание элементарных вещей и может сосредоточиться на уникальных задачах.

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

Agile (аджайл) — это группа «гибких» методологий для разработки программного обеспечения. Суть agile описана в Agile-манифесте , в котором на первое место выходят взаимодействие, работающий продукт, сотрудничество с заказчиком и готовность к изменениям.

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

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

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

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

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

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

Как методология управления проектами, scrum предполагает, что самоорганизованная команда представляет законченный продукт в фиксированный временной отрезок (спринт). Для успешного применения scrum, необходимо разобраться в его структуре. Она включает правила, роли, события и артефакты.

Главное правило: scrum строится по принципу «3-5-3»: 3 роли, 5 событий, 3 артефакта. Если хоть один из этих элементов отсутствует, то технологию нельзя назвать scrum.

Роли scrum

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

Владелец продукта

Он ответственен за общий список задач (бэклог продукта). Владелец продукта scrum (scrum Product Owner) обязан определить приоритетность задач.

Остальные члены команды высказывают своё мнение. Но именно владелец продукта устанавливает ценность конкретной задачи и принимает решение, которое способны реализовать разработчики.

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

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

Команда разработчиков

Команда scrum отвечает за исполнение работ из бэклога спринта. Без согласия скрам-команды никто абсолютно не вправе заносить поправки в бэклог.

Правильная команда в scrum самостоятельно определяет, как именно работать, какие конкретные работы проводить в пределах спринта, как повысить ценность. Любой из участников располагает собственными навыками, при этом все друг друга обучают и делятся рабочими нюансами. Это позволяет не нарушить процесс из-за чьей-то ошибки или несостоятельности.

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

Scrum-мастер

Отвечает за соблюдение командой правил и структуры работы. Он обучает остальных участников нюансам scrum-процесса и изыскивает возможность оптимизации работы. Всё общение разработчиков с людьми извне происходит через scrum -мастера.

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

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

События scrum

Основой scrum выступают спринты — чёткий ритм работы команды. Продолжительность спринта варьируется — как правило, от одной до четырёх недель. Любые scrum-события связаны со спринтом.

Организация бэклога

За данное событие в скрам отвечает владелец продукта. Он следит, чтобы продукт соответствовал требованиям, отслеживает рыночную ситуацию, уточняет потребности заказчика.

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

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

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

Планирование спринта

Команда разработчиков совместно со scrum-мастером планирует на общем собрании объём работ для предстоящего спринта и устанавливает цели.

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

Ежедневное совещание (стендап)

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

Обычно участники стендапа рассказывают:

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

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

Обзор итогов спринта

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

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

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

Это scrum-мероприятие предназначено для обзора завершённых этапов. Команда записывает результаты, обсуждает нюансы спринта и сопутствующих процессов.

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

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

Посмотрим, как будут выглядеть мероприятия у нашей бригады строителей, которая работает по scrum:

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

Далее бригада переходит к осуществлению следующего этапа работ (последующий спринт) и порядок мероприятий повторяется. И так до полного завершения строительства и передачи готового дома заказчику.

Артефакты scrum

Артефакты scrum — это работы, которые надлежит сделать для завершения спринта. Они обеспечивают прозрачность проекта для всех участников.

Бэклог продукта

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

Владелец продукта всё время работает над бэклогом, пересматривает приоритеты и перепроверяет актуальность. Если этого не делать, то из-за рыночных изменений либо новой информации некоторые задачи могут стать неактуальными.

Бэклог спринта

В состав этого скрам-артефакта включены рабочие задачи, реализуемые в рамках спринта.

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

Инкремент

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

Ну и снова наша scrum-бригада строителей. Разберём, как будут выглядеть артефакты в данном случае:

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

Как применять scrum удалённым командам

Если продукт разрабатывает удалённая команда, то ведение проекта по scrum можно организовать в специальных сервисах. Например, Scrum-доска Jira от Atlassian позволяет объединить все данные по проекту.

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

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

Область применения scrum

Изначально scrum был разработан для сферы разработки программного обеспечения. Но постепенно фреймворк распространился и на другие области. Например, скрам используют в исследованиях, бизнесе, образовании, маркетинге. С начала 90-х гг. scrum активно применяют для таких целей, как:

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

Например, scrum можно применять для создания email-рассылки. Команда разработчиков будет включать маркетолога, копирайтера, редактора, дизайнера, верстальщика. Владельцем продукта может выступить email-маркетолог. При наличии необходимых знаний редактор может представлять scrum-мастера. Процесс создания рассылки можно поделить на несколько этапов (спринтов). Например:

Создание и запуск рассылки.
Доработка писем с учётом реакции аудитории.
Улучшение конверсии рассылки.

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

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

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

Правила Scrum

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

Компоненты Scrum

Бэклог, Sprint или итерация, Stand up, Sprint Review, ретроспектива в 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: искать и устранять потери. Тогда была озвучена идея спринтов — коротких итераций, на которые делится работа.

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

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

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

Коротко говоря, Scrum — это способ организации рабочего процесса. Он пришел из мира разработки программного обеспечения и сейчас применяется в разных сферах бизнеса. Метод изобрели программисты Кен Швабер и Джефф Сазерленд. Они наблюдали за тем, как работают американские военные и спецназ и пришли к выводу, что основа успеха состоит в качественной командной работе. Сам же термин пришел из регби и в переводе с английского означает «схватка».

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

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

Состав scrum-команды

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

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

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

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

Третий элемент команды — scrum-мастер. Он выступает в роли куратора и помогает коллективу сплотиться. Мастер проводит ежедневные собрания, помогает найти выход из тупикового этапа разработки и перевести команду на нужное направление. Главный успех scrum-мастера — сделать так, чтобы команда стала самоуправляемой и перестала в нем нуждаться. В идеале должны остаться только разработчики и владелец продукта.

Основные принципы работы по Scrum

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

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

Чем Scrum отличается от Kanban

Метод управления проектами Kanban также принадлежит семейству Agile. Но Scrum — это структурированный подход с четко прописанными этапами создания продукта, а Kanban — сбалансированный. Его главная задача — сделать так, чтобы у всех членов команды было одинаковое количество работы. В Kanban не должно быть переработок части команды и ситуаций, когда некоторые сотрудники осталась без задач и не знают чем себя занять.

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

Преимущества Scrum

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

Вице-президент «Ренессанс страхование» Владимир Тарасов рассказал РБК Трендам, к каким результатам пришла компания после применения метода:

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

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

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

Недостатки Scrum

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

Владимир Тарасов:

«Scrum не подходит для текущей операционной деятельности. Он больше ориентирован на проекты. У нас не классический Scrum. Мы объединили текущую работу по конкретным страховым случаям с проектами и задачами на улучшение процесса, разработку и испытание новых инструментов. Scrum не дает ответа, как сочетать операционную работу с проектами. Мы придумали свои собственные инструменты сочетания несочетаемого. Сам фреймворк это допускает».

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

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

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

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

Как внедрить Scrum для управления бизнес-процессами

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

Как внедрить Scrum в компанию

Подробную инструкцию по внедрению Scrum и о его процессах можно посмотреть в гайде или в книге от соавтора методологии Джеффа Сазерленда «Scrum: революционный метод управления проектами». О том, как правильно распоряжаться ресурсами и повышать личную эффективность, читайте в материале РБК Трендов про бережливое производство в жизни.

Читайте также: